データ モデルとは何ですか?

多くのソフトウェア アプリケーションの基盤は、多くの場合、データ モデルです。データ モデルは、アプリケーション内でどのデータが使用され、やり取りされるかを定義します。このデータは、メモリに一時的に保存されるか、データベースなどのデータ ストアに永続的に保存されます。

データモデル Mendix ドメイン モデルと呼ばれるビジュアル言語を使用して構築されます。ドメイン モデル内では、次のコンポーネントを定義できます。

• エンティティ: これらは永続化または非永続化が可能で、データを一時的または永続的に保存できます。永続化されたエンティティは、一意の主キー (場所エンティティまたは金融取引エンティティなど) が付属するデータベース テーブルに相当します。
• Attributesこれらは、データベース テーブルの列のようなものです (つまり、場所の名前と住所、または金融取引の日付と種類)。
• 協会: これらは、2 つのデータベース テーブル間の結合のように、2 つのエンティティ間の関係を定義します。

時 Mendix アプリケーションが実行されると、ランタイムはモデルを選択したデータベースと比較し、必要な更新スクリプトをすべて実行します。 Mendix 以下を含むさまざまなデータベース タイプをサポートしています。

• PostgreSQL
• Microsoft SQL サーバー
• MySQL
• オラクル
• ハナDB

選択はあなた次第です！

1. エンティティを定義する

新しいプロジェクトを開始するときはいつでも、最初に定義する必要があるのはデータ構造です。アプリケーションを構築するために作成する必要があるエンティティについて考える必要があります。この例では、顧客がさまざまな製品を注文できるようにするアプリケーションを構築します。

このアプリケーションのドメイン モデルでは、顧客、注文、注文明細の永続エンティティが必要です。これにより、顧客がどの製品を注文したかを追跡できます。各永続エンティティは、一意のキーを持つデータベース内のテーブルになります。次の図は、4 つのエンティティを示しています。

2. 属性を追加する

エンティティを作成したら、各エンティティに詳細を追加する必要があります。ここで属性が役立ちます。この例では、顧客には名前やアカウントの種類 (VIP や一般など) があるかもしれません。製品には名前や説明があるかもしれません。
エンティティに入力していくと、アプリケーションの詳細が明らかになります。戻って必要な他の属性を追加するのは非常に簡単です。下の図は、4 つのエンティティ内で属性がどのようにリストされているかを示しています。

名前と自動生成された注文番号、および注文日を追加しました。属性はテーブル列に相当し、文字列、整数、ブール値などの属性タイプとサイズ、およびアプリケーションの構築に必要なすべての一般的なデータ型を持ちます。

3. 関連付けを作成する

エンティティとその属性を決定したら、それらがどのように関連しているかを決定します。この例では、顧客は複数の注文を持つことができ、注文は複数の注文明細を持つことができ、各製品は複数回注文できます。下の図は、エンティティ間の関係を表しています。

関連付けを通じて関係が視覚的に表現されていることがわかります。顧客と注文の関係は、アスタリスクで示されているように 1 対多です。この例をさらに進めると、関係間の動作を削除することもできます。

たとえば、顧客に注文がある場合、顧客に関連付けられているすべての注文を削除する必要がありますか (カスケード削除と呼ばれます)? または、顧客に注文がある場合、ユーザーが注文を削除できないようにする必要がありますか (防止削除と呼ばれます)?

関連付けをダブルクリックして、動作と削除オプションの構成方法を確認します。削除動作はビジネス ニーズによって異なります。次の質問を検討してください。注文があるときに顧客を維持することが重要ですか? それとも、顧客を削除するときにデータベースをクリーンアップして孤立した注文がないようにすることの方が重要ですか?

これらはビジネス ユーザーに尋ねるのに適した質問であり、適切なビジネス ルールを作成するのに役立ちます。これは、青 (防止削除) または赤 (カスケード削除) で視覚的に表現されます。

何ができるか見てみましょう Mendix