Access の概要

データベースの概要

お使いのブラウザーではビデオがサポートされていません。

演習

データベースと Web アプリは、ビジネス上の大きな利点をもたらすことがあります。 データベース設計は、目的が従業員情報の管理、データに関する週間レポートの提出、顧客注文の追跡のいずれであっても、その目的を達成する上で重要です。 データベース設計を理解することに時間をかけることにより、最初からきちんと機能し、ニーズの変化にも適応できるデータベースを構築することができます。

重要: Access Web アプリは、デスクトップ データベースとは異なります。 この記事では、Web アプリの設計については説明しません。

概念と用語

最初に、基本的な用語と概念について説明します。 有用なデータベースを設計するには、1 つの主題に集中したテーブルを作成します。 テーブルには、その主題に必要なすべてのデータをフィールドに分けて取得し、フィールドには、可能な限り最小の単位でデータを格納します。

リレーショナル データベース

データをテーブルに分割するデータベースで、スプレッドシートのようなものです。 各テーブルには、顧客 (1 つのテーブル) や製品 (別のテーブル) など、1 つの主題のデータのみを格納します。

レコードとフィールド

テーブル内の個別のデータの記憶域。 行 (またはレコード) には、顧客の名前など、一意の各データ ポイントが格納されます。 列 (またはフィールド) は、各データ ポイントに関してキャプチャされる情報を可能な限り最小の単位に分離します。名は 1 つの列で、名は別の列である可能性があります。

主キー

各レコードが一意である必要がある値。 たとえば、Elizabeth Andersen という同じ名前の顧客が 2 人いる場合があります。 しかし、Elizabeth Andersen レコードの 1 つは番号 12 を主キーとして、もう 1 つは主キーが 58 です。

親子関係

テーブル間の一般的なリレーションシップです。 たとえば、1 つの顧客が複数の注文を持つことができます。 親テーブルには主キーがあり、子テーブルには外部キーがあります。 これは主キーの値で、子テーブルのレコードと親テーブルがどのように関連付けられるかを示します。 これらのキーはリレーションシップによりリンクされます。

適切なデータベース設計とは

適切なデータベース設計の基本となるのは、次の 2 つの原則です。

  • 重複する情報 (冗長データとも呼ばれる) を避けます。 スペースを無駄にし、エラーの可能性を高める。

  • データが正しく完了していることを確認します。 不完全な情報や誤った情報はクエリやレポート内で流れ、最終的には誤った情報の決定につながる可能性があります。

このような問題を回避するには、次の対策が役立ちます。

  • 絞り込みフォーカスがある主題ベースのテーブルにデータベース情報を分割します。 複数のテーブルの情報が重複しないようにします。 (たとえば、顧客名は 1 つのテーブルにのみ入力する必要があります)。

  • データを重複させるのではなくキーを使用してテーブルを結合します。

  • データベース情報の正確さと整合性を支援し、確保するプロセスを含めます。

  • データの処理およびレポートのニーズを考慮してデータベースを設計します。

データベースの有用性を長期にわたって維持するには、次の 5 つの手順を実行します。

手順 1: データベースの目的を決定する

開始する前に、データベースの目的を定めます。

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

手順 2: 必要な情報を見つけて整理する

製品名や注文番号など、記録する必要があるすべての種類の情報を収集します。

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

最初のリストを完璧に設定する心配はいりません。時間のと一度に微調整できます。 しかし、この情報を使用しているすべてのユーザーを考慮し、アイデアを求める必要があります。

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

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

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

ヒント: 顧客テーブルの名や名など、情報の各部分を最も小さな便利な部分に分割してください。 一般に、情報の項目 (顧客の名など) に基づいて並べ替え、検索、計算、またはレポートを行う場合は、そのアイテムを独自のフィールドに入力する必要があります。

手順 3: 情報をテーブルに分割する

情報の項目を主なエンティティや主題 (製品、顧客、注文など) に分割します。 各主題がテーブルになります。

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

件名にグループ分けされた情報アイテムのスクリーン ショット

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

注: 優れたデータベースは、複数のテーブルで構成されます。 すべての情報を 1 つのテーブルのみに保存するのは避けてください。 その場合、情報が重複し、データベースのサイズが大きくなり、エラーも増加します。 各事実情報は 1 回だけ記録するように設計してください。 仕入先の住所など、情報が繰り返されているのを発見した場合は、その情報が個別のテーブルに保存されるようにデータベースを再構築します。

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

製品と仕入先データの画面スニペット

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

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

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

手順 4: 情報の項目を列に変える

各テーブルに格納する必要がある情報を決定します。 これらのデータの個々の部分がテーブルのフィールドになります。 たとえば、従業員テーブルには、姓、名、雇用日などのフィールドが含まれます。

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

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

最初のリストを作成し、確認して調整します。 情報は、可能な限り最小のフィールドに分割してください。 たとえば、最初のリストにフィールドとして [住所] がある場合は、住所、市区町名、州、郵便番号に分割するか、顧客がグローバルの場合はさらに多くのフィールドに分割します。 この方法では、たとえば、適切な形式で郵送を行い、州別に注文に関するレポートを作成できます。

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

手順 5: 主キーを指定する

各テーブルの主キーを選択します。 製品 ID や受注コードなどの主キーは、各レコードを一意に識別します。 明らかに一意の識別子がない場合、Access を使用して作成します。

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

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

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

製品テーブルの画面スニペット

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

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

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

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

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

ヒント: 一意の番号を主キーとして作成するには、オートナンバー データ型を使用する列を追加します。 オートナンバー データ型は、各レコードに一意の数値を自動的に割り当てます。 この種類の識別子には、それが表す行について説明する事実情報は含まれません。 電話番号や顧客名など、行に関する事実情報を含む主キーとは異なり、番号が変更されることはないので、オートナンバー データ型の列は主キーとして使用するのに最適です。

さらに詳しく

フィールド、コントロール、オブジェクトに名前を付けるためのガイドライン

テーブルの概要

Excel のトレーニング

Outlook のトレーニング

ヘルプを表示

Office のスキルを磨く
トレーニングの探索
新機能を最初に入手
Office Insider に参加する

この情報は役に立ちましたか?

ご意見をいただきありがとうございます。

フィードバックをお寄せいただき、ありがとうございます。Office サポートの担当者におつなぎいたします。

×