リレーショナルデータベース設計ガイド（4-6 of 15）[翻訳]

初心者向けに一連の記事の翻訳の続きを投稿します。

現在およびそれ以降、より多くの情報がメリットにあります。

始まりはここです。

4.テーブルと主キー

前のパートですでに知っているように、データは別の方法で 行またはレコードを含むテーブルに保存されます。 前に、レッスンに関する情報を含むテーブルの例を挙げました。 彼女をもう一度見てみましょう。







テーブルには6つのレッスンがあります。 6つすべてが異なりますが、レッスンごとに同じフィールドの値がテーブルに保存されます。つまり、tutorial_id（レッスン識別子）、title（タイトル）、category（カテゴリ）です。 Tutorial_id-レッスンテーブルの主キー 。 主キーは、テーブル内の各レコードに固有の値です。

以下の顧客テーブルでは、customer_idが主キーです。 この場合、主キーは各レコードの一意の値（数値）でもあります。

日常生活の主な鍵

データベースでは、主キーが識別に使用されます。 人生では、私たちの周りの主なキーはどこにでもあります。 一意の番号に遭遇するたびに、この番号はデータベースの主キーとして機能します（ただし、そのように使用する必要はありません。すべてのデータベースは、自動的にインクリメントされて一緒に挿入される番号として各レコードの一意の値を自動的に生成できます新しいレコードごとに[いわゆる合成または代理主キー-約transl。]）。



いくつかの例

• オンラインストアでの購入時に受け取る注文番号は、このストアのデータベースにある注文テーブルの主キーである場合があります。 これは一意の値です。
• 社会保障番号は、政府機関のデータベース内のテーブルの主キーである場合があります。 前の例のように一意です。
• 請求書番号は、顧客に発行された請求書を格納するデータベーステーブルの主キーとして使用できます。
• 多くの場合、顧客番号は顧客テーブルの主キーとして使用されます。
• ...

これらの例をまとめたものは何ですか？ すべてのレコードで、各レコードの一意の非反復値が主キーとして選択されます。 もう一度。 主キーとして選択されたデータベーステーブルフィールドの値は常に一意です。

主キーの特徴は何ですか？ 主な機能。

主キーは、レコードを識別するために使用されます。



主キーは、各レコードが一意になるように、テーブル内のレコードを識別するために使用されます 。 別の類推...テクニカルサポートに電話するとき、オペレーターは通常、システムで識別できる番号（契約、電話など）の名前を尋ねます。

番号を忘れた場合、テクニカルサポートオペレーターは、お客様を一意に識別するのに役立つその他の情報を提供するように求めます。 たとえば、誕生日と姓の組み合わせ。 また、主キー、またはそれらの組み合わせにすることもできます。



主キーは一意です。



主キーは常に一意です。 その意味がユニークではないことを想像してください。 その後、テーブル内のデータを識別するために使用できませんでした。 つまり、主キーの値は、主キーとして選択された列で1回しか使用できません。 RDBMSは、主キーフィールドに重複を挿入できないように設計されているため、エラーが発生します。

別の例。 first_nameフィールドとlast_nameフィールドを持つテーブルがあり、2つのレコードがあると想像してください。



| first_name | last_name |

| vasya | pupkin |

| vasya | pupkin |



つまり 2つのVasyaがあります。 テーブルから特定のVasyaを選択します。 どうやってやるの？ 記録は互いに違いはありません。 これは、主キーが役立つ場所です。 id列（合成主キーのクラシックバージョン）を追加し、...



Id | first_name | last_name |

1 | vasya | pupkin |

2 | vasya | pupkin |



今、すべてのヴァシャはユニークです。



主キーの種類。



通常、主キーは数値です。 ただし、他のデータ型にすることもできます。 主キーとして文字列を使用することは一般的な慣行ではありません（文字列はテキストの一部です）が、理論的にも実際的にも可能です。

複合主キー。

多くの場合、主キーは1つのフィールドで構成されますが、2つ（3つ、4つなど）のように、複数の列を組み合わせることもできます。 ただし、主キーは常に一意であり、n番目のフィールドの組み合わせ（この場合は2）が一意であることを覚えています。 これについては後で詳しく説明します。



自動番号付け



