Northwind 2.0 Starter Edition: データベース設計

以下のセクションでは、データベース テーブルのリレーションシップがどのように設計されたかを示します。 オブジェクト名は、Northwind 2.0 Starter Edition データベースで容易に調べることができるように提供されています。

テーブルとリレーションシップのデータベース設計

6 つのテーブルとそれらの間のリレーションシップを示すリレーションシップ図を開くには、[ データベース ツール>リレーションシップ] を選択します。

この図には、6 つのテーブルがすべて示されています。 図では、テーブル間の線はテーブル間のリレーションシップを示します。 線末の 1 と無限大記号 (∞) は、リレーションシップの一面 (たとえば、1 人の顧客) とリレーションシップの多面を表します。 たとえば、1 人の顧客が多数の注文を送信したとします。 詳細については、「テーブルのリレーションシップの概要」を参照してください。

テーブルの原則の詳細

次の原則は、Northwind 2.0 Starter Edition のテーブルおよび一般的なテーブルに適用されます。

主キー テーブル内の各レコードを一意に識別する。 すべてのテーブルには主キーがあります。 リレーションシップ図では、キー記号によってこれらの主キーが識別されます。 主キーの名前付け規則は、それらが含まれているテーブルに対して名前が付けられます。たとえば、"TableNameID" などです。 

効率性 パフォーマンスとストレージ効率を向上させるには、主キーに数値キーを使用する必要があります。 また、Access で新しいレコードの主キーごとに新しい一意の値が自動的に生成される方が便利です。 オートナンバー型には両方の特性があります。 それ以外の場合、オートナンバーは意味のない数値であり、他の目的には使用しません。 詳細については、「 オートナンバー型フィールドを主キーとして追加する」を参照してください。

外部キー テーブルがデータベース内の他のテーブルに関連しているかどうかに応じて、テーブルに 1 つ以上の外部キーを設定することもできます。 外部キーには、関連テーブルの主キーの値に対応する値が含まれています。 

固有インデックス テーブル内の他のフィールドにも、OrderStatus.StatusCode のように、独自の一意のインデックスが設定されていることがあります。 StatusCode 自体が主キーではない場合でも、同じコードを持つ 2 つの Order Status テーブルに 2 つの注文状態を含めることは非論理的です。 一意インデックスを指定すると、そのフィールドの値が重複しないように Access に指示します。

一意でないインデックス テーブルには、これらのフィールドの検索や並べ替えを高速化するためのインデックスがある場合もあります (例: Orders.OrderDate)。 多くの注文が同じ日に行われた可能性があり、多くの場合、注文日を検索して並べ替えます。 そのフィールドには、検索と並べ替えを高速化するための一意でないインデックスがあります。

