私はデータベースの正規化の概念を理解していますが、特に就職の面接では、それを平易な英語で説明するのにいつも苦労しています。ウィキペディアの投稿を読みましたが、それでも開発者以外の人に概念を説明するのは難しいと思います。「重複データを取得しないようにデータベースを設計する」が最初に頭に浮かぶことです。
データベースの正規化の概念をわかりやすい英語で説明する良い方法はありますか？また、第1正規形、第2正規形、第3正規形の違いを示す良い例は何ですか？
あなたが就職の面接に行き、その人が尋ねたとしましょう： 正規化の概念と、正規化されたデータベースを設計する方法を説明してください。
インタビュアーが探している重要なポイントは何ですか？
妻に説明するとしたら、次のようになります。
主なアイデアは、大きなデータの重複を避けることです。
人々のリストと彼らの出身国を見てみましょう。すべての人に対して「ボスニア・ヘルツェゴビナ」と同じくらい長い国名を保持する代わりに、国の表を参照する番号を保持するだけです。したがって、「ボスニア・ヘルツェゴビナ」を 100 保有する代わりに、#45 を 100 保有します。将来、バルカン諸国でよくあることですが、ボスニアとヘルツェゴビナの 2 つの国に分かれます。1 つの場所だけを変更する必要があります。そうですね。
さて、2NF を説明するために例を変えて、すべての人が訪れた国のリストを保持していると仮定しましょう。次のようなテーブルを保持する代わりに:
Person CountryVisited AnotherInformation D.O.B.
Faruz USA Blah Blah 1/1/2000
Faruz Canada Blah Blah 1/1/2000
国のリストを含む 1 つのテーブル、人物のリストを含む 1 つのテーブル、およびそれらを接続する別のテーブルの 3 つのテーブルを作成します。これにより、人の情報や国の情報を変更することができる最大の自由が得られます。これにより、正規化が期待するように「重複行を削除」できます。
1 対多の関係は、外部キーで接続された 2 つの別個のテーブルとして表す必要があります。論理的な 1 対多の関係を 1 つのテーブルに押し込もうとすると、正規化に違反し、危険な問題が発生します。
友達とその猫のデータベースがあるとします。人は複数の猫を飼っている場合があるため、人と猫の間には 1 対多の関係があります。これには、次の 2 つのテーブルが必要です。
Friends
Id | Name | Address
-------------------------
1 | John | The Road 1
2 | Bob | The Belltower
Cats
Id | Name | OwnerId
---------------------
1 | Kitty | 1
2 | Edgar | 2
3 | Howard | 2
(Cats.OwnerIdは への外部キーですFriends.Id)
上記の設計は完全に正規化されており、すべての既知の正規化レベルに準拠しています。
しかし、上記の情報を次のような単一の表で表現しようとしたとします。
Friends and cats
Id | Name | Address | CatName
-----------------------------------
1 | John | The Road 1 | Kitty
2 | Bob | The Belltower | Edgar
3 | Bob | The Belltower | Howard
(これは、Excel シートに慣れていて、リレーショナル データベースに慣れていなかった場合に作成したであろう種類の設計です。) 単一テーブルのアプローチでは、データの一貫性を保つために、いくつかの情報を繰り返さなければなりません。この設計の問題点は、ボブの住所が「鐘楼」であるという情報などのいくつかの事実が 2 回繰り返されることです。これは冗長であり、データのクエリと変更が難しくなり、(最悪の場合) 論理的な矛盾が生じる可能性があります。
例えば。Bob が移動した場合は、両方の行の住所を変更する必要があります。ボブが別の猫を飼った場合、他の 2 行に入力した名前と住所を正確に繰り返さなければなりません。たとえば、行の 1 つでボブの住所をタイプミスすると、突然、データベースのボブの住所に関する情報に一貫性がなくなります。正規化されていないデータベースは、矛盾した自己矛盾するデータの導入を防ぐことができないため、データベースは信頼できません。これは明らかに受け入れられません。
正規化しても、間違ったデータの入力を防ぐことはできません。正規化によって防止されるのは、データの不整合の可能性です。
正規化はビジネス上の決定に依存することに注意することが重要です。顧客データベースがあり、顧客ごとに 1 つの住所のみを記録することにした場合、テーブルの設計(#CustomerID, CustomerName, CustomerAddress)は問題ありません。ただし、各顧客が複数の住所を登録できるようにする場合は、顧客と住所の間に 1 対多の関係があるため、同じテーブル設計は正規化されません。したがって、データベースを見て正規化されているかどうかを判断するだけではなく、データベースの背後にあるビジネス モデルを理解する必要があります。
これは私がインタビュー対象者に尋ねるものです：
複数のテーブルを使用する代わりに、アプリケーションに単一のテーブルを使用しないのはなぜですか？
答えはもちろん正規化です。すでに述べたように、冗長性を回避し、異常を更新します。
これは完全な説明ではありませんが、正規化の1つの目標は、厄介なことなく成長できるようにすることです。
たとえば、userテーブルがあり、すべてのユーザーが1つだけの電話番号を持っている場合phonenumber、そのテーブルに列を含めることは問題ありません。
ただし、各ユーザーが可変数の電話番号を使用する場合は、、などphonenumber1の列を設定するのは厄介ですphonenumber2。これには2つの理由があります。
phonenumber3なり、誰かが4番目の数値を追加する必要がある場合は、テーブルに列を追加する必要があります。代わりに、テーブルが必要ですphonenumber。各行には、電話番号と、userテーブル内のどの行に属する外部キー参照が含まれています。空白の列は必要ありません。各ユーザーは、必要な数の電話番号を使用できます。
正規化に関する 1 つの注意点: 完全に正規化されたデータベースはスペース効率が高くなりますが、使用パターンによっては、必ずしも最も時間効率の良いデータ配置とは限りません。
非正規化された場所からすべての情報を検索するために複数のテーブルをスキップすると、時間がかかります。ストレージ容量よりも時間が重要な高負荷の状況 (1 秒あたり数百万行が飛び交う、数千の同時クライアント、たとえばクレジット カード トランザクション処理など) では、適切に非正規化されたテーブルは、完全に正規化されたテーブルよりも優れた応答時間を提供できます。
詳細については、Ken Henderson が執筆した SQL に関する書籍を参照してください。
正規化は、いわば効率的に物事を行うためにメモをとるようなものだと思います。
正規化せずにアイスクリームを買いに行かなければならないというメモがあった場合は、各ポケットに1つずつ、アイスクリームを買いに行かなければならないという別のメモがあります。
さて、実際には、これを行うことは決してないでしょう。それでは、なぜデータベースでこれを行うのでしょうか。
設計と実装の部分については、「用語」に戻って素人の言葉から遠ざけることができますが、単純化できると思います。最初に必要なことを言ってから、正規化が行われるときに、次のことを確認すると言います。
非正規化についても言えば、もっと印象的かもしれませんし、常に最良の構造を持ち、通常の形であるとは限らないという事実もあります。
正規化は、関係を介して接続するテーブルを設計するために使用される一連のルールです。
これは、繰り返しのエントリを回避し、必要なストレージスペースを削減し、新しいデータに対応するために既存のテーブルを再構築する必要をなくし、クエリの速度を上げるのに役立ちます。
第一正規形：データは最小単位に分割する必要があります。テーブルには、列の繰り返しグループを含めることはできません。各行は、1つ以上の主キーで識別されます。たとえば、「カスタム」テーブルに「名前」という名前の列があり、「名」と「名」に分割する必要があります。また、「カスタム」には、特定のカスタムを識別するための「CustiomID」という名前の列が必要です。
第2正規形：各非キー列は、主キー全体に直接関連している必要があります。たとえば、「Custom」テーブルに「City」という名前の列がある場合、都市には主キーと都市名が定義された別のテーブルが必要です。「Custom」テーブルで、「City」列を「CityID」に置き換えます。物語の中で「CityID」を外部キーにします。
3番目の正規形：各非キー列は、他の非キー列に依存してはなりません。たとえば、注文テーブルでは、「合計」列は「単価」と「数量」に依存しているため、「合計」列を削除する必要があります。
私は Access コースで正規化を教えており、それをいくつかの方法で分類しています。
絵コンテやデータベースの計画の前段階について説明した後、正規化について詳しく説明します。私は次のようにルールを説明します。
ボードに名前欄を書き、ビル・ランバーグのように姓名を入れます。次に、学生にクエリを実行し、名前と姓がすべて 1 つのフィールドにある場合に問題になることを尋ねます。例として私の名前を使用します。ジム・リチャーズです。生徒たちが道を案内してくれない場合は、手を引っ張って連れて行きます。:) 私の名前は一部の人にとっては難しい名前だと言います。なぜなら、私には 2 つのファーストネームと見なす人もいれば、リチャードと呼ぶ人もいるからです。私の姓を検索しようとしている場合、私の姓はフィールドの最後に埋もれているため、通常の人 (ワイルドカードなし) では検索が難しくなります。また、姓でフィールドを簡単にソートするのは難しいだろうと彼らに伝えます。
次に、意味のあるものは、データベースを使用する予定の聴衆に基づいていることを彼らに知らせます. 私たちの仕事では、人々の住所を保存している場合、アパート番号またはスイート番号用の別のフィールドは必要ありませんが、UPS や FEDEX などの配送会社は、必要なときにアパートまたはスイートを簡単に取得するために分離する必要がある場合があります。彼らは移動中で、配達から配達まで走っています。ですから、私たちにとっては意味がありませんが、彼らにとっては間違いなく意味があります。
私は例えを使って、空白を避けるべき理由を彼らに説明します。私は、Access やほとんどのデータベースは、Excel のように空白を格納しないことを伝えます。Excel では、セルに何も入力されていなくてもファイル サイズが大きくなることはありませんが、Access では、実際にフィールドを使用する時点までその領域が確保されます。そのため、空白であってもスペースを使い果たし、検索速度も低下することを説明します。
私が使用するアナロジーは、クローゼットの中の空の靴箱です。クローゼットに靴箱があり、靴を探している場合は、箱を開けて、それぞれの靴を探す必要があります。空の靴箱があると、クローゼットのスペースが無駄になり、特定の靴を探す必要があるときに時間を無駄にします.
私は、顧客情報の繰り返し値がたくさんある表を見せてから、重複を避けたいと伝えます。なぜなら、私はソーセージの指を持っており、同じことを何度も入力しなければならない場合、値を間違って入力してしまうからです。このデータの「ファットフィンガーリング」により、クエリが正しいデータを見つけられなくなります。代わりに、データを別のテーブルに分割し、主キー フィールドと外部キー フィールドを使用してリレーションシップを作成します。この方法では、顧客の名前や住所などを複数回入力するのではなく、顧客のフィールドに顧客の ID 番号を使用するだけなので、スペースを節約できます。次に、ドロップダウン リスト/コンボ ボックス/ルックアップ リスト、または後で Microsoft が名前を付けたいと考えているものについて説明します。:) ユーザーとして、あなたは顧客を検索して入力したくないでしょう ' その顧客フィールドには毎回番号が入力されるため、顧客のリストを提供するドロップダウン リストをセットアップします。ここで顧客の名前を選択すると、顧客の ID が入力されます。これは 1 対多の関係になりますが、1 人の顧客が多くの異なる注文を持つことになります。
多対多の関係について話すときに、これを示します。まず、2 つのテーブルを作成します。1 つは従業員情報を保持し、もう 1 つはプロジェクト情報を保持します。テーブルはこのように配置されています。
(Table1)
tblEmployees
* EmployeeID
First
Last
(Other Fields)….
Project1
Project2
Project3
Etc.
**********************************
(Table2)
tblProjects
* ProjectNum
ProjectName
StartDate
EndDate
…..
これは、従業員と従業員が取り組んでいるすべてのプロジェクトとの関係を確立する良い方法ではないことを彼らに説明します. 第一に、新しい従業員がいる場合、彼らはプロジェクトを持っていないので、それらのフィールドをすべて無駄にします.第二に、従業員が長い間ここにいる場合、彼らは 300 のプロジェクトに取り組んでいる可能性があるため、 300 のプロジェクト フィールドを含める。新規でプロジェクトが 1 つしかない人は、299 の無駄なプロジェクト フィールドを持つことになります。この設計にも欠陥があります。なぜなら、特定のプロジェクトに携わったすべての人を見つけるために、各プロジェクト フィールドを検索する必要があるからです。そのプロジェクト番号は、どのプロジェクト フィールドにも含まれる可能性があるからです。
かなりの量の基本的な概念について説明しました。他に質問がある場合、または明確化/平易な英語での分解の助けが必要な場合はお知らせください. wiki ページは平易な英語として読めず、一部の人にとっては気が遠くなるかもしれません.
データベースの正規化は、冗長データを排除するためにデータベースを設計する正式なプロセスです。設計は次のもので構成されています。
データ ディクショナリまたはその他のメタデータ表現を使用して、設計を検証します。
正規化の最大の問題は、ユーザー プロファイルなど、概念的には 1 つのアイテムを表す複数のテーブルが作成されることです。履歴ログや金融取引など、レコードが挿入されているが更新されていないテーブルのデータを正規化することについて心配する必要はありません。
参考文献
正規化に関する wiki リンクを何度も読みましたが、正規化のより良い概要については、この記事を参照してください。第四正規形までの正規化を分かりやすくシンプルに解説しています。それを読んでください！
プレビュー:
ノーマライゼーションとは？
正規化は、データベース内のデータを効率的に編成するプロセスです。正規化プロセスには 2 つの目標があります。冗長なデータを排除する (たとえば、同じデータを複数のテーブルに格納する) ことと、データの依存関係を意味のあるものにする (関連するデータのみをテーブルに格納する) ことです。これらは両方とも、データベースが消費するスペースの量を削減し、データが論理的に格納されるようにするため、価値のある目標です。
http://databases.about.com/od/specificproducts/a/normalization.htm
あなたの妻と話すことの類推のために+1。この種の会話には、テクノロジーに疎い人と話すのにいくらかの安らぎが必要だと思います。
しかし...
この会話に加えて、コインの反対側があります (インタビューでは重要になる可能性があります)。
正規化するときは、データベースがどのようにインデックス化され、クエリがどのように記述されるかを監視する必要があります。
真に正規化されたデータベースでは、不適切な結合操作、テーブルの不適切なインデックス作成、およびテーブル自体の単純な不適切な設計が原因で遅いクエリを作成する方が簡単であることがわかりました。
率直に言って、高レベルの正規化されたテーブルに不適切なクエリを記述する方が簡単です。
どのアプリケーションにも妥協点があると思います。ある時点で、多数のテーブルに結合して 1 つのデータ セットを取得することなく、いくつかのテーブルからすべてを簡単に取得できるようにしたいと考えています。