การออกแบบฐานข้อมูลสำหรับโดเมนธุรกิจวิดีโอเกมที่มีความสัมพันธ์แบบหลายต่อหลายคน

16

ฉันค่อนข้างใหม่ในการออกแบบฐานข้อมูลและฉันตัดสินใจที่จะสร้างฐานข้อมูลสมมุติของตัวเองเพื่อฝึกหัด อย่างไรก็ตามฉันมีปัญหาในการสร้างแบบจำลองและทำให้เป็นมาตรฐานในขณะที่ฉันเห็นว่ามีความสัมพันธ์แบบหลายต่อหลายคน (M: N)

คำอธิบายภาพจำลองทั่วไป

ฐานข้อมูลมีวัตถุประสงค์เพื่อเก็บข้อมูลเกี่ยวกับผู้คนที่ทำงานในซีรี่ส์ Zelda ฉันต้องการติดตามคอนโซลที่สามารถเล่นเกมได้พนักงานที่มีส่วนร่วมในการพัฒนาเกมงานที่พนักงานมี ( พนักงานหลายคนทำงานในงานที่แตกต่างกันในหลายเกม ) ฯลฯ

กฎเกณฑ์ทางธุรกิจ

  • หลายพนักงานสามารถทำงานได้ในหลายเกม
  • หลายเกมสามารถอยู่บนเดียวกันคอนโซล
  • Multiple Consolesสามารถเป็นแพลตฟอร์มสำหรับเกมเดียวกันได้
  • หลายพนักงานสามารถมีเหมือนกันงาน
  • พนักงานสามารถมีหลายงาน
  • เกมสามารถมีหลายพนักงาน
  • เกมสามารถมีหลายประเภทของงานในการพัฒนาของมัน
  • เกมหลายเกมสามารถแนบJobประเภทเดียวกันได้
  • คอนโซลสามารถมีหลายคนที่ทำงานกับมัน
  • คนสามารถทำงานได้ในหลายConsoles

ชื่อแอตทริบิวต์และค่าตัวอย่าง

  • ชื่อพนักงานซึ่งสามารถแบ่งออกเป็นชื่อแรกและนามสกุล (เช่น“ John” และ“ Doe”)
  • ชื่อเกม (ตัวอย่างเช่น "Ocarina of Time")
  • ตำแหน่งงาน (ตัวอย่างเช่น "การออกแบบระดับ", "ผู้อำนวยการ", "ความสงบ", "ผู้ออกแบบระดับ", "โปรแกรมเมอร์", "การรองรับหลายภาษา" ฯลฯ )
  • ชื่อคอนโซล (ตัวอย่างเช่น“ Game Boy Advance”)

ปัญหา

จนถึงตอนนี้ดูเหมือนว่าไม่ว่าสิ่งที่ฉันออกแบบมีความซ้ำซ้อนของข้อมูลและความสัมพันธ์ M: N ระหว่างประเภทกิจการที่น่าสนใจทุกที่ อย่างไรก็ตามฉันรู้สึกว่าผู้ออกแบบฐานข้อมูลต้องประสบกับปัญหาประเภทนี้ตลอดเวลาดังนั้นจึงต้องมีวิธีแก้ไข

หมายเหตุ : ฉันสามารถค้นหาข้อมูลเพื่อเติมตารางได้ดีปัญหาคือการจัดระเบียบให้เป็นฐานข้อมูลที่มีตารางในรูปแบบปกติ

database-design  normalization  denormalization  many-to-many 
— dpolaristar
แหล่งที่มา
1
ความคิดเห็นย้ายไปที่ห้องสนทนาตามที่ร้องขอ
— Paul White Reinstate Monica

คำตอบ:

18

