私は本といくつかの記事をオンラインで読み直し、適切なデータベースを設計するためのステップの短いリストを作成しました (もちろん、最初にデータベース設計の基本を理解する必要があります)。ステップについては、以下で詳しく説明します。
（本には多くの手順が記載されています：Database Systems - Design, Implementation and Management (9th Edition)ページ番号もそれを参照していますが、ここでできる限り説明し、この回答を編集してより完全なものにします）
- 組織の業務内容の詳細な説明を作成します。
- オペレーションの記述から、ビジネス ルールを特定します。
- ビジネス ルールから主要なエンティティと関係を特定します。
- エンティティ/関係を EER モデルに変換する
- 命名規則を確認する
- ERR モデルを論理モデルにマップする (pg 400)*
- 論理モデルの正規化 (pg 179)
- DB 設計の改善 (pg 187)
- 論理モデルの整合性制約の検証 (pg 402) (長さなど)
- ユーザー要件に対して論理モデルを検証する
- テーブルを mySQL コードに変換します (ワークベンチでエクスポート関数を使用して EER を SQL ファイルに変換し、次に mySQL に変換します)。
*ワークベンチとそこで設計した ER モデルの作業を使用している場合は、この手順を省略できます。
1.事業会社を詳しく説明してください。個人的なプロジェクトを作成している場合は、それを詳細に説明します。会社と協力している場合は、会社を説明する文書を要求し、従業員に情報をインタビューします (インタビューでは一貫性のない情報が生成される可能性があります。設計にとってどの情報がより重要であるかを監督者に確認してください)。 )
2.収集した情報を見て、そこからルールを生成し始めます。自分の知識に不足している情報を必ず埋めてください。先に進む前に、社内の監督者に確認してください。
3.ビジネス ルールから主要なエンティティと関係を特定します。設計プロセス中、データベース設計者は、エンティティ、属性、および関係の定義を支援するためにインタビューだけに依存するわけではないことに注意してください。組織が日常業務で使用する帳票やレポートを調べると、驚くほど多くの情報が収集されます。(123ページ)
4.データベースが複雑な場合は、ERD 設計を次のサブステップに分割できます
i) 外部モデルを作成する (46 ページ)
ii) 外部モデルを組み合わせて概念モデルを形成する (48 ページ)
Follow the following recursive steps for the design (or for each substep)
I. Develop the initial ERD.
II. Identify the attributes and primary keys that adequately describe the entities.
III. Revise and review the ERD.
IV. Repeat steps until satisfactory output
You may also use entity clustering to further simplify your design process.
ERD によるデータベースの記述: 実線を使用して弱いエンティティを接続します (弱いエンティティとは、親エンティティなしでは存在できず、PK に親 PK を含むものです)。破線を使用して強力なエンティティを接続します (強力なエンティティとは、他のエンティティから独立して存在できるエンティティです)
5.名前が命名規則に従っているかどうかを確認します。私は以前ここで命名規則の提案をしていましたが、人々はあまり好きではありませんでした。独自の基準に従うか、オンラインで命名規則を調べることをお勧めします。非常に便利な命名規則を見つけた場合は、コメントを投稿してください。
6.
論理設計には、通常、ER モデルを一連の関係 (テーブル)、列、および制約定義に変換することが含まれます。
次の手順を使用して、ER を論理モデルに変換します。
- 強力なエンティティのマッピング (他のエンティティの存在を必要としないエンティティ)
- スーパータイプ/サブタイプの関係をマッピングする
- 弱いエンティティのマッピング
- 二項関係をマッピングする
- より高度な関係をマッピングする
7.論理モデルを正規化します。必要な特性を得るために、論理モデルを非正規化することもできます。（パフォーマンスの向上など）
8.
属性の原子性を改善する - 一般的に、原子性の要件に注意を払うことをお勧めします。アトミック属性は、これ以上細分化できない属性です。このような属性は原子性を示すと言われています。原子性の程度を向上させることで、クエリの柔軟性も得られます。
データの粒度に必要な主キーの絞り込み - 粒度とは、テーブルの行に格納された値によって表される詳細レベルを指します。前述のように、最小レベルの粒度で格納されたデータはアトミック データと呼ばれます。たとえば、ASSIGN_HOURS 属性が、特定のプロジェクトで特定の従業員が働いた時間を表すとします。しかし、それらの値は最小レベルの粒度で記録されていますか? つまり、ASSIGN_HOURS は、時間合計、日合計、週合計、月合計、または年合計を表しますか? 明らかに、ASSIGN_HOURS にはより注意深い定義が必要です。この場合、関連する質問は次のようになります: ASSIGN_HOURS データを記録するのは、どの時間枠 (時間、日、週、月など) ですか? 例えば、EMP_NUM と PROJ_NUM の組み合わせが、ASSIGNMENT テーブルで受け入れ可能な (複合) 主キーであると仮定します。この主キーは、従業員がプロジェクトの開始以降に作業した合計時間数のみを表すのに役立ちます。ASSIGN_NUM などの代理主キーを使用すると、粒度が低くなり、柔軟性が向上します。たとえば、EMP_NUM と PROJ_NUM の組み合わせが主キーとして使用され、従業員が ASSIGNMENT テーブルに 2 つの「勤務時間」エントリを作成するとします。そのアクションは、エンティティの完全性要件に違反しています。複合 PK の一部として ASSIGN_DATE を追加しても、従業員が同じ日に同じプロジェクトに対して 2 つ以上のエントリを作成すると、エンティティの整合性違反が生成されます。
次の質問に答えてみてください。等。
以下のコメントに提案やより良い説明へのリンクを自由に残してください。回答に追加します
