Модель сутність-атрибут-значення
![]() | В іншому мовному розділі є повніша стаття Entity–attribute–value model(англ.). Ви можете допомогти, розширивши поточну статтю за допомогою перекладу з англійської.
|
Ця стаття не містить посилань на джерела. (19 березня 2024) |
Модель сутність–атрибут–значення (англ. entity–attribute–value, EAV) — це модель даних, яка дозволяє гнучко зберігати довільні, розріджені (велика кількість необов'язкових властивостей) або спеціальні властивостей або значення даних, призначена для ситуацій, коли структура моделі є довільною, можуть змінюватись користувачем або під час виконання, інакше неможливо передбачити за допомогою заздалегідь відомого.
Цей тип моделі даних пов'язаний з математичним поняттям розрідженої матриці . EAV також відома як модель об'єкт–атрибут–значення, вертикальна модель бази даних або відкрита схема .
Це представлення даних аналогічно методам збереження розрідженої матриці, де зберігаються лише непорожні значення. У моделі даних EAV кожна пара атрибут–значення є фактом, що описує сутність, а рядок у таблиці EAV зберігає один факт. Таблиця EAV має малу кількість колонок, та велику кількість рядків.
Дані записуються у вигляді трьох стовпців:
- Сутність : предмет, що описується.
- Атрибут або параметр : зазвичай реалізується як зовнішній ключ у таблиці визначень атрибутів. Таблиця визначень атрибутів може містити такі стовпці: ідентифікатор атрибута, ім'я атрибута, опис, тип даних і стовпці, що допомагають перевірити вхідні дані, наприклад, максимальна довжина рядка та регулярний вираз, набір допустимих значень тощо.
- Значення атрибута.
Сутність є зовнішнім ключем до таблиці «об'єктів», яка записує загальну інформацію про кожен «об'єкт» у базі даних – принаймні бажану назву та короткий опис, а також категорію/клас організації, до якої вона належить. Кожному запису (об'єкту) у цій таблиці присвоюється ідентифікатор (або сурогатний ключ) об'єкта.
Іноді використовується підхід «центральна таблиця об'єктів». Основна перевага центральної таблиці об'єктів полягає в тому, що, маючи допоміжну таблицю синонімів об'єктів і ключових слів, можна забезпечити наскрізний механізм пошуку, по всій системі, де користувач може знайти інформацію про будь-який об'єкт, що цікавить, без необхідності спочатку вказати категорію, до якої він належить.
У самій таблиці EAV це лише ідентифікатор атрибута, зовнішній ключ на таблицю визначень атрибутів.
Значення найчастіше приведені[en] (або серіалізовані) до одного типу, наприклад до рядків. Такий приклад простої, хоча і немасштабованої структури має такі проблеми:
- потрібні постійні конвертування типів даних. Використання індексу за значенням є марним, наприклад порівняння числа з його текстовим зображенням є марним.
- якщо необхідно зберігати блоби, наприклад зображення то приходиться кодувати їх в Base64 в одній таблиці з малими цілими іншими даними, наприклад з числами або рядками.
Іноді, щоб нівелювати ці проблеми, використовують окремі таблиці значень для кожного типу даних, причому метадані для даного атрибута визначають таблицю значень, у якій зберігатимуться його дані. Цей підхід насправді досить ефективний, оскільки скромний обсяг метаданих атрибутів для даного класу або форми, з якими користувач вирішує працювати, можна легко кешувати в пам'яті. Однак це додає складності в реалізації, а також міграція вимагає переміщення даних з однієї таблиці в іншу, якщо змінюється тип даних атрибута.
База даних EAV має сенс для категорій даних, де атрибути численні та рідкісні, дінамічно з'являються та змінюється їх тип. Якщо є вибір, то в такому випадку є сенс використовувати об'єктно-орієнтовані бази даних, але в умовах використання реляційних баз, EAV - один з способів який переносить складність кількості та різномаїття таблиць в саму таблицю.
Окрім таблиць EAV додаються допоміжні таблиці, що містять метадані. Наприклад згадана вище таблиця визначення атрибутів.
Альтернативами можуть бути використання JSON/XML в базах.