データベースの概要

目的に集中した設計にするには、データベースの目的を要約し、それをたびたび参照します。 たとえば、在宅ビジネス用の小さいデータベースが必要な場合は、"メーリング リストやレポートを生成するために、顧客データベースに顧客情報の一覧を保持する" というような簡単な目的を書き出します。 企業で使用するデータベースの場合は、さまざまな役割のユーザーがデータベースとそのデータをいつ、どのように使用するかを説明するために複数の段落が必要になるかもしれません。 設計プロセス全体で参照する具体的で詳細なミッション ステートメントを作成します。

既存の情報と追跡方法から開始します。 たとえば、現時点ではおそらく、発注書を台帳に記録していたり、顧客情報を紙の用紙に記録したりしているでしょう。 これらの情報源を使用して、現在取得している情報 (たとえば、用紙のすべての記入欄など) を一覧にします。 重要な情報を現在取得していない場合は、どんな種類の情報が必要であるかを検討します。 それぞれのデータの種類がデータベースのフィールドになります。

最初のリストを完璧にすることを心配しないでください。時間の経過と同時に微調整できます。 しかし、この情報を使用するすべての人を考慮し、アイデアを求めます。

次に、データベースから得られる情報や作成するレポートまたはメーリング リストの種類について検討します。 その後、これらの目的を達成するために必要な情報を取得しているかどうかを確認します。 たとえば、地域別の売上高を示すレポートが必要な場合は、地域レベルの売上高データの取得が必要です。 表示したい実際の情報を使用して、レポートのレイアウトを考えてみましょう。 その後、レポートを作成するために必要なデータの一覧を作成します。 メーリング リストや、データベースをもとに作成するその他の出力についても、同じ手順を実行します。

例

顧客がオプトイン (またはオプトアウト) することができる、定期的に送信されるメールによる更新情報があり、そのオプトインしている登録者の一覧を印刷するとします。 顧客テーブルには、"Yes" または "No" の値を入力できる "メール送信" 列が必要です。

顧客がメールの受信に同意した場合、メール アドレスが必要なので、そのフィールドも必要になります。 適切な頭語 ("拝啓"、"前略"、"謹啓" など) を含めたい場合は、"頭語" フィールドが必要です。 メールの宛名に顧客の姓を使用する場合は、"姓" フィールドを追加します。

必要な情報の一覧を作成したら、データを整理するために必要な主なエンティティ (または主題) を決定します。 エンティティ間でデータが重複しないようにします。 たとえば、製品売上データベースの準備リストは次のようになります。

ここでの主なエンティティは、顧客、仕入先、製品、注文です。 これらの 4 つのテーブル (顧客に関する事実情報のテーブル、仕入先に関する事実情報のテーブルなど) から開始します。 これは最終的な設計にならないかもしれませんが、開始するのに適しています。

テーブル数は少ないよりも多い方がよい理由を理解するために、次に示すテーブルについて考えてみましょう。

各行には、製品とその仕入先の両方に関する情報が含まれています。 同じ仕入先から仕入れられた製品が複数ある場合、仕入先名と住所の情報を何度も繰り返す必要があります。 これはディスク領域の無駄遣いです。 代わりに、仕入先の情報を個別の仕入先テーブルに 1 回だけ記録し、そのテーブルを製品テーブルに関連付けます。

この設計の 2 番目の問題は、仕入先に関する情報を修正する必要が生じた場合に発生します。 仕入先の住所を変更する必要があるとしましょう。 仕入先の住所は複数の場所に表示されているので、ある場所で誤って住所を変更したのに、別の場所では変更を忘れてしまうことも考えられます。 仕入先の住所を 1 か所だけに記録すれば、この問題は解決されます。

最後に、Coho Winery から仕入れている製品が 1 つしかなく、その製品を削除したいが、仕入先の名前と住所の情報は残しておきたいとしましょう。 この設計の場合、仕入先情報を消失せずに製品レコードを削除するにはどうすればよいでしょうか。 それはできません。 各レコードには、仕入先に関する事実に加えて商品に関する事実情報が含まれているので、一方を削除しないで他方を削除することは不可能です。 これらの事実情報を分けて保存するには、このテーブルを 2 つのテーブル (1 つ目は製品情報、2 つ目は仕入先情報) に分割します。 このようにすると、製品レコードを削除した場合、製品に関する事実情報だけが削除され、仕入先に関する事実情報は削除されません。

データベース テーブルの主題を選択した後、そのテーブルの列には、その 1 つの主題に関する事実情報のみを格納する必要があります。 たとえば、製品テーブルには、製品に関する事実情報のみを格納し、仕入先に関する事実情報は格納しないようにする必要があります。

表で管理する情報を決定するには、以前に作成した一覧を使用します。 たとえば、顧客テーブルに、姓、名、住所、メールの送信、頭語、メール アドレスが含まれているとしましょう。 テーブル内の各レコード (顧客) には、同じ列セットが含まれるので、顧客ごとにまったく同じ情報が格納されます。

最初のリストをCreateし、確認して絞り込みます。 情報は、可能な限り最小のフィールドに分割してください。 たとえば、最初のリストに [住所] がフィールドとして含まれる場合は、番地、市区町村、州、郵便番号に分割するか、顧客がグローバルな場合は、さらに多くのフィールドに分割します。 そうすれば、たとえば、適切な形式で郵送を行ったり、状態別の注文を報告したりできます。

各テーブルのデータ列を調整したら、各テーブルの主キーを選択できます。

各テーブルの各行を一意に識別する方法が必要です。 前に取り上げた、2 人の顧客が同じ名前を持っている例を思い出してください。 これらの顧客は同じ名前を共有しているので、それぞれを個別に識別するための方法が必要です。

そのため、すべてのテーブルには、各行を一意に識別する列 (または列のセット) が含まれている必要があります。 これは 主キー と呼ばれ、多くの場合、従業員 ID 番号やシリアル番号などの一意の番号です。 Access では、主キーを使用して、複数のテーブルのデータをすばやく関連付け、データをまとめます。

主キーが 2 つ以上のフィールドで構成される場合もあります。 たとえば、注文品目を格納する受注明細テーブルでは、主キーに 2 つの列 (受注コードと製品 ID) が使用されます。 主キーで複数の列が使用される場合、これを複合キーと呼びます。

カタログで各製品を一意に識別する製品番号など、テーブル内の情報を一意に識別する識別子が既にある場合、それを使用します。ただし、値が主キーに関する次の規則に従っている場合に限られます。

• 識別子は必ず、レコードごとに異なります。 主キーでは、値の重複は認められません。

• 項目には必ず、値が設定されていなければなりません。 テーブル内のすべてのレコードには、主キーを含む必要があります。 複数の列 (部品ファミリと部品番号など) を使用してキーを作成する場合、両方の値が常に存在する必要があります。

• 主キーは、変更することがない値です。 キーは他のテーブルで参照されるため、あるテーブルの主キーを変更すると、それを参照するすべてのテーブルでもキーが変更されることを意味します。 頻繁に変更すると、エラーが発生する危険性が高まります。

明らかな識別子がない場合は、任意の一意の番号を主キーとして使用します。 たとえば、注文を識別するためだけの一意の注文番号を各注文に割り当てます。