JA/translation/Base/New features in 3 1
このページは、http://wiki.services.openoffice.org/wiki/Base/New_features_in_3_1の日本語訳です。
翻訳：飯高敏和、査読：久保田貴也
Ooo 3.1におけるデータベースの新機能
dba openoffice orgのメーリングリストと参照された仕様書に載っている機能から、編集しました。
Base全般
データベースドキュメントのマクロ
Database documents (.odb) now allow to embed macros and scripts, in exactly the same way the other OOo document types already allow.
データベースドキュメント（.odb）は現在、他の種類のOOoドキュメントが既にそうしているのと全く同じやり方で、マクロとスクリプトを埋め込んでいます。
Up to now, macros can be embedded into sub documents of a database document, that is, into forms and reports (which technically are Text documents), it will change to one place, database document.
これまでのところでは、マクロはデータベースドキュメントの複数のサブドキュメントに埋め込むことができます。つまり、フォームとレポート（技術的なことを述べると、これらはテキスト形式の複数のドキュメントです）に埋め込むことができます。しかしそれは、データベースドキュメント一箇所に変わることになります。
これが意味するのは、マクロが全てフォームからデータベースの主要部分に移動したということであり、フォームドキュメントの要素へのマクロの割り当てが、フォームドキュメントのマクロではなく、データベースドキュメントのマクロつきで可能になることなのです。ドキュメントそのものからも、フォーム、レポート、テーブルデザイン、クエリーデザイン、リレーションデザイン、テーブルデータビューなどのドキュメントの任意のサブコンポーネントからも、マクロを実行することができます。任意のサブコンポーネントのツールバーやメニューのなかにマクロをカスタマイズすることができます。マクロをフォームかレポートに記録するとき、マクロの格納先をたずねる最終ダイアログは、データベースドキュメントをのぞき、もはやフォームやレポートはリストに表示しません。
マイグレーション
OpenOffice.org 3.1より前のバージョンで作成されたデータベースドキュメントは、マクロやスクリプトの 埋め込まれたフォームやレポートを含んでいるかもしれません。これが禁じられているために、マイグレーション手続きが不可欠になっています。
全てのマクロとスクリプトがデータベース・ドキュメントの中にあるようにするために、ドキュメントを改変するのが目標なのですが、これを自動的にすることはできません。
互換性警告
ユーザーがサブドキュメントの中にマクロかスクリプト (もしくは両方) を含んでいる「古い」ドキュメントを単純に開いてしまうと、最初にそのファイルを開いた際に互換性警告ボックスがでる他はなにもありません。ユーザーがマクロを マイグレーションするまでは、データベースドキュメントと全てのサブドキュメントは、あたかもこの仕様書が問題にしている機能を実装していないかのように動作するでしょう。特に、フォームやレポートの既存マクロを変更したり、またはあらたに追加したり、サブドキュメントのマクロをツールバーやメニューにカスタマイズしたり、サブドキュメントのなかでこれらのマクロをイベントとバインドしたり、などなど自由にできてしまいます。
マイグレーション ウィザード
新しいメニューの項目を導入し、名前を「マクロのマイグレーション・・・」とし、最上位のメニュー「ツール」の既存の項目である「SQL・・・」のすぐ下におきます。
ユーザーがこのメニューの項目を選択すると、ウィザードがマイグレーションを通じてユーザーをガイドすることになり、それは効率的に次のような四つの段階からなっています。
- データベースドキュメントの全てのサブコンポーネント、つまりフォームとレポート、そして開いているどのデザイナーも閉じられます。
- データベースドキュメントがバックアップされます。
- 進捗状況バーが表示されている間は、スクリプトとマクロがマイグレーションされます。
- 概要が表示されます。
機能の詳細にわたる説明については、次の仕様書を読むことが推奨されています。
http://wiki.services.openoffice.org/wiki/Macros_in_Database_Documents
フォームやレポートのドキュメントへのプログラムからのより簡単なアクセス
データベースのドキュメントに含まれているフォームやレポートへのプログラムからのアクセスは、これまでになく簡単になっています。つまり、
ThisDatabaseDocument.FormComponents.getByName( "フォーム名" ).open
は、ドキュメントのUIのフォームをダブルクリックするのと全く同じ仕方で、「フォーム名」というフォームを開くことになります。すなわち、ドキュメントのUIに結びつくプログラムが、適切かつ完全にできるのです。
ドライバーごとのクラスパスを事前に明示するための新たな構成設定
org.openoffice.Office.DataAccess構成モジュールには新たな設定があります。それにより、ドライバーごとをベースに、JDBCドライバーを探す際に用いるクラスパスを明示することができます。
共有されたOOoインストールの管理者は、インストールの事前構成のためのこの設定を用いることができ、それによりユーザーは、各々の.JARファイルを、各自のJAVAオプションに加える必要がなくなります。
新たな構成のノードの完全パスは、
/org.openoffice.Office.DataAccess/JDBC/DriverClassPaths
となります。
典型的な構成を断片的に抜き出すと、以下のようになります。
<node oor:name="JDBC">
<node oor:name="DriverClassPaths">
<node oor:name="com.mysql.jdbc.Driver" oor:op="replace">
<prop oor:name="Path">
<value>url_to_jar_file</value>
</prop>
</node>
</node>
</node>
データベース構造が変更されれば、リレーションデザインに通知されます
新しいテーブルが追加される際、そして新しい行が追加される際にもまた、目下のところではリレーションデザインが検出するようになっています。「テーブル追加」ダイアログもまた、新しいテーブルが追加された場合には、通知されます。
リレーションデザインは現在、自己参照のテーブルリレーションをサポートしています
リレーションデザインは現在、参照しているテーブルが同時にまた参照されているテーブルであることができるようにするリレーションの作成をサポートしています。
テーブル
ファイルベースのデータベースのための相対パス
現在は、ファイルベースのデータベース（dBaseや表計算ドキュメントのような）を作成する場合には、ファイルのURL（「データURL」と呼ぶことにしましょう）は完全な仕方、つまり「[../../../foo/bar file:///c:/foo/bar]」というような形で、保管されます。
結果として、データベースドキュメント（.odbファイル）を、下地になっているデータと一緒に、他のマシーンに移す場合には、この移植先のマシーンにファイル構造を複製するか、データベースのための設定を調整する必要がでてきます。
現在では、「ツール->オプション->読み込み/保存」ダイアログの「ファイルシステムに関連したURLを保存」オプションをチェックすれば、パスを相対パスで保存することができるようになっています。
Hsqldb向けには、主キーを別様に取り扱うテーブルデザインになっています
これは、hsqldbのためだけのものです。
Auto increment属性の列が追加されると、この列には自動的に、テーブルの主キー属性がつきます。その後で主キーフラグを取り除くと、auto incrementフラグも取り除かれることになります。
Hsqldb はひとつの auto increment属性の列をサポートしているだけで、しかもその列は単独の主キー属性の列でなければなりません。
PS:Auto increment属性の列が用いられている場合に、主キーが一つより多くの列からなっているということは、hsqldbではありえません。
編集のために開かれたビューは、自動的に「SQLを直接実行」モードにされます
ビューを構成するSQLコマンドを編集するためのビューテーブル（現在のところでは、埋め込まれたHSQLDBだけのためにサポートにされた機能です）を開けば、クエリーエディターは自動的に「SQLを直接実行」モードにされます。
クエリー
関数の引数リストにおいて認識されるパラメーター
OOoのパーサーは、関数の引数リストにおけるパラメーターを認識することができます。それはつまり、いまやSELECT CONCAT( :C, "name" ) FROM "name"のようなクエリーが、実行されたならば、パラメーターの値の入力をユーザーに求めるダイアログを、適切に表示することになるということです。
クエリーデザイン：SQLシンタクスが広がりました
SQLパーサーは今では、TRIMコマンドを正しく認識するようになっています。
TRIM( FROM <COLUMN_NAME> )
が今では、
TRIM( BOTH FROM <COLUMN_NAME> )
の省略された形式としてサポートされています。
これらの関数は、文字列の冒頭と末尾の空白を取り除きます。
SQLシンタクスハイライト
Base向の「SQLビュー」にも、「ツール-SQL…」と同様、SQLシンタクスハイライトのサポートが追加されました。
「SQLビュー」に使用されるフォントでは、HTMLとBASIC IDEと同じ設定であることが重視されることになります。そして、使用される色の全てを設定することができます。
仕様書は以下になります：
http://wiki.services.openoffice.org/wiki/SQL_Syntax_Highlighting
フォーム
フォームコントロール：新しい属性：テキストの向き
フォームコントロールは全て、新しい属性である「テキストの向き」をサポートしています。これは、コントロールのテキストの向きをうまく制御してくれます。アラビア語やヘブライ語やヒンディー語のような、右から左へと向かうテキストを使う人々の言語では、左から右へのレイアウトの操作フォームを使う必要があるとなると、フォームの見た目が変になってしまいます。
CTLサポートが、言語設定において有効にされたならば、「ラベルフィールド」の下の一般タブの属性に、新しい属性が見つかります。
詳細については、次の仕様書を見てください。
http://specs.openoffice.org/g11n/Right-to-left_control_forms/R2L-enabled_control_forms.sxw
フォームコントロール：新しい属性「入力必須」
データベースの列に接続することができる（つまり、「データフィールド」属性を持つ）フォームコントロールは今では全て、「入力必須」と呼ばれる新たな属性を持っています。新しい属性は、プロパティー、データタブ上の「空の文字列はNULL」の下にあります。
この属性は、はそのフィールドの入力が空 (NULL) とならないようにチェックするかどうか制御します。(フォームの現在のレコードがデータベースに書き込まれる直前に、必須なものとして定義されている（つまり、特別な値であるNULL値を含むことができない）データベースのフィールドに関連するコントロールのために、この属性は評価されます。
もし属性が「はい」に設定されていて、現在のレコードがデータベースに書き込まれる際にフィールドに入力がない場合には、ユーザーにエラーメッセージが表示されることになります。それぞれのコントロールは、その後でフォーカスされることになります。属性は「はい」がデフォルトになっていて、新たに作成されたコントロールは、以前のOOoのバージョンと同じように動作するということが、今のところ知られていることに注意してください。
もし属性が「いいえ」に設定されていて、現在のレコードがデータベースに書き込まれる際にフィールドに入力がない場合には、これは無視されます。更新を拒絶するのか、サーバーサイドのデフォルトの値で各々の列を埋めるのかは、下地になっているデータベースによります。
データベースドキュメントの拡張設定（編集/データベース/拡張設定）における「必須フィールドのためのフォームデータ入力チェック」がチェックされていない場合には、このデータベースドキュメントのフォームの全てで、いかなるコントロールに向けた「入力必須」属性も、ドキュメント全体をカバーする設定がコントロールごとの設定を無効にするので、何ら効果を持ちません。
もし「データフィールド」が設定されていなければ（空であれば）、それはとにかく関連するコントロールのためだけに評価されるので、「入力必須」は無効にされます。
もし「空の文字列はNULL」が「いいえ」に設定されていれば、「入力必須」もまた無効にされます。なぜなら、「空の文字列はNULL」が「いいえ」に設定されているということは、ユーザーがコントロールに何も値を入力しない場合には、専用の値であるNULLの代わりに空の文字列が書き込まれ、ユーザーがどんなことをしようが、NULLでない値が書き込まれるからです。
「空の文字列はNULL」の動作が改良されました
「空の文字列はNULL」属性が「はい」に設定してあるフォームコントロールの動作は改良されました。この変更は、既存のフォームに、以前とは少し異なる動作をさせるかもしれません。ですが今では、もっと直観にかなったものになっています。
第一に、それぞれのコントロールに触れずにレコードを保存する場合に、その属性が今はまた重要になってきます。それはつまり、この属性が「はい」に設定されているコントロールを考えてみると、このような宣言は、コントロールが空の文字列を含んでいれば、これがデータベースには（特別な値である）NULL値として伝えられるということを宣言していることになります。
ところが以前は、フォームの行挿入に移行すると、コントロールの初期値は空ですが、現在のレコードの他のコントロールにデータを入力し、もとのコントロールに実際には触れずにデータを保存すると、実際には空の文字列に更新していたのです。ですが今では、変更に伴って、NULLに更新しています。「空の文字列はNULL」＝「はい」が求めている動作とは、これなのです。
第二に、コントロールがNOT NULLとして宣言されているデータベースの列と関連している場合には、コントロールは常に、「空の文字列はNULL」が何を要求していようが、NULLの代わりに空の文字列に更新していました。事実上、これはデータベースのフィールドのサーバー側のデフォルトを無効にしてしまっていました。というのは、フィールドがNULLである場合にのみ、そのようなデフォルトが適用されるからです。今では、変更に伴って、コントロールはそのような設定ではNULLに更新するようになっています。このようにして、サーバー側のデフォルトが有効になります。
チェックボックス：修正された属性
グリッドコントロールにおけるチェックボックス列は今では、「トライステート」属性を持っています。この属性は、通常のチェックボックスフォームコントロールから分かるように、チェックボックスが「未決定」の状態であることを許すかどうかを制御します。
イメージコントロール：比率を保持しつつのイメージの倍率変更
ドキュメントのイメージフォームコントロールには、表示するイメージの倍率を変えるためのモードが追加されました。
以前は、「スケール」属性を「はい」か「いいえ」に設定することでのみ、倍率を制御することができました。そこでは、「はい」というのは縦横で異なる倍率変更を意味しています。つまり、イメージの寸法を歪めてしまうことを意味しているのです。
現在では、「スケール」属性では、「いいえ」（以前と同じ機能）と「比率を保持」と「サイズに合わせる」（昔の「はい」と同じ）が許容されています。「比率を保持」が選択されると、イメージはなおもコントロールの寸法にマッチするように拡大もしくは縮小されますが、その比率は一定に保たれた概観になっています。
ドキュメントのデザイナーがドキュメントやコントロールをデザインする時点では、表示されるイメージの大きさが分からないコントロールに対して特に有用です。。特にこれは、データベースから得られたイメージを表示するデータベースにおけるイメージコントロールに対して有用です。
イメージコントロール：ドキュメントに埋め込まれたイメージのサポート
イメージコントロールを今では、コントロールが置いてあるドキュメントに埋め込まれたイメージに関連付けることができます。
もっと正確に述べると、イメージコントロールに表示されるイメージを選択すると、ファイルピッカーにおける「リンク」オプションは、もはや無効にはなっていません。
オプションのチェックをはずせば（従来のバージョンをまねて、デフォルトではチェックが入っています）、イメージがコントロールに表示され、ドキュメントを保存するに際しては、イメージはドキュメントそのものに埋め込まれます。
このようにして、他の人や他のインストールや他のプラットフォームと交換できるイメージコントロールをそなえたドキュメントを作成することができるのです。こういうことは以前は、イメージをコピーしたり、そのイメージをもとのマシーンとまったく同じように配置したりする (これはあきらかに無理なときがしばしばある)必要があるため、はるかに困難でした。
イメージコントロール：テキスト型のデータベースの列と関連付け、そのコンテンツをイメージへの相対リンクとして解釈することができます
データベースフォームのイメージコントロールを、テキスト型の列に関連付けることができます。以前は、イメージコントロールと関連付けることができるのは、バイナリーと合理的に解釈できる（BLOB型など）コンテンツを有する列だけでした。今では、テキスト型のデータベースの列をイメージコントロールのソースとして選択すると、それぞれの列のコンテンツはURLとして解釈され、このURLによって指し示されているイメージを読み込んで表示します。また、イメージコントロールの埋め込まれているドキュメントに相対的なURLも許可されています。
ナビゲーションツールバー：新しいアイテム「コントロールを更新」
フォームのナビゲーションツールバー（これはデータベースから得られたデータで埋められた活動中のフォームを持つとすぐに使われるものです）には、「コントロールを更新」と呼ばれ、「更新」アイテムのすぐ後に位置する新しいアイテムがあります。
この新しいアイテムが有効になるのは、唯一リストかコンボボックスコントロールにフォーカスがある場合のみです。押されると、コントロールのアイテムリストは更新されます。
フォームの外部のあるインスタンスが、テーブル/クエリーのデータを変更すると、データベースのテーブル（もしくはクエリー）のコンテンツに基づいたリストにとっては、これは特に面白いものになります。この場合には、「コントロールを更新」の機能を使うことで、これらの変更をコントロールのアイテムリストに反映させることができます。
レポート
Sun Report Builderに向けた新たなショートカット
編集メニューは現在、「全て選択」項目を含んでいます。
これが含んでいるのは、
編集->全て選択->全て選択(CTRL+A)
ラベルを全て選択
フォーマットされたフィールドを全て選択
全てのレポートを選択
です。
新たなレポートを開く際に、自動的に最初のテーブルと関連付けます
データベースに新たなレポートを作成するに際しては、データベースから最初のテーブルをとってきてレポートと関連付けることになります。加えて、フィールド追加ダイアログは、全ての利用可能なフィールドをともなって開くことになります。
レポート出力フォーマットもまた現在、プロパティブラウザで利用可能です
プロパティブラウザは現在では、SRBにおいて選択される際には、フィルターの下の最後の項目である、データページ上のレポート向けに選択された出力フォーマットを表示します。
現在のところ利用可能なフォーマットは以下になります。
-ODFテキストドキュメント
-ODFスプレッドシート
フィールド追加ダイアログは、ソーティングと挿入のツールバーをサポートしています
フィールド追加ダイアログには現在、フィールド向けのリストボックスの上にツールバーがあります。ツールバーを使うことで、ソート順序を削除したり、ソース（テーブル、クエリー）から取り出した元の順序を修復したりできるのと同様に、フィールドを昇順にソートしたり降順にソートしたりすることができます。追加されたツールバーは、「挿入」の項目を含んでいて、この項目によって、レポートセクションに選択されたフィールドを挿入することができます。フィールドの複数選択もまた、サポートされています。
SRB内部からの関数ウィザード
スプレッドシートで使用される関数を現在、Sun Report Builderの内部で使うことができます。
-データフィールド（フォーマットされたフィールドとイメージコントロール）
-一般タブ上の条件付で出力を行う式
-数式
-初期値
からウィザードを開始することができます。
ウィザードは、レポートエンジンによりサポートされている全ての関数を表示します。
SRC向けのドキュメントは、以下で見つかります。
http://wiki.services.openoffice.org/wiki/SUN_Report_Builder/Documentation
関数の説明は、以下で見つかります。
http://wiki.services.openoffice.org/wiki/Base/Reports/Functions
