Супертип / підтип, що визначає категорію: повне роз'єднання або неповне перекриття

Я будую базу даних інвентаризації, в якій зберігаються інформаційні засоби, такі як настільні комп'ютери, ноутбуки, комутатори, маршрутизатори, мобільні телефони тощо. Я використовую шаблон супертипу / підтипу, де всі пристрої зберігаються в одній таблиці та конкретну інформацію вводиться в таблиці підтипів. Моя дилема - це вибір між двома наступними проектами:

У верхній діаграмі всі пристрої мають спільні підтипи. Наприклад, настільні комп'ютери та ноутбуки матимуть записи у таких таблицях: Device, NetworkDevice. Комутатор матиме записи в: Device, NetworkDevice. Маршрутизатор матиме записи в: Device, NetworkDevice, WANDevice. Будь-який пристрій, для якого ми відстежуємо місцезнаходження, матиме запис у Location. Деякі плюси і мінуси, які я придумав для цієї установки:

• Pro: ВИБІРИ записи, що базуються на загальному полі, наприклад, Hostname або LocationID, простіше.
• Pro: Немає нульових полів.
• Con: Таблиці, які повинні бути включені до операцій CRUD для певного пристрою, не є очевидними та можуть заплутати майбутні DBA.

У нижній діаграмі всі пристрої мають свій підтип (Є більше класів пристроїв, які тут не показані). У цій ситуації очевидно, з яких записів таблиць вставляється або вибирається з них. Настільні комп’ютери та ноутбуки входять у Комп'ютер тощо. Деякі плюси і мінуси, про які я думав для цієї установки:

• Про: Одразу очевидно, які таблиці використовувати для операцій CRUD для підтипів.
• Про: Для операцій з CRUD потрібно використовувати лише одну таблицю.
• Con: ВИБІР записів на основі загальних полів підтипу вимагає об'єднання всіх таблиць, наприклад, пошук за ім'ям хосту або LocationID.

В обох ситуаціях поле ClassDiscriminator розміщується у підтипових таблицях для використання із обмеженням CHECK для контролю, які типи можна вставити.

Чи є якісь рекомендації щодо того, який дизайн краще, або це повністю питання думки та залежить від цільової мети бази даних?

EDIT: Конкретне запитання, що стосується перекриття таблиці "NetworkDevice". Ця таблиця призначена для зберігання мережевої інформації для будь-якого пристрою з ім'ям хоста та / або IP-адресою, будь то комп'ютер, комутатор або маршрутизатор. Чи характер перекриття цієї таблиці є чимось, що може спричинити проблеми, чи добре її реалізувати таким чином?

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

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

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

• Якщо загальна кількість полів баз даних у підтипах порівняно мала (скажімо, менше 100) або є значна спільність між підтипами, то розбиття підтипів на окремі фізичні таблиці, мабуть, мало значення. Це додасть значних накладних витрат для звітування про запити та пошукові запити. У більшості випадків найкраще мати єдину таблицю та керувати своїм підтипом у програмі. (Мабуть, найближчий до вашої проблеми)

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

• Якщо у вас є велика кількість підтипів з розрізненими атрибутами та / або вимога зробити це налаштованим, то загальна структура та додаткові метадані можуть бути більш доречними. Дивіться цю публікацію SO для переходу на деякі можливі підходи. (Система адміністрування страхових полісів)

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

• Деякі перетворювачі O / R можуть підтримувати лише певний підхід до управління підкласами.

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

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

Розглянемо першу розробку логічної моделі даних звуку , використовуючи правила даних моделювання ієрархії класифікації знайдену в моделі підприємства Моделі , в книзі Девіда Хея. Під час створення ієрархії класифікації кожне виникнення (рядок) повинно бути одного і лише одного підтипу. Це означає, що підтипи взаємовиключні. Класифікація повинна базуватися на єдиній, фундаментальній, незмінній характеристиці. Використання цього основного правила надасть велику чіткість вашій моделі. У вашій моделі єдина характеристика, яку слід класифікувати, - це призначення пристрою - телефон, мережевий комутатор, комп’ютер, маршрутизатор тощо. Кожен пристрій повинен бути одного і лише одного з цих типів. Так, наприклад, розташування не буде підтипом. Атрибути, такі як IP-адреса, належать до супер-типу.

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

Зауважте, нарешті, ви завжди можете реалізувати шаблон EAV як схему базової таблиці, а потім створити шар абстракції подання, який представляє дані додатку у вигляді таблиць супер та підтипів. Це дає вам гнучкість на рівні зберігання, але розуміння на рівні перегляду додатків.

Товар - це не товарний запас. Інвентар та товари відрізняються.

Продукт - це дійсно специфікація товару, а не фізична річ.

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

Я б поглянув на Книгу ресурсів Сільверстона, модель даних, ресурс 1. Це заощадить вам багато часу.

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

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

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