ตามการตีความข้อกำหนดของฉันของคุณคุณต้องการค้นหาวิธีในการใช้โครงสร้างsupertype-subtypeสองแบบที่แตกต่างกัน (แต่เชื่อมต่อ )
ในการที่จะเปิดเผยวิธีการเพื่อให้บรรลุภารกิจที่กำหนดไว้ฉันจะเพิ่มสถานการณ์ให้กับประเภทเอนทิตีสมมุติสองแบบคลาสสิกที่เรียกว่าFooและBarซึ่งฉันจะอธิบายรายละเอียดการร้อง
กฎเกณฑ์ทางธุรกิจ
ต่อไปนี้เป็นข้อความบางส่วนที่จะช่วยฉันในการสร้างโมเดลเชิงตรรกะ:
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
โมเดลเชิงตรรกะ
จากนั้นแบบจำลองตรรกะIDEF1X [1]จะแสดงในรูปที่ 1 (และคุณสามารถดาวน์โหลดได้จาก Dropbox ในรูปแบบ PDFเช่นกัน):
นอกจากนี้ The Foo and Bar
ฉันไม่ได้เพิ่มFooและBarทำให้โมเดลดูดีขึ้น แต่เพื่อให้แสดงออกได้มากขึ้น ฉันคิดว่าพวกเขามีความสำคัญเนื่องจากต่อไปนี้:
ในฐานะที่เป็นAและBมีคุณสมบัติที่มีชื่อEคุณสมบัตินี้แสดงให้เห็นว่าพวกเขาเป็นประเภท subentity ของที่แตกต่างกัน ( แต่ที่เกี่ยวข้อง) การเรียงลำดับของแนวคิด , เหตุการณ์ , คน , วัดฯลฯ ซึ่งผมเป็นตัวแทนโดยวิธีการของBarประเภท superentity ว่าในที่สุดก็เป็น ประเภทย่อยของFooซึ่งถือDแอตทริบิวต์ที่ด้านบนของลำดับชั้น
เนื่องจากCหุ้นเพียงหนึ่งแอตทริบิวต์กับส่วนที่เหลือของประเภทกิจการภายใต้การอภิปรายซึ่ง ได้แก่Dด้านนี้เอาแต่ใจว่ามันเป็นชนิด subentity ของชนิดของอีกแนวคิด , เหตุการณ์ , คน , วัดฯลฯ ดังนั้นฉันภาพกรณีนี้โดยอาศัยอำนาจตามFooชนิดเอนทิตีซุปเปอร์
อย่างไรก็ตามสิ่งเหล่านี้เป็นเพียงข้อสันนิษฐานและเนื่องจากฐานข้อมูลเชิงสัมพันธ์หมายถึงการสะท้อนความหมายของบริบททางธุรกิจบางอย่างอย่างถูกต้องคุณต้องระบุและจำแนกสิ่งต่าง ๆ ที่น่าสนใจในโดเมนเฉพาะของคุณเพื่อให้คุณสามารถจับภาพความหมายได้มากขึ้น .
ปัจจัยสำคัญในระยะการออกแบบ
มันค่อนข้างมีประโยชน์ที่จะต้องตระหนักถึงความจริงที่ว่าการวางคำศัพท์ทั้งหมดไว้ในคลัสเตอร์ supertype-subtype พิเศษนั้นเป็นความสัมพันธ์ปกติ ให้เราอธิบายสถานการณ์ด้วยวิธีต่อไปนี้:
- แต่ละพิเศษประเภท superentityเกิดขึ้นจะเกี่ยวข้องกับการเพียงหนึ่งsubentity ชนิดสมบูรณ์
ดังนั้นจึงมีการติดต่อ (หรือ cardinality) ของหนึ่งต่อหนึ่ง (1: 1) ในกรณีเหล่านี้
ดังที่คุณทราบจากการโพสต์ก่อนหน้าของคุณแอตทริบิวต์discriminator (คอลัมน์เมื่อนำมาใช้) มีบทบาทสำคัญเมื่อสร้างการเชื่อมโยงในลักษณะนี้เพราะมันบ่งบอกถึงอินสแตนซ์ย่อยที่ถูกต้องซึ่งมีการเชื่อมต่อชนิด การย้ายคีย์หลักจาก (i) supertype ไปยัง (ii) subtypes ก็มีความสำคัญเช่นกัน
โครงสร้างคอนกรีต DDL
และจากนั้นฉันเขียนโครงสร้าง DDL ที่ยึดตามโมเดลเชิงตรรกะที่แสดงด้านบน:
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)
);
ด้วยโครงสร้างนี้คุณหลีกเลี่ยงการจัดเก็บเครื่องหมาย NULL ในตารางฐานของคุณ (หรือความสัมพันธ์ ) ซึ่งจะแนะนำความคลุมเครือให้กับฐานข้อมูลของคุณ
การพิจารณาความซื่อสัตย์ความสอดคล้องและอื่น ๆ
เมื่อคุณใช้ฐานข้อมูลของคุณคุณต้องตรวจสอบให้แน่ใจว่า (a) แต่ละแถวsupertype พิเศษนั้นได้รับการเติมเต็มด้วยคู่ของsubtype ที่สอดคล้องกันและในทางกลับกันรับประกันได้ว่า (b) แถวย่อยดังกล่าวเข้ากันได้กับค่าที่อยู่ในคอลัมน์discriminator supertype . ดังนั้นจึงค่อนข้างสะดวกในการใช้ ACID TRANSACTIONSเพื่อให้แน่ใจว่าตรงตามเงื่อนไขเหล่านี้ในฐานข้อมูลของคุณ
คุณไม่ควรละทิ้งความแข็งแกร่งเชิงตรรกะการแสดงออกของตนเองและความถูกต้องของฐานข้อมูลของคุณสิ่งเหล่านี้เป็นแง่มุมที่ทำให้ฐานข้อมูลของคุณแข็งแกร่งขึ้น
คำตอบที่โพสต์ก่อนหน้านี้ทั้งสองมีประเด็นที่เกี่ยวข้องซึ่งควรคำนึงถึงเมื่อออกแบบสร้างและจัดการฐานข้อมูลของคุณและโปรแกรมแอปพลิเคชัน
การดึงข้อมูลตามนิยามของ VIEW
คุณสามารถตั้งค่ามุมมองบางอย่างที่รวมคอลัมน์ของ supertype-ชนิดย่อยที่แตกต่างกันในกลุ่มเพื่อให้คุณสามารถดึงข้อมูลที่อยู่ในมือโดยไม่ต้องเช่นการเขียนที่จำเป็น JOIN คำสั่งทุกครั้ง ด้วยวิธีนี้คุณสามารถเลือกโดยตรงจากมุมมอง ( ความสัมพันธ์ที่ได้รับหรือตาราง ) ที่น่าสนใจได้อย่างง่ายดาย
อย่างที่คุณเห็น“ เทด” Codd เป็นอัจฉริยะอย่างไม่ต้องสงสัย เครื่องมือที่เขาพินัยกรรมค่อนข้างแข็งแกร่งและสง่างามและแน่นอนว่ามีการบูรณาการซึ่งกันและกัน
แหล่งข้อมูลที่เกี่ยวข้อง
หากคุณต้องการวิเคราะห์ฐานข้อมูลที่กว้างขวางซึ่งเกี่ยวข้องกับความสัมพันธ์แบบ supertype-subtype คุณจะพบคุณค่าของคำตอบพิเศษที่เสนอโดย@PerformanceDBAกับคำถาม Stack Overflow ต่อไปนี้:
บันทึก
1. Integration Definition สำหรับการสร้างแบบจำลองข้อมูล ( IDEF1X ) เป็นเทคนิคการสร้างแบบจำลองข้อมูลที่ขอแนะนำอย่างสูงซึ่งก่อตั้งขึ้นเป็นมาตรฐานในเดือนธันวาคม 1993 โดยสถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา ( NIST ) มันมีพื้นฐานมาจาก(a)เนื้อหาทางทฤษฎียุคแรกที่เขียนโดย Dr. EF Codd; ใน(ข) Entity-Relationshipมุมมองของข้อมูลที่พัฒนาโดยดร. พีพีเฉิน ; และ(c)เทคนิคการออกแบบฐานข้อมูลแบบลอจิคัลสร้างโดย Robert G. Brown เป็นที่น่าสังเกตว่า IDEF1X ได้รับการทำเป็นทางการโดยใช้ตรรกะลำดับที่หนึ่ง