データ モデリング : データ構造を設計する

アプリでデータを保存、または表示する場合は、設計で重要となる部分はデータ構造です。 データが特定のアプリまたは画面でどのように使用されるかだけでなく、他のユーザーがどのようにデータを使用するかも考慮してください。 ペルソナ、タスク、ビジネス プロセス、目標を参考とすることで、格納するデータとその構造の定義付けに役立ちます。

ヒント

データベース設計の基本 : これは Access データベース向けに作成されたものではありますが、データ設計の基本に関するこの記事には、データ モデリングの原則についての汎用的な説明がされています。

以下の経費報告書を例に考えてみましょう。

経費精算書のメイン部分には、従業員名と部門の詳細が表示されています。 主要な部分の下部に、購入した各アイテムの説明が複数行にわたって表示されます。 これらを明細項目と呼びます。 明細項目は、経費報告書の主要部分とは異なる構造を持っています。 すべての経費報告書には、いくつかの明細項目が存在します。

このようなデータをデータベースに格納するには、データベース設計でデータ構造をモデル化する必要があります。

1対多 (1 : N) のデータ構造

これは、前述の例で説明したデータ構造のタイプです。 経費報告書の主要な部分は、いくつかの明細項目にリンクされています。 （明細項目の観点から関係を確認することもできます: 多くの明細項目から 1 つの経費報告書へ（N : 1））

多対多（N:N）のデータ構造

多対多のデータ構造は特別なタイプです。 これは、複数のレコードをその他レコードの複数のセットに関連付けることができる場合を指します。 分かりやすい例としては、ビジネス パートナーのネットワークがあります。 自分に複数の取引先（顧客や仕入先）があり、取引先も自分の同僚（複数）と取引しています。

データ モデリングの例

システムで発生する可能性のあるモデリングにはいくつかのタイプが存在します。 いくつかの例を以下に挙げます。

例 1: 休暇申請

この簡単な例には、2 つのデータ セットがあります。 一方が従業員、もう一方が休暇申請です。 各従業員が複数の申請を出すため、ここでのリレーションシップは一対多 (「一」が従業員、「多」が申請) です。 従業員データと休暇申請データは、従業員番号を共通フィールドとすることで、互いに関連づけられています（別名キー）。

例 2: 発注書の承認

ここでは、データ構造が非常に洗練されているように見えますが、この記事の冒頭で説明した経費報告書の例と非常によく似ています。 各仕入先または発注先が、複数の発注書に関連付けられています。 各従業員が複数の発注書を担当します。 したがって、これらのデータ セットはどちらも一対多のデータ構造を持っています。

従業員が常に同じ仕入先または発注先を使用するとは限らないため、仕入先は複数の従業員によって使用され、各従業員は複数の仕入先と取引を行います。 したがって、従業員と仕入先のリレーションシップは多対多です。

例 3: 経費精算

次のステップ: 作成するアプリのタイプを決定する

注意

ドキュメントの言語設定についてお聞かせください。 簡単な調査を行います。 (この調査は英語です)

この調査には約 7 分かかります。 個人データは収集されません (プライバシー ステートメント)。