ใช่การระบุความสัมพันธ์หรือความสัมพันธ์แบบหลายต่อหลายคน (M: N เพื่อความกระชับ) เป็นสถานการณ์ที่ผู้ปฏิบัติงานฐานข้อมูลเผชิญค่อนข้างบ่อยเมื่อวางโครงร่างแนวคิด ความสัมพันธ์ของอัตราส่วนของความสำคัญต่อภาวะหัวใจและหลอดเลือดนั้นเกิดขึ้นในสภาพแวดล้อมทางธุรกิจที่แตกต่างกันมากและเมื่อแสดงอย่างเหมาะสมในระดับตรรกะด้วยวิธีการเช่นการจัดเรียงของ SQL-DDL พวกเขาจะไม่นำเสนอความซ้ำซ้อนที่เป็นอันตราย

ด้วยวิธีนี้วัตถุประสงค์ของการออกกำลังกายการสร้างแบบจำลองฐานข้อมูลควรจะสะท้อนลักษณะที่เกี่ยวข้องของบริบททางธุรกิจที่น่าสนใจที่มีความแม่นยำสูง ; ดังนั้นหากคุณระบุได้อย่างถูกต้องว่ามีการเชื่อมโยง M: N จำนวนมากคุณจะต้องแสดงพวกเขาใน (ก) สคีแนวคิดและใน (b) การประกาศระดับตรรกะที่เกี่ยวข้องไม่ว่าจะมีการเชื่อมต่อจำนวนเท่าใดก็ตาม อื่น ๆ - ต้องระบุอัตราส่วนของความสำคัญเชิงหัวใจ

กฎเกณฑ์ทางธุรกิจ

คุณได้ให้คำถามที่มีบริบทที่ดีและได้ชี้แจงว่าฐานข้อมูลที่คุณกำลังทำงานอยู่นั้นเป็นสมมุติฐานที่บริสุทธิ์ซึ่งเป็นจุดสำคัญเนื่องจากฉันเห็นว่าสถานการณ์ทางธุรกิจ "โลกแห่งความจริง" เช่นเดียวกับที่อยู่ในการพิจารณาจะกว้างกว่านี้มาก และดังนั้นจะบ่งบอกถึงข้อกำหนดด้านข้อมูลที่ซับซ้อนมากขึ้น

ฉันตัดสินใจที่จะ (1) ทำการแก้ไขและขยายกฎเกณฑ์ทางธุรกิจที่คุณให้ไว้เพื่อ (2) สร้างกรอบแนวคิดเชิงพรรณนาที่มีความหมายมากขึ้น - แม้ค่อนข้างเพียงพอ - นี่คือสูตรบางอย่างที่ฉันรวบรวม:

  • พรรค1เป็นทั้งบุคคลหรือองค์กร
  • พรรคคือจำแนกตามตรงหนึ่งPartyType
  • PartyTypeจัดประเภทเป็นศูนย์หนึ่งหรือหลายภาคี
  • องค์การพัฒนาศูนย์หนึ่งหรือหลายผลิตภัณฑ์
  • สินค้าเป็นทั้งระบบหรือเกม
  • สินค้าแยกตามตรงหนึ่งProductType
  • ระบบเป็นหมวดหมู่โดยว่าหนึ่งSystemType
  • เกมสามารถเล่นผ่านทางหนึ่งต่อหลายระบบ
  • ระบบที่ใช้ในการเล่นแบบหนึ่งต่อหลายเกม
  • เกมจำแนกตามศูนย์หนึ่งหรือหลายประเภท
  • แนวจัดประเภทเป็นศูนย์หนึ่งหรือหลายเกม
  • สินค้าอินเตอร์เน็ตแบบหนึ่งต่อหลายงาน
  • งานเป็นจริงด้วยศูนย์หนึ่งหรือหลายคนที่กำลังเล่นบทบาทของผู้ร่วมมือ
  • บุคคลที่เป็นผู้ประสานงานในศูนย์หนึ่งหรือหลายงาน

1 พรรคเป็นคำที่ใช้ในบริบททางกฎหมายเมื่อพูดถึงบุคคลหรือกลุ่มบุคคลที่ประกอบกิจการที่เดียวดังนั้นนิกายนี้เหมาะที่จะเป็นตัวแทนของคนและองค์กร

ไดอะแกรม IDEF1X

