Розробка бази даних для бізнес-домену для відеоігор із безліччю взаємозв'язків багато-до-багатьох


16

Я відносно новий в розробці баз даних, і я вирішив зробити власну гіпотетичну базу даних для практики. Однак у мене виникають проблеми з її моделюванням та нормалізацією, оскільки я вважаю, що існує чимало відносин "багато до багатьох" (M: N).

Загальний опис сценарію

База даних призначена для зберігання даних про різних людей , які працювали над серією Zelda. Я хочу , щоб стежити за консолі (с) , що гра може бути відтворена на, співробітників , які мали участь в іграх розвитку, Робота співробітників були (багато співробітники працювали на різні робочих місцях на кількох ігор ) і т.д.

Правила бізнесу

  • Кілька працівників можуть працювати в декількох Іграх .
  • Кілька Ігор можуть бути на одній консолі .
  • Кілька консолей можуть бути платформою для однієї гри .
  • Кілька працівників можуть мати одну роботу .
  • Співробітник може мати кілька робочих місць .
  • У грі може бути декілька працівників .
  • У грі може бути кілька типів робочих місць у її розробці
  • У кількох іграх може бути доданий один і той же тип роботи .
  • На консолі може працювати декілька людей, які працюють над нею.
  • Людина може працювати на декількох консолях .

Імена атрибутів та вибіркові значення

  • Ім’я працівника , яке можна розділити на Перше та Останнє (наприклад, "Джон" та "Собака")
  • Назва гри (наприклад, «Окарина часу»)
  • Назва роботи (наприклад, "Дизайн рівня", "Директор", "Композиція", "Дизайнер рівнів", "Програміст", "Локалізація" тощо).
  • Ім’я консолі (наприклад, "Advance Game Game")

Питання

Поки що, мабуть, незалежно від того, що я розробляю, є надмірність даних та зв'язки M: N між типами інтересу суб'єкта господарювання скрізь. Однак я вважаю, що дизайнери баз даних повинні постійно стикатися з такою проблемою, тому рішення повинно бути.


Примітка : я добре вмію знайти дані для заповнення таблиці, проблема полягає в організації їх в базі даних з таблицями в нормалізованій формі.


1
Коментарі запитувались до кімнати чату за запитом.
Пола Вайт Відновити Моніку

Відповіді:


18

Так, ідентифікація асоціацій чи відносин між багатьма (M: N для стислості) - це ситуація, з якою практик бази даних стикається досить часто, коли розробляє концептуальну схему. Асоціації зазначених коефіцієнтів кардинальності виникають у бізнес-середовищах дуже різного характеру, і коли належним чином представлені на логічному рівні за допомогою, наприклад, устрою SQL-DDL, вони не вносять шкідливих надмірностей.

Таким чином, метою вправи з моделювання баз даних повинно бути відображення відповідних характеристик бізнес-контексту з високою точністю ; отже, якщо ви правильно визначите, що існує чимало асоціацій M: N, ви повинні висловити їх у (а) концептуальній схемі, а також у (b) відповідних деклараціях логічного рівня, незалежно від того, скільки з'єднань цього - чи будь-яких інше - мають бути вирішені види коефіцієнтів кардинальності.

Правила бізнесу

Ви поставили чітко контекстуалізоване запитання, а також уточнили, що база даних, над якою ви працюєте, суто гіпотетична, що є важливим моментом, оскільки я вважаю, що бізнес-сценарій у реальному світі, як розглянутий, був би набагато більш масштабним. і, отже, означало б більш складні інформаційні вимоги.

Я вирішив (1) внести декілька модифікацій та розширень до бізнес-правил, які ви надали, щоб (2) створити більш описову концептуальну схему - хоч і все ще досить гіпотетичну. Ось деякі рецептури, які я зібрав разом:

  • Сторона 1 є або особа або організація
  • Партія класифікується точно-один PartyType
  • PartyType класифікує нуль-один-або-багато Сторони
  • Організація розробляє нульові один або багато- продукти
  • Продукт являє собою або системи або гри
  • Продукт класифікується точно-один ProductType
  • Система каталогізована рівно-однієї SystemType
  • Гра може бути відтворена через один-ко-многим системам
  • Система використовується для відтворення один-ко-многим Ігор
  • Гра класифікується нульовим однієї або багатьом жанрам
  • Жанр класифікує нуль-один-або-багато ігор
  • A Продукт бере своє початок один-ко-многим Джобсом
  • Робота виконується на нуль-один-або-багатьох людей , , які грають в ролі в Коллабораторов
  • Особа є Collaborator в нуль один або-багато робочих місць

1 Сторона - термін, що використовується в юридичних контекстах, коли йдеться про фізичну особу або групу осіб, які складають єдину сутність, тому ця конфесія підходить для представлення людей та організацій .


Діаграма IDEF1X

