Đúng, việc xác định các mối quan hệ hoặc mối quan hệ nhiều-nhiều (M: N cho sự ngắn gọn) là một tình huống mà một người thực hành cơ sở dữ liệu phải đối mặt khá phổ biến khi đưa ra một lược đồ khái niệm. Các hiệp hội về tỷ lệ tim mạch nói trên xuất hiện trong các môi trường kinh doanh có tính chất rất khác nhau và khi được biểu diễn đúng ở mức logic bằng cách sắp xếp SQL-DDL, chúng không đưa ra các dự phòng có hại.
Theo cách này, mục tiêu của một bài tập mô hình hóa cơ sở dữ liệu phải là để phản ánh các đặc điểm có liên quan của bối cảnh kinh doanh quan tâm với độ chính xác cao ; do đó, nếu bạn xác định chính xác rằng có nhiều liên kết M: N, thì bạn phải thể hiện chúng trong (a) lược đồ khái niệm và cả trong (b) các khai báo mức logic tương ứng, bất kể có bao nhiêu kết nối của Kẻ đó các loại tỷ lệ cardinality khác phải được giải quyết.
Quy tắc kinh doanh
Bạn đã cung cấp một câu hỏi được bối cảnh hóa tốt và cũng đã làm rõ rằng cơ sở dữ liệu bạn đang làm việc hoàn toàn là giả thuyết, đó là một điểm quan trọng vì tôi đánh giá rằng một kịch bản kinh doanh thế giới thực như thế giới như một vấn đề đang được xem xét sẽ mở rộng hơn nhiều và, do đó, sẽ ngụ ý các yêu cầu thông tin phức tạp hơn.
Tôi quyết định (1) thực hiện một vài sửa đổi và mở rộng cho các quy tắc kinh doanh mà bạn đã cung cấp để (2) tạo ra một lược đồ khái niệm mô tả hơn nữa Mặc dù vẫn còn giả thuyết. Dưới đây là một số công thức mà tôi kết hợp lại với nhau:
- Một Đảng 1 là hoặc là một người hoặc một tổ chức
- Một bên được phân loại theo chính xác một PartyType
- Một PartyType phân loại zero-one-hoặc-nhiều Bên
- Một tổ chức phát triển zero-một-hoặc-nhiều sản phẩm
- Một sản phẩm hoặc là một hệ thống hoặc một trò chơi
- Một sản phẩm được phân loại theo chính xác một ProductType
- Một hệ thống được phân loại theo chính xác một SystemType
- Một trò chơi có thể được chơi thông qua một-nhiều hệ thống
- Một hệ thống được sử dụng để chơi one-to-many Games
- Một game được phân loại bởi zero-một-hoặc-nhiều thể loại
- Một thể loại phân loại zero-one-hoặc-nhiều Games
- Một sản phẩm tạo ra nhiều việc làm
- Một công việc được hoàn thành bởi zero-một-hoặc-nhiều người , những người đang chơi Vai trò của Cộng tác viên
- Một người là một cộng tác trong zero-một-hoặc-nhiều Jobs
1 Bên là một thuật ngữ được sử dụng trong bối cảnh pháp lý khi đề cập đến một cá nhân hoặc một nhóm các cá nhân sáng tác một thực thể duy nhất, vì vậy mệnh giá này phù hợp để đại diện cho Nhân dân và Tổ chức .
Sơ đồ IDEF1X
Sau đó, tôi đã tạo sơ đồ IDEF1X 2 như trong Hình 1 (đảm bảo nhấp vào liên kết để xem nó ở độ phân giải cao hơn), hợp nhất trong một thiết bị đồ họa duy nhất theo quy tắc kinh doanh được trình bày ở trên (cùng với một số quy tắc khác có vẻ phù hợp):
2 Đị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 hóa dữ liệu 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 tài liệu 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 quan hệ, tức là, Tiến sĩ EF Codd; trên (b) chế độ xem mối quan hệ thực thể của dữ liệu, đượ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.
Như bạn có thể thấy, tôi chỉ mô tả ba hiệp hội M: N bằng các loại thực thể liên kết tương ứng , nghĩa là:
- Cộng tác viên
- Hệ thống trò chơi
- GameGenre
Trong số các khía cạnh khác, có hai cấu trúc siêu kiểu riêng biệt , trong đó:
Người và Tổ chức là các kiểu con thực thể loại trừ lẫn nhau của Đảng , siêu thực thể của họ
Sản phẩm là siêu kiểu của Hệ thống và Trò chơi , lần lượt là các kiểu con loại trừ lẫn nhau
Trong trường hợp bạn không quen thuộc với các hiệp hội siêu kiểu, bạn có thể tìm sự giúp đỡ, ví dụ: câu trả lời của tôi cho các câu hỏi có tên:
Bố cục SQL-DDL logic minh họa
Kế tiếp, chúng ta phải đảm bảo rằng, ở mức logic:
- Mỗi loại thực thể được đại diện bởi một bảng cơ sở riêng
- Mỗi thuộc tính duy nhất của loại thực thể áp dụng được biểu thị bằng một cột cụ thể
- Một kiểu dữ liệu chính xác đượ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 xác định rõ, có thể là INT, DATETIME, CHAR, v.v. (tất nhiên, khi sử dụng, ví dụ: Firebird hoặc PostgreQuery , bạn có thể muốn sử dụng các DOMAIN mạnh hơ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
Vì vậy, tôi đã khai báo cách sắp xếp DDL sau dựa trên sơ đồ IDEF1X được hiển thị trước đây:
CREATE TABLE PartyType ( -- Stands for an independent entity type.
PartyTypeCode CHAR(1) NOT NULL, -- To retain 'P' or 'O'.
Name CHAR(30) NOT NULL, -- To keep 'Person' or 'Organization'.
--
CONSTRAINT PartyType_PK PRIMARY KEY (PartyTypeCode)
);
CREATE TABLE Party ( -- Represents an entity supertype.
PartyId INT NOT NULL,
PartyTypeCode CHAR(1) NOT NULL, -- To hold the value that indicates the type of the row denoting the complementary subtype occurrence: either 'P' for 'Person' or 'O' for 'Organization'.
CreatedDateTime TIMESTAMP NOT NULL,
--
CONSTRAINT Party_PK PRIMARY KEY (PartyId),
CONSTRAINT PartyToPartyType_FK FOREIGN KEY (PartyTypeCode)
REFERENCES PartyType (PartyTypeCode)
);
CREATE TABLE Person ( -- Denotes an entity subtype.
PersonId INT NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
FirstName CHAR(30) NOT NULL,
LastName CHAR(30) NOT NULL,
GenderCode CHAR(3) NOT NULL,
BirthDate DATE NOT NULL,
--
CONSTRAINT Person_PK PRIMARY KEY (PersonId),
CONSTRAINT Person_AK UNIQUE (FirstName, LastName, GenderCode, BirthDate), -- Composite ALTERNATE KEY.
CONSTRAINT PersonToParty_FK FOREIGN KEY (PersonId)
REFERENCES Party (PartyId)
);
CREATE TABLE Organization ( -- Stands for an entity subtype.
OrganizationId INT NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
Name CHAR(30) NOT NULL,
FoundingDate DATE NOT NULL,
--
CONSTRAINT Organization_PK PRIMARY KEY (OrganizationId),
CONSTRAINT Organization_AK UNIQUE (Name), -- Single-column ALTERNATE KEY.
CONSTRAINT OrganizationToParty_FK FOREIGN KEY (OrganizationId)
REFERENCES Party (PartyId)
);
CREATE TABLE ProductType ( -- Represents an independent entity type.
ProductTypeCode CHAR(1) NOT NULL, -- To enclose the values 'S' and 'G' in the corresponding rows.
Name CHAR(30) NOT NULL, -- To comprise the values 'System' and 'Person' in the respective rows.
--
CONSTRAINT ProductType_PK PRIMARY KEY (ProductTypeCode)
);
CREATE TABLE Product ( -- Denotes an entity supertype.
OrganizationId INT NOT NULL,
ProductNumber INT NOT NULL,
ProductTypeCode CHAR(1) NOT NULL, -- To keep the value that indicates the type of the row denoting the complementary subtype occurrence: either 'S' for 'System' or 'G' for 'Game'.
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Product_PK PRIMARY KEY (OrganizationId, ProductNumber), -- Composite PRIMARY KEY.
CONSTRAINT ProductToOrganization_FK FOREIGN KEY (OrganizationId)
REFERENCES Organization (OrganizationId),
CONSTRAINT ProductToProductType_FK FOREIGN KEY (ProductTypeCode)
REFERENCES ProductType (ProductTypeCode)
);
CREATE TABLE SystemType ( -- Stands for an independent entity type.
SystemTypeCode CHAR(1) NOT NULL,
Name CHAR(30) NOT NULL,
--
CONSTRAINT SystemType_PK PRIMARY KEY (SystemTypeCode)
);
CREATE TABLE MySystem ( -- Represents a dependent entity type.
OrganizationId INT NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
SystemNumber INT NOT NULL,
SystemTypeCode CHAR(1) NOT NULL,
ParticularColumn CHAR(30) NOT NULL,
--
CONSTRAINT System_PK PRIMARY KEY (OrganizationId, SystemNumber),
CONSTRAINT SystemToProduct_FK FOREIGN KEY (OrganizationId, SystemNumber)
REFERENCES Product (OrganizationId, ProductNumber),
CONSTRAINT SystemToSystemType_FK FOREIGN KEY (SystemTypeCode)
REFERENCES SystemType (SystemTypeCode)
);
CREATE TABLE Game ( -- Denotes an entity subtype.
OrganizationId INT NOT NULL, -- To be constrained as (a) the PRIMARY KEY and (b) a FOREIGN KEY.
GameNumber INT NOT NULL,
SpecificColumn CHAR(30) NOT NULL,
--
CONSTRAINT Game_PK PRIMARY KEY (OrganizationId, GameNumber),
CONSTRAINT GameToProduct_FK FOREIGN KEY (OrganizationId, GameNumber)
REFERENCES Product (OrganizationId, ProductNumber)
);
CREATE TABLE Genre ( -- Stands for an independent entity type.
GenreNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
Description CHAR(90) NOT NULL,
--
CONSTRAINT Genre_PK PRIMARY KEY (GenreNumber),
CONSTRAINT Genre_AK1 UNIQUE (Name),
CONSTRAINT Genre_AK2 UNIQUE (Description)
);
CREATE TABLE SystemGame ( -- Represents an associative entity type or M:N association.
SystemOrganizationId INT NOT NULL,
SystemNumber INT NOT NULL,
GameOrganizationId INT NOT NULL,
GameNumber INT NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT SystemGame_PK PRIMARY KEY (SystemOrganizationId, SystemNumber, GameOrganizationId, GameNumber), -- Composite PRIMARY KEY.
CONSTRAINT SystemGameToSystem_FK FOREIGN KEY (SystemOrganizationId, SystemNumber) -- Multi-column FOREIGN KEY.
REFERENCES MySystem (OrganizationId, SystemNumber),
CONSTRAINT SystemGameToGame_FK FOREIGN KEY (SystemOrganizationId, GameNumber) -- Multi-column FOREIGN KEY.
REFERENCES Game (OrganizationId, GameNumber)
);
CREATE TABLE GameGenre ( -- Denotes an associative entity type or M:N association.
GameOrganizationId INT NOT NULL,
GameNumber INT NOT NULL,
GenreNumber INT NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT GameGenre_PK PRIMARY KEY (GameOrganizationId, GameNumber, GenreNumber), -- Composite PRIMARY KEY.
CONSTRAINT GameGenreToGame_FK FOREIGN KEY (GameOrganizationId, GameNumber)
REFERENCES Game (OrganizationId, GameNumber), -- Multi-column FOREIGN KEY.
CONSTRAINT GameGenreToGenre_FK FOREIGN KEY (GenreNumber)
REFERENCES Genre (GenreNumber)
);
CREATE TABLE Job ( -- Stands for an associative entity type or M:N association.
OrganizationId INT NOT NULL,
ProductNumber INT NOT NULL,
JobNumber INT NOT NULL,
Title CHAR(30) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Job_PK PRIMARY KEY (OrganizationId, ProductNumber, JobNumber), -- Composite PRIMARY KEY.
CONSTRAINT Job_AK UNIQUE (Title), -- Single-column ALTERNATE KEY.
CONSTRAINT JobToProduct_FK FOREIGN KEY (OrganizationId, ProductNumber) -- Multi-column FOREIGN KEY.
REFERENCES Product (OrganizationId, ProductNumber)
);
CREATE TABLE Collaborator ( -- Represents an associative entity type or M:N association.
CollaboratorId INT NOT NULL,
OrganizationId INT NOT NULL,
ProductNumber INT NOT NULL,
JobNumber INT NOT NULL,
AssignedDateTime DATETIME NOT NULL,
--
CONSTRAINT Collaborator_PK PRIMARY KEY (CollaboratorId, OrganizationId, ProductNumber, JobNumber), -- Composite PRIMARY KEY.
CONSTRAINT CollaboratorToPerson_FK FOREIGN KEY (CollaboratorId)
REFERENCES Person (PersonId),
CONSTRAINT CollaboratorToJob_FK FOREIGN KEY (OrganizationId, ProductNumber, JobNumber) -- Multi-column FOREIGN KEY.
REFERENCES Job (OrganizationId, ProductNumber, JobNumber)
);
Có thể nhấn mạnh rằng có các tuyên bố về các ràng buộc PRIMARY KEY tổng hợp trên một số bảng, đại diện cho hệ thống phân cấp các kết nối diễn ra giữa các loại thực thể khái niệm, sự sắp xếp có thể rất có lợi đối với việc truy xuất dữ liệu khi, ví dụ, biểu thị CHỌN các hoạt động bao gồm các mệnh đề THAM GIA để có được các bảng dẫn xuất .
Có, (i) mọi liên kết M: N và (ii) mỗi một trong các loại thực thể liên quan được ký hiệu là (iii) bảng tương ứng trong cấu trúc DDL hợp lý, do đó, đặc biệt chú ý đến các ràng buộc CHÍNH HÃNG và NGOẠI TỆ (và lưu ý tôi để lại dưới dạng nhận xét) của các bảng biểu thị các yếu tố khái niệm này, bởi vì chúng hỗ trợ trong việc đảm bảo rằng các kết nối giữa các hàng có liên quan đáp ứng tỷ lệ tim mạch áp dụng.
Việc sử dụng các khóa tổng hợp đã được Tiến sĩ EF Codd giới thiệu từ chính nguồn gốc của mô hình quan hệ, như đã được chứng minh trong các ví dụ mà ông đưa vào bài báo chuyên đề năm 1970 của mình có tên Mô hình quan hệ cho các ngân hàng dữ liệu chia sẻ lớn (chính xác là cũng trình bày phương pháp thanh lịch nhất để xử lý các hiệp hội M: N khái niệm).
Tôi đưa ra một db <> fiddle và SQL Fiddle , cả hai đều chạy trên Microsoft SQL Server 2014, để cấu trúc có thể được kiểm tra trong trò chơi hành động.
Bình thường hóa
Chuẩn hóa là một thủ tục mức logic ngụ ý, về cơ bản nói:
Loại bỏ các cột không nguyên tử thông qua hình thức bình thường đầu tiên để thao tác và thu hẹp dữ liệu dễ dàng hơn nhiều để đối phó với ngôn ngữ sử dụng dữ liệu (ví dụ: SQL).
Loại bỏ các phụ thuộc không mong muốn giữa các cột của một bảng cụ thể nhờ các hình thức bình thường kế tiếp để tránh cập nhật dị thường .
Đương nhiên, người ta phải tính đến ý nghĩa của (các) bảng và cột (s) có vấn đề.
Tôi thích nghĩ về việc chuẩn hóa như một bài kiểm tra dựa trên khoa học mà một nhà thiết kế áp dụng cho các yếu tố thích hợp một khi anh ta đã phác họa một sự sắp xếp mức logic ổn định để xác định xem các mục của nó có tuân theo mọi hình thức thông thường hay không. Sau đó, nếu cần, người thiết kế thực hiện các biện pháp sửa lỗi thích hợp.
Dư
Trong mô hình quan hệ, trong khi việc sao chép các giá trị có trong các cột không chỉ được chấp nhận mà còn được mong đợi , các hàng trùng lặp bị cấm . Ở mức độ đó, theo như tôi có thể thấy, các hàng trùng lặp và các loại dư thừa có hại khác được ngăn chặn trong tất cả các bảng có bố cục logic được trình bày trước đó, có lẽ bạn muốn làm rõ mối quan tâm của mình về vấn đề này.
Dù sao, bạn chắc chắn có thể (a) tự đánh giá cấu trúc đã nói của mình bằng các hình thức thông thường để xác định nếu nó đáp ứng các yêu cầu và (b) sửa đổi nó nếu cần thiết.
Tài nguyên liên quan
- Trong loạt bài này của bài viết tôi trình bày một số thảo luận về một M đơn giản: N hiệp hội có thể interrelate các trường hợp của hai khác nhau các loại thực thể.
- Trong một phương pháp khác, tôi đề xuất một cách tiếp cận để xử lý sự xuất hiện của Hóa đơn vật liệu trực tuyến và các bộ phận của vụ nổ, trong đó tôi mô tả cách kết nối các trường hợp khác nhau của cùng loại thực thể.
Hiệp hội ternary
Có một khía cạnh quan trọng khác mà bạn đưa ra thông qua các bình luận (được đăng trong câu trả lời hiện đã bị xóa):
Mỗi lần tôi cố gắng làm một cây cầu, các yếu tố trong cây cầu đó cũng có nhiều đến nhiều, tôi có ấn tượng không được phép hoặc ít nhất là không được khuyến khích.
Tình huống đó dường như chỉ ra rằng một trong những mối quan tâm của bạn có liên quan đến các hiệp hội ternary khái niệm . Về cơ bản, loại liên kết này xuất hiện khi tồn tại (1) mối quan hệ liên quan đến (2) hai mối quan hệ khác, nói cách khác, mối quan hệ giữa các mối quan hệ cũng vậy, vì mối quan hệ là một thực thể theo đúng nghĩa của nó -.
Những sắp xếp này, khi được quản lý phù hợp, cũng không mang lại dư thừa có hại. Và, vâng, nếu có một trường hợp sử dụng nhất định khi bạn xác định rằng các mối quan hệ đó xuất hiện giữa các loại thực thể của thế giới thực, thì bạn phải (i) mô hình và (ii) khai báo chúng với độ chính xác ở mức logic.