Theo giải thích của tôi về thông số kỹ thuật của bạn, bạn muốn tìm một phương pháp để thực hiện hai cách khác nhau (nhưng được kết nối cấu trúc siêu kiểu con ) .
Để đưa ra một cách tiếp cận để đạt được nhiệm vụ nói trên, tôi sẽ thêm vào kịch bản có vấn đề về hai tác phẩm kinh điển loại thực thể giả định được gọi Foovà Bar, tôi sẽ trình bày chi tiết dưới đây.
Quy tắc kinh doanh
Dưới đây là một vài câu lệnh sẽ giúp tôi tạo ra một mô hình logic:
A Foo is either one Bar or one CA Foo is categorized by one FooTypeA Bar is either one A or one CA Bar is classified by one BarType
Mô hình logic
Và sau đó, mô hình logic IDEF1X [1] kết quả được hiển thị trong Hình 1 (và bạn có thể tải xuống từ Dropbox dưới dạng PDF ):
Bổ sung Foo và Bar
Tôi đã không thêm FoovàBar để làm cho mô hình đẹp hơn, nhưng để làm cho nó biểu cảm hơn. Tôi cho rằng chúng quan trọng do những điều sau đây:
Như Avà Bchia sẻ thuộc tính được đặt tên E, tính năng này gợi ý rằng chúng là các loại thuộc tính của một loại khái niệm , sự kiện , con người , đo lường , v.v., mà tôi đại diện bằng phương tiện của Barloại siêu thực, lần lượt, là một kiểu thuộc tính Foo, giữ Dthuộc tính ở đầu phân cấp.
Kể từ khi Cchỉ chia sẻ một thuộc tính với phần còn lại của các loại thực thể được thảo luận, ví dụ D, khía cạnh này ám chỉ rằng nó là một loại subentity của một loại khái niệm , sự kiện , người , đo lường , vv, do đó tôi mô tả trường hợp này nhờ loại Foosiêu thực thể.
Tuy nhiên, đây chỉ là giả định và vì cơ sở dữ liệu quan hệ có nghĩa là phản ánh chính xác ngữ nghĩa của bối cảnh kinh doanh nhất định , bạn phải xác định và phân loại tất cả những điều quan tâm trong miền cụ thể của mình để bạn có thể, chính xác hơn, nắm bắt được ý nghĩa hơn .
Các yếu tố quan trọng trong giai đoạn thiết kế
Nó khá hữu ích để nhận thức được thực tế rằng, đặt tất cả các thuật ngữ sang một bên, một cụm siêu kiểu phụ độc quyền là một mối quan hệ bình thường. Hãy để chúng tôi mô tả tình huống theo cách sau:
- Mỗi lần xuất hiện loại siêu độc quyền chỉ liên quan đến một bổ sung loại phụ .
Do đó, có một sự tương ứng (hoặc cardinality) của một đối một (1: 1) trong những trường hợp này.
Như bạn đã biết từ các bài viết trước của bạn, thuộc tính phân biệt đối xử (cột, khi được triển khai) đóng vai trò tối quan trọng khi tạo liên kết có tính chất này, bởi vì nó chỉ ra thể hiện của kiểu con chính xác mà siêu kiểu được kết nối . các di cư KHÓA CHÍNH từ (i) siêu kiểu sang (ii) các kiểu con cũng có ý nghĩa quan trọng.
Kết cấu bê tông DDL
Và sau đó tôi đã viết một cấu trúc DDL dựa trên mô hình logic được trình bày ở trên:
CREATE TABLE FooType -- Look-up table.
(
FooTypeCode CHAR(2) NOT NULL,
Description CHAR(90) NOT NULL,
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_FooType PRIMARY KEY (FooTypeCode),
CONSTRAINT AK_FooType_Description UNIQUE (Description)
);
CREATE TABLE Foo -- Supertype
(
FooId INT NOT NULL, -- This PK migrates (1) to ‘Bar’ as ‘BarId’, (2) to ‘A’ as ‘AId’, (3) to ‘B’ as ‘BId’, and (4) to ‘C’ as ‘CId’.
FooTypeCode CHAR(2) NOT NULL, -- Discriminator column.
D INT NOT NULL, -- Column that applies to ‘Bar’ (and therefore to ‘A’ and ‘B’) and ‘C’.
CreatedDateTime DATETIME NOT NULL,
CONSTRAINT PK_Foo PRIMARY KEY (FooId),
CONSTRAINT FK_from_Foo_to_FooType FOREIGN KEY (FooTypeCode)
REFERENCES FooType (FooTypeCode)
);
CREATE TABLE BarType -- Look-up table.
(
BarTypeCode CHAR(1) NOT NULL,
Description CHAR(90) NOT NULL,
CONSTRAINT PK_BarType PRIMARY KEY (BarTypeCode),
CONSTRAINT AK_BarType_Description UNIQUE (Description)
);
CREATE TABLE Bar -- Subtype of ‘Foo’.
(
BarId INT NOT NULL, -- PK and FK.
BarTypeCode CHAR(1) NOT NULL, -- Discriminator column.
E INT NOT NULL, -- Column that applies to ‘A’ and ‘B’.
CONSTRAINT PK_Bar PRIMARY KEY (BarId),
CONSTRAINT FK_from_Bar_to_Foo FOREIGN KEY (BarId)
REFERENCES Foo (FooId),
CONSTRAINT FK_from_Bar_to_BarType FOREIGN KEY (BarTypeCode)
REFERENCES BarType (BarTypeCode)
);
CREATE TABLE A -- Subtype of ‘Bar’.
(
AId INT NOT NULL, -- PK and FK.
X INT NOT NULL, -- Particular column.
CONSTRAINT PK_A PRIMARY KEY (AId),
CONSTRAINT FK_from_A_to_Bar FOREIGN KEY (AId)
REFERENCES Bar (BarId)
);
CREATE TABLE B -- (1) Subtype of ‘Bar’ and (2) supertype of ‘A’ and ‘B’.
(
BId INT NOT NULL, -- PK and FK.
Y INT NOT NULL, -- Particular column.
CONSTRAINT PK_B PRIMARY KEY (BId),
CONSTRAINT FK_from_B_to_Bar FOREIGN KEY (BId)
REFERENCES Bar (BarId)
);
CREATE TABLE C -- Subtype of ‘Foo’.
(
CId INT NOT NULL, -- PK and FK.
Z INT NOT NULL, -- Particular column.
CONSTRAINT PK_C PRIMARY KEY (CId),
CONSTRAINT FK_from_C_to_Foo FOREIGN KEY (FooId)
REFERENCES Foo (FooId)
);
Với cấu trúc này, bạn tránh việc lưu trữ các dấu NULL trong các bảng cơ sở (hoặc các mối quan hệ ), điều này sẽ gây ra sự mơ hồ cho cơ sở dữ liệu của bạn.
Tính toàn vẹn, nhất quán và các cân nhắc khác
Khi bạn đang triển khai cơ sở dữ liệu của mình, bạn phải đảm bảo rằng (a) mỗi hàng siêu kiểu độc quyền luôn được bổ sung bởi đối tác phụ của nó và tương ứng , đảm bảo rằng (b) hàng phụ kiểu đó tương thích với giá trị có trong cột phân biệt siêu phân loại . Do đó, việc sử dụng ACID khá thuận tiệnTRANSACTIONS để đảm bảo rằng các điều kiện này được đáp ứng trong cơ sở dữ liệu của bạn.
Bạn không nên từ bỏ tính hợp lý, tự thể hiện và độ chính xác của cơ sở dữ liệu của bạn, đây là những khía cạnh quyết định làm cho cơ sở dữ liệu của bạn vững chắc hơn.
Hai câu trả lời được đăng trước đó đã bao gồm các điểm thích hợp chắc chắn có giá trị khi thiết kế, tạo và quản lý cơ sở dữ liệu của bạn và (các) chương trình ứng dụng của nó.
Lấy dữ liệu bằng cách định nghĩa XEM
Bạn có thể thiết lập một số chế độ xem kết hợp các cột của các nhóm siêu kiểu phụ khác nhau , để bạn có thể truy xuất dữ liệu trong tay mà không cần, ví dụ, viết các mệnh đề THAM GIA cần thiết mỗi lần. Bằng cách này, bạn có thể CHỌN trực tiếp TỪ VIEW ( mối quan hệ hoặc bảng có nguồn gốc ) một cách dễ dàng.
Như bạn có thể thấy, chắc chắn, Ted Ted Codd là một thiên tài. Các công cụ mà anh ấy để lại khá mạnh mẽ và thanh lịch, và tất nhiên, được tích hợp tốt với nhau.
Tài nguyên liên quan
Nếu bạn muốn phân tích một số cơ sở dữ liệu rộng lớn liên quan đến các mối quan hệ siêu kiểu phụ, bạn sẽ tìm thấy giá trị các câu trả lời phi thường được đề xuất bởi @PerformanceDBA cho các câu hỏi Stack Overflow sau:
chú thích
1. Đị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ệ Hoa Kỳ ( NIST ). Nó hoàn toàn dựa trên (a) các tài liệu lý thuyết ban đầu được tác giả bởi Tiến sĩ EF Codd; trên (b) các Entity-Mối quan hệ quan điểm của dữ liệu, 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. Điều đáng chú ý là IDEF1X đã được chính thức hóa bằng cách logic thứ nhất.