Course All lectures for JA purposes - Lecture: 主要なデータベース設計の手順

2.1. コンセプチュアルデザイン

データベースの設計は、次の 3 つの段階で実行されます。

コンセプチュアルデザイン;
論理的なデザイン。
物理的なデザイン。

概念設計フェーズの目的は、対象領域に関するユーザーのアイデアに基づいて概念データモデルを作成することです。これを達成するために、一連の一連の手順が実行されます。エンティティ (概念的) スキーマの例:

1. エンティティとそのドキュメントの定義。エンティティを識別するために、他から独立して存在するオブジェクトが定義されます。このようなオブジェクトはエンティティです。各エンティティには、ユーザーが理解できる意味のある名前が付けられます。エンティティの名前と説明がデータディクショナリに入力されます。可能であれば、各エンティティの予想されるインスタンス数が設定されます。

2. エンティティとその文書間の関係の決定。データベース設計要件を満たすために必要なエンティティ間の関係のみが定義されます。それぞれの種類が設定されています。エンティティのメンバーシップクラスが明らかになります。リンクには動詞で表現される意味のある名前が割り当てられます。各接続の詳細な説明は、そのタイプと、接続に参加しているエンティティの所属クラスを示し、データディクショナリに入力されます。

3. 対象領域の ER モデルの作成。ER 図は、エンティティとエンティティ間の関係を表すために使用されます。これらに基づいて、モデル化された対象領域の単一の視覚イメージ、つまり対象領域の ER モデルが作成されます。

4. 属性の定義とそのドキュメント。作成された ER モデルのエンティティを記述するすべての属性が明らかになります。各属性には、ユーザーが理解できる意味のある名前が付けられます。次の情報が各属性のデータディクショナリに保存されます。

属性名と説明。
値の型と次元。
属性のデフォルト値 (存在する場合)。
属性が NULL 値を持つことができるかどうか。
属性が複合属性であるかどうか、複合属性である場合はどのような単純属性で構成されているか。たとえば、属性「クライアントのフルネーム」は、単純な属性「姓」、「名」、「父称」で構成することも、「Sidorsky Evgeniy Mikhailovich」などの単一の値を含む単純な属性にすることもできます。ユーザーが「名前」の個々の要素にアクセスする必要がない場合、属性は単純なものとして表示されます。
属性が計算されるかどうか、計算される場合はその値がどのように計算されるか。

5. 属性値の定義とそのドキュメント。ER モデルに参加しているエンティティの属性ごとに、有効な値のセットが決定され、名前が割り当てられます。たとえば、属性「アカウントの種類」には、「預金」、「現在」、「オンデマンド」、「カード口座」の値のみを含めることができます。属性に関連するデータディクショナリエントリは、属性値セットの名前で更新されます。

6. エンティティの主キーの定義とそのドキュメント。このステップは、インスタンスの一意の識別を可能にするエンティティの属性または属性セットとしての主キーの定義によって導かれます。主キー情報はデータディクショナリに配置されます。

7. エンドユーザーとの概念的なデータモデルについてのディスカッション。概念的なデータモデルは、開発されたデータモデルの説明を含む付属のドキュメントを備えた ER モデルによって表されます。ドメインの不一致が見つかった場合は、ユーザーが提案したモデルが個人的な見解を適切に反映していることをユーザーが確認するまで、モデルが変更されます。

2.2 論理設計

論理設計段階の目的は、選択したデータモデルに基づく概念モデルを、後でデータベースの物理実装に使用される DBMS の機能に依存しない論理モデルに変換することです。これを実現するには、次の手順を実行します。

論理データベーススキーマの例。

1. データモデルの選択。ほとんどの場合、データの表形式の表示の明瞭さと操作の利便性により、リレーショナルデータモデルが選択されます。

2. ER モデルに基づいて一連のテーブルを定義し、文書化します。ER モデルのエンティティごとにテーブルが作成されます。エンティティ名はテーブルの名前です。テーブル間の関係は、主キーと外部キーのメカニズムを通じて確立されます。テーブルの構造とテーブル間に確立された関係が文書化されます。

3. テーブルの正規化。正規化を適切に実行するには、設計者はデータのセマンティクスと使用パターンを深く理解する必要があります。このステップでは、前のステップで作成したテーブルに正規化手順を適用して、その構造が正しいかどうかをチェックします。これは、各テーブルを少なくとも 3 番目の NF に持っていくことにあります。正規化の結果、非常に柔軟なデータベース設計が得られ、必要な拡張を簡単に行うことができます。

