3 Simple Steps to Build Your Data Model in Mendix
【本ブログは翻訳です。元ブログはこちらです】
この投稿では、Mendixドメインモデルの各主要コンポーネントと、それらがアプリケーションの作成にどのように貢献するかについて説明します。 この投稿全体でテストケースを使用します:製品注文アプリケーション。 顧客は、それぞれが製品に接続されている複数の注文ラインを持つ注文を行うことができる必要があります。
さあ、始めましょう!
データモデルとは何ですか?
多くのソフトウェアアプリケーションの基盤は、多くの場合、そのデータモデルです。 データモデルは、アプリケーション内で使用および操作されるデータを定義します。 このデータは、一時的にメモリに保存されるか、データベースなどのデータストアに永続的に保存されます。
Mendixのデータモデルは、ドメインモデルと呼ばれる視覚言語を使用して構築されています。 ドメインモデル内で、次のコンポーネントを定義できます。
- Entities:これらは永続化または非永続化でき、データを一時的または永続的に保存できます。 永続化されたエンティティは、一意の主キー(つまり、ロケーションエンティティまたは金融トランザクションエンティティ)が付属するデータベーステーブルに相当します。
- Attributes:これらはデータベーステーブルの列のようなものです(つまり、場所の名前と住所、または金融取引の日付と種類)。
- Associations:これらは、2つのデータベーステーブル間の結合など、2つのエンティティ間の関係を定義します。
Mendixアプリケーションが実行されると、ランタイムはモデルを選択されたデータベースと比較し、必要なすべての更新スクリプトを実行します。 Mendixは、次のようなさまざまなデータベースタイプをサポートしています。
- PostgreSQL
- Microsoft SQL Server
- MySQL
- Oracle
- HANA DB
選ぶのはあなたです!
1. Entitiesを定義する
新しいプロジェクトを開始するときはいつでも、最初に定義する必要があるのはデータ構造です。 アプリケーションを構築するために作成する必要のあるエンティティについて考える必要があります。 この例では、顧客が複数の異なる製品を注文できるようにするアプリケーションを作成します。
このアプリケーションのドメインモデルでは、顧客、注文、注文明細の永続化エンティティが必要です。 これにより、顧客がどの製品に対してどのような注文をしたかを追跡できます。 永続化された各エンティティは、一意のキーを持つデータベース内のテーブルになります。 次の図は、4つのエンティティを示しています。
2. Attributesの追加
エンティティを作成したら、各エンティティに詳細を追加する必要があります。ここで、属性が機能します。 この例では、顧客は名前、またはVIPや一般などのアカウントタイプを持っている可能性があります。 製品には名前または説明がある場合があります。
エンティティに記入すると、アプリケーションの詳細が実を結びます。 戻って必要な他の属性を追加するのは非常に簡単です。 次の図は、4つのエンティティ内でAttributesがどのようにリストされているかを示しています。
名前と自動生成された注文番号、および注文日を追加しました。 属性はテーブル列と同等であり、文字列、整数、ブール値などの属性タイプとサイズ、およびアプリケーションの構築に必要なすべての一般的なデータ型があります。
3. Associationsの作成
エンティティとその属性を決定したら、それらがすべてどのように関連しているかを決定します。 この例では、顧客は複数の注文を行うことができ、注文は複数の注文ラインを持ち、各製品は複数回注文できます。 次の図は、エンティティ間の関係を表しています。
アソシエーションを通じて関係が視覚的にどのように表されているかに気付くでしょう。 アスタリスクで示されているように、顧客と注文の関係は1対多です。 この例をさらに一歩進めるために、関係間の動作を削除することもできます。
たとえば、顧客に注文がある場合、顧客に関連付けられているすべての注文を削除する必要がありますか(カスケード削除と呼ばれます)? または、顧客が注文を持っている場合、ユーザーが注文を削除できないようにする必要がありますか(防止削除と呼ばれます)?
関連付けをダブルクリックして、動作と削除オプションの構成方法を確認します。 削除動作は、ビジネスニーズに依存する必要があります。 次の質問を検討してください。顧客が注文したときに顧客を維持することは重要ですか。 または、データベースをクリーンアップし、顧客を削除するときに孤立した注文がないことがより重要ですか?
これらはビジネスユーザーに尋ねる良い質問であり、適切なビジネスルールを作成するのに役立ちます。 これの視覚的表現は、青(削除の防止用)または赤(カスケード削除の場合)のいずれかです。