データベース設計

データベース設計とは、データベースモデルに従ってデータを編成することです。設計者は、どのデータを保存するか、データ要素がどのように相互に関係するかを決定します。この情報を使用して、データをデータベースモデルに適合させ始めることができます。^[1]データベース管理システムはそれに応じてデータを管理します。

データベース設計は、いくつかのステップで構成されるプロセスです。

データベース設計の最初のステップは、データを分類し、相互関係を識別することです。データの理論的な表現は、オントロジーまたは概念データ モデルと呼ばれます。

ほとんどの場合、データベースを設計する人は、財務情報や生物学情報など、保存されるデータが抽出されるドメインの専門知識ではなく、データベース設計の専門知識を持つ人です。したがって、特定のデータベースに保存されるデータは、そのドメインの専門知識を持ち、システム内に保存されるデータの意味を認識している人と協力して決定する必要があります。

このプロセスは、一般的に要件分析の一部と考えられており、ドメイン知識を持つ人々から必要な情報を引き出すためにデータベース設計者のスキルが必要です。これは、必要なドメイン知識を持つ人々が、保存する必要がある個別のデータ要素の観点から考えることに慣れていないため、データベースのシステム要件を明確に表現できないことが多いためです。保存されるデータは、要件仕様によって決定できます。^[2]

データベース設計者は、データベース内に格納されるデータを把握したら、次にデータ内のどこに依存関係があるかを判断する必要があります。データが変更されると、目に見えない他のデータも変更されることがあります。たとえば、名前と住所のリストでは、複数の人が同じ住所を持つことができるが、1 人の人が複数の住所を持つことはできないという状況を想定し、住所は名前に依存します。名前とリストが指定されると、住所は一意に決定できます。ただし、逆は当てはまりません。つまり、住所とリストが指定されると、1 つの住所に複数の人が住むことができるため、名前を一意に決定することはできません。住所は名前によって決定されるため、住所は名前に依存していると見なされます。

(注:リレーショナル モデルは、その中のデータ要素間の関係を記述するため、このように呼ばれるという誤解がよくあります。これは正しくありません。リレーショナル モデルは、関係と呼ばれる数学的構造に基づいているため、このように呼ばれています。)

得られた情報は、図やスキーマで形式化できます。この段階では、概念スキーマです。

最も一般的な概念スキーマの 1 つは、ER (エンティティ リレーションシップ モデル) 図です。

ER 図の属性は通常、属性の名前が付いた楕円としてモデル化され、属性を含むエンティティまたは関係にリンクされます。

ERモデルは情報システム設計でよく使用され、例えば概念構造設計段階で情報要件やデータベースに格納される情報の種類を記述するために使用されます。^[3]

さまざまな情報間の関係と依存関係が判明したら、データを論理構造に整理し、データベース管理システムがサポートするストレージ オブジェクトにマッピングすることができます。リレーショナル データベースの場合、ストレージ オブジェクトは行と列にデータを格納するテーブルです。オブジェクト データベースの場合、ストレージ オブジェクトは、データを管理およびアクセスするアプリケーションを作成するために使用するオブジェクト指向プログラミング言語で使用されるオブジェクトに直接対応します。関係は、関連するオブジェクト クラスの属性として、またはオブジェクト クラスで動作するメソッドとして定義できます。

このマッピングは通常、実際のオブジェクトか抽象的なオブジェクトかを問わず、単一のオブジェクトに依存する関連データの各セットをテーブルに配置することによって実行されます。これらの依存オブジェクト間の関係は、さまざまなオブジェクト間のリンクとして保存されます。

各テーブルは、論理オブジェクトの実装、または 1 つ以上の論理オブジェクトの 1 つ以上のインスタンスを結合する関係を表すことができます。テーブル間の関係は、子テーブルと親テーブルを接続するリンクとして保存できます。複雑な論理関係はそれ自体がテーブルであるため、複数の親へのリンクを持つ可能性があります。

リレーショナル データベース設計の分野において、正規化とは、データベース構造が汎用クエリに適しており、データの整合性の損失につながる可能性のある挿入、更新、削除の異常など、特定の望ましくない特性がないことを確認するための体系的な方法です。

標準的なデータベース設計ガイドラインでは、設計者は完全に正規化された設計を作成する必要があるとされています。選択的な非正規化はその後実行できますが、パフォーマンス上の理由からのみです。トレードオフは、ストレージ スペースとパフォーマンスです。設計が正規化されるほど、データの冗長性は少なくなります (したがって、格納に必要なスペースが少なくなります)。ただし、一般的なデータ取得パターンでは、複雑な結合、マージ、並べ替えが必要になる場合があります。これにより、データの読み取りと計算サイクルが増えます。データ ウェアハウス設計に対するディメンション モデリングアプローチなど、一部のモデリング分野では、非正規化設計、つまり大部分が3NFに準拠しない設計が明示的に推奨されています。正規化は、 1NF、2NF、 3NF 、Boyce-Codd NF (3.5NF)、4NF、5NF 、および6NFの正規形で構成されます。

