データベース設計スキル (3)

ヒント|設計|データ|データベース|データベース設計

著者: allsky

4 番目の正規化形式を定義する前に、まず 3 つの基本的なデータ関係、1 対 1、1 対多、多対多について触れたいと思います。最初の正規化されたユーザー テーブルを振り返ってみましょう。 url フィールドを別のテーブルに配置すると、users テーブルにレコードを挿入するたびに、url テーブルに行が挿入されます。 1 対 1 の関係が得られます。users テーブルの各行に対して、urls テーブルには対応する行が存在します。私たちのアプリケーションにとって、これは実用的でも標準でもありません。

次に、2番目の正則化の例を見てください。各ユーザー レコードについて、テーブルではレコードの複数の URL を関連付けることができます。これは 1 対多の関係であり、非常に一般的な関係です。

多対多の関係の場合、少し複雑になります。 3 番目の正規化された形式の例では、1 人のユーザーが多数の URL に関連付けられており、
複数のユーザーが複数の URL に関連付けられるように構造を変更して、複数の 1 対多の構造を取得できるようにしたいと考えています。説明する前に、テーブル構造の変更を見てみましょう

users

userId name relCompId

1 Joe 1

2 Jill 2

Companies

compId company company_address

1 ABC 1 Work Lane

2
1 1 1

2 1 2

3 2 1

4 2 2

データの冗長性をさらに減らすために、第 4 レベルの正則化形式を使用します。かなり奇妙な url_relations テーブルを作成しました。そのテーブル内のフィールドはすべて主キーまたは外部キーです。このテーブルを通じて、urls テーブル内の重複する項目を削除できます。 4 番目の正規化形式の具体的な要件は次のとおりです:

4 番目の正規化形式

1. 多対多のリレーションシップでは、独立したエンティティを同じテーブルに格納することはできません

これは多対多にのみ適用されるため、 -多くの関係があるため、ほとんどの開発者はこのルールを無視できます。ただし、場合によっては、この
の例のように、同じエンティティを分離し、関係を独自のテーブルに移動することで URL テーブルを改善した場合のように、非常に実用的になることがあります。

理解しやすいように、具体的な例を挙げてみましょう。以下では、SQL ステートメントを使用して、joe に属するすべての URL を選択します。 users.userId = 1 AND urls.urlId = url_relations.popularUrlId

全員の個人情報と URL 情報を繰り返し処理したい場合は、次のようにすることができます:

SELECT name, url FROM users, urls, url_relationswheresusers.userId = url_relations. requiredUserId AND
urls.urlId = url_relations.popularUrlId

正規化の 5 番目のレベル

正規化の 1 番目のレベルもありますが、これは一般的ではなく、少し難解で、ほとんどの場合は不要です。その原則は次のとおりです:

1. 元のテーブルは、それから分離されたテーブルを通じて再構築できる必要があります

この規定を使用する利点は、分離されたテーブルに冗長な列が導入されないことを保証できることです。 create テーブル構造はすべて、実際に必要な大きさです。このルールを適用することをお勧めしますが、非常に大規模なデータ セットを扱う場合を除き、このルールを使用する必要はありません。

この記事があなたのお役に立ち、これらの形式化されたルールをすべてのプロジェクトに適用するのに役立つことを願っています。これらのメソッドがどこから来たのか疑問に思われるかもしれませんが、最初の 3 つの正規化規則は 1972 年に E.F. コッド博士の論文「データベースのリレーショナル モデルのさらなる正規化」で提案され、残りの規則は理論化されました。後に集合論と関係数学者となる。コメント: よく言われるように、テーブルを細かく分割しすぎると、テーブル間にさまざまな相関関係が必要になり、クエリが複雑になり、効率も低下する可能性があるため、場合によっては、レベルを逆転する必要があります。これらの正規化については、プロジェクトの規模に応じて、必要に応じていくつかのテストを実行して、より合理的なテーブル構造を設計することができます。