FAQ
技術的な質問> データベース
技術的な質問> データベース
Q130：ツリーを現状のDB構造を示すだけならスキーマ関係は不要でもよいのでしょうか？
Q130-1：
以前のメールで、ツリーを表示するときに現在の状態を読み込ませる必要があるとの回答をいただいたのもあり、件名のサンプルがそれを実行していると思い移植しようとしたのですが、スキーマというのがWikiとかで見てもいまいち良くわかりません。
ツリーを現状のDB構造を示すだけならスキーマ関係は不要でもよいのでしょうか？
ツリー部分を移植しようとしてもデータベース接続フレーム複合コンポーネントの中身を結構使用していて、自分が今作っているものはローカルMySQL管理を含んだMySQL連携複合コンポーネントなので、かなり厄介な感じになりそうなのです。DB管理とツリー系を上手くまとめた複合コンポーネントとかできたりしないでしょうか。
ツリーを現状のDB構造を示すだけならスキーマ関係は不要でもよいのでしょうか？
ツリー部分を移植しようとしてもデータベース接続フレーム複合コンポーネントの中身を結構使用していて、自分が今作っているものはローカルMySQL管理を含んだMySQL連携複合コンポーネントなので、かなり厄介な感じになりそうなのです。DB管理とツリー系を上手くまとめた複合コンポーネントとかできたりしないでしょうか。
A130-1：
> 以前のメールで、ツリーを表示するときに現在の状態を読み込ませる必要があるとの回答をいただいたのもあり、件名のサンプルがそれを実行していると思い移植しようとしたのですが、スキーマというのがWikiとかで見てもいまいち良くわかりません。
ご指摘の通り、スキーマは分かりにくい考え方であり、また、データベースソフトウェアごとに扱いが異なっていることもあって、それがより理解を難しくしている面も否めません。
非常に大雑把に言いますと、スキーマとは、1つのデータベースに含まれている複数のテーブルをグループ化するためのものであるとお考えになって差し支えないかと存じます。
仮に、現在のデータベースに、T1、T2、T3、T4という4つのテーブルが存在するとします。データベースの利用者としてAさんとBさんの2人がいるとして、以下のような利用形態であるとします。
(a) AさんはT1、T2、T3しか使うことがなく、BさんはT1、T3、T4しか使わない。
(b) AさんにはT4を見せたくない。
(c) BさんにはT2を見せたくない。
このような場合に、以下のような2つのスキーマSa、Sbを作成し、AさんにはSa、BさんにはSbへのアクセス権を与えるといったような使い方をします。
スキーマSaに属するテーブル: T1、T2、T3
スキーマSbに属するテーブル: T1、T3、T4
このように、スキーマは利用者に対するアクセス権限付与を管理するために用いることが多いようです。ただ、実際の仕組みはデータベースソフトウェアごとに異なっており、ユーザ名がそのままスキーマになるというデータベースもあります。
> ツリーを現状のDB構造を示すだけならスキーマ関係は不要でもよいのでしょうか？
MySQLには元々スキーマという概念がなかったので、MySQLをお使いになるのであれば、スキーマは無視してもよろしいかと存じます。
> ツリー部分を移植しようとしてもデータベース接続フレーム複合コンポーネントの中身を結構使用してて、自分が今作っているものはローカルMySQL管理を含んだMySQL連携複合コンポーネントなので、かなり厄介な感じになりそうなんです。。
> DB管理とツリー系を上手くまとめた複合コンポーネントとかできたりしないでしょうか…
データベース構造のツリー表示機能を、必要以上に難しいものとお考えになっているように思われます。
スキーマを考えない場合、ツリー表示で行っていることは以下の通りです。
(1) データベースアクセスコンポーネントの「getDatabaseTree()」メソッドでツリーデータを取得
(2) (1)で取得したツリーデータを引数として、ツリーコンポーネントの「ツリーデータを設定する(PFObjectTree)」メソッドを実行
付属のサンプル"データベースアクセス0.mzax"にこの機能を追加したサンプル"データベースアクセス0_ツリー付.mzax"を用意しましたので、どうぞご覧ください。データベースに接続後、[データベースツリー設定]ボタンをクリックすると、接続先データベースの構造がツリー表示されます。
以前にお送りいただいたアプリケーションの場合、データベースアクセスコンポーネントがローカルMySQL管理複合コンポーネント内にありますので、「getDatabaseTree()」メソッドを最上位階層まで公開し、そのメソッド戻り値を引数として、DB一覧複合コンポーネントの公開メソッド「ツリーデータを設定する(PFObjectTree)」を実行することになります。
MySQL連携複合コンポーネントはデータベースへの接続・切断時にイベント番号0の処理完了イベントを発生しますので、その接続先でDB一覧複合コンポーネントの公開メソッド「ツリーデータを設定する(PFObjectTree)」を実行します。
補足ですが、データベースアクセスコンポーネントの「getDatabaseTree()」メソッドは、データベースに接続されていない時には[Database]というルートノードのみのツリーを返しますので、結果的には切断時にツリーがクリアされたような状態になります。
関連ファイル：データベースアクセス0_ツリー付.mzax
ご指摘の通り、スキーマは分かりにくい考え方であり、また、データベースソフトウェアごとに扱いが異なっていることもあって、それがより理解を難しくしている面も否めません。
非常に大雑把に言いますと、スキーマとは、1つのデータベースに含まれている複数のテーブルをグループ化するためのものであるとお考えになって差し支えないかと存じます。
仮に、現在のデータベースに、T1、T2、T3、T4という4つのテーブルが存在するとします。データベースの利用者としてAさんとBさんの2人がいるとして、以下のような利用形態であるとします。
(a) AさんはT1、T2、T3しか使うことがなく、BさんはT1、T3、T4しか使わない。
(b) AさんにはT4を見せたくない。
(c) BさんにはT2を見せたくない。
このような場合に、以下のような2つのスキーマSa、Sbを作成し、AさんにはSa、BさんにはSbへのアクセス権を与えるといったような使い方をします。
スキーマSaに属するテーブル: T1、T2、T3
スキーマSbに属するテーブル: T1、T3、T4
このように、スキーマは利用者に対するアクセス権限付与を管理するために用いることが多いようです。ただ、実際の仕組みはデータベースソフトウェアごとに異なっており、ユーザ名がそのままスキーマになるというデータベースもあります。
> ツリーを現状のDB構造を示すだけならスキーマ関係は不要でもよいのでしょうか？
MySQLには元々スキーマという概念がなかったので、MySQLをお使いになるのであれば、スキーマは無視してもよろしいかと存じます。
> ツリー部分を移植しようとしてもデータベース接続フレーム複合コンポーネントの中身を結構使用してて、自分が今作っているものはローカルMySQL管理を含んだMySQL連携複合コンポーネントなので、かなり厄介な感じになりそうなんです。。
> DB管理とツリー系を上手くまとめた複合コンポーネントとかできたりしないでしょうか…
データベース構造のツリー表示機能を、必要以上に難しいものとお考えになっているように思われます。
スキーマを考えない場合、ツリー表示で行っていることは以下の通りです。
(1) データベースアクセスコンポーネントの「getDatabaseTree()」メソッドでツリーデータを取得
(2) (1)で取得したツリーデータを引数として、ツリーコンポーネントの「ツリーデータを設定する(PFObjectTree)」メソッドを実行
付属のサンプル"データベースアクセス0.mzax"にこの機能を追加したサンプル"データベースアクセス0_ツリー付.mzax"を用意しましたので、どうぞご覧ください。データベースに接続後、[データベースツリー設定]ボタンをクリックすると、接続先データベースの構造がツリー表示されます。
以前にお送りいただいたアプリケーションの場合、データベースアクセスコンポーネントがローカルMySQL管理複合コンポーネント内にありますので、「getDatabaseTree()」メソッドを最上位階層まで公開し、そのメソッド戻り値を引数として、DB一覧複合コンポーネントの公開メソッド「ツリーデータを設定する(PFObjectTree)」を実行することになります。
MySQL連携複合コンポーネントはデータベースへの接続・切断時にイベント番号0の処理完了イベントを発生しますので、その接続先でDB一覧複合コンポーネントの公開メソッド「ツリーデータを設定する(PFObjectTree)」を実行します。
補足ですが、データベースアクセスコンポーネントの「getDatabaseTree()」メソッドは、データベースに接続されていない時には[Database]というルートノードのみのツリーを返しますので、結果的には切断時にツリーがクリアされたような状態になります。
関連ファイル：データベースアクセス0_ツリー付.mzax