テーブル名とフィールド名 名前は自由にできますが、一貫性が重要です。 テーブル名とフィールド名は、1 つ以上の単語の間にスペースを入れず、スラッシュ (/)、シャープ記号 (#)、パーセント (%)) などの特殊文字は使用しないことをお勧めします。 たとえば、OrderDate は使用しますが、Order Date は使用しないでください。OrderNumber または OrderNo は使用しますが、Order# は使用しないでください。 

キャメルケース 単語は大文字にして名前の個々の部分を強調します (例: OrderDate など)。ただし、Orderdate や orderDate は使用しないでください。

必須値 この原則は、アプリケーションにとってのビジネス ルールの重要性を浮き彫りにします。 状況によっては、一部のフィールドで値、または特定の値が必要な場合があります。 たとえば、注文を出した顧客を知らなければ、注文は何の役に立ちますか? つまり、得意先 ID は "注文" テーブルの必須フィールドです。 

集計フィールド Access では、Employees.FullName フィールドなどのテーブルの集計フィールドがサポートされています。 集計フィールドは、テーブルではなくクエリ内に作成することをお勧めします。

添付ファイルのフィールド Access では添付ファイル フィールドがサポートされています。たとえば、従業員の画像を保持する Employees.Picture などです。 添付ファイルには、画像、ドキュメント、電子メール、その他のバイナリ情報を保存できます。 添付ファイルはデータベース内の多くの領域を占有します。 代わりに、ファイル サーバーに添付ファイルを保存する方が効率的です。

複数値を持つフィールド 名前が示すように、複数値を持つフィールドは、1 つのフィールド (たとえば、Employees.Title) に 1 つ以上の値を格納します。 特にデータベースを拡大する場合は、慎重に使用することをお勧めします。 他のほとんどのデータベース システムにはそのような機能がないため、多くのやり直しが必要になります。 

データ型の詳細については、「データ型とフィールド プロパティの概要」を参照してください。

Northwind の個々のテーブル

ここでは、各テーブルの最も重要な機能について説明します。 テーブルのデザインを確認するには、ナビゲーション ウィンドウでテーブルを選択して右クリックし、[ デザイン ビュー] を選択するか、[ データベース ツール>リレーションシップ] の順に選択してテーブル オブジェクトを右クリックします。 詳細については、「テーブルの概要」を参照してください。

Employees テーブル

このテーブルには、Northwind の従業員に関する情報が格納されています。 

フィールド	説明
FirstName, LastName	両方の名前が必須であり、Northwind では、組み合わせて一意の名前である必要があります。 テーブル デザインでは、[ インデックス] ダイアログ ボックスを開くと、FirstName + LastName に一意のインデックスがあることがわかります。 FirstName と LastName は一意にインデックス付けされるため、Northwind テーブルには同じ名前の 2 人の従業員を格納できません。 他の状況では、別のビジネス ルールを使用することもできます。
FullNameFNLN, FullNameLNFN	集計フィールドの式プロパティを参照して、集計フィールドの値がどのように結合されるかを確認してください。 ミドル イニシャルを含めるには、コンポーネント間に適切な間隔を空けて既存の式に追加します。
電話のフィールド	電話のビジネス ルールは、サービスの種類よりも従業員の好みが重要であるということです。 そのため、携帯電話、オフィス、自宅などではなく、プライマリおよびセカンダリの電話番号が使用されます。
挨拶	問い呼びは短いテキスト フィールドです。 Access の複数値を持つフィールド機能を説明するために、これは、定義済みの値の編集可能なリストを含むコンボ ボックスです。 このような短い静的リストは、多くを変更しないため、複数値を持つフィールドの候補となる場合が少なくなっています。
JobTitle	JobTitle も必須フィールドです。

[顧客] テーブル

このテーブルには、Northwind の顧客に関する情報が格納されます。 

フィールド	説明
CustomerName	Northwind の顧客は企業であるため、顧客名が必要です。 ただし、従業員名とは異なり、一意にインデックスが作成されないため、2 人以上の顧客が同じ名前を持たせます。
PrimaryContactFirstName、PrimaryContactLastName、 PrimaryContactJobTitle	顧客が第一連絡先担当者として 1 人の個人を持っていない場合があるため、第一連絡先の姓と役職は必要ありません。 連絡先は、注文の役職を教えてはなりません。
BusinessPhone	Northwind では、顧客ごとに 1 つの電話番号のみが必要になりますが、これにより顧客または顧客の連絡先に対して複数の電話番号を取得する機能はなくなります。 実際の状況では、通常、より複雑なビジネス ルールが連絡先情報に適用されます。
住所、市区町村 都道府県、郵便番号	Northwind では、注文品を顧客に出荷するための住所が必要です。 顧客の汎用アドレスは 1 つのみです。 実際の状況では、多くの場合、顧客は別の請求先、配送先、またはその他の住所を持っています。 organization の別のビジネス ルールには、追加のフィールドが必要になります。
メモ	Notes フィールドは長いテキスト型で、最大 1 GB のテキストを格納します。 これにより、後続の注文状況で使用するために、顧客に関する詳細なコメントを入力できます。

注文テーブル

このテーブルには、Northwind の注文に関する情報が格納されています。 

フィールド	説明
OrderDate, ShippedDate, PaidDate	注文には 3 つの日付が必要です。 これらはすべて日付/時刻のデータ型ですが、2 つの形式があります。 OrderDate には、1 日のさまざまな時間帯の注文量の分析に関心がある場合があるため、日付と時刻の両方が含まれています。 他の 2 つの日付については、日付のみが必要です。 ShippedDate と PaidDate のテーブル入力規則により、これらの日付が OrderDate より前ではないことが保証されます。
OrderStatusID	注文の状態は、注文が Northwind ワークフロー内のどこにあるかを示します。 注文は、新規 —>請求済み —>出荷済み —> の 4 つのフェーズを経て移動します。 現在の OrderStatus の外部キーは、OrderStatus のルックアップ テーブルの OrderStatusID を使用します。 ステータス ルックアップ テーブルを使用すると、事前に定義された 4 つのステータスのみを注文に割り当てることができます。

注文詳細テーブル

このテーブルには、Northwind の注文の詳細に関する情報が格納されます。 

フィールド	説明
OrderID	[受注明細] テーブルの各品目は、[受注] テーブルの 1 つの受注に属している必要があります。 OrderID は、その注文を識別する外部キーです。 前述のように、1 つまたは複数の品目を含む 1 つの注文は一対多のリレーションシップを示します。
ProductID	[受注明細] テーブルの各レコードには、注文された製品の ProductID が含まれています。 ProductID は [受注明細] テーブルの外部キーで、その注文でその製品を識別します。 これも一対多リレーションシップです。
OrderID+ ProductID	Employees テーブルで示したように、複数のフィールドに固有インデックスを設定できます。 OrderDetails テーブルの OrderID + ProductID の一意インデックスにより、各注文に製品が 1 回だけ含まれるようになります。 リボンから [インデックス] プロパティ シートを開くと、この一意のインデックスが表示されます。

製品テーブル

このテーブルには、Northwind の製品に関する情報が格納されます。 

フィールド	説明
商品コード	Northwind 製品には、主キーである ProductID に加えて、わかりやすい一意にインデックス付けされた製品コードがあります。 従業員は通常、主キーの値ではなく製品コードを参照します。 製品コードは、カテゴリ指定と数値で構成される複合値です。たとえば、製品 1 の場合は "飲料" の B-1。
製品名、 Product Description	短いテキストの製品名に加えて、長いテキストの説明文が製品に適用されます。 この値は、カタログの説明や顧客の質問に答えるために使用できます。
単価	すべての製品はアイテムごとに単価を付けて販売されており、機能のショーケースとしてデータベースを簡略化します。 ほとんどの場合、実際の状況では、価格設定ははるかに複雑であることがよくあります。

関連項目

Northwind 2.0 Starter Edition