データベースの正規化について知っておくべきことすべて

2. テーブルの各列はアトミックである必要があります。

これは基本的に、列の内容を分割できなくなるまで分割する必要があることを意味します。 役割に注意してください スタッフの列 テーブルは、StaffID=3の行のルール2に違反しています。

3. テーブルの各行は一意である必要があります。

正規化されたテーブルの一意性は、通常、主キーを使用して実現されます。主キーは、テーブルの各行を一意に定義します。ほとんどの場合、主キーは1つの列のみで定義されます。複数の列で構成される主キーは、複合キーと呼ばれます。

4. レコードが保存される順序は重要ではありません。

スタッフのデータを揃えるには 第一正規形の教義を持つ表は、図2、3、および4に示すように表を分割する必要があります。

図。 2人のスタッフテーブル

スタッフのデータを絞り込みました テーブルを作成し、一意性を保証するために複合主キーを実装しました。また、2つの追加のテーブルロールを作成しました および部門 コアスタッフと関係があります 外部キーを使用して実装されたテーブル。リスト2のDDLを確認してください。

リスト2.新しいスタッフのDDL 第一正規形の表。

USE [PrivateWork]
GO

CREATE TABLE [dbo].[staffers](
	[staffID] [int] IDENTITY(1,1) NOT NULL,
	[StaffName] [varchar](50) NULL,
	[DeptID] [int] NOT NULL,
	[RoleID] [int] NOT NULL,
	[Gender] [char](1) NULL,
	[DateofBirth] [datetime2](7) NULL,
PRIMARY KEY CLUSTERED 
(
	[staffID] ASC,
	[RoleID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[staffers1NF]  WITH CHECK ADD FOREIGN KEY([DeptID])
REFERENCES [dbo].[Department] ([DeptID])
GO

ALTER TABLE [dbo].[staffers1NF]  WITH CHECK ADD FOREIGN KEY([RoleID])
REFERENCES [dbo].[Roles] ([RoleID])
GO

図。 3部門の表

図。 4つの役割の表

第2正規形

1. 第一正規形はすでに配置されている必要があります。

2. すべての非キー列は、主キーに部分的に依存していてはなりません。

2番目のルールの目的は、テーブルのすべての列が、主キーを一緒に構成するすべての列に依存している必要があるということです。図2、3、および4の表を振り返ると、第一正規形のすべての要件を満たしていることがわかります。また、2つのテーブルの第2正規形の要件を達成しましたロール および部門 。ただし、スタッフの場合 テーブル、まだ問題があります。主キーは、StaffID列とRoleID列で構成されています。

ここでは、スタッフの性別と生年月日がRoleIDに依存しないため、第2正規形の規則2が破られています。部分的な依存関係があります。

図。第一正規形の5人のスタッフ

この例では、主キーからRoleIDを削除することでこれを修正できますが、これを行うと、別のルール、つまり第一正規形に記載されている一意性の役割に違反することになります。別のアプローチを取る必要があります。 スタッフを変更します スタッフが複数の役割を果たすことができることを理解したテーブル。図6を参照してください。

図。 2番目の正規形の6人のスタッフテーブル

一意性を維持し、部分的な依存関係を削除することに成功しました。

リスト3.2番目の正規形の新しいスタッフテーブルのDDL。

USE [PrivateWork]
GO

CREATE TABLE [dbo].[staffers2NF](
	[staffID] [int] IDENTITY(1,1) NOT NULL,
	[StaffName] [varchar](50) NULL,
	[DeptID] [int] NOT NULL,
	[RoleID1] [int] NOT NULL,
	[RoleID2] [int] NULL,
	[RoleID3] [int] NULL,
	[Gender] [char](1) NULL,
	[DateofBirth] [datetime2](7) NULL,
PRIMARY KEY CLUSTERED 
(
	[staffID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[staffers2NF]  WITH CHECK ADD FOREIGN KEY([DeptID])
REFERENCES [dbo].[Department] ([DeptID])
GO

ALTER TABLE [dbo].[staffers2NF]  WITH CHECK ADD FOREIGN KEY([RoleID1])
REFERENCES [dbo].[Roles] ([RoleID])
GO

ALTER TABLE [dbo].[staffers2NF]  WITH CHECK ADD FOREIGN KEY([RoleID2])
REFERENCES [dbo].[Roles] ([RoleID])
GO

ALTER TABLE [dbo].[staffers2NF]  WITH CHECK ADD FOREIGN KEY([RoleID3])
REFERENCES [dbo].[Roles] ([RoleID])
GO

第3正規形

1. 2番目の正規形はすでに配置されている必要があります。

2. すべての非キー列は、主キーへの推移的な依存関係を持ってはなりません。

第3正規形の目的は、非キー列がすでに主キーに依存している場合でも、非キー列に依存する列があってはならないということです。

例として、スタッフに列を追加することにしたと仮定します。 スタッフのマネージャーをはっきりと見るために、図7に示すような表。そうすることで、マネージャー名はDeptIDに依存し、DeptIDはStaffIDに依存するため、2番目の第3正規形ルールに違反することになります。これは推移的な依存関係です。

図。第3正規形（破られた規則）の7人のスタッフテーブル

古いフォームを保持し、StaffersテーブルとDepartmentテーブルの間の結合を使用して必要な情報を表示することをお勧めします。

図。 8スタッフと部門の間で参加する

select * from staffers2NF s 
join Department d 
on s.DeptID=d.DeptID;

Select account_no from Customer_Accounts where Phone_No like ‘%2348039988456%’;