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 XYZ 1 Job Street
urls
urlId url
1 ABC.com
2XYZ.com 。かなり奇妙な url_relations テーブルを作成しました。そのテーブル内のフィールドはすべて主キーまたは外部キーです。このテーブルを通じて、urls テーブル内の重複する項目を削除できます。 4 番目の正規化形式の具体的な要件は次のとおりです:
4 番目の正規化形式
1. 多対多の関係では、独立したエンティティを同じテーブルに格納することはできません
理由としてのみ適用されます。多対多の関係に依存するため、ほとんどの開発者はこのルールを無視できます。ただし、場合によっては、この
の例のように、同じエンティティを分離し、関係を独自のテーブルに移動することで URL テーブルを改善した場合のように、非常に実用的になることがあります。
理解しやすいように、具体的な例を挙げてみましょう。以下では、SQL ステートメントを使用して、joe に属するすべての URL を選択します:
SELECT name, url FROM users, urls, url_relationswheresurl_relations.popularUserId = 1 AND
users。 userId = 1 AND urls.urlId = url_relations. AssociatedUrlId
各人の個人情報と URL 情報を繰り返し処理したい場合は、次のようにすることができます:
SELECT name, url FROM users, urls, url_relationswheresusers.userId = url_relations.popularuserId AND
正規化の 1 番目のレベルもありますが、これは一般的ではなく、少し難解で、ほとんどの場合は不要です。その原則は次のとおりです: | 1. 元のテーブルは、それから分離されたテーブルを通じて再構築可能でなければなりません