Згодом я створив діаграму IDEF1X 2, показану на рисунку 1 (обов'язково натисніть на посилання, щоб побачити її у більшій роздільній здатності), консолідувавши в одному графічному пристрої ділові правила, представлені вище (разом із деякими іншими, які здаються актуальними):

Малюнок 1 - Діаграма IDEF1X для робочих місць відеозапису


2 Визначення інтеграції для інформаційного моделювання ( IDEF1X ) - це дуже рекомендована методика моделювання даних, яка була встановлена ​​як стандарт у грудні 1993 р. Національним інститутом стандартів і технологій США (NIST). Він ґрунтується на (а) ранньому теоретичному матеріалі, створеному єдиним автором реляційної моделі, тобто доктором Е.Ф. Коддом; (b) перегляд даних про відносини між сутностями , розроблений доктором П.П. Ченом ; а також (c) техніку проектування логічної бази даних, створену Робертом Г. Брауном.


Як бачите, я зобразив лише три асоціації M: N за допомогою відповідних типів асоціативної сутності , тобто:

  • Співробітник
  • SystemGame
  • GameGenre

Серед інших аспектів, є дві чіткі супертипові підтипові структури, де:

  • Особа та Організація є взаємовиключними субтипами суб'єкта Партії , їх супертип

  • Продукт - це супертип системи та гри , які, у свою чергу, є взаємовиключними підтипами

Якщо ви не знайомі з асоціаціями підтипів підтипів, ви можете знайти допомогу, наприклад, мої відповіді на запитання під назвою:

Ілюстративний логічний макет SQL-DDL

Послідовно, ми повинні переконатися, що на логічному рівні:

  • Кожен тип сутності представлений індивідуальною базовою таблицею
  • Кожне окреме властивість відповідного типу об'єкта позначається певним стовпцем
  • Для кожного стовпця фіксується точний тип даних , щоб переконатися, що всі значення, які він містить, належать певному та чітко визначеному набору, будь то INT, DATETIME, CHAR тощо (звичайно, при використанні, наприклад, Firebird або PostgreSQL , можливо, ви хочете використовувати більш потужні DOMAIN)
  • Кілька обмежень налаштовуються (декларативно), щоб гарантувати, що твердження у вигляді рядків, що зберігаються у всіх таблицях, відповідають бізнес-правилам, визначеним на концептуальному рівні

Тому я оголосив наступне розташування 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)
);

Доречно підкреслити, що в декількох таблицях є оголошення складених обмежень PRIMARY KEY, які позначають ієрархію зв'язків, що мають місце серед понятійних типів сутності, розташування, яке може бути дуже корисним щодо пошуку даних, наприклад, якщо висловити SELECT операції, що включають пропозиції JOIN для отримання похідних таблиць.

Так, (i) кожна асоціація M: N та (ii) кожен з асоційованих типів сутності позначаються (iii) відповідною таблицею в логічній структурі DDL, тому зверніть особливу увагу на обмеження ПОЧАТКОВОГО та ЗОВНІШНЬОГО КЛЮЧА (і зауваження я залишив як коментар) таблиць, що представляють ці концептуальні елементи, оскільки вони допомагають забезпечити, щоб з'єднання між відповідними рядками відповідали застосовним коефіцієнтам кардинальності.

Використання складених ключів було введено доктором Е. Ф. Коддом з самого початку виникнення реляційної парадигми, як це продемонстровано в прикладах, які він включив до своєї семінарської роботи 1970 року під назвою "Реляційна модель для великих спільних банків даних" (яка, зокрема, також представляє найелегантніший метод обробки концептуальних об'єднань M: N).

Я поставив db <> fiddle та SQL Fiddle , обидва працюють на Microsoft SQL Server 2014, щоб структура могла бути перевірена "в дії".

Нормалізація

Нормалізація - це процедура логічного рівня, яка, в основному, передбачає:

  1. Усунення неатомних стовпців за допомогою першої нормальної форми, щоб маніпулювання та звуження даних набагато простіше впоратися з підмовою використання даних (наприклад, SQL).

  2. Позбавлення небажаних залежностей серед стовпців певної таблиці завдяки послідовним нормальним формам, щоб уникнути аномалій оновлення .

Зрозуміло, потрібно враховувати значення , що містяться в розглянутій таблиці та стовпцях.

Мені подобається вважати нормалізацію випробуванням, заснованим на науці, що дизайнер застосовує до відповідних елементів, як тільки він окреслив стійке розташування на логічному рівні, щоб визначити, чи відповідають його пункти кожній із звичайних форм чи ні. Потім, у разі потреби, дизайнер вживає відповідних коригуючих заходів.

Надмірність

У реляційній моделі, хоча дублювання значень, що містяться у стовпцях, є не тільки прийнятним, але й очікуваним , дублювати рядки заборонено . Настільки, наскільки я бачу, у всіх таблицях, що містяться в логічному макеті, викритому раніше, запобігаються повторювані дублікати рядків та інші види шкідливих надмірностей, можливо, ви хочете уточнити своє занепокоєння з цього приводу.

У будь-якому випадку, ви можете, безумовно, (а) оцінити на своїй власній структурі по масі звичайних форм, щоб визначити, чи відповідає вона вимогам, і (b) змінити її, якщо це необхідно.

Супутні ресурси

  • У цій серії публікацій я викладаю деякі міркування щодо прямолінійної асоціації M: N, яка може взаємозв'язувати примірники двох різних типів сутності.
  • У цьому іншому я пропоную підхід до вирішення виникнення конструкції "Матеріал білла" або "Вибух частин", в якій я описую, як з'єднати окремі екземпляри одного типу сутності.

Тернарні асоціації

Є ще один важливий аспект, який ви зрозуміли за допомогою коментарів (розміщених у видаленій відповіді):

Кожен раз, коли я намагаюся зробити міст, елементи цього мосту також мають "Багато до багатьох", я відчуваю, що це не дозволяється або, принаймні, не відволікається.

Ця обставина, схоже, вказує на те, що одне з ваших проблем пов'язане з концептуальними потрійними асоціаціями . В основному, подібні асоціації виникають тоді, коли існують (1) відносини, що включають (2) два інших відносини, іншими словами "відносини між відносинами" - типова ситуація, оскільки відносини є суб'єктом власного права. -.

При належному управлінні ці домовленості також не приносять шкідливих скорочень. І так, якщо є певний випадок використання, коли ви визначаєте, що такі відносини представлені серед типів "реального світу" сутності, ви повинні (i) моделювати та (ii) оголошувати їх з точністю на логічному рівні.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.