次のセクションでは、データベース テーブルリレーションシップがどのように設計されたかを示します。 Northwind 2.0 Starter Edition データベースで簡単に調べることができるように、オブジェクト名が用意されています。
6 つのテーブルとその間のリレーションシップを示すリレーションシップ ダイアグラムを開くには、[ データベース ツール ] > [リレーションシップ] を選択します。
この図は、6 つのテーブルすべてを示しています。 この図では、テーブル間の線によってそれらの間のリレーションシップが識別されます。 行の末尾にある 1 と無限大記号 (∞) は、リレーションシップの一方の側 (たとえば、顧客) とリレーションシップの多辺を表します。 たとえば、1 人の顧客が多数の注文を送信します。 詳細については、「 テーブル リレーションシップのガイド」を参照してください。
次の原則は、Northwind 2.0 Starter Edition のテーブルと一般的なテーブルに適用されます。
主キー テーブル内の各レコードを一意に識別します。 すべてのテーブルに主キーがあります。 リレーションシップ図では、キー シンボルによってそれらの主キーが識別されます。 主キーの名前付け規則には、"TableNameID" など、そのテーブルの名前が付けられます。
効率 パフォーマンスを向上させ、ストレージの効率を高めるには、主キーを数値にする必要があります。 さらに、新しいレコードの主キーごとに新しい一意の値を自動的に生成する方が便利です。 AutoNumber データ型には、両方の特性があります。 それ以外の場合、オートナンバーは意味のない数値であり、他の目的には使用されません。 詳細については、「 AutoNumber フィールドを主キーとして追加する」を参照してください。
外部キー テーブルは、データベース内の他のテーブルに関連しているかどうかに応じて、1 つ以上の外部キーを持つことができます。 外部キーには、関連テーブルの主キーの値に対応する値が含まれています。
一意のインデックス テーブル内の他のフィールドには、独自の一意のインデックス (OrderStatus.StatusCode など) もあります。 StatusCode 自体が主キーではない場合でも、同じコードを持つ OrderStatus テーブルに 2 つの Order Status を含めるのは非論理的です。 一意のインデックスは、そのフィールドの値が重複しないように Access に指示します。
一意でないインデックス テーブルには、これらのフィールドの検索と並べ替えを高速化するためのインデックス (Orders.OrderDate など) もあります。 多くの注文は同じ日に行うことができます。多くの場合、注文日を検索して並べ替える必要があります。 検索と並べ替えを高速化するために、そのフィールドには一意でないインデックスがあります。
テーブル名とフィールド名 任意の方法で名前を付けることができますが、一貫性が重要です。 テーブル名とフィールド名の間にスペースがなく、スラッシュ (/)、ポンド記号 (#)、パーセント (%) などの特殊文字を含めずに、1 つ以上の単語を指定することをお勧めします。 たとえば、OrderDate を使用しますが、注文日は使用しないでください。OrderNumber または OrderNo を使用しますが、Order# は使用しません。
CamelCase 単語を大文字にして、名前の個々の部分 (OrderDate など) を強調表示しますが、Orderdate や orderDate は強調表示しません。
必要な値 この原則は、アプリケーションのビジネス ルールの重要性を高めます。 状況によっては、一部のフィールドで値や特定の値が必要な場合があります。 たとえば、注文を行った顧客を知らなくても、注文の良い点は何ですか? つまり、CustomerID は Orders テーブルの必須フィールドです。
計算フィールド Access では、テーブルの計算フィールド (Employees.FullName フィールドなど) がサポートされています。 テーブルではなく、クエリで計算フィールドを作成することもできます。
添付ファイル フィールド Access では、従業員の画像を保持する Employees.Picture などの添付ファイル フィールドがサポートされています。 添付ファイルには、画像、ドキュメント、電子メール、およびその他のバイナリ情報を格納できます。 添付ファイルは、データベース内の多くの領域を占有します。 代わりに、ファイル サーバーに添付ファイルを格納する方が効率的です。
複数値フィールド 名前が示すように、複数値フィールドは、1 つのフィールド (Employees.Title など) に 1 つ以上の値を格納します。 特にデータベースをアップサイズする場合は、控えめに使用することをお勧めします。 他のほとんどのデータベース システムにはデータベース システムがないため、多くの再作業が必要になります。
データ型の詳細については、「データ型とフィールド プロパティの概要」を参照してください。
このセクションでは、各テーブルの最も重要な機能について説明します。 テーブルのデザインを確認するには、ナビゲーション ウィンドウでテーブルを選択し、右クリックして [ デザイン ビュー] を選択するか、[ データベース ツール ] > [リレーションシップ] を選択して、テーブル オブジェクトを右クリックします。 詳細については、「 テーブルの概要」を参照してください。
重要: 名前付けの競合を引き起こす可能性がある予約語の使用は避けてください。 詳細については、「 予約語とシンボルへのアクセス」を参照してください。
Employees テーブル
この表には、Northwind の従業員に関する情報が格納されています。
|
フィールド |
説明 |
|
FirstName、LastName |
どちらの名前も必須であり、Northwind では一緒に一意の組み合わせである必要があります。 テーブル デザインで [ インデックス ] ダイアログ ボックスを開くと、FirstName + LastName に一意のインデックスがあることがわかります。 FirstName と LastName は一意にインデックスが作成されるため、Northwind テーブルには同じ名前の 2 人の従業員を格納できません。 その他の状況では、別のビジネス ルールを使用できます。 |
|
FullNameFNLN, FullNameLNFN |
計算フィールドの expression プロパティを見て、Access が計算フィールドの値を結合する方法を確認します。 中間のイニシャルを含める場合は、コンポーネント間に適切な間隔を設定して既存の式に追加します。 |
|
電話フィールド |
電話のビジネス ルールは、従業員の優先順位がサービスの種類よりも関連性が高いということです。 そのため、セル、オフィス、自宅などではなく、プライマリとセカンダリの電話番号が使用されます。 |
|
挨拶 |
[敬礼] は [短いテキスト] フィールドです。 Access の複数値フィールド機能を示すために、定義済みの値の編集可能なリストを含むコンボ ボックスです。 簡単に言うと、このような静的リストは、多くの場合、多値フィールドの候補になります。 |
|
JobTitle |
JobTitle はもう 1 つの必須フィールドです。 |
Customers テーブル
この表には、Northwind の顧客に関する情報が格納されています。
|
フィールド |
説明 |
|
CustomerName |
Northwind の顧客は企業であり、顧客名が必要です。 ただし、従業員名とは異なり、一意のインデックスが作成されていないため、2 人以上の顧客が同じ名前を持つことができます。 |
|
PrimaryContactFirstName、PrimaryContactLastName、 PrimaryContactJobTitle |
顧客がプライマリ連絡先として 1 人の個人を持っていない可能性があるため、プライマリ連絡先の姓と役職は必要ありません。 連絡先が注文の役職を与えない場合があります。 |
|
BusinessPhone |
Northwind では、顧客ごとに 1 つの電話番号のみが必要ですが、これにより、顧客または顧客からの連絡先に対して複数の電話番号をキャプチャする機能はなくなります。 実際の状況では、通常、より複雑なビジネス ルールが連絡先情報に適用されます。 |
|
住所、市区町村 State、ZIP |
Northwind には、顧客に注文を発送するための住所が必要です。 顧客のジェネリック アドレスは 1 つだけです。 実際の状況では、顧客は別々の請求、出荷、またはその他の住所を持っていることが多いです。 organizationの別のビジネス ルールでは、追加のフィールドが必要になります。 |
|
メモ |
[メモ] フィールドは、最大 1 GB のテキストを格納する長いテキスト データ型です。 これにより、後続の注文状況で使用する顧客に関する詳細なコメントを入力できます。 |
Orders テーブル
次の表は、Northwind の注文に関する情報を格納します。
|
フィールド |
説明 |
|
OrderDate、ShippedDate、PaidDate |
注文には 3 つの日付が必要です。 これらはすべて日付/時刻データ型ですが、2 つの形式があります。 OrderDate には日付と時刻の両方があります。これは、1 日のさまざまな部分の注文量を分析することに関心がある可能性があるためです。 他の 2 つの日付の場合は、日付のみが必要です。 ShippedDate と PaidDate のテーブル検証規則では、これらの日付が OrderDate の前にないことを確認します。 |
|
OrderStatusID |
注文の状態は、Northwind ワークフロー内の注文の場所を示します。 注文は次の 4 つのフェーズを経て移動します: 新規 —> 請求済 み —> 出荷済 み —> クローズ。現在の OrderStatus の外部キーは、OrderStatus の参照テーブルの OrderStatusID を使用します。 Status ルックアップ テーブルを使用すると、事前に定義された 4 つの状態のみを注文に割り当てることができます。 |
注文の詳細テーブル
次の表は、Northwind の注文の詳細に関する情報を格納します。
|
フィールド |
説明 |
|
OrderID |
OrderDetails テーブルの各行項目は、Orders テーブル内の 1 つの Order に属している必要があります。 OrderID は、その順序を識別する外部キーです。 前に説明したように、1 つ以上の行項目を含む 1 つの注文は、1 対多のリレーションシップを示しています。 |
|
ProductID |
OrderDetails テーブルの各レコードには、注文された製品の ProductID が含まれています。 ProductID は、OrderDetails テーブル内の外部キーであり、その順序でその Product を識別します。 これは 1 対多のリレーションシップでもあります。 |
|
OrderID+ ProductID |
Employees テーブルで確認したように、複数のフィールドに一意のインデックスを設定できます。 OrderDetails テーブルの OrderID+ProductID に対する一意のインデックスにより、各注文に製品が 1 回だけ含まれるようにします。 リボンから Indexes プロパティ シートを開くと、この一意のインデックスが表示されます。 |
製品テーブル
次の表は、Northwind の製品に関する情報を格納します。
|
フィールド |
説明 |
|
Productcode |
主キーである ProductID、Northwind 製品に加えて、人間に優しい一意のインデックス付けされた製品コードがあります。 従業員は通常、主キー値ではなく製品コードを参照します。 製品コードは、カテゴリ指定と数値で構成される複合値です。たとえば、"飲料" の場合は B-1、製品 1 です。 |
|
製品名, 製品の説明 |
短いテキストの製品名に加えて、長いテキストの説明が製品に適用されます。 この値は、カタログの説明で使用することも、顧客の質問に回答するために使用することもできます。 |
|
UnitPrice |
すべての製品は、機能のショーケースとしてデータベースを簡素化する各項目の単価で販売されています。 ほとんどの実際の状況では、価格が大幅に複雑になることが多いです。 |
関連項目
