Theo cách giải thích của tôi về mô tả của bạn về bối cảnh kinh doanh mà bạn quan tâm, bạn đang xử lý một cấu trúc siêu kiểu 1 trong đó (a) Diễn viên , Giám đốc và Nhà văn là các kiểu con thực thể của (b) Person , siêu thực thể của họ và (c) phân nhóm nói không loại trừ lẫn nhau.
Theo cách này, nếu bạn quan tâm đến việc xây dựng cơ sở dữ liệu quan hệ phản ánh chính xác kịch bản như vậy và do đó hy vọng rằng nó hoạt động như vậy, thì việc làm rõ nhận xét sau của bạn khá quan trọng đối với các điểm trước đó, bởi vì chúng có ý nghĩa tại cả (1) khái niệm và (2) mức độ biểu diễn logic của cơ sở dữ liệu được đề cập:
[V]] bảng bổ sung cho từng loại người dùng tương ứng mà mỗi loại có bộ cột duy nhất của riêng họ.
[V]] chỉ có bốn loại người dùng có liên quan. Có một cơ hội bên ngoài rằng con số này có thể tăng lên, nhưng xác suất là thấp - và trong trường hợp như vậy sẽ là một con số rất nhỏ.
Tôi sẽ giải thích tất cả các khía cạnh đó và một số yếu tố quan trọng khác trong các phần dưới đây.
Quy tắc kinh doanh
Trước tiên, để xác định lược đồ khái niệm tương ứng, có thể sử dụng lược đồ tương ứng để bạn có thể điều chỉnh nó để đảm bảo rằng nó đáp ứng các yêu cầu thông tin chính xác của Wap , tôi đã xây dựng một số quy tắc kinh doanh có tầm quan trọng đặc biệt:
- Một Người có thể thực hiện Vai trò 2 hoặc 3 (tức là một đối với tất cả) . Nói cách khác, một người có thể
- một diễn viên và
- một giám đốc và
- một nhà văn .
- Một người có thể đăng nhập thông qua UserProfile 0 hoặc 1 .
- Một diễn viên cung cấp một hoặc hai hoặc ba URL 3 .
- Một diễn viên được nhóm bởi một dân tộc .
- Một nhóm dân tộc không có một hoặc nhiều diễn viên .
- Một Nhà văn dựa trên một Địa điểm .
- Một Location là cơ sở của zero-một-hay-hơn Writers .
Sơ đồ IDEF1X tiếp xúc
Sau đó, tôi đã tạo sơ đồ IDEF1X 4 được hiển thị trong Hình 1 , nhóm này bao gồm tất cả các công thức ở trên cùng với các quy tắc khác xuất hiện thích hợp:
Như đã trình bày, siêu kiểu Person (i) có hộp riêng, (ii) sở hữu các thuộc tính hoặc thuộc tính áp dụng cho tất cả các kiểu con và (iii) trình bày các dòng kết nối nó với các hộp của mỗi kiểu con.
Đổi lại, mọi kiểu con (a) xuất hiện trong hộp chuyên dụng của riêng nó và (b) giữ độc quyền các thuộc tính áp dụng của nó. KEY PRIMARY của supertype, PersonId , di chuyển 5 đến các kiểu con với tên vai trò lần lượt là 6 ActorId , DirectorId và WriterId .
Ngoài ra, tôi đã tránh ghép Người với loại thực thể UserProfile , cho phép tách tất cả các hàm ý, liên kết hoặc mối quan hệ theo ngữ cảnh của họ, v.v. Thuộc tính PersonId đã di chuyển sang UserProfile với tên vai trò UserId .
Bạn nêu trong cơ quan câu hỏi rằng
Và tất cả các diễn viên sẽ phải bao gồm ít nhất một URL cho bất kỳ hồ sơ diễn viên trực tuyến nào khác của họ; hiện tại có ba cái mà họ có thể bao gồm, nhưng con số này có thể tăng lên.
Vì vậy, URL là một loại thực thể theo đúng nghĩa của nó và được liên kết trực tiếp với phân nhóm Diễn viên theo trích dẫn này.
Và, trong các bình luận , bạn xác định rằng
[Mạnh] một diễn viên sẽ có một headshot (ảnh), trong khi một nhà văn sẽ không [Bắn]
Sau đó, trong số các tính năng khác, tôi đã bao gồm Headshot như một thuộc tính của loại thực thể Actor .
Đối với các loại thực thể Dân tộc và Địa điểm , tất nhiên họ có thể yêu cầu các tổ chức phức tạp hơn (ví dụ: Diễn viên có thể thuộc một, hai hoặc nhiều nhóm dân tộc khác nhau theo tỷ lệ riêng biệt và Nhà văn có thể dựa trên một địa điểm cần ghi âm quốc gia, khu vực hành chính, quận, v.v.) nhưng có vẻ như nhu cầu của bối cảnh kinh doanh của bạn được bao phủ thành công với các cấu trúc ở đây được mô hình hóa.
Đương nhiên, bạn có thể thực hiện nhiều điều chỉnh khi cần thiết.
Thiết kế logic SQL-DDL minh họa
Do đó, dựa trên sơ đồ IDEF1X được hiển thị và mô tả ở trên, tôi đã viết bố cục DDL logic được hiển thị như sau (Tôi đã cung cấp các ghi chú giải thích một số đặc điểm mà tôi đánh giá là đặc biệt quan trọng đối với các bảng, cột và ràng buộc khai báo):
-- You should determine which are the most fitting
-- data types and sizes for all your table columns
-- depending on your business context characteristics.
-- Also, you should make accurate tests to define the
-- most convenient INDEX strategies based on the exact
-- data manipulation tendencies of your business needs.
-- As one would expect, you are free to utilize
-- your preferred (or required) naming conventions.
CREATE TABLE Person ( -- Represents the supertype.
PersonId INT NOT NULL,
FirstName CHAR(30) NOT NULL,
LastName CHAR(30) NOT NULL,
BirthDate DATE NOT NULL,
GenderCode CHAR(3) NOT NULL,
TwitterProfile CHAR(30) NOT NULL,
PhoneNumber CHAR(30) NOT NULL,
EmailAddress CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Person_PK PRIMARY KEY (PersonId),
CONSTRAINT Person_AK1 UNIQUE ( -- Composite ALTERNATE KEY.
FirstName,
LastName,
GenderCode,
BirthDate
),
CONSTRAINT Person_AK2 UNIQUE (TwitterProfile), -- ALTERNATE KEY.
CONSTRAINT Person_AK3 UNIQUE (EmailAddress) -- ALTERNATE KEY.
);
CREATE TABLE Ethnicity ( -- Its rows will serve a “look-up” purpose.
EthnicityId INT NOT NULL,
Name CHAR(30) NOT NULL,
Description CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Ethnicity_PK PRIMARY KEY (EthnicityId),
CONSTRAINT Ethnicity_AK UNIQUE (Description)
);
CREATE TABLE Actor ( -- Stands for one of the subtypes.
ActorId INT NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
Headshot CHAR(30) NOT NULL, -- May, e.g., contain a URL indicating the path where the photo file is actually stored.
EthnicityId INT NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Actor_PK PRIMARY KEY (ActorId),
CONSTRAINT ActorToPerson_PK FOREIGN KEY (ActorId)
REFERENCES Person (PersonId),
CONSTRAINT ActorToEthnicity_PK FOREIGN KEY (EthnicityId)
REFERENCES Ethnicity (EthnicityId)
);
CREATE TABLE Director ( -- Denotes one of the subtypes
DirectorId INT NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
Bio CHAR(120) NOT NULL,
Etcetera CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Director_PK PRIMARY KEY (DirectorId),
CONSTRAINT DirectorToPerson_PK FOREIGN KEY (DirectorId)
REFERENCES Person (PersonId)
);
CREATE TABLE Country (
CountryCode CHAR(2) NOT NULL,
Name CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Country_PK PRIMARY KEY (CountryCode),
CONSTRAINT Country_AK UNIQUE (Name)
);
CREATE TABLE Location ( -- Its rows will serve a “look-up” purpose.
CountryCode CHAR(2) NOT NULL,
LocationCode CHAR(3) NOT NULL,
Name CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Location_PK PRIMARY KEY (CountryCode, LocationCode),
CONSTRAINT Location_AK UNIQUE (CountryCode, Name)
);
CREATE TABLE Writer ( -- Represents one of the subtypes.
WriterId INT NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
CountryCode CHAR(2) NOT NULL,
LocationCode CHAR(3) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Writer_PK PRIMARY KEY (WriterId),
CONSTRAINT WriterToPerson_PK FOREIGN KEY (WriterId)
REFERENCES Person (PersonId),
CONSTRAINT WriterToLocation_PK FOREIGN KEY (CountryCode, LocationCode)
REFERENCES Location (CountryCode, LocationCode)
);
CREATE TABLE UserProfile (
UserId INT NOT NULL, -- Must be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
UserName CHAR(30) NOT NULL,
Etcetera CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT UserProfile_PK PRIMARY KEY (UserId),
CONSTRAINT UserProfile_AK UNIQUE (UserName), -- ALTERNATE KEY.
CONSTRAINT UserProfileToPerson_PK FOREIGN KEY (UserId)
REFERENCES Person (PersonId)
);
CREATE TABLE URL (
ActorId INT NOT NULL,
Address CHAR(90) NOT NULL,
Etcetera CHAR(30) NOT NULL,
AddedDateTime DATETIME NOT NULL,
--
CONSTRAINT URL_PK PRIMARY KEY (ActorId, Address), -- Composite PRIMARY KEY.
CONSTRAINT URLtoActor_FK FOREIGN KEY (ActorId)
REFERENCES Actor (ActorId)
);
Do đó, (1) mọi khía cạnh số ít của bố cục logic ở trên đều mang một ý nghĩa rất chính xác từ (2) một đặc điểm riêng của môi trường kinh doanh theo thỏa thuận 7 lợi ích với tinh thần của khung quan hệ của Tiến sĩ Edgar Frank Codd -, bởi vì:
- Mỗi bảng cơ sở đại diện cho một loại thực thể riêng.
- Mỗi cột là viết tắt của một thuộc tính duy nhất của loại thực thể tương ứng.
- Một loại dữ liệu cụ thể được cố định cho từng cột để đảm bảo rằng tất cả các giá trị mà nó chứa thuộc về một tập hợp cụ thể và được phân tách chính xác a, có thể là INT, DATETIME, CHAR, v.v. (và chúng tôi hy vọng rằng cuối cùng MySQL sẽ kết hợp DOMAIN hỗ trợ trong phiên bản tương lai gần).
- Nhiều ràng buộc được cấu hình (khai báo) để đảm bảo rằng các xác nhận dưới dạng hàng được giữ lại trong tất cả các bảng tuân thủ các quy tắc kinh doanh được xác định ở cấp độ khái niệm.
Mỗi hàng có nghĩa là truyền đạt ngữ nghĩa được xác định rõ, ví dụ: một Personhàng được đọc
Người được xác định bởi PersonId rđược gọi bởi FirstName svà LastName t, được sinh ra trên BirthDate u, có Giới tính v, các tweet trên TwitterProfile w, được truy cập qua PhoneNumber x, được liên hệ qua EmailAddress yvà được đăng ký trên createdDateTimez .
Việc có bố cục như thế này rất thuận lợi, vì bạn có thể rút ra các bảng mới (ví dụ: các thao tác CHỌN thu thập các cột TỪ nhiều bảng với sự trợ giúp của mệnh đề THAM GIA) mà sự thành công của Wapin cũng mang một ý nghĩa rất chính xác (xem phần mang tên xem Lượt xem dưới đây).
Chúng ta sẽ đề cập rằng, với cấu hình này, (i) một hàng đại diện cho một thể hiện của kiểu con được xác định bởi (ii) cùng một giá trị PRIMARY KEY để phân biệt hàng biểu thị sự xuất hiện của siêu kiểu bổ sung. Vì vậy, nó là nhiều hơn cơ hội để lưu ý rằng
- (a) đính kèm một cột bổ sung để giữ các thay thế được tạo bởi hệ thống và được gán bởi hệ thống 8 đến (b) các bảng đứng cho các kiểu con là (c) hoàn toàn không cần thiết .
Với thiết kế logic này, nếu các kiểu con mới được xác định là có liên quan trong bối cảnh kinh doanh của bạn, bạn sẽ phải khai báo một bảng cơ sở mới, nhưng điều đó cũng xảy ra khi các loại thực thể khác được coi là có ý nghĩa, vì vậy, tình huống sẽ xảy ra Thực tế, bình thường.
Lượt xem
Để tải xuống Fetch, ví dụ, tất cả thông tin tương ứng với Diễn viên , Giám đốc hoặc Nhà văn , bạn có thể khai báo một số chế độ xem (ví dụ: bảng có nguồn gốc hoặc có thể biểu thị) để bạn có thể CHỌN trực tiếp từ một tài nguyên mà không cần phải viết liên quan đến THAM GIA mọi lúc; ví dụ, với VIEW được khai báo bên dưới, bạn có thể có được thông tin Diễn viên đầy đủ của hoàng tử :
--
CREATE VIEW FullActor AS
SELECT P.FirstName,
P.Lastname,
P.BirthDate,
P.GenderCode,
P.TwitterProfile,
P.PhoneNumber,
P.EmailAddress,
A.Headshot,
E.Name AS Ethnicity
FROM Person P
JOIN Actor A
ON A.ActorId = P.PersonId
JOIN Ethnicity E
ON E.EthnicityId = A.EthnicityId;
--
Tất nhiên, bạn có thể làm theo một cách tiếp cận tương tự để lấy thông tin về Giám đốc và Nhà văn đầy đủ của hoàng tử :
--
CREATE VIEW FullDirector AS
SELECT P.FirstName,
P.Lastname,
P.BirthDate,
P.GenderCode,
P.TwitterProfile,
P.PhoneNumber,
P.EmailAddress,
D.Bio,
D.Etcetera
FROM Person P
JOIN Director D
ON D.DirectorId = P.PersonId;
--
CREATE VIEW FullWriter AS
SELECT P.FirstName,
P.Lastname,
P.BirthDate,
P.GenderCode,
P.TwitterProfile,
P.PhoneNumber,
P.EmailAddress,
L.Name AS Location,
C.Name AS Country
FROM Person P
JOIN Writer W
ON W.WriterId = P.PersonId
JOIN Country C
ON C.CountryCode = W.CountryCode
JOIN Location L
ON L.LocationCode = W.LocationCode;
--
Tôi đã đăng tất cả các câu lệnh DDL và các khung nhìn DML ở đây đã thảo luận trong SQL Fiddle này chạy trên MySQL 5.6 để bạn có thể xem và kiểm tra chúng trong hành động.
Chú thích
1 Trong một số kỹ thuật mô hình hóa khái niệm, các hiệp hội siêu kiểu con được gọi là mối quan hệ lớp siêu lớp .
2 Mặc dù bạn đề cập rằng trên thực tế tồn tại nhiều Vai trò hơn mà một Người có thể thực hiện, nhưng ba người bạn tiết lộ là đủ tốt để thảo luận về kịch bản phơi bày một số phân nhánh quan trọng .
3 Nhưng, như bạn đã lưu ý, trong tương lai, một Diễn viên cuối cùng có thể cung cấp một-nhiều URL .
4 Định nghĩa tích hợp cho mô hình hóa thông tin ( IDEF1X ) là một kỹ thuật mô hình rất được khuyến khích, được thành lập như một tiêu chuẩn vào tháng 12 năm 1993 bởi Viện Tiêu chuẩn và Công nghệ Quốc gia Hoa Kỳ (NIST). Nó dựa trên (a) các công trình lý thuyết ban đầu được tác giả bởi người khởi tạo duy nhất của mô hình dữ liệu quan hệ, tức là, Tiến sĩ EF Codd; trên (b) quan điểm về mối quan hệ thực thể , được phát triển bởi Tiến sĩ PP Chen ; và cũng trên (c) Kỹ thuật thiết kế cơ sở dữ liệu logic, được tạo bởi Robert G. Brown.
5 Tiêu chuẩn IDEF1X định nghĩa di chuyển khóa là quy trình Mô hình hóa việc đặt khóa chính của một thực thể cha mẹ hoặc chung [tức là một siêu kiểu] trong thực thể con hoặc thể loại của nó [tức là một kiểu con] như là một khóa ngoại.
6 Trong IDEF1X, tên vai trò là nhãn đặc biệt được gán cho thuộc tính FK để thể hiện ý nghĩa mà nó giữ trong phạm vi của loại thực thể tương ứng.
7 Ngoại trừ, một cách tự nhiên, đối với các thuộc tính khái niệm giả định (và các cột logic) Director.Etcetera và UserProfile.Etcetera , chỉ là các trình giữ chỗ mà tôi đã sử dụng để thể hiện tính khả thi của việc thêm nhiều thuộc tính (và cột) áp dụng cho loại thực thể khái niệm tương ứng (và bảng logic).
8 Ví dụ, nối thêm một cột bổ sung với thuộc tính AUTO_INCREMENT vào bảng cơ sở dữ liệu, chạy chạy trên MySQL.