ต่อจากนั้นฉันสร้างไดอะแกรมIDEF1X 2 ที่แสดงในรูปที่ 1 (ตรวจสอบให้แน่ใจว่าได้คลิกลิงก์เพื่อดูในความละเอียดที่สูงกว่า) โดยรวมไว้ในอุปกรณ์กราฟิกเดียวที่มีกฎเกณฑ์ทางธุรกิจที่นำเสนอข้างต้น

รูปที่ 1 - ไดอะแกรม Video Gae Jobs IDEF1X

2 นิยามการรวมสำหรับการสร้างแบบจำลองข้อมูล ( IDEF1X ) เป็นเทคนิคการสร้างแบบจำลองข้อมูลที่ได้รับการแนะนำสูงซึ่งก่อตั้งขึ้นเป็นมาตรฐานในเดือนธันวาคม 1993 โดยสถาบันมาตรฐานและเทคโนโลยีแห่งชาติของสหรัฐอเมริกา(NIST) มันขึ้นอยู่กับ (a) เนื้อหาทางทฤษฎีต้นที่เขียนโดยผู้สร้าง แต่เพียงผู้เดียวของรูปแบบเชิงสัมพันธ์คือดร. EF Codd; บน (b) มุมมองเอนทิตีของข้อมูลที่พัฒนาโดยDr. PP Chen ; และ (c) เทคนิคการออกแบบฐานข้อมูลแบบลอจิคัลสร้างโดย Robert G. Brown

อย่างที่คุณเห็นฉันได้อธิบายความสัมพันธ์ M: N เพียงสามรายการโดยวิธีการเชื่อมโยงเอนทิตีประเภทที่เกี่ยวข้องเช่น:

  • ผู้ประสานงาน
  • SystemGame
  • GameGenre

เหนือสิ่งอื่นใดมีโครงสร้างsupertype-subtype สองโครงสร้างที่:

  • บุคคลและองค์กรเป็นประเภทย่อยของนิติบุคคลพิเศษซึ่งกันและกันของภาคีนิติบุคคลประเภทของพวกเขา

  • สินค้าเป็น supertype ของSystem and Gameซึ่งเป็นประเภทย่อยที่ไม่เกิดร่วมกัน

ในกรณีที่คุณไม่คุ้นเคยกับการเชื่อมโยง supertype-subtype คุณอาจพบความช่วยเหลือเช่นคำตอบของคำถามที่มีชื่อ:

โครงร่าง SQL-DDL เชิงตรรกะ

อย่างต่อเนื่องเราต้องทำให้แน่ใจว่าในระดับตรรกะ:

  • แต่ละประเภทเอนทิตีแสดงโดยตารางฐานแต่ละรายการ
  • แต่ละคุณสมบัติเดียวของประเภทเอนทิตีที่ใช้งานได้จะถูกแสดงด้วยคอลัมน์ใดคอลัมน์หนึ่ง
  • ประเภทข้อมูลที่แน่นอนได้รับการแก้ไขสำหรับแต่ละคอลัมน์เพื่อให้แน่ใจว่าค่าทั้งหมดที่มีอยู่เป็นของชุดที่กำหนดไว้อย่างดีไม่ว่าจะเป็น INT, DATETIME, CHAR เป็นต้น (แน่นอนเมื่อใช้เช่นFirebirdหรือPostgreSQLคุณอาจต้องการจ้าง DOMAINs ที่ทรงพลังกว่า)
  • มีการกำหนดค่าข้อ จำกัดหลายข้อ (อย่างชัดเจน) เพื่อรับประกันว่าการยืนยันในรูปแบบของแถวที่เก็บไว้ในตารางทั้งหมดเป็นไปตามกฎทางธุรกิจที่กำหนดในระดับแนวคิด

ดังนั้นฉันจึงประกาศการจัดเรียง DDL ต่อไปนี้ตามแผนภาพ IDEF1X ที่แสดงก่อนหน้านี้:

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)
);

