Mọi thứ bạn cần biết về Chuẩn hóa cơ sở dữ liệu

Mô hình quản lý dữ liệu quan hệ lần đầu tiên được phát triển bởi Tiến sĩ Edgar F. Codd vào năm 1969. Hệ thống quản lý cơ sở dữ liệu quan hệ hiện đại (RDBMSes) phù hợp với mô hình. Cấu trúc khóa được xác định với RDBMS là cấu trúc logic được gọi là “bảng”. Bảng chủ yếu bao gồm các hàng và cột (còn được gọi là bản ghi và thuộc tính hoặc bộ và trường). Theo nghĩa toán học chặt chẽ, thuật ngữ bảng thực sự được gọi là một mối quan hệ và giải thích cho thuật ngữ "Mô hình quan hệ". Trong toán học, một quan hệ là một đại diện của một tập hợp.

Thuộc tính biểu thức mô tả tốt mục đích của một cột - nó đặc trưng cho tập hợp các hàng được liên kết với nó. Mỗi cột phải thuộc một kiểu dữ liệu cụ thể và mỗi hàng phải có một số đặc điểm nhận dạng duy nhất được gọi là “khóa”. Thay đổi dữ liệu thường hiệu quả hơn khi được thực hiện bằng mô hình quan hệ trong khi việc truy xuất dữ liệu có thể nhanh hơn với Mô hình phân cấp cũ hơn đã được định nghĩa lại trong các hệ thống NoSQL kiểu mẫu.

Chuẩn hóa dữ liệu là một quy trình toán học mô hình hóa dữ liệu kinh doanh thành một biểu mẫu đảm bảo rằng mỗi thực thể được biểu diễn bằng một quan hệ duy nhất (bảng). Những người đề xuất ban đầu của mô hình quan hệ đã đề xuất một khái niệm về Dạng chuẩn. Edgar Codd đã định nghĩa Dạng chuẩn đầu tiên, dạng thứ hai và thứ ba. Sau đó anh được tham gia bởi Raymond F. Boyce. Họ cùng nhau xác định Dạng chuẩn Boyce-Codd. Hiện tại, sáu Dạng chuẩn được định nghĩa về mặt lý thuyết nhưng trong hầu hết các ứng dụng thực tế, chúng tôi thường mở rộng Chuẩn hóa lên đến Dạng Chuẩn thứ Ba. Mỗi Biểu mẫu Thông thường cố gắng tránh sự bất thường trong quá trình sửa đổi dữ liệu, giảm bớt sự dư thừa và phụ thuộc của dữ liệu trong một bảng. Mỗi cấp độ chuẩn hóa có xu hướng giới thiệu nhiều bảng hơn, giảm bớt sự dư thừa, tăng tính đơn giản của mỗi bảng nhưng cũng làm tăng độ phức tạp của toàn bộ hệ quản trị cơ sở dữ liệu quan hệ. Vì vậy, các hệ thống RDBM về mặt cấu trúc có xu hướng phức tạp hơn các hệ thống Phân cấp.

Tại sao Chuẩn hóa Cơ sở dữ liệu:Bốn Điểm bất thường

Việc lưu trữ dữ liệu mà không chuẩn hóa gây ra một số vấn đề về tiêu thụ dữ liệu. Những người ủng hộ chuẩn hóa gọi những vấn đề như vậy là dị thường. Để mô tả những điểm bất thường này, hãy xem dữ liệu được trình bày trong Hình 1.

Hình. 1 Bảng Nhân viên

Liệt kê 1. Bảng Cơ bản để Thể hiện Chuẩn hóa Cơ sở dữ liệu.

1.1. Tạo bảng

use privatework
go
create table staffers (
staffID int identity (1,1)
,StaffName varchar(50)
,Role varchar(50)
,Department varchar (100)
,Manager varchar (50)
,Gender char(1)
,DateofBirth datetime2
)

1.2. Chèn hàng

insert into staffers values ('John Doe','Engineering','Kweku Amarh','M','06-Oct-1965');
insert into staffers values ('Henry Ofori','Engineering','Kweku Amarh','M','06-Mar-1982');
insert into staffers values ('Jessica Yuiah','Engineering','Kweku Amarh','F','06-Oct-1965');
insert into staffers values ('Ahmed Assah','Engineering','Kweku Amarh','M','06-Oct-1965');

1.3. Truy vấn bảng

select * from staffers;

Bảng này về bản chất đại diện cho hai bộ dữ liệu đã được kết hợp một cách vô tình:tên nhân viên và phòng ban. Lưu ý rằng tất cả các nhân viên đều thuộc cùng một bộ phận:Kỹ thuật. Điều đó được thực hiện vì sự đơn giản và để chứng minh sự bình thường hóa. Có ba vấn đề chính liên quan đến việc sử dụng cấu trúc này:

