では、最初のデータベースモデルを作成したいのですが、開始方法がわかりませんか？続きを読む！
テーブル、列、関係についてはもう少し知っていると思います。そうでない場合は、続行する前にビデオチュートリアルをご覧ください。
システムの説明から始める
常に説明を使用してデータベースモデルの作成を開始する必要があります システムの。教室の状況では、システムの説明は教師から提供されます。実生活では、説明の準備はプロセスです。 それ自体で。私はあなたが説明を持っていると仮定します。それがあなたのクライアント、あなたの上司、あなたの教師によってあなたに与えられたのか、あなたがそれを自分で書いたのかは関係ありません。
説明を見て、すべての名詞を強調表示する 。説明の名詞は、テーブル、属性、例の3つのカテゴリに大まかに分類できます。
- テーブル システム内の主要なエンティティを表します：人、物理的なオブジェクト、イベント、トランザクションなど。
- 属性 プライマリエンティティに関連付けられたプロパティです。それらはあなたの実体の特徴を説明します。データベースモデルでは、それらはテーブルの列になります。
- 例 まさにその例です。 データ型を理解するのに役立ちます 特定の属性の関係を理解するのに役立ちます 異なるエンティティ間。
説明から始めると、同じ用語集を使用するように強制できるという利点があります。 ユーザーとして。小学校向けのシステムを作る場合は、生徒について話す必要があります。大学で同様のシステムを作成する場合は、学生について話す必要があります。
テーブル、関係、列
- 名詞が強調表示されたら、表を特定します 。すべてを一度にモデル化する必要はありません。最初にシステムのコア機能に焦点を合わせます。
- テーブルができたら、関係を把握します テーブルの間。この手順により、新しい中間（ジャンクション）テーブルが導入される可能性があります。
- 最後に列を追加します テーブルに。
この時点で、説明をもう一度読み、不足しているものがないかどうかを確認する必要があります。追加するものがあることを保証します。新しいテーブル、新しい関係、および新しい列を追加します。説明をもう一度読んでください...
心に留めておくべきこと
データベースモデルの作成は反復です 処理する。すべてを一度にモデル化しようとしないでください。システムのコアエンティティから始めます。後で詳細を追加できます。
質問をしても大丈夫です 。説明がどれほど正確であっても、常に疑問があります。何かが常に過小評価されます。よくわからないことについて質問してください。質問できない場合は、合理的な仮定を立て、その仮定を書き留めてください。
常に複数の方法があります 各システムをモデル化します。明らかに悪いモデルもありますが、他のほとんどのモデルでは、モデルが正しいか間違っているかを判断するのが困難です。モデルは、システムの目的、データがシステムに到達する方法、さらには設計者の個人的な好みによって異なります。経験を積むにつれて、設計上の決定についてより自信を持てるようになります。
例：レンタカーシステム
例として、レンタカーシステムのデータベースモデルを作成します。まず、システムの説明を見てください：
レンタカー会社は、顧客に車をレンタルします。会社は数台の車を所有しています。各車には、ブランド、モデル名、製造年、走行距離、色などがあります。車は、小型、中型、大型、リムジンのさまざまなカテゴリに分類されます。
会社には、レンタカーを借りることができる場所がたくさんあります。レンタル場所は、全国のさまざまな都市にあります。 1つの都市に複数の会社の場所が存在する可能性があります。
有効な運転免許証を持っている21歳以上の人なら誰でも、レンタカーを借りることができます。 25歳未満または75歳以上のお客様は、他のお客様とは異なる（より高い）料金を支払います。
顧客は通常、レンタカーを借りる前に、車の予約をします。顧客は、車を借りる日付、乗車場所、降車場所、および借りたい車のカテゴリを指定します。顧客は、GPS、子供用のチャイルドシートなど、車内に追加の機器が必要であることを指定できます。
顧客が車を借りるとき、彼はピックアップとドロップオフの場所、およびドロップオフの日付を宣言します。顧客はさまざまな種類の保険を購入できます。また、クレジットカード会社などが保険に加入しているため、保険は不要であると判断することもできます。お客様は、早期ドロップオフの可能性、さまざまな給油オプションなど、追加のオプションを選択できます。
顧客は車を返却するときに料金を支払います。
まず、すべての名詞を強調表示します。
次の段階は、テーブルを見つけることです 。システム内の基本的なエンティティを探します。まず、少なくとも次のものが必要です。車、顧客、場所、都市、設備、（車）カテゴリ、保険。それらを図に入れます。 idを追加しました すべてのテーブルにはある種のIDが必要であるため、すべてのテーブルの列。主キーは後でいつでも変更できます。
基本的なシステムエンティティがモデルに含まれていますが、システムのコア機能であるレンタカーと予約が欠落していることに注意してください。最初に言ったことを思い出してください。テーブルは物理オブジェクトであるだけでなく、イベントやトランザクションでもあります。 reservationを追加する必要があります およびrental テーブルとしても。どうぞ：
次に、モデル内のテーブル間に参照を追加します。参照を追加するときに番号を付けました。各リファレンスの横にあるメモは、いつ追加されたかを示しています。
- 各車はカテゴリに属します
- 各予約は車のカテゴリ用です
- 各場所は都市にあります
- 各予約には、送迎場所があります。
- 各予約は顧客が行います
- 各レンタルは顧客によって行われます
- 各レンタルは特定の車用です
- 各レンタルには、送迎場所があります。
- 各レンタルはいくつかの保険に関連しています。しかし、レンタルごとに1つの保険しかありませんか？いいえ。レンタルに関連する保険は多数あります（車両の損傷、人身傷害、他人の車の負傷に対する保険など）。
rental_insuranceという中間テーブルを追加しましたrentalに接続 およびinsuranceテーブル。
車と設備の間の参照がまだ不足しています。機器は車に恒久的に取り付けられていますか、それともある車から別の車に移動できますか？説明にはその質問に対する答えがないので、合理的な仮定を立てます。はい、移動できます。新しいテーブルcar_equipmentを追加します およびcar間の参照 およびequipment 。
companyを削除します テーブル。レンタル会社は暗黙的にシステムに存在します。結局のところ、別の会社が独自のシステムと独自のデータベースを持つことになります。
最後に、列とそのデータ型を追加します。また、reservationの間に関係がないことにも気づきました。 およびequipment 。しかし、特定の機器の予約は行われていますか？いいえ、それはある種の機器用に作られています。テーブルequipment_categoryを追加します テーブルを接続しますreservation およびequipment それに。
終わりましたか？説明をもう一度読んでください。私たちのデータベースモデルはまだ料金を省略しています。ええと...
これは読者のための演習です。 （ただし、データベースモデリングのスキルを練習したくない場合は、ここでレンタカー会社向けのすぐに使用できるデータベース構造を見つけることができます。）