มันเป็นโอกาสที่ดีที่จะเน้นว่ามีการประกาศข้อ จำกัด คีย์หลักคอมโพสิตข้ามหลายตารางซึ่งหมายถึงลำดับชั้นของการเชื่อมต่อที่เกิดขึ้นระหว่างประเภทเอนทิตี้ของแนวคิดการจัดเรียงที่มีประโยชน์มากเมื่อเทียบกับการดึงข้อมูลเมื่อแสดงเช่น SELECT การดำเนินงานที่มีส่วนคำสั่ง JOIN เพื่อรับตารางที่ได้รับ

ใช่ (i) การเชื่อมโยง M: N ทุกครั้งและ (ii) ทุกประเภทเอนทิตีที่เกี่ยวข้องถูกแสดงด้วย (iii) ตารางที่สอดคล้องกันในโครงสร้าง DDL เชิงตรรกะดังนั้นจึงต้องใส่ใจเป็นพิเศษกับข้อ จำกัด หลักและกุญแจต่างประเทศ (และ บันทึกย่อที่ฉันทิ้งไว้เป็นความคิดเห็น) ของตารางที่แสดงองค์ประกอบที่เป็นแนวคิดเหล่านี้เพราะพวกเขาช่วยในการตรวจสอบให้แน่ใจว่าการเชื่อมต่อระหว่างแถวที่เกี่ยวข้องนั้นตรงตามอัตราส่วนอัตราการเต้นของหัวใจที่เกี่ยวข้อง

การใช้งานของปุ่มคอมโพสิตถูกนำโดยดร. EF Coddจากต้นกำเนิดมากจากกระบวนทัศน์เชิงสัมพันธ์ที่แสดงให้เห็นในตัวอย่างที่เขารวมในปี 1970 กระดาษน้ำเชื้อของเขาที่ชื่อสัมพันธ์รูปแบบขนาดใหญ่ที่ใช้ร่วมกันข้อมูลธนาคาร (ซึ่งอย่างแม่นยำนอกจากนี้ยังมีการจัด วิธีที่หรูหราที่สุดในการจัดการกับการเชื่อมโยง M: N)

ฉันวาง ซอร์ด db <>และซอซอเดอร์SQL Fiddle , ทั้งคู่ทำงานบน Microsoft SQL Server 2014, เพื่อให้สามารถทดสอบโครงสร้าง“ ทำงานได้”

normalization

การทำให้เป็นมาตรฐานเป็นกระบวนการระดับตรรกะที่มีความหมายโดยทั่วไปแล้วการพูด:

  1. การกำจัดคอลัมน์ที่ไม่ใช่อะตอมมิกผ่านรูปแบบปกติครั้งแรกเพื่อให้การจัดการข้อมูลและการหดตัวทำได้ง่ายกว่ามากในการจัดการกับข้อมูลย่อยของการใช้งานข้อมูล (เช่น SQL)

  2. การกำจัดที่ไม่พึงประสงค์อ้างอิงในหมู่คอลัมน์ของตารางที่เฉพาะเจาะจงโดยอาศัยรูปแบบปกติต่อเนื่องเพื่อหลีกเลี่ยงการปรับปรุงความผิดปกติ

โดยธรรมชาติแล้วเราต้องคำนึงถึงความหมายของตารางและคอลัมน์ที่มีปัญหาด้วย

ฉันชอบคิดว่าการทำให้เป็นมาตรฐานเป็นการทดสอบทางวิทยาศาสตร์ที่นักออกแบบนำไปใช้กับองค์ประกอบที่เกี่ยวข้องเมื่อเขาหรือเธอได้วิเคราะห์การจัดระดับตรรกะที่มีเสถียรภาพเพื่อพิจารณาว่ารายการนั้นสอดคล้องกับทุกรูปแบบปกติหรือไม่ จากนั้นหากจำเป็นผู้ออกแบบจะใช้มาตรการแก้ไขที่เหมาะสม

ความฟุ่มเฟือย