Điểm bất thường khi chèn

Để chèn một bản ghi mới, chúng tôi phải tiếp tục lặp lại tên bộ phận và người quản lý.

Sự bất thường khi xóa

Để xóa hồ sơ của một nhân viên, chúng tôi cũng phải xóa người quản lý và bộ phận được liên kết. Nếu cần xóa hồ sơ của TẤT CẢ nhân viên, chúng tôi cũng phải xóa tất cả các phòng ban và tất cả người quản lý.

Sự bất thường của bản cập nhật

Nếu cần thay đổi người quản lý của bất kỳ bộ phận nào, chúng tôi phải thực hiện thay đổi trong mỗi hàng của bảng này vì các giá trị được trùng lặp cho từng nhân viên.

Biểu mẫu Thông thường của Cơ sở dữ liệu

Trong các phần sau của bài viết, chúng tôi sẽ cố gắng mô tả các Dạng chuẩn thứ nhất, Thứ 2 và Thứ 3 có nhiều khả năng được quan sát trong Hệ thống RDBM thực. Có những phần mở rộng khác của lý thuyết như Dạng chuẩn thứ tư, thứ năm và Boyce-Codd nhưng trong bài viết này, chúng tôi sẽ giới hạn ở Ba dạng chuẩn.

Biểu mẫu Thông thường Đầu tiên

Biểu mẫu Thông thường đầu tiên được xác định bởi bốn quy tắc:

Mỗi cột phải chứa các giá trị của cùng một kiểu dữ liệu.

Bảng Nhân viên đã đáp ứng quy tắc này.

Mỗi cột trong bảng phải là nguyên tử.

Về cơ bản, điều này có nghĩa là bạn nên chia nội dung của một cột cho đến khi chúng không thể chia được nữa. Lưu ý rằng Vai trò trong cột Nhân viên bảng ngắt quy tắc 2 cho hàng có StaffID =3.

Mỗi hàng trong bảng phải là duy nhất.

Tính duy nhất trong bảng chuẩn hóa thường đạt được bằng cách sử dụng Khóa chính. Khóa chính xác định duy nhất mỗi hàng trong bảng. Hầu hết thời gian, Khóa chính chỉ được xác định bởi một cột. Khóa chính bao gồm nhiều cột được gọi là Khóa tổng hợp.

Thứ tự lưu trữ các bản ghi không quan trọng.

Để căn chỉnh dữ liệu trong Nhân viên bảng với các nguyên lý của Dạng chuẩn đầu tiên, chúng ta cần chia bảng như trong Hình 2, 3 và 4.

Hình. Bàn 2 Nhân viên

Chúng tôi đã thu hẹp dữ liệu trong Nhân viên bảng và triển khai Khóa chính tổng hợp để đảm bảo tính duy nhất. Chúng tôi cũng đã tạo hai bảng bổ sung Vai trò và Phòng ban có mối quan hệ với Nhân viên cốt lõi bảng được triển khai bằng Phím ngoại. Xem lại DDL trong Liệt kê 2.

Liệt kê 2. DDL của Nhân viên mới Bảng cho Biểu mẫu Thông thường Đầu tiên.

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

Hình. Bảng 3 Phòng ban

Hình. Bảng 4 vai trò

Dạng chuẩn thứ hai

Biểu mẫu Thông thường đầu tiên phải có sẵn.
Mọi cột không phải khóa không được có Sự phụ thuộc một phần vào Khóa chính.

Điểm mạnh của quy tắc thứ hai là tất cả các cột của bảng phải phụ thuộc vào tất cả các cột bao gồm Khóa chính cùng nhau. Nhìn lại các bảng trong Hình 2, 3 và 4, chúng ta thấy mình đã đạt được tất cả các yêu cầu của Dạng chuẩn thứ nhất. Chúng tôi cũng đã đạt được các yêu cầu của Biểu mẫu chuẩn thứ hai cho hai bảng Vai trò và Phòng ban . Tuy nhiên, trong trường hợp của Nhân viên bảng, chúng tôi vẫn có một vấn đề. Khóa chính của chúng tôi bao gồm các cột StaffID và RoleID.

Quy tắc 2 của Biểu mẫu thông thường thứ hai bị phá vỡ ở đây bởi thực tế là Giới tính và Ngày sinh của nhân viên không phụ thuộc vào RoleID. Có sự phụ thuộc một phần.

Hình. 5 nhân viên cho Biểu mẫu thông thường đầu tiên

