XMLDB XML構造の定義 (Dev docs)

提供:MoodleDocs
移動先:案内検索

XMLDB ドキュメンテーション > ロードマップ > XML構造の定義


ジャスティフィケーション

Moodle は MySQL、MariaDB、Postgresql、OCI および MS SQL Server を含む、多数のデータベースエンジンをサポートしています。それぞれこれらはテーブル作成ステートメントに対して、若干異なるフォーマットを持っています。

XMLDB は人間が読めるフォーマットでデータベースの構造を記述するために、標準化されたフォーマットとして作成されました。 Moodle インストーラはこれを DDL コマンドに変換して、データベースの構造を作成することができます。

Moodle XMLDB エディタは、Moodle 内のすべてのテーブルに対して、XMLDB 構造を正しく定義するために使用する必要があります。また、XMLDB の構造をアップグレードスクリプトに変換し、Moodleの upgrade.php ファイルにコピー&ペーストすることも可能です。

XMLDBエディタ

主な記事

XMLは読む (書く) のはかなり簡単ですが、大きな欠点として、開発者が簡単に、しかも間違いなく採用できることがありました。また、バージョン管理システムがXMLファイルでおかしくなる問題 (MLに感謝!) から、XMLファイルには高密度なフォーマット (物理的に 長い行 という意味) を使用することが必要であると指摘されました。

いろいろと考えた結果、私たちは XML フォーマットに特化したエディタを作ることにしました。このエディタは使いやすく、1つの Moodle DB に存在するすべてのオブジェクトのサポートを提供する必要があります。そして、それは完成しました (そして、将来の拡張を簡単にサポートすることを、私たちは望んでいます) 。

XMLDB エディタは、テーブル/フィールド/キー/インデックスの追加を実質的に簡単な作業にし、開発者は XML ファイルや手動編集によるエラーと戦う代わりに、コーディングや改良に時間を使うことができます (もちろん、ビール、ダンス、本、音楽など、余った時間を自由に使うことができます) 。 ;-)

Moodleの各 db ディレクトリの下にある新しい install.xml ファイルは、クリックとキーストロークだけで編集することができます (私たちはこれを推奨します) 。 これらの install.xml には、サポートする各 RDBMS に必要な特定のオブジェクトを生成するために必要なすべての情報が含まれています。明らかに、このようなファイルは、これまで使われてきた *.sql ファイルを置き換えるものです。

起動

管理者としてサーバにログインし、管理ブロックの開発タブの下に、"XMLDB エディタ" を指す新しいリンクが表示されます。

1つの 重要な注意 は、ファイルを適切に処理するために、Webサーバは "install.xml" ファイルが存在するすべての "db" ディレクトリへの書き込み権限が必要だということです (もちろん、ファイル自体への書き込み権限も必要です) 。 ;-)

以上です!

使用方法

XMLDB エディタの使い方はとても簡単だと思いますので、ここでは完全な使い方のガイドは掲載しません。ぜひ、しばらく使ってみて、その動作や install.xml ファイルの変更方法を確認してみてください。

上下に分かれた構造で、新しいXMLDBファイルを ロード (または 作成) するところから始まります。そして、そのファイルを 編集 すると、その 大まかな構造 が表示されます。この構造は、テーブル という1種類の要素を持っており、 XMLDB エディタを使えば、簡単にテーブルの 追加編集削除移動 を行うことができます。 さらに、既存のテーブル (MySQL および Maria DB の場合) をXMLDB 構造にすることが可能で、DB から XMLDB エディタに任意のテーブルを後付けすることができます。

注: 作成リンクがクリックできない場合... まず、/db フォルダを作成し (リストにあるように、実際には存在しないかもしれません) 、ウェブサーバから書き込み可能であることを確認する必要があります

テーブルを編集している間、その フィールドキーインデックス を見ることができ、それらを簡単に扱うことができるようになります。なお、一部の項目は編集不可とすることができます。それは、何らかの方法で使用されている (あるキーやインデックスの一部) ためで、そのことを警告するためのものです。

フィールドは編集可能で、nametypelengthdecimalsnull-abilitydefaults 等を指定することができます。キーインデックス についても全く同じです。

XMLDB エディタのすべてのページで、変更する項目 (テーブル、インデックス、キー、フィールドなど) に関する コメント を1つ入力することができるのも興味深い点です。他の開発者が DB モデルをもう少し理解するのに役立つと思いますので、必要に応じてお使いください。

次のセクションでは、XMLDB ファイルを作成し、扱うための いくつかの重要なガイドライン について説明しますので、忘れずに読んで理解してください。

規約