主キーフィールドは、常にではありませんが、多くの場合、データベース自体によって処理されます。 相対的に言えば、作成時に各レコードに一意の数値を自動的に割り当てるようにデータベースに指示できます。 通常、データベースは1から番号付けを開始し、各レコードのこの番号を1単位ずつ増やします。 この主キーは、自動インクリメントまたは自動番号付けと呼ばれます。 自動インクリメントキーを使用すると、一意のプライマリキーを指定できます。 このようなキーの古典的な名前は、代理主キーです[上記のように。 -約 翻訳]。 このようなキーには、エンティティ（オブジェクト）に関連する有用な情報が含まれておらず、その情報はテーブルに格納されているため、サロゲートと呼ばれます。

5.外部キーを使用したテーブルのリンク

データベースの開発を始めたとき、関連していると思われる情報を1つのテーブルに保存しようとすることがよくありました。 たとえば、顧客テーブルに注文に関する情報を保存できます。 結局、注文は顧客のものですよね？ いや 顧客と注文は、データベース内の別個のエンティティです。 両方とも独自のテーブルが必要です。 そして、これら2つのテーブルのエントリは、それらの間の関係を確立するために関連付けることができます。 データベース設計は、2つの問題の解決策です。

• 格納するエンティティを決定する
• これらのエンティティ間の関係は何ですか

1対多。

顧客と注文には1対多の関係（関係）があります。これは、 1人のクライアントが多数の注文を持つことができるためです。 クライアントを1つだけ持つことができます。 現時点でこの接続の理解が曖昧であっても心配しないでください。 また、次のパートで関係についても説明します。



現在重要なことの1つは、1対多の関係では、 2つの別個のテーブルが必要であることです。 1つは顧客用、もう1つは注文用です。 これらの2つのテーブルを作成して、少し練習してみましょう。

どのような情報を保存しますか？ 最初の質問を解決します。

まず、 注文と顧客に関するどの情報を保存するかを決定します。 これを行うには、 「どのユニットの情報ブロックが顧客に関連しており、どのユニットの情報が注文に関連しているのか」という質問を自問する必要があります。



顧客テーブルを設計します。



注文は実際には顧客に属しますが、注文は顧客に関連する最小限の情報ブロックではありません（つまり、このブロックは、注文日、注文配送先住所など、より小さなものに分割できます）。

以下のフィールドは、顧客に適用される情報の最小ブロックです。

• customer_id（主キー）-顧客識別子
• first_name-名前
• last_name-ミドルネーム
• 住所-住所
• zip_code-郵便番号
• 国-国
• birth_date-生年月日
• ユーザー名-ユーザー名（ログイン）
• パスワード-パスワード

SQLyogでこのテーブルを直接作成します（当然、他のプログラムを使用できます）。 以下は、作成後のSQLyogでのテーブルの表示例です。 すべてのグラフィカルデータベース管理アプリケーションのインターフェイス構造はほぼ同じです。 グラフィカルユーティリティを使用せずに、コマンドラインを使用してテーブルを作成することもできます。





SQLyogでテーブルを作成します。 customer_idフィールドのプライマリキー（PK）チェックボックスが選択されていることに注意してください。 customer_idフィールドは主キーです。 [Auto Incr]チェックボックスも選択されています。これは、データベースが一意の数値を自動的に置き換えることを意味します。ゼロから開始すると、毎回1単位ずつ増加します。



注文の表を設計します。

注文に必要な情報の最小ブロックは何ですか？

• order_id（主キー）-注文識別子
• order_date-注文の日付と時刻
• customer-注文した顧客

以下はSQLyogのテーブルの例です。





ドラフト表。 顧客フィールドは、顧客テーブルのcustomer_idフィールドの参照（外部キー）です。



注文テーブルの顧客フィールドは顧客テーブルの主キー（ customer_id ）を参照するため、これら2つのテーブル（ 顧客と注文 ）は関連しています。 このような関係は、 外部キー関係と呼ばれます 。 外部キーは、別のテーブルの主キーの単純なコピー（値のコピー）として想像してください。 この場合、各レコードが挿入されると、 顧客テーブルのcustomer_idフィールドの値が注文テーブルにコピーされます。 したがって、当社ではすべての注文が顧客に結び付けられています。 また、前述のように、各クライアントは多くの注文を行うことができます。



外部キー関係の作成。



「注文テーブルの顧客フィールドが顧客テーブルのcustomer_idフィールドを参照していることをどのように確認できるか、またはどのように確認できるか」と疑問に思われるかもしれません。 答えは簡単です-接続を作成する方法をまだ示していないため、これを行うことはできません。

以下は、テーブル間のリレーションシップを作成するために使用したウィンドウを含むSQLyogウィンドウです。





注文テーブルと顧客の間に外部キー関係を作成します。