Trong ví dụ đã cho, chúng tôi có thể cố gắng khắc phục điều này bằng cách xóa RoleID khỏi Khóa chính nhưng nếu chúng tôi làm điều này, chúng tôi sẽ phá vỡ một quy tắc khác:vai trò của tính duy nhất được nêu trong Biểu mẫu thông thường đầu tiên. Chúng ta phải có một cách tiếp cận khác. Chúng tôi sẽ sửa đổi Nhân viên bàn với sự hiểu biết rằng một nhân viên có thể đóng nhiều hơn một vai trò. Xem Hình 6.

Hình. Bảng 6 Nhân viên cho Biểu mẫu Thông thường Thứ hai

Chúng tôi đã thành công trong việc duy trì tính duy nhất cũng như loại bỏ Sự phụ thuộc một phần.

Liệt kê 3. DDL của Bảng nhân viên mới cho Biểu mẫu thông thường thứ hai.

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

Dạng chuẩn thứ ba

Biểu mẫu Bình thường thứ 2 phải có sẵn.
Mọi cột không phải khóa không được có Phụ thuộc Phụ thuộc vào Khóa Chính.

Điểm nổi bật của biểu mẫu thông thường thứ ba là không được có bất kỳ cột nào phụ thuộc vào các cột không phải khóa ngay cả khi các cột không phải khóa đó đã phụ thuộc vào Khóa chính.

Ví dụ:giả sử chúng tôi quyết định thêm một cột bổ sung vào Nhân viên như thể hiện trong Hình 7 để thấy rõ người quản lý của nhân viên. Khi làm điều đó, chúng tôi sẽ phá vỡ quy tắc Biểu mẫu thông thường thứ ba, vì Tên người quản lý phụ thuộc vào DeptID và đến lượt nó, DeptID phụ thuộc vào StaffID. Đây là phụ thuộc bắc cầu.

Hình. 7 Bảng Nhân viên cho Dạng Thông thường Thứ Ba (Quy tắc Vỡ)

Tốt hơn nên giữ lại biểu mẫu cũ và hiển thị thông tin cần thiết bằng cách sử dụng phép nối giữa bảng Nhân viên và bảng Bộ phận.

Hình. 8 Tham gia giữa Nhân viên và Bộ phận

Liệt kê 4. Truy vấn Hiển thị Nhân viên và Người quản lý.

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

Ứng dụng thực tế

Hầu hết các ứng dụng trưởng thành đều thực hiện các quy tắc chuẩn hóa ở phạm vi hợp lý. Chúng tôi thấy rằng việc triển khai chuẩn hóa dữ liệu làm phát sinh việc sử dụng Ràng buộc khóa chính và Ràng buộc khóa ngoài. Ngoài ra, các vấn đề như lập chỉ mục Phím ngoại cũng hiển thị khi chúng tôi nghiên cứu sâu hơn về chủ đề này. Trước đó, chúng tôi đã đề cập đến việc việc thiếu chuẩn hóa có thể ảnh hưởng như thế nào đến thao tác mượt mà của dữ liệu như được mô tả trong Các bất thường về Chèn, Xóa và Cập nhật. Việc thiếu chuẩn hóa thích hợp cũng có thể ảnh hưởng gián tiếp đến hiệu suất truy vấn.

Gần đây tôi bắt gặp một bảng có dạng như trong bảng 1 mà chúng tôi sẽ gọi là Customer_Accounts.

S / Không	Tên	Tài khoản_No	Phone_No
1	Kenneth Igiri	9922344592	2348039988456, 2348039988456, 2348039988456
2	Ernest Doe	6677554897	2348022887546, 2348039988456

Tài khoản_ Khách hàng trên Bảng 1

Vấn đề chính với bảng này là nó vi phạm quy tắc thứ hai của Biểu mẫu Chuẩn đầu tiên. Kết quả trong trường hợp của chúng tôi là việc tìm kiếm khách hàng dựa trên số điện thoại của họ yêu cầu sử dụng LIKE trong mệnh đề WHERE và% ở đầu.

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

Tác động của cấu trúc trên là trình tối ưu hóa chưa bao giờ sử dụng chỉ mục, đây là một vấn đề lớn về hiệu suất.

Kết luận

Chuẩn hóa dữ liệu nằm trong lĩnh vực Thiết kế cơ sở dữ liệu và cả nhà phát triển và DBA nên chú ý đến các quy tắc được nêu trong bài viết này. Tốt hơn hết là bạn nên hoàn thành quá trình chuẩn hóa trước khi cơ sở dữ liệu đi vào sản xuất. Các lợi ích của Hệ thống quản lý cơ sở dữ liệu quan hệ được thiết kế phù hợp đơn giản là đáng để nỗ lực.