ドキュメント データベースでは、別のアプローチが採用されています。このようなデータベースに保存されるドキュメントには、通常、複数の正規化されたデータ ユニットが含まれており、多くの場合、ユニット間の関係も含まれています。すべてのデータ ユニットと問題の関係が一緒に取得されることが多い場合、このアプローチにより取得回数が最適化されます。また、一貫性が自己完結している明確に識別可能なデータ ユニットが存在するため、データの複製方法も簡素化されます。もう 1 つの考慮事項は、このようなデータベース内の 1 つのドキュメントの読み取りと書き込みには、1 つのトランザクションが必要になることです。これは、マイクロサービスアーキテクチャでは重要な考慮事項となる可能性があります。このような状況では、多くの場合、ドキュメントの一部は API を介して他のサービスから取得され、効率上の理由からローカルに保存されます。データ ユニットがサービス間で分割されると、サービス コンシューマーをサポートするための読み取り (または書き込み) に複数のサービス呼び出しが必要になる可能性があり、複数のトランザクションの管理が必要になる可能性があります。これは、好ましくない場合があります。

データベースの物理設計では、ストレージ メディア上のデータベースの物理的な構成を指定します。これには、データ要素とデータ型の詳細な仕様が含まれます。

このステップでは、DBMSデータ ディクショナリにあるインデックスオプションやその他のパラメータを指定します。これは、モジュール、データベースのハードウェア、システムのソフトウェア仕様を含むシステムの詳細な設計です。物理層で対処されるいくつかの側面:

• セキュリティ – エンドユーザーと管理者のセキュリティ。
• パフォーマンス - 主に読み取り/更新/削除クエリのインデックス作成、挿入クエリのデータ型の選択によって対処されます。
• レプリケーション – どのデータが別のデータベースにコピーされるか、またその頻度。マスターは複数あるか、それとも 1 つだけか?
• 高可用性 - 構成がアクティブ/パッシブであるかアクティブ/アクティブであるかにかかわらず、トポロジ、調整スキーム、信頼性の目標などをすべて定義する必要があります。
• パーティション分割 - データベースが分散されている場合、単一のエンティティについて、データはデータベースのすべてのパーティション間でどのように分散され、パーティション障害はどのように考慮されるか。
• バックアップおよび復元スキーム。

アプリケーション レベルでは、物理設計の他の側面として、ストアド プロシージャ、マテリアライズド クエリ ビュー、OLAPキューブなどを 定義する必要がある場合があります。

次の手順は、リレーショナル DBMS である Microsoft Accessのデータ モデリング プロセスの提案です。

1. データベースの目的を決定します– これは、残りの手順の準備に役立ちます。
2. 必要な情報を見つけて整理する- 製品名や注文番号など、データベースに記録するすべての種類の情報を収集します。
3. 情報をテーブルに分割する- 情報項目を製品や注文などの主要なエンティティまたは主題に分割します。各主題はテーブルになります。
4. 情報項目を列に変換する– 各テーブルに保存する必要がある情報を決定します。各項目はフィールドになり、テーブル内の列として表示されます。たとえば、従業員テーブルには、姓や入社日などのフィールドが含まれる場合があります。
5. 主キーの指定– 各テーブルの主キーを選択します。主キーは、各行を一意に識別するために使用される列または列のセットです。例としては、製品 ID や注文 ID などがあります。
6. テーブルの関係を設定する– 各テーブルを確認し、あるテーブルのデータが他のテーブルのデータとどのように関連しているかを判断します。必要に応じて、テーブルにフィールドを追加するか、新しいテーブルを作成して関係を明確にします。
7. 設計の改良– 設計のエラーを分析します。テーブルを作成し、サンプル データのレコードをいくつか追加します。テーブルから期待どおりの結果が得られるかどうかを確認します。必要に応じて設計を調整します。
8. 正規化ルールを適用する– データ正規化ルールを適用して、テーブルが正しく構造化されているかどうかを確認します。必要に応じてテーブルを調整します。^[4]

• S. Lightstone、T. Teorey、T. Nadeau、「物理データベース設計: インデックス、ビュー、ストレージなどを活用するためのデータベース プロフェッショナル ガイド」、Morgan Kaufmann Press、2007 年。ISBN 0-12-369389-6 
• M. Hernandez、「一般人のためのデータベース設計: リレーショナル データベース設計の実践ガイド」、第 3 版、Addison-Wesley Professional、2013 年。ISBN 0-321-88449-3 

• [1]
• [2]
• データベース正規化の基礎 2007-02-05 にWayback Machineにアーカイブされました(Mike Chapple (About.com))
• データベース正規化の紹介 2011-09-28 にWayback Machineでアーカイブ、パート 2 2011-07-08 にWayback Machineでアーカイブ
• 「データベース正規化入門」。2011 年 6 月 6 日にオリジナルからアーカイブ。2012年 2 月 25 日に取得。
• 「正規化」。2010年1月6日にオリジナルからアーカイブ。2012年2月25日に閲覧。