データベースの構造に関するガイドライン とは別に、さらにいくつかの慣習を守る必要があります:

  1. 名前について:
    1. すべて小文字の名前 (テーブル、インデックス、キー、フィールド) 。
    2. テーブル名およびフィールド名には、a-z、0-9、_ のみを使用する必要があります。テーブル名は最大28文字まで、カラム名は最大30文字までです。
    3. XMLDB ファイルのキーとインデックス名は、キー/インデックスに存在するフィールド名を "-" (マイナス) 文字で連結して形成する必要があります。
    4. 主キーは常に "primary" という名前でなければなりません (これは以前の慣習の一つの例外です) 。
    5. 予約語を完全に避けることを強くお勧めします。現在、いくつかの予約語があることは知っていますが、次のリリースでは完全に排除されるはずです。
  2. NULLS について
    1. すべてのフィールドを 愚かな デフォルト値 '' (空文字列) で NOT NULL として作成することは避けてください。テーブルを作成するために使用される基本的なコードは、適切に処理されますが、XMLDB の構造は REAL である必要があります。詳しくは 問題のページをご覧ください。
  3. FOREIGN KEYS について
    1. XMLDB ファイルのテーブルの下に、既存の 外部キー (FK) を適切に定義する必要があります。これにより、誰もがその構造をもう少しよく知ることができ、将来、より制約の多いシステムに進化させることができます。また、適切なインデックスを作成するために必要な情報を、基本コードに提供することができます。
    2. もし、フィールドの組み合わせを FK として定義した場合、そのフィールドにインデックスを作成する必要はないことに注意してください。コードは自動的にそれを行います!
    3. 規約 1.3 を尊重してください。
  4. UNIQUE KEYS について
    1. フィールドを ユニークキー (UK) として宣言するのは、それらが1つの FK のターゲットとして使用される場合のみです。代わりにユニークインデックスを作成します。
    2. 規約 1.3 を尊重してください。

一例: 課題モジュール

ここでは、現在の課題モジュールの XMLDB スキーマの実装 (簡単なもの) を検証してみます。XMLDB エディタで完全に生成されていますが、XML の内部をもう少し知ることができるのは良いことです。

ご覧の通り、構造はいたってシンプルです:

  • XMLDB
    • テーブル (1つまたは複数) 、それぞれに
      • FIELDS
      • KEYS
      • INDEXES
      • SENTENCES

まず最初に、すべての要素が PREVIOUSNEXT 属性を含んでいることに注意してください。RDBMS の観点からは全く意味がないのですが、この属性によって全ての要素を順番に並べておくことができます。 また、COMMENT フィールドも随所に存在し、必要に応じて使用することができます。

TABLE 要素

TABLE 要素は、内部 (FIELDS, KEYS, INDEXES) のための単なる1つのコンテナなので、無視してもかまいません。もう少し検証して行きましょう:

FIELD 要素

DB の1つのフィールドにマッピングされます (当然ですが) 。各フィールドに対して、nametype (ニュートラルタイプ のリストから)、lengthdecimals (いくつかの型に対して) を定義することができます。notnull (true/false)、unsigned (true/false)、sequence (autonumeric または serial, true/false) および default (デフォルト値を割り当てる) が挙げられます。

つまり、この例では、assignment と assignment_submissions という2つのテーブルがあり、それぞれが独自のフィールドを持ち、上記に関連するすべての情報を定義しています。命名規則に従っていることに注意してください。

KEY 要素

ここで、すべての プライマリキー (PK)、ユニークキー (UK)、外部キー (FK) が定義されることになります。それぞれのキーについて、nametypefields (キーに属するもの) 、オプションとして (キーが FK の場合) 対象の reftablereffields を定義しています。

この例では、課題テーブルには、"id" フィールドで構築された1つの (必須!) PK ("プライマリ" と呼ばれる、規則は規則です) があります。

もう一つのテーブルである "assignment_submissions" は、その PK (もう一度 "プライマリ" と呼びます) と一つの FK を持ち、"assignment" フィールドが "assignment" テーブルの "id" フィールドを指しています。FK は名前の規則に従い、その名前は単純にその一部であるフィールドの名前である ("assignment") ことに注意してください。また、FK は、同じモジュールの1つの PK をターゲットとしています。

最後に、これらすべてのキーに対してインデックスが作成されていないことに注意してください。テーブルが作成されると、Moodleはそれらを自動的に生成します。すべてのキーは対応するインデックスを持つことになります。Point. ;-)

INDEX 要素

すべてのインデックスが定義される場所です。それぞれのインデックスについて、nameunique (true/false)、構成する fields (カンマ区切りの文字列) を定義することが可能です。命名規則に従っていることにご注意ください。

また、"assignment_submissions" テーブルの "assignment" フィールドに基づくような、いくつかの "明白なインデックス" が存在しません。 はい、理由はお分かりですね。このカラムは FK として定義されており、インデックスが自動的に作成されるからです (前のセクションを参照) 。

DTD および XML スキーマ

これが誰かの役に立つかどうかは分かりませんが、XMLDB ファイル用の 自動生成 DTD がここにあります。また、 自動生成 XML スキーマ も1つ用意されています。どんな改善/修正も大歓迎です!

関連項目