Loading article…
第一正規形( 1NF ) は、リレーショナル データベースにおけるリレーションのプロパティです。リレーションが第一正規形になるのは、属性ドメインにリレーションが要素として含まれていない場合のみです。[1]または、より非公式には、テーブル列にテーブルを値として含めることはできません。データベースの正規化は、データベースを標準正規形のリレーションで表現するプロセスであり、第一正規形は最低限の要件です。SQL -92では、テーブル値列の作成や使用はサポートされていません。つまり、「従来のリレーショナル データベース機能」のみを使用する場合 (拡張機能は後で標準化されても除く)、ほとんどのリレーショナル データベースは必然的に第一正規形になります。第一正規形を必要としないデータベース システムは、NoSQLシステムと呼ばれることがよくあります。SQL :1999などの新しい SQL 標準では、複合型を含む、いわゆる非アトミック型が許可され始めています。SQL :2016などの新しいバージョンでも、JSON が許可されています。
概要
階層型データベースでは、レコードに子レコードのセット (繰り返しグループまたはテーブル値属性と呼ばれる) を含めることができます。このようなデータ モデルがリレーションとして表される場合、繰り返しグループは、値自体がリレーションである属性になります。第 1 正規形は、ネストされたリレーションを、直接の包含ではなく外部キーを通じて親行に関連付けられた個別の「トップレベル」リレーションに変換することで排除します。
この正規化の目的は、柔軟性とデータの独立性を高め、データ言語を簡素化することです。また、これにより、冗長性と異常性を排除するさらなる正規化が可能になります。
ほとんどのリレーショナル データベース管理システムはネストされたレコードをサポートしていないため、テーブルはデフォルトで第 1 正規形になります。特に、SQL にはネストされたテーブルを作成または活用する機能がありません。したがって、階層型データベースからリレーショナル データベースにデータを移動する場合、第 1 正規形への正規化は必須の手順になります。
根拠
1NFに正規化する根拠: [2]
- 通常の 2 次元配列の形式でリレーショナル データを表示、保存、交換できます。ネストされたリレーションをサポートするには、より複雑なデータ構造が必要になります。
- データ言語が簡素化されます。データ項目はリレーション名、属性名、キーだけで識別できるためです。ネストされたリレーションをサポートするには、ネストされたデータ項目に対応するために、階層型データ パスをサポートするより複雑な言語が必要になります。
- 階層モデルでは1 対多の関係しか表現できないのに対し、外部キーを使用して関係を表現すると、より柔軟になります。
- データ項目の配置は親子階層に直接結び付けられていないため、データベースは時間の経過に伴う構造の変化に対してより耐性があります。
- データの冗長性と異常性を排除するさらなる正規化レベルが可能になります。
欠点と批判
- 特定の操作ではパフォーマンスが低下します。階層モデルでは、ネストされたレコードは親レコードの後に物理的に格納されるため、サブツリー全体を 1 回の読み取り操作で取得できます。1NF 形式では、レコード タイプごとに結合操作が必要になりますが、これは複雑なツリーの場合は特にコストがかかる可能性があります。このため、ドキュメント データベースでは1NF は使用されません。
- オブジェクト指向言語は、実行時状態を、ポインターまたは参照によって接続されたオブジェクトのツリーまたは有向グラフとして表します。これは、1NF リレーショナル データベースにきれいにマッピングされません。この問題は、オブジェクト リレーショナル インピーダンス ミスマッチと呼ばれることもあり、オブジェクト リレーショナル マッパー(ORM) ライブラリが橋渡しを試みています。
- 1NF は、値に複雑なデータ型を許可しないと解釈されてきました。ただし、これは解釈の余地があり、CJ Date は、値は任意の複雑なオブジェクトになる可能性があると主張しています。[引用が必要]
歴史
第一正規形は、1970年にエドガー・F・コッドの論文「大規模共有データバンクのためのデータのリレーショナルモデル」で導入されましたが、当初は単に「正規形」と呼ばれていました。 1971年に論文「リレーショナルモデルのさらなる正規化」で追加の正規形が導入されたときに、「第一正規形」に名前が変更されました。[3]
例
次のシナリオでは、まずデータベース設計が第 1 正規形に違反する可能性があることを示し、その後に準拠する例を示します。
1NFに違反する設計
顧客のクレジットカード取引に関するこの表は、第 1 正規形に準拠していません。
各顧客には、トランザクションの「繰り返しグループ」が対応します。このような設計は、階層型データベースでは表現できますが、SQL ではネストされたテーブルがサポートされていないため、SQL データベースでは表現できません。
顧客の取引に関連するあらゆるクエリの自動評価には、大きく分けて 2 つの段階が含まれます。
- 1つまたは複数の顧客の取引グループを解凍して、グループ内の個々の取引を検査できるようにし、
- 最初のステージの結果に基づいてクエリ結果を導出する
たとえば、2003 年 10 月にすべての顧客に対して発生したすべての取引の金額合計を調べるには、まず各顧客の取引グループを展開し、次に取引日が 2003 年 10 月であるすべての取引の金額を合計する必要があることをシステムが認識している必要があります。
Codd の重要な洞察の 1 つは、構造の複雑さを軽減できるという点です。構造の複雑さを軽減すると、ユーザー、アプリケーション、および DBMS は、クエリを作成して評価する能力と柔軟性が向上します。上記の構造をより標準化したものは、次のようになります。
1NFに準拠した設計
モデルを第 1 正規形にするには、正規化を実行します。正規化 (第 1 正規形への) は、非単純なドメインを持つ属性を抽出して、独立した関係を分離するプロセスです。抽出された関係は、それを含む関係の主キーを参照する外部キーで修正されます。このプロセスは、複数のレベルにネストされた非単純なドメインに再帰的に適用できます。[4]
この例では、顧客 ID は包含関係の主キーであるため、新しい関係に外部キーとして追加されます。
変更された構造では、最初のリレーションでは主キーは {Customer ID} であり、2 番目のリレーションでは {Customer ID, Transaction ID} です。
これで、各行は個別のクレジットカード取引を表し、DBMS は、日付が 10 月であるすべての行を検索し、その金額を合計するだけで、必要な回答を得ることができます。データ構造はすべての値を同等の立場に置き、各値を DBMS に直接公開するため、各値をクエリに直接参加させることができます。一方、以前の状況では、一部の値は特別に処理する必要のある下位レベルの構造に埋め込まれていました。したがって、正規化された設計は汎用クエリ処理に適していますが、正規化されていない設計は適していません。
この設計は、第 2正規形と第 3 正規形の追加要件を満たしていることは注目に値します。
原子性
エドガー・F・コッドの 1NF の定義では、「原子性」の概念に言及しています。コッドは、「各関係が定義されているドメインの値は、DBMSに対して原子性を持つ必要があります。」と述べています。[5]コッドは、原子値を「DBMS によって小さな部分に分解できない値 (特定の特殊関数を除く)」と定義しています。[6]つまり、列は、1 つの部分が DBMS にとって意味するものが同じ列の別の部分に依存するような、複数の種類のデータを含む部分に分割されるべきではありません。
ヒュー・ダーウェンとクリス・デイトは、コッドの「アトミック値」の概念は曖昧であり、この曖昧さが1NFをどのように理解すべきかについての広範な混乱につながっていると示唆している。[7] [8]特に、「分解できない値」という概念は、アトミックなデータ型はほとんどない、あるいはまったくないということを暗示しているように思われるため、問題がある。
- RDBMS では通常、文字列を部分文字列に分解する演算子が提供されているため、文字列はアトミックではないと思われます。
- RDBMS では通常、固定小数点数を整数部分と小数部分に分解する演算子が提供されているため、固定小数点数はアトミックではないと思われます。
- ISBNは言語と発行者識別子を含んでいるため、アトミックではないようです。
デイトは「原子性の概念には絶対的な意味はない」と示唆している。[9] [10]値は、ある目的のためには原子であると考えられるかもしれないが、他の目的のためにはより基本的な要素の集合体と考えられるかもしれない。この立場が受け入れられるならば、1NF は原子性を参照して定義することはできない。考えられるあらゆるデータ型 (文字列型や数値型から配列型やテーブル型まで) の列は、1NF テーブルで受け入れられるが、必ずしも望ましいとは限らない。たとえば、顧客名の列を名と姓の 2 つの別々の列に分ける方が望ましいかもしれない。
関係の表現としての1NFテーブル
デイトの定義によれば、表が第一正規形となるのは、それが「何らかの関係に同型」である場合のみであり、具体的には、次の5つの条件を満たすことを意味する。[11]
- 行には上から下への順序はありません。
- 列には左から右への順序はありません。
- 重複行はありません。
- すべての行と列の交差には、適用可能なドメインからの値が 1 つだけ含まれます (他の値は含まれません)。
- すべての列は通常の列です (つまり、行には行 ID、オブジェクト ID、非表示のタイムスタンプなどの非表示のコンポーネントはありません)。
これらの条件のいずれかに違反すると、テーブルは厳密にはリレーショナルではなく、したがって第 1 正規形でないことを意味します。
この第 1 正規形の定義を満たさない テーブル (またはビュー) の例は次のとおりです。
- 一意のキー制約がないテーブル。このようなテーブルは重複行を収容できるため、条件 3 に違反します。
- 定義によって結果が特定の順序で返されることが義務付けられているビュー。そのため、行の順序付けはビューの本質的かつ意味のある側面です。(このようなビューは、SQL:2003標準に準拠するSQL を使用して作成することはできません。) これは条件 1 に違反します。真の関係にあるタプルは、互いに対して順序付けられていません。
- 少なくとも 1 つのnull 許容属性を持つテーブル。null 許容属性は、すべての列にその列のドメインから 1 つの値のみを含めることを要求する条件 4 に違反します。条件 4 のこの側面は議論の的となっています。これは、null を明示的に規定したCoddの後のリレーショナル モデル構想[12]からの重要な逸脱を示しています。 [13] Chris Date によって定義された第 1 正規形は、リレーション値属性 (テーブル内のテーブル) を許可します。Date は、テーブル内の列にテーブルを含めることができるリレーション値属性は、まれなケースでのみ有用であると主張しています。[14]
参考文献
- ^ Codd, EF (1970)。「大規模共有データバンクのためのリレーショナルデータモデル」。Communications of the ACM。Classics。13 (6): 377–87。p. 380-381
- ^ Codd, EF (1970). 「大規模共有データバンクのためのリレーショナルデータモデル」 Communications of the ACM. Classics. 13 (6): 377–87.
- ^ Codd, EF (1971)。リレーショナル モデルのさらなる正規化。Courant Computer Science Symposium 6 in Data Base Systems、Rustin, R. 編。
- ^ Codd, EF (1970)。「大規模共有データバンクのためのリレーショナルデータモデル」。Communications of the ACM。Classics。13 (6): 377–87。p. 381
- ^ Codd, EF 『データベース管理のためのリレーショナルモデル バージョン2』（Addison-Wesley、1990年）。
- ^ Codd, EF 『データベース管理のためのリレーショナルモデル バージョン2』（Addison-Wesley、1990年）、6ページ。
- ^ Darwen, Hugh. 「関係値属性、または、本当の第 1 正規形は立ち上がってください」、CJ Date および Hugh Darwen 著『Relational Database Writings 1989-1991 』 (Addison-Wesley、1992 年)。
- ^ Date, CJ (2007).第一正規形の本当の意味. Apress. p. 108. ISBN 978-1-4842-2029-0。
「何年もの間、私は他の人と同じように混乱していました。さらに悪いことに、私は自分の著作、セミナー、その他のプレゼンテーションを通じてその混乱を広めるために最善を尽くしました（最悪？）。」とデイトは書いています。
{{cite book}}:|work=無視されました (ヘルプ) - ^ Date, CJ (2007).第一正規形の本当の意味. Apress. p. 112. ISBN 978-1-4842-2029-0。
{{cite book}}:|work=無視されました (ヘルプ) - ^ Date, CJ (2015 年 11 月 6 日)。SQL とリレーショナル理論: 正確な SQL コードの書き方。O'Reilly Media。pp. 50– 。ISBN 978-1-4919-4115-7. 2018年10月31日閲覧。
- ^ Date, CJ (2007).第一正規形の本当の意味. Apress. pp. 127–128. ISBN 978-1-4842-2029-0。
{{cite book}}:|work=無視されました (ヘルプ) - ^ Date, CJ (2009). 「付録 A.2」. SQL とリレーショナル理論. O'Reilly.
Codd は 1969 年に初めてリレーショナル モデルを定義し、1979 年まで NULL を導入しませんでした。
- ^ Date, CJ (1985 年 10 月 14 日)。「DBMS は本当にリレーショナルですか?」。Computerworld。NULL値は、
データ型に関係なく、欠落した情報や適用できない情報を体系的に表現するために、完全なリレーショナル DBMS でサポートされる必要があります。
（コッドの12のルールの3番目） - ^ Date, CJ (2007).第一正規形の本当の意味. Apress. pp. 121–126. ISBN 978-1-4842-2029-0。
{{cite book}}:|work=無視されました (ヘルプ)
さらに読む
- Date, CJ, & Lorentzos, N., & Darwen, H. (2002). Temporal Data & the Relational Model (第 1 版). Morgan Kaufmann. ISBN 1-55860-855-9 .
- Date, CJ (1999)、『データベースシステム入門』（第8版）。Addison-Wesley Longman。ISBN 0-321-19784-4。
- ケント、W. (1983)リレーショナルデータベース理論における 5 つの正規形の簡単なガイド、Communications of the ACM、vol. 26、pp. 120–125
- Codd, EF (1970)。大規模共有データバンクのためのリレーショナルデータモデル。IBM 研究所、カリフォルニア州サンノゼ。
- Codd, EF (1971)。リレーショナル モデルのさらなる正規化。Rustin, R 編、Courant Computer Science Symposium 6 in Database Systems。