上のウィンドウでは、左側の注文テーブルの顧客フィールドが、右側の顧客テーブルのプライマリキー（customer_id）とどのように関連付けられているかを確認できます。



これで、テーブルにある可能性のあるデータを見ると、2つのテーブルが接続されていることがわかります。





注文は、顧客テーブルを参照する顧客フィールドを介して顧客にリンクされます。



この画像では、 maryクライアントが3つの注文を行い、 pabloクライアントが1つの注文を行い、 johnクライアントが何も注文していないことがわかります。

「そして、これらすべての人々が正確に何を注文したのか」と尋ねることができます。これは良い質問です。 注文された商品が注文表に表示されることを期待しているかもしれません。 しかし、これは悪い設計例です。 1つのエントリに複数の製品をどのように配置しますか？ 商品は個別のエンティティであり、個別のテーブルに保存する必要があります。 また、 注文と商品のテーブル間の関係は、1対多の関係になります。 これについては後で説明します。

6.セキュリティと通信の図の作成

前に、さまざまなテーブルのレコードがリレーショナルデータベースで相互に通信する方法を学習しました。 テーブルを作成およびリンクする前に、システムに存在するエンティティ （データベースの作成対象）について検討し、これらのエンティティが互いに通信する方法を決定することが重要です。 データベース設計では、エンティティとその関係は通常、 エンティティ関係図（ERD）で提供されます。 この図は、データベース設計プロセスの結果です。

エンティティ。

エンティティとは何かと疑問に思うかもしれません。 まあ...これはシステムの「もの」です。 あそこ。 私はいろいろなことを非常によく説明しているので、私の母はいつも先生になりたいと思っていました。



データベース設計のコンテキストでは、エンティティはデータベースモデル内の独自のテーブルに値するものです。 データベースを設計するときは、データベースを作成するシステムでこれらのエンティティを定義する必要があります。 むしろ、システムがどのデータを扱うかを知るために、クライアントまたはあなた自身との対話の問題です。



例としてオンラインストアを見てみましょう。 オンラインストアは商品を販売します 。 製品は、オンラインストアシステムの明白なエンティティになる可能性があります。 商品は顧客が注文し ます 。 そのため、 注文と顧客という 2つの明確なエンティティが見つかりました。



注文はクライアントによって支払われます...それは興味深いです。 オンラインストアのデータベースに支払い用の別のテーブルを作成しますか？ おそらく。 しかし、支払いは注文に関連する最小限の情報ブロックですか？ それも可能です。



不明な場合は、どの支払い情報を保持するかを考えてください。 支払方法または支払日を保持することもできます 。 しかし、これらはまだ注文に関連する可能性のある最小限の情報ブロックです。 表現を変更できます。 支払い方法-注文の支払い方法。 支払い日-注文の支払い日。 したがって、概念的には支払いをエンティティとして区別できますが、別のテーブルで支払いを行う必要はありません。 支払いは情報（支払い方法、支払い日）のコンテナと考えることができます。



アカデミックになりすぎないようにしましょう。



ご覧のとおり、エンティティとデータベース内のテーブル自体には違いがあります。 同じものではありません。 情報技術業界のスペシャリストは、この問題に関して非常にアカデミックでありつまらないものです。 私はそのような専門家ではありません。 この違いは、データの観点、情報によって異なります。 ソフトウェアの観点からデータモデリングを見ると、データベースに直接転送できない多くのエンティティを思い付くことができます。 このガイドでは、厳密にデータベースの観点からデータを見ており、私たちの小さな世界では、エンティティはテーブルです。





ちょっと待ってください。データベースの学位を取得することに本当に近づいています。



ご覧のとおり、システムのエンティティの定義は、ある程度の経験が必要な知的プロセスであり、多くの場合、変更、修正、思考の対象となりますが、これはロケット科学ではありません。





複雑なアプリケーションで作業している場合、エンティティ関係図は非常に大きくなる可能性があります。 一部のチャートには、数百または数千ものテーブルが含まれる場合があります。

コミュニケーション。

データベース設計の2番目のステップは、システム内のエンティティ間に存在する関係を選択することです。 理解するのは少し難しいかもしれませんが、繰り返しますが、これはロケット科学ではありません。 ある程度の経験を獲得し、作業を再考することで、次のデータベースモデルを正しい方法またはほぼ正しい方法で完成させることができます。



だから。 1対多の関係について説明しましたが、このガイドの後の部分で関係について詳しく説明しますので、これで終わりではありません。 エンティティの関係を決定することはデータベース設計の重要な部分であり、これらの関係はエンティティ関係図に表示されることを覚えておいてください。