次のコースは MOOC 学習から派生したものです。元のコースを参照してください:データベースの原則とアプリケーション
の大学院レビュー
データベース設計
データベース設計は、アプリケーションシステム要件分析のデータ要件に基づいて、データの抽象化、データ表現、データストレージの問題を解決し、アプリケーション要件を満たすシンプルで効率的、標準化された合理的なデータベースを設計することを目的としています。最終的に、DBMS に格納できるデータベースの論理構造と物理構造が得られます。
データベースの設計手法は、初期の経験に基づく直観的な設計から、ソフトウェア工学の考え方による標準化された設計に発展し、コンピュータ支援設計や設計ツールソフトによる自動設計を活用するように開発されてきました。
ERモデルに基づく標準的な設計手法に基づき、データベース設計は通常、要件分析、概念構造設計、論理構造設計、物理構造設計、データベース実装、データベース運用、保守の6段階に分かれます。
要件分析はデータベース全体の設計の基礎であり、主にユーザーとアプリケーションシステムのデータ要件を正確に理解して分析し、データベースに保存および管理する必要があるデータを明確にし、データセキュリティに対するユーザーのニーズを明確にします。および整合性、アクセス権の設定など。
概念構造の設計は、データベース全体の設計の鍵となります。要件分析に基づいて、データを抽象化した結果をERモデルなどの概念モデルを用いて表現し、特定のDBMSに依存しない概念モデルを得る必要があります。
論理構造設計では、概念構造設計で得られた概念モデルを、選択したDBMSがサポートするデータモデルに対応するデータベースモード、例えばリレーショナルデータベースモードに変換し、最適化する。
物理構造設計は、論理構造設計から得られたデータベースモデルであり、選択したDBMSがサポートするデータ定義言語を使用してデータベースの3レベルのスキーマ構造を記述し、アプリケーション環境に適したストレージ構造とアクセス方法を決定します。 。
データベース実装の段階では、特定の DBMS 上で物理構造設計の結果が実現され、データベースが構築され、データベースのプログラミングが実行され、データがストレージに編成され、テスト操作が実行されます。
正式に運用されるデータベースは、システム運用中に継続的に評価・改善を行う必要があります。
データベース設計は、上記の 6 つの段階を継続的に反復し、段階的に改良していくプロセスです。データベースの設計にはデータベース システム アプリケーション ソフトウェアの設計が伴いますが、設計プロセスではこの 2 つを組み合わせて相互に補完する必要があります。
データ フロー図は、データベース構造化設計アプローチの (要件分析) フェーズを記述するために使用されるツールです。
情報要件は、組織が管理する必要があるデータとその構造を表します。
処理要件は、組織がデータに対して頻繁に実行する必要がある処理操作を表します。
質問: リレーショナル データベース設計の理論的サポート: リレーショナル データベース設計プロセスの初期に学んだデータベース理論をどのように使用しますか?
回答: 概念設計段階では、ER モデルを使用してデータベースの概念モデルを設計し、論理設計段階では、リレーショナル正規化理論を使用してデータベース スキーマを設計します。
概念的な構造設計
データベース概念構造設計フェーズで得られた結果は**: ER図で表される概念構造**です。
情報の構造を説明するための E-R 図ですが、コンピューター内の情報の表現には関与しません。
ステップ：
1. エンティティとエンティティの属性を抽出し、ER図を描画する
2. エンティティ間の関係と、接続が発生した後に生成される属性特性を決定し、描画します
3. エンティティと関係の ER 図を結合して、完全な ER 図を構築する
サブ ER 図をマージする場合、各サブ図の不一致、つまり競合を除去する必要があります。ER 図間の競合には主に 3 つのタイプがあります。
つまり、属性の競合、名前の競合、構造の競合です。
- 名前の競合: 同義語または同義語
- 属性の競合: 属性タイプの競合
- 構造の競合: プロパティ値の単位の競合
論理構造設計
論理構造の設計フェーズで得られる結果は次のとおりです。特定の DBMS がサポートするデータの論理構造
リレーショナル データベースの正規化理論は、主にデータベースの論理構造をガイドするために使用されます。
リレーショナル スキーマの設計は、(論理構造設計) フェーズのタスクです。
- 1:1 関係は、独立した関係スキーマに変換したり、関係の両端のエンティティに対応する関係スキーマと結合したりできます。
例: 2 つの関係: クラス (クラス番号、学科、専攻、人数) モニター (学生番号、名前)
1つ目の方法：担当者（学生番号、クラス番号）を追加するか、
2種類目：クラス（クラス番号、学科、専攻、人数、モニター学生ID） モニター（学生ID、名前）
- 1: n 接続は独立したリレーショナル スキーマに変換でき、リレーションの n 末端エンティティに対応するリレーショナル スキーマとマージすることもできます。
たとえば、クラス (クラス番号、学科、専攻、人数) 学生 (学生番号、名前)という 2 つの関係が考えられます。
最初のタイプ: テーブルの追加 (所属): (学生番号、クラス番号)
2種類目：class（クラス番号、学科、専攻、人数）student（学生番号、名前、クラス番号）
- m:n 関係は、独立したリレーショナル スキーマにのみ変換できます。
たとえば、次の 2 つの関係: コース (コース番号、コース名、単位) 学生 (学生番号、名前)
コース選択結果（学生番号、コース番号、成績）
- 3 つ以上のエンティティ間の多変量関係は、個別に関係モデルに変換する必要があります。
- 子エンティティと ISA エンティティの関連付けの変換
ERモデルからリレーショナルモデルに変換する場合、M:N関係をリレーショナルモデルに変換する場合、リレーショナルモデルの候補キーは(M末端実体キーワードとN末端実体キーワードの組み合わせ)となります。
ER モデルに 3 つの異なるエンティティ タイプと 3 つの m:n 関係がある場合、ER モデルをリレーショナル モデルに変換する規則に従って、変換後の関係の数は ( 7 ) になります。
リレーショナル データベースの論理構造設計フェーズで完了する主なタスクは次のとおりです ( )。
ERモデルをリレーショナル スキーマに変換 -> リレーショナル スキーマの正規化 -> リレーショナル スキーマの最適化 -> ユーザー スキーマの設計
物理構造設計
設計で解決すべき課題：データベースの格納構造の設計＋データベースの格納方法の設計、ディスクへの最小限のI/O回数の確保
設計の目標は、ストレージ容量が少なく、データアクセス効率が高く、メンテナンスコストが低いデータベース物理モデルを取得することです。
この段階で得られる結果は、ストレージ構造とアクセス方法を含むデータベースの物理構造です。
データベースの格納構造を決定する、つまり、リレーションシップ、インデックス、クラスタ、ログ、バックアップなどのデータの格納配置や格納構造を決定するのが、データベース設計（物理構造設計）の作業です。
（物理構造設計） SQL言語で定義されたデータベーススキーマを取得できます。
の：
- ユーザーのアウトドアモードを定義する
- 主にビューを定義するため
- 定義内パターン
- インデックスは DBMS で採用されている主な保存方法であり、DBMS はインデックスに基づいてクエリ プランをカスタマイズおよび最適化できます。
- インデックスの作成により、データ ファイルのストレージ構造が決定されます。
- データベースを定義する
Q: インデックスの作成が内部スキーマの定義の一部になるのはなぜですか?
回答: 内部モードは物理モードとも呼ばれ、データ ストレージのファイル構造、インデックス、クラスター、ハッシュ、その他のアクセス方法とアクセス パスなど、データベースの物理ストレージ構造と物理アクセス方法を示します。したがって、インデックスの作成は内部スキーマの定義の一部です。