ส่วนหนึ่งของสถานการณ์ที่คุณกำลังสับสนกับสามารถจำลองที่มีโครงสร้างที่เรียกว่าคลาสสิกsupertype-ย่อย1โครงสร้าง
ฉันจะ (1) แนะนำความคิดเบื้องต้นที่เกี่ยวข้อง (2) รายละเอียดวิธีที่ฉันจะวิเคราะห์ - ในระดับแนวคิด - บริบททางธุรกิจภายใต้การพิจารณาและ (3) ให้เนื้อหาที่เกี่ยวข้องเพิ่มเติม - แทนการแสดงระดับตรรกะที่สอดคล้องกันผ่าน SQL ประกาศ DDDL ดังต่อไปนี้
บทนำ
โครงสร้างของลักษณะนี้เกิดขึ้นเมื่อในสภาพแวดล้อมทางธุรกิจที่กำหนดมีกลุ่มของประเภทนิติบุคคลที่supertypeมีคุณสมบัติหนึ่งหรือมากกว่าหนึ่ง (หรือคุณลักษณะ) ที่ใช้ร่วมกันโดยส่วนที่เหลือของประเภทกิจการในกลุ่มคือ ที่เชื้อ ทุกประเภทย่อยจะมีชุดของคุณสมบัติเฉพาะที่สามารถใช้ได้กับตัวเองเท่านั้น
คลัสเตอร์ Supertype-subtype มีสองชนิด:
พิเศษสุดๆ มาถึงเมื่ออินสแตนซ์ของชนิดของสิ่งเหนือธรรมชาติจะต้องมีชนิดย่อยหนึ่งและหนึ่งเท่านั้น จึงเกิดขึ้นชนิดย่อยที่มีศักยภาพในคำถามเป็นพิเศษร่วมกัน นี่คือสิ่งที่เกี่ยวข้องกับสถานการณ์ของคุณ
กรณีทั่วไปที่มี supertype-subtype เกิดขึ้นเป็นโดเมนธุรกิจที่ทั้งองค์กรและบุคคลถูกพิจารณาเป็นฝ่ายกฎหมายเช่นในสถานการณ์ที่พิจารณาในการโพสต์ชุดนี้
ไม่ จำกัดเฉพาะ นำเสนอตัวเองเมื่อ supertype เช่นอาจจะครบครันด้วยชนิดย่อยหลายเหตุการณ์ที่เกิดขึ้นซึ่งแต่ละถูกบังคับให้เป็นที่ที่แตกต่างกันหมวดหมู่
ตัวอย่างของชนิดของ supertype-ชนิดย่อยนี้จะเกี่ยวข้องกับการโพสต์เหล่านี้
หมายเหตุ : มันเป็นมูลค่าการกล่าวขวัญว่าโครงสร้าง supertype-subtype ซึ่งเป็นองค์ประกอบของอักขระเชิงแนวคิด - ไม่ได้อยู่ในกรอบทฤษฎีการจัดการข้อมูลที่เฉพาะเจาะจงไม่ว่าจะเป็นเชิงสัมพันธ์เครือข่ายหรือลำดับชั้น - ซึ่งแต่ละโครงสร้างมีโครงสร้างเฉพาะ
มันเป็นโอกาสที่ดีที่จะชี้ให้เห็นว่าแม้ว่ากลุ่ม supertype-subtype จะมีความคล้ายคลึงกับการสืบทอดของ object-oriented application programming (OOP) และการพหุสัณฐานพวกมันเป็นอุปกรณ์ที่แตกต่างกันเพราะพวกมันมีจุดประสงค์ที่แตกต่างกัน ในฐานข้อมูลแนวคิดรูปแบบใช่หรือไม่เพราะต้องแสดงถึงโลกแห่งความจริง aspects- หนึ่งที่เกี่ยวข้องกับโครงสร้างคุณสมบัติในการสั่งซื้อเพื่ออธิบายข้อมูลความต้องการในขณะที่ในหลายรูปแบบ OOP และมรดกในหมู่สิ่งอื่น ๆ หนึ่ง (ก) สเก็ตช์และ (ข) การดำเนินการคำนวณและพฤติกรรมลักษณะ ด้านที่เป็นของการออกแบบโปรแกรมและการเขียนโปรแกรม
นอกเหนือจากนั้นคลาส OOP ส่วนบุคคลซึ่งเป็นส่วนประกอบของแอปพลิเคชันโปรแกรมไม่จำเป็นต้อง“ สะท้อน” โครงสร้างของเอนทิตีแต่ละประเภทที่อยู่ในระดับแนวคิดของฐานข้อมูลในมือ ในส่วนนี้ผู้สร้างแอปพลิเคชันอาจสร้างเช่นคลาสเดียวที่“ รวม” คุณสมบัติทั้งหมดของเอนทิตีระดับสองแนวคิด (หรือมากกว่า) ประเภทเอนทิตีที่แตกต่างกันและคลาสดังกล่าวอาจรวมถึงคุณสมบัติที่คำนวณได้
การใช้โครงสร้างความสัมพันธ์เอนทิตี้เพื่อแสดงแบบจำลองแนวคิดด้วยโครงสร้าง supertype-subtype
คุณขอแผนภาพความสัมพันธ์เอนทิตี (ERD เพื่อความกะทัดรัด) แต่ถึงแม้ว่าจะเป็นแพลตฟอร์มการสร้างแบบจำลองที่ไม่ธรรมดา แต่วิธีดั้งเดิม - ซึ่งได้รับการแนะนำโดยดร. ปีเตอร์พิน - ชานเฉิน2 - ไม่ได้จัดหาโครงสร้างเพียงพอที่จะเป็นตัวแทนของสถานการณ์ พูดคุยกับความแม่นยำที่ต้องใช้แบบจำลองแนวคิดฐานข้อมูลที่เหมาะสม
ดังนั้นจึงจำเป็นต้องขยายวิธีการดังกล่าวสถานการณ์ที่ให้ผลลัพธ์ในการพัฒนาวิธีการที่ช่วยในการสร้างไดอะแกรมความสัมพันธ์เอนทิตี (EERDs) ที่เพิ่มขึ้นโดยธรรมชาติแล้วผสานเทคนิคการสร้างไดอะแกรมเบื้องต้นด้วยลักษณะที่แสดงออกใหม่ . หนึ่งในคุณลักษณะเหล่านั้นคือความเป็นไปได้ในการอธิบายโครงสร้าง supertype-subtype อย่างแม่นยำ
สร้างแบบจำลองบริบทที่คุณสนใจ
ภาพประกอบที่แสดงในรูปที่ 1เป็น EERD (ใช้สัญลักษณ์คล้ายกับที่เสนอโดย Ramez A. Elmasri และ Shamkant B. Navathe 3ที่อ้างถึงโครงสร้างเช่นsuperclass / subclass ) ซึ่งฉันจำลองโดเมนธุรกิจที่คุณอธิบายถึงการพิจารณาทั้งหมด รายละเอียด นอกจากนี้ยังสามารถใช้ได้เป็นPDF ที่สามารถดาวน์โหลดได้จาก Dropbox
ดังที่คุณเห็นในแผนภาพข้างต้นทั้งสองGroupและSoloPerformerจะแสดงเป็นชนิดย่อยพิเศษของArtistประเภท superentity:
คำอธิบายไดอะแกรม
ในการเริ่มต้นคำอธิบายของ EERD สิ่งสำคัญคือต้องชี้ให้เห็นว่าประโยคของคุณ
- “ศิลปินจะต้องมีทั้งกลุ่มหรือ SoloPerformer ( แต่ไม่ทั้งสอง)”
เกี่ยวข้องกับความไม่ต่อเนื่องและแง่มุมที่สมบูรณ์ของคลัสเตอร์ supertype-subtype
Disjointness
คุณลักษณะ disjointness เป็นสิ่งที่สำคัญอย่างยิ่งเพราะมันเป็นสิทธิที่นี่ที่“หรือบางส่วน” ที่คุณกล่าวถึงมาลงเล่นเนื่องจากความจริงที่ว่าArtistจะต้องมีอย่างใดอย่างหนึ่งเช่นชนิดย่อยหนึ่งหรืออื่น ๆ ซึ่งผมระบุไว้ใน EERD ผ่านขนาดเล็ก วงกลมที่มีตัวอักษร“D”, สร้างที่ได้รับชื่อของที่กฎเคลื่อน
เมื่อ supertype อาจจะเสริมด้วยหนึ่งหรือมากกว่าของเชื้อที่เป็นไปได้จุดนี้จะต้องแสดงออกโดยวงกลมขนาดเล็กที่ถือป้ายด้วยตัวอักษร“o” สัญลักษณ์ที่เรียกว่าทับซ้อนกฎ
คุณสมบัติ Discriminator
นอกจากนี้ยังอยู่ในขอบเขตของdisjointnessปัจจัยของสมาคม supertype-ชนิดย่อยนี้จะมีมูลค่าการให้ความสนใจใกล้เคียงกับArtist.Typeสถานที่ให้บริการเนื่องจากการดำเนินงานที่มีความเกี่ยวข้องมากในการจัดเรียงนี้มันทำหน้าที่เป็นชนิดย่อยdiscriminator มันถูกตั้งชื่อในลักษณะนี้เนื่องจากเป็นคุณสมบัติที่ชี้ให้เห็นชนิดย่อยแบบเอกสิทธิ์เฉพาะบุคคลที่Artistเกี่ยวข้องกับตัวอย่างเฉพาะ
ในกรณีของnonexclusive clusters การใช้คุณสมบัติ discriminator นั้นไม่จำเป็นสำหรับ supertype บางชนิดสามารถมี subtypes หลายชนิดเป็นส่วนเติมเต็ม
กฎความเชี่ยวชาญโดยรวมและความสมบูรณ์
ข้อกำหนดที่กำหนดว่าทุกคนArtistจะต้องมีอินสแตนซ์ย่อยเสริมที่เกี่ยวข้องกับคุณสมบัติความสมบูรณ์ของคลัสเตอร์นี้ สิ่งนี้ถูกตีความโดยใช้กฎความเชี่ยวชาญทั้งหมดซึ่งแสดงผ่านสัญลักษณ์เส้นคู่ที่เชื่อมต่อ (a) Artistsupertype ที่มี (b) โครงสร้างกฎที่แยกจากกัน
กลุ่มที่เกี่ยวข้องกับนักแสดงเดี่ยว
การประเมินประโยค
- “ กลุ่มประกอบไปด้วยSoloPerformersหนึ่งคนขึ้นไป”
และ
- “ SoloPerformerอาจเป็นสมาชิกของหลายกลุ่มหรือไม่มีกลุ่ม ”
หนึ่งสามารถรับรู้ว่าทั้งสองชนิดย่อยมีส่วนร่วมในหลายต่อหลายคน (M: N) สมาคม (หรือความสัมพันธ์) Group-SoloPerformerซึ่งเป็นตัวแทนของผมกับเพชรรูปกล่องระบุว่าเป็น
หากนำไปใช้ในฐานข้อมูลเชิงสัมพันธ์เป็นตารางฐานส่วนประกอบนี้จะเป็นประโยชน์อย่างมากในการรับมา (เช่นเพื่อทำการคำนวณ) ยอดรวมNumberของการSoloPerformersทำขึ้นคอนกรีตGroup(หนึ่งในข้อกำหนดที่คุณระบุ)
ความสัมพันธ์ระหว่างนักแสดงเดี่ยวและเครื่องมือ
ข้อกำหนด
- “ SoloPerformer […] อาจเล่นเครื่องดนตรีหนึ่งรายการหรือมากกว่า”
อนุญาตให้เราอนุมานได้ว่าในเวลาเดียวกัน
- “ เครื่องมือเล่นโดยมีศูนย์หนึ่งหรือมากกว่าหนึ่ง SoloPerformers”
ดังนั้นนี่เป็นอีกตัวอย่างหนึ่งของการเชื่อมโยง M: N และฉันใช้รูปทรงเพชรที่กำหนดSoloPerformer-Instrumentให้เปิดเผย
วัสดุเพิ่มเติม
เพื่ออธิบายขอบเขตของโครงสร้าง supertype-subtype ฉันจะรวมทรัพยากรอีกสองอย่างคือ
ไดอะแกรมIDEF1X 4นำเสนอในรูปที่ 2 ( และคุณสามารถดาวน์โหลดได้จาก Dropbox ในรูปแบบ PDFเช่นกัน) ที่แสดงความสามารถในการแสดงออกของไดอะแกรมประเภทนี้เกี่ยวกับโดเมนธุรกิจที่มีปัญหา และ
โครงสร้างโลจิคัล DDL ของที่เก็บข้อมูลที่เกี่ยวข้องที่เป็นตัวอย่างของวิธีการจัดการสถานการณ์จำลองเต็มรูปแบบภายใต้การอภิปรายโดยอาศัยระบบการจัดการฐานข้อมูล SQL
1. การเป็นตัวแทน IDEF1X
เทคนิคการสร้างแบบจำลองข้อมูลสารสนเทศ IDEF1X มีความสามารถในการวาดภาพโครงสร้าง supertype-subtype อย่างแน่นอนแม้ว่าจะมีข้อ จำกัด : มันไม่ได้ให้ยืมกลไกการแสดงภาพเพื่อระบุว่าคลัสเตอร์ที่แม่นยำนั้นเป็นแบบเอกสิทธิ์เฉพาะบุคคลหรือไม่รวมอยู่ด้วยสมบูรณ์หรือไม่สมบูรณ์ประจำตัวประชาชนของทุกประเภทที่ subentity เป็นไปได้อย่างมีนัยสำคัญ) โชคดีที่เราสามารถใช้สัญลักษณ์ข้อมูลวิศวกรรม (IE) เพื่อแสดงมุมมองที่สำคัญยิ่งนี้ได้อย่างแม่นยำยิ่งขึ้นในขณะที่ใช้ประโยชน์จากพลังเชิงพรรณนาของมาตรฐาน IDEF1X
ในเทคนิคนี้คุณสมบัติหลักของคำถามของคุณคือ“ ความสัมพันธ์การจัดหมวดหมู่” ซึ่งประเภทของซูเปอร์เรียกว่า“ เอนทิตี้ทั่วไป” และประเภทย่อยได้รับชื่อของ“ เอนทิตีหมวดหมู่” อย่างไรก็ตามฉันจะใช้คำว่าsupertype-subtype ต่อไปในโพสต์นี้เพราะ (1) มันถูกใช้โดย Dr. Edgar Frank Codd ผู้เริ่มต้นของโมเดลเชิงสัมพันธ์ (2) มันเป็นที่รู้จักอย่างกว้างขวางมากขึ้นและ (3) สัญกรณ์ IE คือ ใช้แทน "ดั้งเดิม" อย่างใดอย่างหนึ่ง
ปุ่มต่างประเทศและคลัสเตอร์ supertype-subtype
ดังที่แสดงให้เห็นว่า IDEF1X ให้ประโยชน์เพิ่มเติม: หมายถึงการแสดงคำจำกัดความ FOREIGN KEY (FK) องค์ประกอบที่มีความสำคัญยิ่งหากผู้ประกอบการกำลังจะเป็นตัวแทนของสมาคม supertype-subtype ในฐานข้อมูลเชิงสัมพันธ์
ในการสั่งซื้อเพื่อให้เห็นภาพเช่นการจัดเรียงของสมาคมคีย์หลัก (PK) คุณสมบัติของ supertype คือArtist.ArtistNumberมีการโยกย้ายไปGroupและSoloPerformerแม้ว่ามันจะได้รับมอบหมายแตกต่างกันสองชื่อบทบาท5, 6 , GroupNumberและSoloPerformerNumberตามลำดับสำหรับวัตถุประสงค์ของการเน้นหมายลำเลียงโดยสถานที่ให้บริการในบริบทของแต่ละประเภท subentity
นอกเหนือจากการถูกกำหนดให้เป็น PKs แล้วGroup.GroupNumberและSoloPerformer.SoloPerformerNumberคุณสมบัติต่าง ๆ ในขณะเดียวกันก็อธิบายว่าเป็น FOREIGN KEYs (FKs) ที่อ้างอิงถึงArtist.ArtistNumberคุณสมบัติของ PK แบบ supertype
ดังนั้นเนื่องจากทุกครั้งSoloPerformerและGroupเหตุการณ์ที่เกิดขึ้นขึ้นอยู่กับArtistอินสแตนซ์ที่แน่นอนประเภทกิจการเหล่านี้มีส่วนเกี่ยวข้องในการระบุความสัมพันธ์ที่มีผลต่อกระบวนการโยกย้ายทรัพย์สิน PK ที่อธิบายไว้ในวรรคก่อนหน้า
คีย์ต่างประเทศและประเภทเอนทิตีเชื่อมโยง
ไดอะแกรม IDEF1X ทำหน้าที่เป็นอย่างดีเพื่อแสดงให้เห็นถึง FKs ที่ประกอบด้วย PKs ของความสัมพันธ์เอนทิตีทั้งสองประเภทที่เกี่ยวข้องเช่น, GroupMemberและSoloPerformerInstrument; คนแรกเชื่อมต่อทั้งสองประเภทย่อยและคนที่สองเชื่อมโยงประเภทย่อยที่มีประเภทนิติบุคคลอิสระคือInstrument.
2. การประกาศโลจิคัล SQL-DDL ของ Expository
ดังที่อธิบายไว้ก่อนหน้านี้โครงสร้าง supertype-subtype เป็นวิธีการในการแสดงแนวคิดเชิงธุรกิจเฉพาะโดเมนบางประเภทเกี่ยวกับข้อกำหนดด้านข้อมูลซึ่งสามารถแสดงในฐานข้อมูลด้วยวิธีการสร้างที่แตกต่างกันซึ่งต้องสอดคล้องกับสิ่งที่เสนอโดยเฉพาะ กระบวนทัศน์ทางทฤษฎี (ไม่ว่าจะเป็นเชิงสัมพันธ์เครือข่ายหรือลำดับชั้น) ตามด้วยระบบการจัดการฐานข้อมูลที่ถูกใช้โดยนักออกแบบ
หนึ่งในข้อดีหลายประการของกระบวนทัศน์เชิงสัมพันธ์คือมันอนุญาตให้แสดงข้อมูลในโครงสร้างธรรมชาติของมันและการประมาณที่นิยมที่สุดสำหรับระบบที่เสนอในทฤษฎีเชิงสัมพันธ์คือระบบการจัดการฐานข้อมูล SQL ที่หลากหลาย
ดังนั้นในที่สุดนี่คือตัวอย่างของข้อความ DDL ซึ่งรวมถึง (a) schema ตารางพื้นฐานพร้อมกับ (b) ข้อ จำกัดบางประการที่เกี่ยวข้อง - ซึ่งเป็นตัวแทนในระดับตรรกะของ abstraction แบบฝึกหัดแบบจำลองแนวความคิดที่ได้รับการปฏิบัติด้านบน:
--
--
CREATE TABLE Artist ( -- Stands for the supertype.
ArtistNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
Type CHAR(1) NOT NULL, -- Holds the discriminator values.
CreatedDateTime DATETIME NOT NULL,
--
CONSTRAINT Artist_PK PRIMARY KEY (ArtistNumber),
CONSTRAINT Artist_AK UNIQUE (Name), -- ALTERNATE KEY.
CONSTRAINT Artist_Type_CK CHECK (Type IN ('G', 'S')) -- Enforces retaining either ‘G’, for ‘Group’, or ‘S’, for ‘SoloPerformer’, only.
);
CREATE TABLE MyGroup ( -- Represents one subtype.
GroupNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
FormationDate DATE NOT NULL,
--
CONSTRAINT MyGroup_PK PRIMARY KEY (GroupNumber),
CONSTRAINT MyGroupToArtist_FK FOREIGN KEY (GroupNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE SoloPerformer ( -- Denotes the other subtype.
SoloPerformerNumber INT NOT NULL, -- To be constrained as PK and FK simultaneously.
BirthDate DATE NOT NULL,
--
CONSTRAINT SoloPerformer_PK PRIMARY KEY (SoloPerformerNumber),
CONSTRAINT SoloPerformerNumberToArtist_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES Artist (ArtistNumber)
);
CREATE TABLE GroupMember ( -- Stands for a M:N association involving the two subtypes.
MemberNumber INT NOT NULL,
GroupNumber INT NOT NULL,
JoinedDate DATE NOT NULL,
--
CONSTRAINT GroupMember_PK PRIMARY KEY (MemberNumber, GroupNumber), -- Composite PK.
CONSTRAINT GroupMemberToSoloPerformer_FK FOREIGN KEY (MemberNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT GroupMemberToMyGroup_FK FOREIGN KEY (GroupNumber)
REFERENCES MyGroup (GroupNumber)
);
CREATE TABLE Instrument ( -- Represents an independent entity type.
InstrumentNumber INT NOT NULL,
Name CHAR(30) NOT NULL,
--
CONSTRAINT Instrument_PK PRIMARY KEY (InstrumentNumber),
CONSTRAINT Instrument_AK UNIQUE (Name) -- ALTERNATE KEY.
);
CREATE TABLE SoloPerformerInstrument ( -- Denotes another M:N association, in this case between a subtype and an independent entity type.
SoloPerformerNumber INT NOT NULL,
InstrumentNumber INT NOT NULL,
CreatedDate DATE NOT NULL,
--
CONSTRAINT SoloPerformerInstrument_PK PRIMARY KEY (SoloPerformerNumber, InstrumentNumber), -- Composite PK.
CONSTRAINT SoloPerformerInstrumentToSoloPerformer_FK FOREIGN KEY (SoloPerformerNumber)
REFERENCES SoloPerformer (SoloPerformerNumber),
CONSTRAINT SoloPerformerInstrumentToInstrument_FK FOREIGN KEY (InstrumentNumber)
REFERENCES Instrument (InstrumentNumber)
);
--
--
การพิจารณาความสมบูรณ์ของข้อมูลและความสอดคล้อง
ในข้อตกลงกับทุกสิ่งที่ได้รับการอธิบายก่อนหน้านี้นักออกแบบจะต้องรับประกันว่าแต่ละ “supertype” แถวตลอดเวลาครบครันด้วยประกอบของ“ย่อย” คู่และในทางกลับให้แน่ใจว่าที่กล่าวว่า“ย่อย” แถวเข้ากันได้กับค่า ที่อยู่ในคอลัมน์“ discriminator” ของ supertype
มันจะเป็นมากในทางปฏิบัติและสง่างามในการบังคับใช้สถานการณ์กล่าวว่าdeclaratively (เป็นกรอบสัมพันธ์เสนอ) แต่อนิจจาไม่มีแพลตฟอร์ม SQL ที่สำคัญได้จัดให้มีกลไกที่เหมาะสมในการทำเช่นนั้น (เท่าที่ผมรู้) ดังนั้นจึงสะดวกในการใช้ACID ธุรกรรมเพื่อให้เงื่อนไขเหล่านี้มักจะพบในฐานข้อมูล (ตัวเลือกอื่นจะใช้ประโยชน์จาก TRIGGERS แต่พวกเขามักจะทำให้สิ่งสกปรก)
ข้อควรพิจารณาเกี่ยวกับการรับข้อมูล
หนึ่งในประเด็นหลักของตัวแบบเชิงสัมพันธ์คือมันพิจารณาการได้มาของข้อมูลเป็นปัจจัยสำคัญในการจัดการข้อมูล ตามก็อำนวยความสะดวกในการสร้าง (ก) ฐานความสัมพันธ์ -or ฐานตารางใน SQL ดังแสดงใน DDL งบข้างต้นและ (ข) ได้รับความสัมพันธ์ - มาตารางใน SQL คือผู้ที่ประกาศโดยอาศัยการดำเนินงานเลือกที่อาจจะ แก้ไขเป็นมุมมองสำหรับการใช้ประโยชน์เพิ่มเติม -
ดังนั้นหนึ่งสามารถประกาศมุมมองที่รวบรวมจุดข้อมูลกลุ่ม "เต็ม" :
CREATE VIEW FullGroup AS
SELECT G.GroupNumber,
A.Name,
A.CreatedDateTime,
G.FormationDate
FROM Artist A
JOIN MyGroup G
ON G.GroupNumber = A.ArtistNumber;
และมุมมองอื่น ๆ ที่รวมข้อมูล "เต็มรูปแบบ" ของSoloPerformer :
CREATE VIEW FullSoloPerformer AS
SELECT SP.SoloPerformerNumber,
A.Name,
A.CreatedDateTime,
SP.BirthDate
FROM Artist A
JOIN SoloPerformer SP
ON SP.SoloPerformerNumber = A.ArtistNumber;
ในลักษณะนี้มันเป็นเรื่องง่ายมากที่จะจัดการ - ประกาศ - ข้อมูลสำคัญทั้งหมดผ่านอุปกรณ์ระดับตรรกะเดียวกันมากเช่นความสัมพันธ์หรือตาราง (ไม่ว่าจะเป็นฐานหรือมา) เห็นได้ชัดว่าการใช้มุมมองมีประสิทธิภาพมากขึ้นเมื่อประเภทเอนทิตีเชิงแนวคิดที่แสดงในฐานข้อมูลเชิงสัมพันธ์มีคุณสมบัติที่น่าสนใจมากขึ้น แต่มันก็มีความเป็นไปได้ที่จะแสดงให้เห็นถึงสถานการณ์ปัจจุบัน
อ้างอิง
1 Codd, EF (ธ.ค. 1979) ขยายฐานข้อมูลเชิงสัมพันธ์รุ่นเพื่อจับความหมายอื่น ๆ , การทำธุรกรรม ACM เกี่ยวกับระบบฐานข้อมูล , เล่มที่ 4 ฉบับที่ 4 (PP. 397-434) นิวยอร์กนิวยอร์กสหรัฐอเมริกา
2 เฉิน, PP (มีนาคม 1976) The Entity-Relationship Model-ต่อมุมมองแบบรวมของข้อมูล , การทำธุรกรรม ACM บนระบบฐานข้อมูล - ปัญหาพิเศษ: เอกสารจากการประชุมนานาชาติเกี่ยวกับฐานข้อมูลขนาดใหญ่มาก: 22-24 กันยายน 1975, รามิงแฮม, แมสซาชูเซตเล่ม 1 ฉบับที่ 1 (PP . 9-36) นิวยอร์กนิวยอร์กสหรัฐอเมริกา
3 Elmasri, R & Navathe, SB (2003) พื้นฐานของระบบฐานข้อมูลรุ่นที่สี่ บริษัท แอดดิสัน - เวสลีย์ลองแมนพับลิชชิ่ง จำกัด , บอสตัน, แมสซาชูเซตส์, สหรัฐอเมริกา
4สถาบันมาตรฐานและเทคโนโลยีแห่งชาติ (สหรัฐอเมริกา) [NIST] (ธ.ค. 1993) นิยามการรวมสำหรับการสร้างแบบจำลองข้อมูล (IDEF1X), การเผยแพร่มาตรฐานการประมวลผลข้อมูลของรัฐบาลกลาง , เล่มที่ 184
5 Codd, EF (มิถุนายน 1970) รูปแบบข้อมูลเชิงสัมพันธ์สำหรับธนาคารข้อมูลขนาดใหญ่ที่ใช้ร่วมกัน , การสื่อสารของ ACM , เล่มที่ 13 ฉบับที่ 6 (หน้า 377-387) นิวยอร์กนิวยอร์กสหรัฐอเมริกา
6ดูข้อมูลอ้างอิง4
