1. 原文書と主体との関係
それは一対一の関係、一対多、多対多の関係です。 一般的に、これらは一対一の関係性、すなわち原本文書のペアです
は一つの実体にのみ対応すべきです。 特別な場合には、1対1または多対1の関係、すなわち1つの原文書が複数の現実に対応することもあります
本体、またはある存在に対応する複数の原文書。 ここでのエンティティは基本的な表として理解できます。 このやり取りを明確にした後、私たちのために設計します
エントリーインターフェースは非常に便利です。
〖例1〗:従業員の履歴書情報は、人事情報システムにおける3つの基本表、すなわち従業員基本情報表と社会表に対応します
関係表、仕事履歴書フォーム。 これは「1つの原文書が複数のエンティティに対応する」という典型的な例です。
2. 主鍵と外部鍵
一般的に、エンティティは主鍵も外部鍵も持っていません。 E-R図では、葉部分のエンティティが主キーを定義できます。
また、主鍵を定義しなくても(子鍵がないため)、外部鍵は必須(父鍵があるため)こともあります。
主キーおよび外部キーの設計は、グローバルデータベース設計において重要な位置を占めています。 グローバルデータベースの設計が完了すると、
アメリカのデータベース設計専門家は「鍵、鍵があちこちにある、鍵だけだ」と言い、これが彼のデータベース設計経験です
また、情報システムの核(データモデル)に関する彼の非常に抽象的な考えも反映しています。 なぜなら、主鍵は非常に抽象的な実体であり、主鍵は
エンティティ間の接続を表す外来キーのペア。
3. 基本表の性質
基本テーブルは中間テーブルや一時テーブルとは異なり、以下の4つの特徴を持っています。
(1) 原子性。 ベーステーブルのフィールドはもはや分解可能ではありません。
(2) 原始性。 ベーステーブルのレコードは元のデータ(基礎データ)のレコードです。
(3) 演繹的。 すべての出力データはベーステーブルとコードテーブルのデータから導出可能です。
(4) 安定性。 基本テーブルの構造は比較的安定しており、テーブル内のレコードは長期間保持されるべきです。
基本テーブルの性質を理解した後、データベース設計において基本テーブルは中間テーブルや一時テーブルと区別できます。
4. パラダイム基準
基本表とその場の関係は、できる限り第三のパラダイムに合致すべきです。 しかし、第三のパラダイムを満たすデータベース設計はしばしばそうでない
最高のデザインです。 データベースの運用効率を向上させるためには、パラダイム基準を適切に削減し、時間の余裕を確保するために冗長性を適切に増やす必要があることが多いです
目的は。
例2:表1に示されているように、商品の保管に関する基本的な表があります。 「Amount」フィールドの存在は、そのテーブルが満たされることを想定して設計されていないことを示しています
第三のパラダイムは十分で、「amount」は「unitprice」と「quantity」を掛け合わせることで得られるため、「amount」が冗長な場であることを示しています。 しかし、増加します
冗長な「amount」フィールドは、空間と時間を交換するというクエリ統計の速度を向上させることができます。
Rose 2002では、規定された列にはデータカラムと計算カラムの2種類があります。 「金額」のような列は「計算列」と呼ばれ、
「単価」や「数量」のような列は「データ列」と呼ばれます。
表1 商品表の表構造
製品名 製品 モデル 単価 数量
テレビ 29インチ 2,500 40 100,000
5. 三つのパラダイムを素人にもわかりやすく理解すること
この三つのパラダイムを分かりやすく理解することは、データベース設計に大きなメリットをもたらします。 データベース設計において、これら3つのパラダイムをより良く適用するために、
三つのパラダイムを素人にもわかりやすく理解する必要があります。
最初のパラダイム:1NFは属性に対する原子制約であり、属性が原子的であることを要求し、もはや分解できないことを求めます。
第二のパラダイムである2NFは、レコードに対する一意性制約であり、レコードに一意識別、すなわちエンティティの一意性を要求します。
パラダイム3:3NFは場の冗長性に関する制約であり、つまり他の場から導出される場はなく、その場が冗長でないことが求められます
。
冗長なデータベース設計ではそれはできません。 しかし、冗長性のないデータベースが必ずしも最良のデータベースとは限りません。時には運を良くするために
効率を達成するためには、パラダイム標準を削減し、冗長データを適切に保持する必要があります。 具体的なアプローチは、概念的データモデルを設計する際に第三のパラダイムに従うことです
物理データモデルの設計において、パラダイム標準の削減作業が考慮されます。 パラダイムを下げるということは、冗長性を可能にする場を加えることです。
6. 多対多の関係を見極め、正しく対処する能力を持つこと
もし二つの主体間に多対多数の関係がある場合、その関係は排除されるべきです。 これを消す方法は、2つの間に3つ目の実数を加えることです
遺体。 このようにして、かつては多対多の関係だったものが、今や二つの一対多の関係に変わってしまったのです。 元の2つのエンティティの属性は合理的に分配されるべきです
三つの存在のもとへ行け。 ここでの三つ目の存在は本質的により複雑な関係であり、基本的な表に対応します。 一般的に言えば、数字です
ライブラリ設計ツールは多対多関係を認識できませんが、多対多の関係性は扱えます。
例3:「図書館情報システム」において、「本」はエンティティであり、「リーダー」もエンティティです。 この二つの存在は同一です
本同士の関係は典型的な多対多の関係です。複数の読者が異なる時期に本を借りることもあれば、ある読者がさらに借りることもあります
この本だ。 この目的のために、この二つの間に「借書と返還書」と呼ばれる第三の存在を加えるべきであり、その性質は「借り時間」と「借り」です
またロゴ(0は本の借り、1は本の返却)も備えており、さらに2つの外部キー(主キーは「book」と主キーは「reader」)も持つ必要があります。これにより
それは「本」や「読者」とつながっています。
7. 主鍵PKの値法
PKはプログラマ向けのテーブル間接続ツールで、物理的な意味を持たない数字の列で、プログラムによって自動的に1に加算されます。 はい
は物理的に意味のあるフィールド名、または複数のフィールド名の組み合わせです。 しかし、前者の方が後者より優れています。 PKが複数のフィールド名の組み合わせであれば、フィールド番号を提案します
あまり数えすぎないでください。インデックスはスペースを多く取るだけでなく、速度も遅くなります。
8. データの冗長性を正しく確保すること
複数のテーブルで主キーと外部キーが繰り返し表示されることはデータ冗長の概念ではなく、多くの人はそれを認識していません
。 キーでないフィールドの繰り返しはデータ冗長性です! そしてそれは低レベルの冗長、つまり繰り返しの冗長です。 高度な冗長性はフィールドベースではありません
繰り返しですが、場の微分です。
例4:商品の「単価、数量、量」の3つの項目、「amount」は「単価」に「数量」を掛けたものから導かれます
それは冗長であり、一種の高度な冗長性です。 冗長性の目的は処理速度を向上させることです。 低レベルの冗長性のみが数を増やす
データの不整合は、同じデータが異なる時間、場所、役割から複数回入力される可能性があるためです。 したがって、私たちは高度な冗長性(pie)を推奨します。
また、低レベルの冗長性(反復冗長性)には反対しています。
9. E-R図式に対する標準的な答えは存在しません
情報システムのE-R図には標準的な答えはありません。なぜなら、その設計や描画方法は唯一無二ではなく、システムが要求する業務をカバーしているからです
範囲と機能的内容は実現可能です。 代わりに、E-R図を修正する必要があります。 単一の標準的な答えはないが、それが恣意的であることを意味するわけではない
デザイン。 良いE-Rダイアグラムの基準は、明確な構造、簡潔な関連付け、適度な数のエンティティ、合理的な属性割り当て、低レベルの冗長性がないことです。
10. ビュー技術はデータベース設計に有用です
基本テーブル、コードテーブル、中間テーブルとは異なり、ビューはデータソースの実際のテーブルに依存して存在する仮想テーブルです。 ビューはプログラマー向けです
データベースを利用するウィンドウは、ベーステーブルデータ合成の一形態であり、データ処理の手法であり、ユーザーデータの機密性の一種でもあります
つまり。 複雑な処理を行い、計算速度を向上させ、ストレージ容量を節約するために、ビューの定義深度は一般的に3層を超えないようにすべきです。 3階分くらい
それでもビューが足りない場合は、ビュー上で一時テーブルを定義し、その一時テーブル上にビューを定義します。 このようにして、視界の奥行きが繰り返し定義されます
制限はありません。
国家の政治、経済、技術、軍事、安全保障に関連する特定の情報システムにおいては、意見の役割はさらに重要である。 これらは
システムの基本テーブルの物理設計が完了すると、最初のビュー層がすぐに基本テーブル上に設定され、このレイヤービューの数と構造は基本テーブルと同じです
番号と構造はまったく同じです。 そして、すべてのプログラマーはビューのみで操作できることが定められています。 データベース管理者のみ、
複数の人が持つ「安全鍵」は、基本テーブルの上で直接操作できます。 読者の皆さんは、なぜこうなるのか考えてみてほしい。
11. 中間テーブル、文および一時テーブル
中間テーブルは統計を保存するテーブルであり、データウェアハウジング、出力レポート、クエリ結果用に設計されており、場合によっては主キーがない場合もあります。
外部キー(データウェアハウスを除く)。 一時テーブルは、プログラマーが個人用に一時的なレコードを保存するために設計します。 ベーステーブルと中間テーブルはDBAによって管理されます
一時テーブルはプログラマー自身が自動的に管理します。
12. 整合性制約は三つの側面で現れます
ドメイン整合性:Checkを使って制約を実装し、データベース設計ツールではフィールドの値範囲を定義する際にChがあります
ECKボタンで、フィールドの価値都市が定義されます。
参照整合性:PK、FK、テーブルレベルのトリガーで実装されています。
ユーザー定義の整合性:ストアドプロシージャやトリガーで実装される一部のビジネスルールです。
13. データベース設計のパッチ適用を防ぐ方法は「3つ少ない」原則です
(1) データベース内のテーブル数が少ないほど良い。 表の数が減った場合にのみ、システムのE-R図が小さく細かいものであると言え、除去されます
重複および冗長なエンティティは客観的な世界の高度な抽象化を形成し、パッチ設計を防ぐために体系的なデータ統合が行われます。
(2) 主キーを組み合わせるテーブル内のフィールドが少ないほど良い。 主キーの役割により、1つは主キーインデックスを作成すること、もう1つはサブテーブルとして機能します
外部キーを使えば、プライマリキーの組み合わせのフィールド数が減り、実行時間を節約するだけでなく、インデックスの記憶容量も節約されます。
(3) 表のフィールド数が少ないほど良い。 システム内でデータ重複がないことを示すフィールドはごくわずかです
データの冗長性はほとんどなく、さらに重要なのは、読者に「行の変更」を学ぶよう促されていることです。これにより、サブテーブルのメインテーブルにフィールドが引き込まれるのを防ぎます
は、メインテーブルに多くの自由体を残します。 いわゆる「列変更行」は、メインテーブルの内容の一部を取り出して別のテーブルを作成することです
サブテーブル。 この方法はとてもシンプルで、慣れなかったり、採用しなかったり、実装しない人もいます。
データベース設計の実務的な原則は、データの冗長性と処理速度の適切なバランスを見つけることです。 「3人少ない」というのは全体的な概観です
思考や包括的な見解は、ある原理を切り離すことはできません。 原理は絶対的ではなく相対的なものです。 「あと3回」という原則は明らかに間違っています。 試してみて
考えてみてください:もしシステムの同じ機能がカバーされている場合、100エンティティ(合計1,000の属性)からなるE--R図は、200エンティティ(合計2,000の属性)からなるE--R図よりも確実に優れています
E-R図の方がずっと良いです。
「3つ少ないもの」という原則を提唱することは、読者がデータベース設計技術を使い、体系的なデータ統合を学ぶことです。 データ統合のステップは以下の通りです:
ファイルシステムはアプリケーションデータベースに統合され、アプリケーションデータベースはトピックデータベースに統合され、トピックデータベースはグローバルな包括的データベースに統合されます。
統合度が高いほどデータ共有は強くなり、情報孤立は少なくなります
主キーの数や属性の数は少なくなります。
「3つ少ないもの」の原則を提唱する目的は、読者がパッチ技術を使ってデータベースを絶えず追加・削除・修正し、企業データを作るのを防ぐことです
ライブラリは恣意的に設計されたデータベーステーブルの「ゴミの山」、あるいはデータベーステーブルの「混乱」となり、最終的にはデータベース内の基本的なテーブルや生成を引き起こしています
コードテーブル、中間テーブル、一時テーブルはごちゃごちゃで数え切れないほど多いため、企業や機関の情報システムの維持や麻痺ができません。
「さらに3つ」という原則は誰でも行えますが、これはデータベース設計における「パッチング方法」の誤謬です。 「三人少なき」の原則
これは「少ないが良い」という原則であり、高度なデータベース設計スキルと技術を必要としますが、誰もができるわけではありません。なぜならこの原則は排除されているからです
「パッチング手法」を用いたデータベース設計の理論的基盤。
14. データベース運用効率を向上させる方法
与えられたシステムハードウェアおよびシステムソフトウェアの条件下で、データベースシステムの運用効率を向上させる方法は以下の通りです。
(1) データベースの物理設計において、パラダイムを削減し冗長性を高め、トリガーを減らし、ストアドプロシージャを増やすこと。
(2) 計算が非常に複雑でレコード数が非常に多い場合(例えば1,000万件)、複雑な計算はまずデータベース外で行われなければなりません
ファイルシステムメソッドがC++言語で計算・処理された後、最終的にテーブルに追加されます。 これが通信請求システム設計の経験です。
(3) テーブルにレコードが多すぎて、例えば1,000万件を超える場合、テーブルは横に分割されるべきです。 水平分割の実践は以下の通りです:
テーブルのレコードを、テーブルの主鍵PKの特定の値に基づいて水平に2つのテーブルに分割します。 テーブルにフィールドが多すぎると判明した場合、例えば
80の場合、テーブルは縦に分割され、元のテーブルは2つのテーブルに分割されます。
(4) データベース管理システムDBMSのシステム最適化、すなわちバッファ数などの様々なシステムパラメータの最適化。
(5) データ指向SQL言語をプログラミングに使用する際は、最適化アルゴリズムを採用しようとします。
要するに、データベースの運用効率を向上させるためには、データベースシステム、データベース設計、プログラム実装の最適化が必要です
これら3つのレベルは同時に努力しています。
上記の14のスキルは、多くのデータベース分析や設計の実践で徐々に要約されています。 これらの経験のために
読者は堅苦しく機械的であってはならず、消化し理解し、事実から真実を求め、柔軟に習得すべきです。 そして徐々に進めてください:申請書を送り出します
展示、応用開発中。
|
掲載地 2015/04/09 21:00:54
|
|
|