4. ユーザーが提供したすべてのトランザクションを実行できるかどうかの論理データモデルをチェックします。トランザクションは、データベースの内容を変更するために個々のユーザーまたはアプリケーションプログラムによって実行される一連のアクションです。したがって、BANK プロジェクトにおけるトランザクションの例としては、特定のクライアントの口座を管理する権利を別のクライアントに譲渡することが考えられます。この場合、データベースに対して複数の変更を一度に行う必要があります。トランザクション中にコンピュータがクラッシュした場合、一部の変更はすでに行われ、その他の変更は行われていないため、データベースは不整合な状態になります。したがって、データベースを以前の一貫した状態に戻すには、すべての部分的な変更を元に戻す必要があります。

トランザクションのリストは、対象領域におけるユーザーのアクションによって決定されます。ER モデル、データディクショナリ、および主キーと外部キーの間の確立された関係を使用して、必要なすべてのデータアクセス操作を手動で実行しようとします。手動操作が失敗した場合、コンパイルされた論理データモデルは不適切であり、除去する必要があるエラーが含まれています。おそらく、それらはエンティティ、関係、または属性のモデルのギャップに関連していると考えられます。

5. データ整合性サポート要件とその文書の決定。これらの要件は、競合するデータがデータベースに入力されるのを防ぐために設けられる制限です。このステップでは、実装の特定の側面に関係なく、データの整合性の問題が取り上げられます。次の種類の制限を考慮する必要があります。

必要なデータ。NULL 値を持つことができない属性があるかどうかを確認します。
属性値の制限。属性の有効な値が定義されています。
エンティティの完全性。これは、エンティティの主キーに NULL 値が含まれていない場合に達成されます。
参照整合性。外部キー値は、親エンティティのテーブル行の 1 つの主キーに存在する必要があることは理解されています。
ビジネスルールによって課される制限。たとえば、BANK プロジェクトの場合、クライアントが 3 つ以上のアカウントを管理することを禁止するルールが採用される場合があります。

確立されたすべてのデータ整合性制約に関する情報は、データディクショナリに配置されます。

6. 論理データモデルの最終バージョンの作成とユーザーとのディスカッション。このステップでは、論理データモデルを表す ER モデルの最終バージョンを準備します。モデル自体と、データディクショナリやリレーショナルテーブルリンクスキーマを含む更新されたドキュメントは、ユーザーによるレビューと分析のために提供されます。ユーザーは、モデルが対象領域を正確に表現していることを確認する必要があります。

2.3. 物理設計

物理設計段階の目的は、コンピュータの外部メモリにあるデータベースの特定の実装を記述することです。これは、データストレージ構造とデータベースデータにアクセスする効率的な方法について説明します。論理設計では、何を行う必要があるかという質問に答えます。物理設計では、それを行う方法が選択されます。物理設計手順は以下のとおりです。

1. 選択した DBMS を使用してデータベーステーブルを設計します。マシンメディア上でホストされるデータベースの作成に使用するリレーショナル DBMS が選択されています。テーブルを設計するためのその機能は深く研究されています。次に、DBMS 環境でのテーブルとその接続スキームの設計が実行されます。準備されたデータベースプロジェクトについては、付属のドキュメントで説明されています。

2. 選択した DBMS の環境にビジネスルールを実装します。テーブル内の情報の更新は、ビジネスルールによって制限される場合があります。これらの実装方法は、選択した DBMS によって異なります。対象領域の要件を実装するためのシステムには、より多くの機能を提供するものと、より少ない機能を提供するものがあります。一部のシステムでは、ビジネスルールの実装がまったくサポートされていません。この場合、アプリケーションはその制限を実装するために開発されます。

ドメインビジネスルールの実装に関連して行われるすべての決定は、付属のドキュメントに詳細に記載されています。

3. データベースの物理的な構成を設計します。このステップでは、テーブルに最適なファイル構成を選択します。設計中のデータベースで実行されるトランザクションが特定され、その中で最も重要なものが強調表示されます。トランザクションのスループット (一定の時間間隔で処理できるトランザクションの数) と、応答時間 (1 つのトランザクションを完了するのに必要な時間) が分析されます。トランザクションのスループットを向上させ、応答時間を短縮するよう努めています。

これらの指標に基づいて、データベースからのデータの選択を高速化するテーブルにインデックスを定義するか、テーブルの正規化レベルの要件を軽減することによって、データベースのパフォーマンスを最適化するための決定が行われます。作成したデータベースを格納するために必要なディスク容量が見積もられます。それを最小限に抑えるよう努めてください。

上記の問題に関して行われた決定は文書化されます。

4. データベース保護戦略の開発。データベースは貴重な企業リソースであり、その保護には細心の注意が払われています。これを行うには、設計者は、選択した DBMS によって提供されるすべての保護を完全かつ明確に理解する必要があります。

5. データベース機能の監視とその調整の組織化。データベースの物理プロジェクトの作成後、その機能の継続的な監視が組織化されます。データベースのパフォーマンスレベルに関する結果の情報は、データベースのチューニングに使用されます。これには、選択した DBMS の手段も関係します。

機能しているデータベースに変更を加える決定は、十分に検討し、検討する必要があります。