ในรูปแบบเชิงสัมพันธ์ในขณะที่การทำสำเนาของค่าที่มีอยู่ในคอลัมน์ไม่ได้เป็นเพียงที่ยอมรับได้ แต่คาดว่าแถวที่ซ้ำกันจะต้องห้าม เท่าที่ฉันสามารถเห็นได้มีการป้องกันแถวที่ซ้ำซ้อนและความซ้ำซ้อนที่เป็นอันตรายประเภทอื่น ๆ ในตารางทั้งหมดที่มีรูปแบบตรรกะที่เปิดเผยก่อนหน้านี้บางทีคุณอาจต้องการชี้แจงข้อกังวลของคุณในเรื่องนี้

อย่างไรก็ตามคุณสามารถ (ก) ประเมินโครงสร้างของคุณเองโดยการกรอกแบบฟอร์มปกติเพื่อกำหนดว่าเป็นไปตามข้อกำหนดและ (b) แก้ไขหากจำเป็น

แหล่งข้อมูลที่เกี่ยวข้อง

  • ในโพสต์ชุดนี้ฉันนำเสนอการพิจารณาบางอย่างเกี่ยวกับการเชื่อมโยง M: N ที่ตรงไปตรงมาซึ่งสามารถเชื่อมโยงอินสแตนซ์ของเอนทิตีที่แตกต่างกันสองประเภท
  • ในอีกข้อหนึ่งฉันเสนอวิธีการจัดการกับการเกิดขึ้นของ "บิลวัสดุ" หรือ "การระเบิดชิ้นส่วน" ซึ่งฉันอธิบายวิธีการเชื่อมต่ออินสแตนซ์ที่แตกต่างกันของเอนทิตีประเภทเดียวกัน

สมาคมที่ประกอบไปด้วย

มีสิ่งสำคัญอีกประการหนึ่งที่คุณนำเสนอผ่านความคิดเห็น (โพสต์ในคำตอบที่ถูกลบตอนนี้):

ทุกครั้งที่ฉันพยายามสร้างสะพานองค์ประกอบในสะพานนั้นก็มีหลายต่อหลายคนฉันอยู่ภายใต้ความรู้สึกที่ไม่ได้รับอนุญาตหรืออย่างน้อยก็ท้อ

สถานการณ์นั้นดูเหมือนจะบ่งบอกว่าหนึ่งในข้อกังวลของคุณเกี่ยวข้องกับความสัมพันธ์แบบไตรภาค โดยพื้นฐานแล้วสมาคมประเภทนี้เกิดขึ้นเมื่อมีอยู่ (1) ความสัมพันธ์ที่เกี่ยวข้อง (2) ความสัมพันธ์อื่น ๆ อีกสองคำกล่าวอีกนัยหนึ่ง“ ความสัมพันธ์ระหว่างความสัมพันธ์” - เป็นสถานการณ์ทั่วไปเช่นกันเนื่องจากความสัมพันธ์เป็นนิติบุคคลในสิทธิ์ของตนเอง -

ข้อตกลงเหล่านี้เมื่อมีการจัดการอย่างเหมาะสมอย่านำความซ้ำซ้อนที่เป็นอันตรายเช่นกัน และใช่หากมีกรณีการใช้งานบางอย่างที่คุณระบุว่าความสัมพันธ์ดังกล่าวปรากฏตัวในประเภทเอนทิตี "โลกแห่งความจริง" คุณจะต้อง (i) โมเดลและ (ii) ประกาศความถูกต้องในระดับตรรกะ

  • นี่คือคำถามและคำตอบที่เราวิเคราะห์โดเมนของวาทกรรมเกี่ยวกับการสำรวจซึ่งรวมถึงตัวอย่างของสมาคมประกอบไปด้วย
  • ในคำตอบที่ดีนี้@Ypercubeนำเสนอไดอะแกรมและโครงสร้าง DDL ตามลำดับสำหรับความสัมพันธ์รูปเพชรที่น่าสนใจซึ่งคล้ายกับสถานการณ์ในระดับนี้มาก
— MDCCL
แหล่งที่มา
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.