Модель сущность-атрибут-значение

Модель «сущность-атрибут-значение» ( EAV ) — это модель данных , оптимизированная для экономичного хранения разреженных или специальных значений свойств или данных, предназначенная для ситуаций, когда шаблоны использования во время выполнения являются произвольными, подверженными изменениям пользователем или в противном случае невозможно предвидеть использование фиксированной конструкции. Вариант использования ориентирован на приложения, которые предлагают большую или богатую систему определенных типов свойств, которые, в свою очередь, подходят для широкого набора объектов, но где обычно создается (или сохраняется) только небольшой, конкретный набор из них для данного сущность. Следовательно, этот тип модели данных относится к математическому понятию разреженной матрицы . EAV также известен как модель объект-атрибут-значение , вертикальная модель базы данных и открытая схема .

Структура данных

Это представление данных аналогично экономичным методам хранения разреженной матрицы , где сохраняются только непустые значения. В модели данных EAV каждая пара атрибут-значение представляет собой факт, описывающий сущность, а строка в таблице EAV хранит один факт. Таблицы EAV часто называют «длинными и тонкими»: «длинный» относится к количеству строк, «тонкий» — к небольшому количеству столбцов.

Данные записываются в три столбца:

• Сущность : описываемый элемент.
• Атрибут в или параметр : обычно реализуется как внешний ключ таблице определений атрибутов. Таблица определений атрибутов может содержать следующие столбцы: идентификатор атрибута, имя атрибута, описание, тип данных и столбцы, способствующие проверке входных данных, например, максимальная длина строки и регулярное выражение, набор допустимых значений и т. д.
• Значение . атрибута

Пример

Рассмотрим, как можно попытаться представить медицинскую карту общего назначения в реляционной базе данных. Очевидно, что создать таблицу (или набор таблиц) с тысячами столбцов невозможно, поскольку подавляющее большинство столбцов будут иметь значение null . Ситуация усложняется тем, что в продольной медицинской карте, которая следует за пациентом с течением времени, может быть несколько значений одного и того же параметра: например, рост и вес ребенка изменяются по мере его роста. Наконец, совокупность клинических данных продолжает расширяться: например, возникают болезни и разрабатываются новые лабораторные тесты; это потребует постоянного добавления столбцов и постоянного пересмотра пользовательского интерфейса. Термин «изменчивость атрибутов» иногда используется для описания проблем или ситуаций, которые возникают, когда список доступных атрибутов или их определений необходимо изменять с течением времени.

Ниже показана выборка строк таблицы EAV для клинических данных визита к врачу по поводу лихорадки утром 1 мая 1998 г. Записи, показанные в угловых скобках, являются ссылками на записи в других таблицах, которые для простоты понимания показаны здесь в виде текста, а не в виде закодированных значений внешнего ключа. В этом примере все значения являются литеральными значениями, но они также могут быть заранее определенными списками значений. Последние особенно полезны, когда известно, что возможные значения ограничены (т. е. перечислимы ).

• Сущность ​ . Для клинических результатов сущностью является событие пациента : внешний ключ в таблице, которая содержит как минимум идентификатор пациента и одну или несколько меток времени (например, дату/время начала и окончания исследования), которые фиксируют, когда описываемое событие произошло.
• Атрибут . или параметр : внешний ключ в таблице определений атрибутов (в данном примере — определений клинических данных) По крайней мере, таблица определений атрибутов будет содержать следующие столбцы: идентификатор атрибута, имя атрибута, описание, тип данных , единицы измерения и столбцы, помогающие проверять вводимые данные, например, максимальную длину строки и регулярное выражение, максимально и минимально допустимое значение. значения, набор допустимых значений и т. д.
• Значение . атрибута Это будет зависеть от типа данных, и вскоре мы обсудим, как хранятся значения.

Приведенный ниже пример иллюстрирует симптомы, которые можно наблюдать у пациента с пневмонией .

Сущность	Атрибут	Ценить
⟨Пациент XYZ, 1 мая 1998 г., 09:30⟩	⟨Температура в градусах Цельсия⟩	"38,9"
⟨Пациент XYZ, 1 мая 1998 г., 09:30⟩	⟨Наличие кашля⟩	"Истинный"
⟨Пациент XYZ, 1 мая 1998 г., 09:30⟩	⟨Тип кашля⟩	«С мокротой желтоватого цвета, с прожилками крови»
⟨Пациент XYZ, 1 мая 1998 г., 09:30⟩	⟨Частота пульса в ударах в минуту⟩	"98"

Описанные выше данные EAV сопоставимы с содержимым товарного чека супермаркета (который будет отражен в таблице «Статьи продаж» в базе данных). В квитанции указаны только сведения о фактически купленных товарах, а не каждый товар в магазине, который покупатель мог приобрести, но не сделал этого. Как и клинические данные конкретного пациента, товарный чек представляет собой компактное представление изначально скудных данных.

• «Субъект» — это идентификатор продажи/транзакции — внешний ключ в таблице транзакций продаж. Это используется для внутренней маркировки каждой позиции, хотя в квитанции информация о распродаже отображается вверху (местоположение магазина, дата/время продажи) и внизу (общая стоимость продажи).
• «Атрибут» — это внешний ключ в таблице продуктов, из которого можно найти описание, цену за единицу, скидки и рекламные акции и т. д. (Продукты так же изменчивы, как и клинические данные, а возможно, даже в большей степени: новые продукты появляются каждый месяц. , в то время как другие удаляются с рынка, если потребители не принимают их на должном уровне. Ни один компетентный разработчик баз данных не будет жестко запрограммировать отдельные продукты, такие как Doritos или диетическая кола, в виде столбцов в таблице.)
• «Значения» — это купленное количество и общая цена позиции.

Моделирование рядов , когда факты о чем-то (в данном случае о транзакции купли-продажи) записываются в виде нескольких строк, а не нескольких столбцов , это стандартный метод моделирования данных. Различия между моделированием строк и EAV (которое можно считать обобщением моделирования строк):

• Таблица, смоделированная по строкам, однородна по фактам, которые она описывает: таблица «Статьи затрат» описывает только проданные продукты. Напротив, таблица EAV содержит практически любые типы фактов.
• Тип данных столбца(ов) значений в таблице, моделируемой по строкам, заранее определяется характером записываемых фактов. Напротив, в таблице EAV концептуальный тип данных значения в конкретной строке зависит от атрибута в этой строке. Отсюда следует, что в производственных системах разрешение прямого ввода данных в таблицу EAV было бы верным путем к катастрофе, поскольку сам механизм базы данных не смог бы выполнить надежную проверку входных данных. Позже мы увидим, как можно создавать общие структуры , выполняющие большинство задач проверки входных данных, без бесконечного написания кода для каждого атрибута.

В хранилище клинических данных строковое моделирование также находит множество применений; подсхема лабораторных испытаний обычно моделируется таким образом, поскольку результаты лабораторных испытаний обычно являются числовыми или могут быть закодированы в числовом виде.

Обстоятельства, при которых вам потребуется выйти за рамки стандартного моделирования строк и перейти к EAV, перечислены ниже:

• Тип данных отдельных атрибутов варьируется (как видно из клинических данных).
• Категории данных многочисленны, растут или меняются, но количество экземпляров (записей/строк) в каждой категории очень мало. Здесь, при традиционном моделировании, диаграмма сущность-связь базы данных может содержать сотни таблиц: таблицы, содержащие тысячи/миллионы строк/экземпляров, выделяются визуально в той же степени, что и таблицы с очень небольшим количеством строк. Последние являются кандидатами на преобразование в представление EAV. Такая ситуация возникает в средах онтологического моделирования, где категории («классы») часто приходится создавать «на лету», а некоторые классы часто удаляются в последующих циклах прототипирования.

Некоторые («гибридные») классы имеют некоторые атрибуты, которые не являются разреженными (присутствуют во всех или большинстве экземпляров), в то время как другие атрибуты сильно варьируются и разрежены. Последние подходят для моделирования EAV. Например, описания продуктов, производимых корпорацией-конгломератом, зависят от категории продукта, например, атрибуты, необходимые для описания марки лампочки, сильно отличаются от тех, которые необходимы для описания устройства медицинской визуализации, но оба имеют общие атрибуты, такие как упаковка Стоимость единицы и единицы товара.

Описание концепций

Сущность

В клинических данных объектом обычно является клиническое событие, как описано выше. В настройках более общего назначения сущность представляет собой внешний ключ в таблице «объектов», в которой записывается общая информация о каждом «объекте» (вещи) в базе данных — как минимум, предпочтительное имя и краткое описание, а также категория/класс объекта, к которому он принадлежит. Каждой записи (объекту) в этой таблице присвоен идентификатор объекта, сгенерированный машиной.

Подход «таблицы объектов» был впервые использован Томом Слезаком и его коллегами из Ливерморской лаборатории Лоуренса для базы данных хромосомы 19 и в настоящее время является стандартом в большинстве крупных биоинформатических баз данных. Использование таблицы объектов не требует одновременного использования конструкции EAV: обычные таблицы могут использоваться для хранения сведений о каждой категории, относящихся к каждому объекту.

Основное преимущество центральной таблицы объектов состоит в том, что, имея вспомогательную таблицу синонимов и ключевых слов объектов, можно обеспечить стандартный механизм поиска, подобный Google, по всей системе, где пользователь может найти информацию о любом интересующем объекте без необходимости сначала укажите категорию, к которой он принадлежит. (Это важно в биологических системах, где такое ключевое слово, как «ацетилхолин», может относиться либо к самой молекуле, которая является нейротрансмиттером, либо к биологическому рецептору, с которым она связывается.)

Атрибут

В самой таблице EAV это просто идентификатор атрибута, внешний ключ в таблице определений атрибутов, как указано выше. Однако обычно существует несколько таблиц метаданных, содержащих информацию, связанную с атрибутами, и они будут рассмотрены ниже.

Значение

Преобразование всех значений в строки, как в приведенном выше примере данных EAV, приводит к простой, но немасштабируемой структуре: требуются взаимные преобразования константных типов данных, если кто-то хочет что-либо сделать со значениями, и индекс значения. столбец таблицы EAV по сути бесполезен. Кроме того, неудобно хранить большие двоичные данные, такие как изображения, в форме, закодированной Base64, в одной таблице с небольшими целыми числами или строками. Поэтому в более крупных системах используются отдельные таблицы EAV для каждого типа данных (включая большие двоичные объекты , «BLOB»), при этом метаданные для данного атрибута идентифицируют таблицу EAV, в которой будут храниться ее данные. Этот подход на самом деле весьма эффективен, поскольку небольшой объем метаданных атрибутов для данного класса или формы, с которыми пользователь выбирает работу, может быть легко кэширован в памяти. Однако при изменении типа данных атрибута требуется перемещение данных из одной таблицы в другую.

История

общего назначения EAV, как средство представления знаний , возникло на основе концепции « списков ассоциаций » ( пар атрибут-значение ). Широко используемые сегодня, они были впервые представлены в языке LISP . Пары атрибут-значение широко используются в различных приложениях, таких как файлы конфигурации (с использованием простого синтаксиса, такого как атрибут = значение ). Примером использования EAV вне базы данных является UIMA (архитектура управления неструктурированной информацией), стандарт, который сейчас находится под управлением Apache Foundation и используется в таких областях, как обработка естественного языка . Программное обеспечение, которое анализирует текст, обычно размечает («аннотирует») сегмент: пример, представленный в руководстве UIMA, представляет собой программу, которая выполняет распознавание именованных объектов (NER) в документе, аннотируя текстовый сегмент «Президент Буш» аннотацией: Тройка атрибут-значение (Человек, Полное_Имя, «Джордж Буш») . Такие аннотации могут храниться в таблице базы данных.

Хотя EAV не имеет прямой связи с AV-парами, Стед и Хаммонд, похоже, первыми додумались использовать их для постоянного хранения данных произвольной сложности. Первыми системами медицинских записей, в которых использовалась EAV, были электронные медицинские карты Regenstrief (разработка под руководством Клемента Макдональда), Система TMR (Медицинская карта) Уильяма Стеда и Эда Хаммонда и Хранилище клинических данных (CDR) HELP, созданное группой Гомера Уорнера в больнице СПД, Солт-Лейк-Сити, Юта. (В системе Regenstrief фактически использовалась конструкция «Пациент-атрибут-временная метка-значение»: использование временной метки поддерживало поиск значений для данного пациента/атрибута в хронологическом порядке.) Все эти системы, разработанные в 1970-х годах, были выпущены до того, как коммерческие системы Основанные на Э. Ф. Кодда , модели реляционной базы данных были доступны, хотя гораздо позже HELP была перенесена на реляционную архитектуру и коммерциализирована корпорацией 3M. (Обратите внимание, что, хотя знаковая статья Кодда была опубликована в 1970 году, ее насыщенный математический тон имел печальный эффект, уменьшив ее доступность среди специалистов, не связанных с компьютерными науками, и, как следствие, задержав принятие модели в кругах ИТ и поставщиков программного обеспечения. Ценность последующей статьи Кодда была опубликована в 1970 году. вклад Кристофера Дж. Дэйта , коллеги Кодда из IBM, в перевод этих идей на доступный язык, сопровождаемый простыми примерами, иллюстрирующими их силу, невозможно переоценить.)

Группа из Колумбийского пресвитерианского медицинского центра первой использовала механизм реляционной базы данных в качестве основы системы EAV.

с открытым исходным кодом TrialDB клинических исследований Система управления данными , разработанная Nadkarni et al. был первым, кто использовал несколько таблиц EAV, по одной для каждого типа данных СУБД .

Структура EAV/CR, разработанная в первую очередь Луисом Маренко и Пракашем Надкарни, наложила принципы объектной ориентации на EAV; он основан на подходе таблицы объектов Тома Слезака (описанном ранее в разделе «Сущность»). SenseLab , общедоступная база данных нейробиологии, построена на основе EAV/CR.

Использование в базах данных

Термин «база данных EAV» относится к конструкции базы данных, в которой значительная часть данных моделируется как EAV. Однако даже в базе данных, описанной как «основанная на EAV», некоторые таблицы в системе являются традиционными реляционными таблицами.

Как отмечалось выше, моделирование EAV имеет смысл для таких категорий данных, как клинические данные, атрибуты которых многочисленны и редки. Если эти условия не выполняются, предпочтительнее использовать стандартное реляционное моделирование (т. е. один столбец на атрибут); использование EAV не означает отказа от здравого смысла или принципов хорошего реляционного дизайна. В системах медицинской документации подсхемы, касающиеся демографических данных пациентов и выставления счетов, обычно моделируются традиционным образом. (Хотя большинство схем баз данных поставщиков являются частными, VistA , система, используемая в медицинской системе Министерства по делам ветеранов США (VA), известная как Управление здравоохранения ветеранов (VHA), имеет открытый исходный код, и его схему легко проверить, хотя он использует механизм базы данных MUMPS, а не реляционную базу данных.)

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

EAV/CR: представление подструктуры с классами и отношениями.

В простой конструкции EAV значения атрибута представляют собой простые или примитивные типы данных с точки зрения ядра базы данных. Однако в системах EAV, используемых для представления весьма разнообразных данных, возможно, что данный объект (экземпляр класса) может иметь подструктуру: то есть некоторые из его атрибутов могут представлять другие виды объектов, которые, в свою очередь, могут иметь подструктуру. произвольного уровня сложности. Например, у автомобиля есть двигатель, трансмиссия и т. д., а у двигателя есть такие компоненты, как цилиндры. (Допустимая подструктура для данного класса определяется в метаданных атрибута системы, как обсуждается позже. Таким образом, например, атрибут «оперативная память» может применяться к классу «компьютер», но не к классу «двигатель». .)

Для представления подструктуры включается специальная таблица EAV, в которой столбец значений содержит ссылки на другие объекты в системе (т. е. значения внешнего ключа в таблице объектов). Чтобы получить всю информацию о данном объекте, требуется рекурсивный обход метаданных, за которым следует рекурсивный обход данных, который останавливается, когда каждый полученный атрибут является простым (атомарным). Рекурсивный обход необходим независимо от того, представлены ли детали отдельного класса в обычной форме или в форме EAV; такой обход выполняется, например, в стандартных объектно-реляционных системах. На практике количество уровней рекурсии имеет тенденцию быть относительно небольшим для большинства классов, поэтому потери производительности из-за рекурсии скромны, особенно при индексировании идентификаторов объектов.

EAV/CR (EAV с классами и отношениями) относится к структуре, которая поддерживает сложную подструктуру. Его название в некоторой степени неверное: хотя оно и было результатом работы над системами EAV, на практике многие или даже большинство классов в такой системе могут быть представлены в стандартной реляционной форме, в зависимости от того, являются ли атрибуты разреженными или плотными. . EAV/CR действительно характеризуется очень подробными метаданными, которых достаточно для поддержки автоматического создания интерфейсов просмотра для отдельных классов без необходимости писать код пользовательского интерфейса для каждого класса. В основе таких интерфейсов браузера лежит возможность генерировать пакет динамических SQL-запросов, который не зависит от класса объекта, сначала просматривая его метаданные и используя информацию метаданных для создания последовательности запросов к таблицам данных, а также некоторые из этих запросов могут быть произвольно рекурсивными. Этот подход хорошо работает для пообъектных запросов, например, в веб-интерфейсах просмотра, где щелчок по имени объекта отображает все сведения об объекте на отдельной странице: метаданные, связанные с классом этого объекта, также облегчают представление деталей объекта, поскольку оно включает заголовки отдельных атрибутов, порядок их представления, а также способы их группировки.

Один из подходов к EAV/CR — разрешить столбцам хранить структуры JSON , которые, таким образом, обеспечивают необходимую структуру классов. Например, PostgreSQL , начиная с версии 9.4, предлагает поддержку двоичных столбцов JSON (JSONB), позволяя запрашивать, индексировать и объединять атрибуты JSON.

Метаданные

По словам профессора доктора Даниэля Масиса (бывшего заведующего кафедрой медицинской информатики Университета Вандербильта), проблемы работы с EAV связаны с тем фактом, что в базе данных EAV «физическая схема» (способ хранения данных) радикально отличается от «логической схемы» – того, как ее рассматривают пользователи и многие программные приложения, такие как пакеты статистики, т. е. как обычные строки и столбцы для отдельных классов. (Поскольку таблица EAV концептуально смешивает яблоки, апельсины, грейпфруты и рагу, если вы хотите провести какой-либо анализ данных с использованием стандартного готового программного обеспечения, в большинстве случаев вам придется преобразовать их подмножества в столбчатую форму. Процесс этого, называемый поворотом , достаточно важен, чтобы его можно было обсудить отдельно.)

Метаданные помогают выполнять ловкость рук, которая позволяет пользователям взаимодействовать с системой с точки зрения логической схемы, а не физической: программное обеспечение постоянно анализирует метаданные для различных операций, таких как представление данных, интерактивная проверка, массовое извлечение данных и специальные запросы. Метаданные фактически могут использоваться для настройки поведения системы.

В системах EAV простота физической и логической структуры данных сочетается со сложностью их метаданных, которые, помимо прочего, играют ту же роль, которую ограничения базы данных и ссылочная целостность играют в стандартных конструкциях баз данных. Такой компромисс, как правило, оправдан, поскольку в типичной смешанной схеме производственных систем данные в обычных реляционных таблицах также могут выиграть от таких функций, как автоматическое создание интерфейса. Структура метаданных настолько сложна, что включает собственную подсхему в базе данных: различные внешние ключи в таблицах данных ссылаются на таблицы внутри этой подсхемы. Эта подсхема является стандартно-реляционной, в ней максимально используются такие функции, как ограничения и ссылочная целостность.

Корректность содержания метаданных с точки зрения предполагаемого поведения системы имеет решающее значение, и задача обеспечения корректности означает, что при создании системы EAV значительные усилия по проектированию должны быть направлены на создание пользовательских интерфейсов для редактирования метаданных, которые могут использоваться людьми. в команде, которая знает проблемную область (например, клиническую медицину), но не обязательно является программистом. (Исторически одной из основных причин, по которой дореляционная система TMR не была принята на сайтах, отличных от ее исходной организации, было то, что все метаданные хранились в одном файле с неинтуитивной структурой. Настройка поведения системы путем изменения содержимого этого файла, не приводя к сбою системы, было настолько деликатной задачей, что авторы системы доверяли ее выполнению только себе.)

Если система EAV реализована через RDF , схемы RDF для выражения таких метаданных можно удобно использовать язык . Эта информация о схеме может затем использоваться ядром базы данных EAV для динамической реорганизации внутренней структуры таблицы для достижения максимальной эффективности.

Некоторые заключительные предостережения относительно метаданных:

• Поскольку бизнес-логика находится в метаданных, а не в явной форме в схеме базы данных (т. е. удален один уровень по сравнению с традиционно разработанными системами), она менее очевидна для тех, кто незнаком с системой. Поэтому инструменты просмотра метаданных и отчетности по метаданным важны для обеспечения удобства обслуживания системы EAV. В обычном сценарии, когда метаданные реализуются как реляционная подсхема, эти инструменты представляют собой не что иное, как приложения, созданные с использованием готовых инструментов отчетности или запросов, которые работают с таблицами метаданных.
• Недостаточно компетентному пользователю легко повредить метаданные (т. е. внести в них несоответствия и ошибки). Поэтому доступ к метаданным должен быть ограничен, а также должен быть создан контрольный журнал обращений и изменений, чтобы справиться с ситуациями, когда доступ к метаданным имеют несколько человек. Использование СУБД для метаданных упростит процесс поддержания согласованности во время создания и редактирования метаданных за счет использования таких функций СУБД, как поддержка транзакций. Кроме того, если метаданные являются частью той же базы данных, что и сами данные, это гарантирует, что их резервное копирование будет выполняться как минимум так же часто, как и сами данные, и их можно будет восстановить к определенному моменту времени.
• Качество аннотаций и документации в метаданных (т. е. описательного/пояснительного текста в описательных столбцах подсхемы метаданных) должно быть намного выше, чтобы облегчить понимание различными членами команды разработчиков. Обеспечение качества метаданных (и поддержание их актуальности по мере развития системы) имеет очень высокий приоритет при долгосрочном управлении и обслуживании любого проекта, в котором используется компонент EAV. Плохо документированные или устаревшие метаданные могут поставить под угрозу долгосрочную жизнеспособность системы.

Информация, зафиксированная в метаданных

Метаданные атрибута

• Метаданные проверки включают тип данных, диапазон допустимых значений или членство в наборе значений, соответствие регулярному выражению, значение по умолчанию и разрешено ли этому значению быть нулевым. В системах EAV, представляющих классы с подструктурой, метаданные проверки также будут фиксировать, к какому классу, если таковой имеется, принадлежит данный атрибут.
• Метаданные представления : как атрибут должен отображаться пользователю (например, в виде текстового поля или изображения указанных размеров, раскрывающегося списка или набора переключателей). Когда составной объект состоит из нескольких атрибутов, как в дизайне EAV/CR, существуют дополнительные метаданные о порядке, в котором атрибуты должны быть представлены, и о том, как эти атрибуты могут быть сгруппированы (под описательными заголовками).
• Для атрибутов, которые являются лабораторными параметрами, регистрируются диапазоны нормальных значений , которые могут варьироваться в зависимости от возраста, пола, физиологического состояния и метода анализа.
• Группировка метаданных . Атрибуты обычно представляются как часть группы более высокого порядка, например, в специальной форме. Метаданные группировки включают такую ​​информацию, как порядок представления атрибутов. Определенные метаданные презентации, такие как шрифты/цвета и количество атрибутов, отображаемых в строке, применяются к группе в целом.

Метаданные расширенной проверки

• Метаданные зависимостей : во многих пользовательских интерфейсах ввод определенных значений в определенные поля/атрибуты требуется либо для отключения/скрытия определенных других полей, либо для включения/отображения других полей. (Например, если пользователь выбирает ответ «Нет» на логический вопрос «Есть ли у пациента диабет?», то последующие вопросы о продолжительности диабета, лекарствах от диабета и т. д. должны быть отключены.) Для этого в универсальная структура предполагает сохранение зависимостей между управляющими атрибутами и контролируемыми атрибутами.
• Вычисления и комплексная проверка . Как и в электронной таблице, значения определенных атрибутов могут быть вычислены и отображены на основе значений, введенных в поля, которые представлены ранее в последовательности. (Например, площадь поверхности тела является функцией высоты и ширины). Точно так же могут существовать «ограничения», которые должны соблюдаться, чтобы данные были действительными: например, при дифференциальном подсчете лейкоцитов сумма подсчетов отдельных типов лейкоцитов всегда должна равняться 100, поскольку отдельные подсчеты представляют собой проценты. Вычисленные формулы и комплексная проверка обычно выполняются путем сохранения выражений в метаданных, которые заменяются макросами значениями, которые вводит пользователь и которые могут быть оценены. В веб-браузерах как JavaScript , так и VBScript есть функция Eval(), которую можно использовать для этой цели.

Проверка, представление и группировка метаданных делают возможным создание фреймворков кода, которые поддерживают автоматическое создание пользовательского интерфейса как для просмотра данных, так и для интерактивного редактирования. В производственной системе, которая доставляется через Интернет, задача проверки данных EAV по существу перемещается с внутреннего уровня/уровня базы данных (который бессилен в отношении этой задачи) на средний уровень/уровень веб-сервера. Хотя внутренняя проверка всегда идеальна, поскольку ее невозможно разрушить, пытаясь напрямую ввести данные в таблицу, проверка среднего уровня с помощью общей структуры вполне работоспособна, хотя значительный объем усилий по проектированию программного обеспечения должен быть направлен сначала на создание структуры. . Наличие инфраструктур с открытым исходным кодом , которые можно изучать и модифицировать для индивидуальных нужд, может во многом помочь избежать повторного изобретения колеса.

Сценарии использования

(Первая часть этого раздела представляет собой краткое изложение справочной статьи Дину/Надкарни в Central, к которому читатель обращается за более подробной информацией.)

Моделирование EAV, под альтернативными терминами « общее моделирование данных » или «открытая схема», уже давно является стандартным инструментом для продвинутых разработчиков моделей данных. Как и любой продвинутый метод, он может быть обоюдоострым, и его следует использовать разумно.

Кроме того, использование EAV не исключает использования традиционных подходов к моделированию реляционных баз данных в рамках одной и той же схемы базы данных. В EMR, которые полагаются на СУБД, такие как Cerner , которые используют подход EAV для своей подсхемы клинических данных, подавляющее большинство таблиц в схеме фактически моделируются традиционно, с атрибутами, представленными в виде отдельных столбцов, а не строк.

Моделирование подсхемы метаданных системы EAV на самом деле очень хорошо подходит для традиционного моделирования из-за взаимосвязей между различными компонентами метаданных. Например, в системе TrialDB количество таблиц метаданных в схеме превышает число таблиц данных примерно в десять раз. Поскольку правильность и согласованность метаданных имеют решающее значение для правильной работы системы EAV, разработчик системы хочет в полной мере воспользоваться всеми преимуществами, предоставляемыми СУБД, такими как ссылочная целостность и программируемые ограничения, вместо того, чтобы заново изобретать СУБД. - колесо двигателя. Следовательно, многочисленные таблицы метаданных, поддерживающие конструкции EAV, обычно находятся в реляционной форме третьей нормальной формы.

Коммерческие системы электронных медицинских карт (EHR) используют моделирование строк для таких классов данных, как диагнозы, проведенные хирургические процедуры и результаты лабораторных исследований, которые разделены в отдельные таблицы. В каждой таблице «сущность» представляет собой комбинацию идентификатора пациента и даты/времени постановки диагноза (или проведения операции или лабораторного исследования); атрибут является внешним ключом в специально назначенной таблице поиска, которая содержит контролируемый словарь - например, МКБ-10 для диагнозов, текущую процедурную терминологию для хирургических процедур, с набором атрибутов значений. (Например, для результатов лабораторных испытаний можно записать измеренное значение, находится ли оно в нормальном, низком или высоком диапазоне, идентификатор лица, ответственного за выполнение теста, дату/время проведения теста и т. д. вкл.) Как говорилось ранее, это не полноценный подход EAV, поскольку домен атрибутов для данной таблицы ограничен, точно так же, как домен идентификаторов продуктов в таблице продаж супермаркета был бы ограничен доменом продуктов в таблице продаж. Таблица товаров.

Однако для сбора данных о параметрах, которые не всегда определены в стандартных словарях, EHR также предоставляют «чистый» механизм EAV, где специально назначенные опытные пользователи могут определять новые атрибуты, их тип данных, максимально и минимально допустимые значения (или допустимый набор). значений/кодов), а затем разрешить другим собирать данные на основе этих атрибутов. В Epic (TM) EHR этот механизм называется «Блок-схемы» и обычно используется для сбора данных наблюдения за медсестрами в стационаре.

Моделирование разреженных атрибутов

Типичным случаем использования модели EAV являются очень редкие гетерогенные атрибуты, такие как клинические параметры в электронных медицинских картах (EMR), как указано выше. Однако даже здесь можно с уверенностью сказать, что принцип моделирования EAV применяется к подсхеме базы данных, а не ко всему ее содержимому. (Например, демографические данные пациентов наиболее естественно моделируются в традиционной реляционной структуре с одним столбцом на атрибут.)

Следовательно, аргументы в пользу EAV и «реляционного» дизайна отражают неполное понимание проблемы: дизайн EAV следует использовать только для той подсхемы базы данных, где необходимо моделировать разреженные атрибуты: даже здесь их необходимо поддерживать. таблицами метаданных третьей нормальной формы . Существует относительно мало проблем при проектировании базы данных, в которых встречаются разреженные атрибуты: именно поэтому обстоятельства, в которых применим дизайн EAV, относительно редки. Даже там, где они встречаются, набор таблиц EAV — не единственный способ справиться с разреженными данными: решение на основе XML (обсуждаемое ниже) применимо, когда максимальное количество атрибутов на объект относительно невелико, а общий объем разреженных данных данные также столь же скромны. Примером такой ситуации являются проблемы регистрации переменных атрибутов для разных типов продуктов.

Разреженные атрибуты также могут возникать в ситуациях электронной коммерции, когда организация покупает или продает обширный и весьма разнообразный набор товаров, при этом детали отдельных категорий товаров сильно различаются.

Моделирование множества классов с очень небольшим количеством экземпляров каждого класса: высокодинамичные схемы.

Другое применение EAV — моделирование классов и атрибутов, которые хотя и не разрежены, но являются динамическими, но где количество строк данных на класс будет относительно скромным — максимум пара сотен строк, но обычно несколько десятков — и система разработчик также обязан предоставить веб-интерфейс конечному пользователю в очень короткие сроки. «Динамический» означает, что новые классы и атрибуты необходимо постоянно определять и изменять для представления развивающейся модели данных. Этот сценарий может возникнуть в быстро развивающихся научных областях, а также при разработке онтологий, особенно на этапах прототипирования и итеративного уточнения.

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

Упомянутая ранее структура EAV/CR была создана для решения именно этой ситуации. Обратите внимание, что модель данных EAV здесь не обязательна, но разработчик системы может счесть ее приемлемой альтернативой созданию, скажем, шестидесяти или более таблиц, содержащих в общей сложности не более двух тысяч строк. Здесь, поскольку количество строк в классе очень мало, соображения эффективности менее важны; Благодаря стандартной индексации по идентификатору класса/идентификатору атрибута оптимизаторы СУБД могут легко кэшировать данные небольшого класса в памяти при выполнении запроса, включающего этот класс или атрибут.

Стоит отметить, что в сценарии с динамическими атрибутами структура описания ресурсов в качестве основы работы по онтологии, связанной с семантической сетью, используется (RDF). RDF, задуманный как общий метод представления информации, является формой EAV: тройка RDF включает объект, свойство и значение.

В конце книги Джона Бентли «Написание эффективных программ» автор предупреждает, что повышение эффективности кода в целом также усложняет его понимание и поддержку, поэтому не следует торопиться и настраивать код, если предварительно не определили, существует что проблемы с производительностью, а такие меры, как профилирование кода, позволили определить точное местонахождение узкого места. Сделав это, вы изменяете только тот код, который должен работать быстрее. Аналогичные соображения применимы и к моделированию EAV: вы применяете его только к той подсистеме, где традиционное реляционное моделирование априори известно как громоздкое (как в области клинических данных) или в ходе эволюции системы обнаруживается, что оно создает значительные проблемы с обслуживанием. Гуру баз данных (и в настоящее время вице-президент по основным технологиям в Oracle Corporation) Том Кайт, например, правильно указывает на недостатки использования EAV в традиционных бизнес-сценариях и подчеркивает, что простая «гибкость» не является достаточным критерием для использования EAV. (Однако он делает решительное заявление о том, что EAV следует избегать при любых обстоятельствах, хотя само подразделение Oracle Health Sciences использует EAV для моделирования атрибутов клинических данных в своих коммерческих системах ClinTrial). и Oracle Clinical. )

Работа с данными EAV

Ахиллесова пята EAV — сложность работы с большими объемами данных EAV. Часто необходимо временно или постоянно осуществлять взаимное преобразование между столбчатыми и строковыми или EAV-моделированными представлениями одних и тех же данных; если это делается вручную, это может привести как к ошибкам, так и к интенсивному использованию процессора. Общие структуры, использующие метаданные атрибутов и группировок атрибутов, устраняют первое, но не последнее ограничение; их использование более или менее обязательно в случае смешанных схем, содержащих смесь традиционных реляционных данных и данных EAV, где коэффициент ошибок может быть очень значительным.

Операция преобразования называется поворотом . Поворот требуется не только для данных EAV, но и для любой формы данных, смоделированных по строкам. (Например, реализации алгоритма Apriori для ассоциативного анализа, широко используемого для обработки данных о продажах в супермаркетах для определения других продуктов, которые покупатели данного продукта также могут купить, в качестве первого шага используют сводные данные, смоделированные по строкам.) Многие механизмы баз данных имеют собственные расширения SQL для облегчения поворота, и такие пакеты, как Microsoft Excel, также поддерживают его. Обстоятельства, при которых поворот необходим, рассматриваются ниже.

• Просмотр небольших объемов данных для отдельного объекта с последующим редактированием данных на основе зависимостей между атрибутами. Эта операция облегчается за счет кэширования небольших объемов необходимых вспомогательных метаданных. Некоторые программы, такие как TrialDB, получают доступ к метаданным для создания полустатических веб-страниц, содержащих встроенный программный код, а также структуры данных, содержащие метаданные.
• Массовое извлечение преобразует большие (но предсказуемые) объемы данных (например, полные данные клинического исследования) в набор реляционных таблиц. Хотя эта задача требует большого количества ресурсов ЦП, она выполняется нечасто и ее не нужно выполнять в режиме реального времени; т. е. пользователь может дождаться завершения пакетного процесса. Важность массового извлечения невозможно переоценить, особенно когда данные необходимо обрабатывать или анализировать с помощью стандартных сторонних инструментов, которые совершенно не осведомлены о структуре EAV. Здесь нецелесообразно пытаться изобретать целые наборы колес с помощью общей структуры, а лучше всего просто массово извлекать данные EAV в реляционные таблицы, а затем работать с ними, используя стандартные инструменты.
• Интерфейсы специальных запросов к данным, смоделированным по строкам или EAV, при запросе с точки зрения отдельных атрибутов (например, «извлечь всех пациентов с наличием заболевания печени, с признаками печеночной недостаточности и без истории злоупотребления алкоголем») должны обычно результаты запроса с отдельными атрибутами отображаются в виде отдельных столбцов. Для большинства сценариев базы данных EAV производительность специальных запросов должна быть приемлемой, но ответы менее секунды не обязательны, поскольку запросы, как правило, носят исследовательский характер.

Реляционное деление

Однако структура модели данных EAV является идеальным кандидатом для реляционного разделения, см. Реляционную алгебру . При хорошей стратегии индексирования можно получить время ответа менее чем за несколько сотен миллисекунд для таблицы EAV с миллиардом строк. MVP Microsoft SQL Server Питер Ларссон доказал это на ноутбуке и сделал решение общедоступным.

Оптимизация производительности поворота

• Одной из возможных оптимизаций является использование отдельного « хранилища » или запрашиваемой схемы, содержимое которой обновляется в пакетном режиме из производственной (транзакционной) схемы. См. хранилище данных . Таблицы в хранилище тщательно индексируются и оптимизируются с помощью денормализации , которая объединяет несколько таблиц в одну, чтобы минимизировать снижение производительности из-за соединений таблиц.
• Определенные данные EAV в хранилище могут быть преобразованы в стандартные таблицы с использованием « материализованных представлений » (см. хранилище данных ), но обычно это последнее средство, которое необходимо использовать осторожно, поскольку количество представлений такого типа имеет тенденцию к нелинейному росту. с количеством атрибутов в системе.
• Структуры данных в памяти : можно использовать хеш-таблицы и двумерные массивы в памяти в сочетании с метаданными группировки атрибутов для сведения данных по одной группе за раз. Эти данные записываются на диск в виде плоского файла с разделителями, с внутренними именами для каждого атрибута в первой строке: этот формат можно легко импортировать в реляционную таблицу. Этот метод «в памяти» значительно превосходит альтернативные подходы, поскольку делает запросы к таблицам EAV максимально простыми и минимизирует количество операций ввода-вывода. Каждый оператор извлекает большой объем данных, а хеш-таблицы помогают выполнить операцию поворота, которая включает в себя помещение значения для данного экземпляра атрибута в соответствующую строку и столбец. Оперативная память (ОЗУ) достаточно распространена и доступна по цене в современном оборудовании, поэтому полный набор данных для одной группы атрибутов даже в больших наборах данных обычно полностью помещается в память, хотя алгоритм можно сделать более интеллектуальным, работая с фрагментами данных. если это окажется не так.

Очевидно, что какой бы подход вы ни выбрали, запрос EAV не будет таким же быстрым, как запрос стандартных реляционных данных, моделируемых по столбцам, для определенных типов запросов, во многом так же, как доступ к элементам в разреженных матрицах не так быстр, как доступ к элементам в разреженных матрицах. -разреженные матрицы, если последние полностью помещаются в основную память. (Разреженные матрицы, представленные с использованием таких структур, как связанные списки, требуют обхода списка для доступа к элементу в заданной позиции XY, тогда как доступ к элементам в матрицах, представленных в виде двумерных массивов, может выполняться с использованием быстрых операций с регистрами ЦП.) Однако если , вы правильно выбрали подход EAV для проблемы, которую пытались решить, это цена, которую вы платите; в этом отношении моделирование EAV является примером компромисса между пространством (и обслуживанием схемы) и временем процессора.

Альтернативы

EAV против универсальной модели данных

Первоначально постулировали Майер, Ульман и Варди: «Универсальная модель данных» (UDM) стремится упростить наивным пользователям запрос сложной реляционной схемы, создавая иллюзию того, что все хранится в одной гигантской «универсальной таблице». Это достигается за счет использования связей между таблицами, поэтому пользователю не нужно беспокоиться о том, какая таблица какой атрибут содержит. Си Джей Дэйт, однако отметил, что в обстоятельствах, когда одна таблица многократно связана с другой (как в генеалогических базах данных, где отец и мать человека также являются отдельными людьми, или в некоторых бизнес-базах данных, где все адреса хранятся централизованно, и организация может иметь разные адреса офисов и адреса доставки), в схеме базы данных недостаточно метаданных для указания однозначных объединений. При коммерциализации UDM, как в SAP BusinessObjects , это ограничение обходится путем создания «Юниверсов», которые представляют собой реляционные представления с предопределенными соединениями между наборами таблиц: разработчик «Юниверса» устраняет неоднозначность неоднозначных объединений, включая множественно связанные соединения. таблицу в представлении несколько раз, используя разные псевдонимы.

Помимо способа явного моделирования данных (UDM просто использует реляционные представления для взаимодействия между пользователем и схемой базы данных), EAV отличается от универсальных моделей данных тем, что он также применим к транзакционным системам, а не только к ориентированным на запросы (только для чтения). ) системы, как в UDM. Кроме того, при использовании в качестве основы для систем запроса клинических данных реализации EAV не обязательно защищают пользователя от необходимости указывать класс интересующего объекта. В витрине клинических данных i2b2 на базе EAV: например, когда пользователь ищет термин, он имеет возможность указать категорию данных, которые интересуют пользователя. Например, фраза « литий » может относиться либо к лекарству (которое используется для лечения биполярного расстройства, либо к лекарству, которое используется для лечения биполярного расстройства) . ) или лабораторный анализ уровня лития в крови пациента. (Уровень лития в крови необходимо тщательно контролировать: слишком большое количество препарата вызывает серьезные побочные эффекты, а слишком малое — неэффективно.)

XML и JSON

Реализация открытой схемы может использовать столбец XML в таблице для сбора переменной/разреженной информации. Аналогичные идеи можно применить к базам данных, поддерживающим столбцы со значениями JSON : разреженные иерархические данные могут быть представлены как JSON. Если база данных поддерживает JSON, например PostgreSQL и (частично) SQL Server 2016 и более поздних версий, атрибуты можно запрашивать, индексировать и объединять. Это может обеспечить повышение производительности более чем в 1000 раз по сравнению с простыми реализациями EAV. но это не обязательно делает приложение базы данных в целом более надежным.

Обратите внимание, что существует два способа хранения данных XML или JSON: один способ — сохранить их в виде простой строки, непрозрачной для сервера базы данных; другой способ — использовать сервер базы данных, который может «видеть» структуру. Очевидно, что у хранения непрозрачных строк есть некоторые серьезные недостатки: их нельзя запрашивать напрямую, нельзя сформировать индекс на основе их содержимого и невозможно выполнять соединения на основе содержимого.

Создание приложения, которое должно управлять данными, становится чрезвычайно сложным при использовании моделей EAV из-за масштаба инфраструктуры, которую необходимо разработать с точки зрения таблиц метаданных и кода платформы приложения. Использование XML решает проблему проверки данных на сервере (которая должна выполняться кодом среднего уровня и браузером в средах на основе EAV), но имеет следующие недостатки:

• Это требует большого количества программистов. XML-схемы, как известно, сложно писать вручную. Рекомендуемый подход — создавать их путем определения реляционных таблиц, генерации кода XML-схемы и последующего удаления этих таблиц. Это проблематично во многих производственных операциях, включающих динамические схемы, где новые атрибуты должны определяться опытными пользователями, которые разбираются в конкретной области применения (например, управление запасами или биомедицина), но не обязательно являются программистами. Напротив, в производственных системах, использующих EAV, такие пользователи определяют новые атрибуты (а также типы данных и проверки, связанные с каждым из них) через приложение с графическим интерфейсом. Поскольку метаданные, связанные с проверкой, должны храниться в нескольких реляционных таблицах в нормализованном дизайне, приложение с графическим интерфейсом, которое связывает эти таблицы вместе и обеспечивает соответствующие проверки согласованности метаданных, является единственным практическим способом разрешить ввод атрибутивной информации, даже для продвинутые разработчики — даже если в конечном результате вместо отдельных реляционных таблиц используются XML или JSON.
• Серверная диагностика, которая выдает решение XML/JSON в случае попытки вставки неверных данных (например, проверка диапазона или нарушение шаблона регулярных выражений), является загадочной для конечного пользователя: чтобы точно передать ошибку, можно было бы: по крайней мере, необходимо связать подробную и удобную для пользователя диагностику ошибок с каждым атрибутом.
• Решение не решает проблему создания пользовательского интерфейса.

Все вышеперечисленные недостатки можно устранить путем создания слоя метаданных и кода приложения, но при его создании исчезло первоначальное «преимущество» отсутствия необходимости создания инфраструктуры. Дело в том, что надежное моделирование атрибутов разреженных данных представляет собой сложную задачу проектирования приложения базы данных, независимо от того, какой подход к хранению используется. работа Сарки, однако доказывает жизнеспособность использования поля XML вместо реляционных таблиц EAV для конкретного типа для уровня хранения данных, а в ситуациях, когда количество атрибутов на объект невелико (например, переменные атрибуты продукта для разных типов продуктов), XML -решение более компактно, чем решение на основе EAV-таблицы. (Сам XML можно рассматривать как средство представления данных значений атрибутов, хотя он основан на структурированном тексте, а не на реляционных таблицах.)

Древовидные структуры и реляционные базы данных

Существует несколько других подходов к представлению данных с древовидной структурой, будь то XML , JSON или другие форматы, такие как модель вложенного набора , в реляционной базе данных. С другой стороны, поставщики баз данных начали включать поддержку JSON и XML в свои структуры данных и функции запросов, как в IBM Db2 , где данные XML хранятся как XML отдельно от таблиц, используя запросы XPath как часть операторов SQL или в PostgreSQL с типом данных JSON которые можно индексировать и запрашивать. Эти разработки дополняют, улучшают или заменяют подход модели EAV.

Использование JSON и XML не обязательно совпадает с использованием модели EAV, хотя они могут частично совпадать. XML предпочтительнее EAV для данных произвольной иерархии, объем которых относительно скромен для одного объекта: он не предназначен для масштабирования до уровня нескольких гигабайт с точки зрения производительности манипулирования данными. XML сам по себе не касается проблемы разреженных атрибутов, и когда модель данных, лежащая в основе представляемой информации, может быть непосредственно разложена на реляционную структуру, XML лучше подходит в качестве средства обмена данными, чем в качестве основного механизма хранения. . EAV, как говорилось ранее, конкретно (и только) применим к сценарию с разреженными атрибутами. Когда такой сценарий реализуется, использование таблиц атрибут-значение для конкретного типа данных, которые можно индексировать по сущности, по атрибуту и ​​по значению и которыми можно управлять с помощью простых операторов SQL, гораздо более масштабируемо, чем использование древовидной структуры XML. Google App Engine, упомянутый выше, использует таблицы строго типизированных значений по уважительной причине.

Графовые базы данных

Альтернативным подходом к решению различных проблем, возникающих с данными, структурированными в формате EAV, является использование графовой базы данных . Они представляют объекты как узлы графа или гиперграфа , а атрибуты — как ссылки или ребра этого графа. Проблема соединения таблиц решается путем предоставления языков запросов, ориентированных на графы, таких как Apache TinkerPop. или средство сопоставления шаблонов атомного пространства OpenCog .

Другая альтернатива — использовать хранилище SPARQL .

Рекомендации по серверному программному обеспечению

PostgreSQL: столбцы JSONB

PostgreSQL версии 9.4 включает поддержку двоичных столбцов JSON (JSONB), к которым можно запрашивать, индексировать и объединять. Это позволяет повысить производительность в тысячу и более раз по сравнению с традиционными конструкциями таблиц EAV.

Схема БД на основе JSONB всегда имеет меньше таблиц: в поля типа JSONB таблицы Entity можно вкладывать пары атрибут-значение. Это делает схему БД простой для понимания, а запросы SQL — краткими. Программный код для управления объектами базы данных на уровне абстракции оказывается намного короче.

SQL Server 2008 и более поздние версии: разреженные столбцы

Microsoft SQL Server 2008 предлагает (собственную) альтернативу EAV. Столбцы с атомарным типом данных (например, числовые, varchar или datetime) можно обозначить как разреженные , просто включив слово SPARSE в определение столбца инструкции CREATE TABLE. Разреженные столбцы оптимизируют хранение значений NULL (которые теперь вообще не занимают места) и полезны, когда большинство записей в таблице будут иметь значения NULL для этого столбца. Индексы по разреженным столбцам также оптимизированы: индексируются только строки со значениями. Кроме того, содержимое всех разреженных столбцов в конкретной строке таблицы может быть агрегировано в один столбец XML (набор столбцов), содержимое которого имеет вид [<column-name>column contents </column-name>]*.... Фактически, если набор столбцов определен для таблицы как часть инструкции CREATE TABLE, к нему обычно добавляются все определенные впоследствии разреженные столбцы. Это имеет интересное следствие: оператор SQL SELECT * from <tablename> не будет возвращать отдельные разреженные столбцы, а объединит их все в один XML-столбец, имя которого совпадает с именем набора столбцов (который, следовательно, действует как виртуальный вычисляемый столбец). Разреженные столбцы удобны для бизнес-приложений, таких как информация о продукте, где применимые атрибуты могут сильно различаться в зависимости от типа продукта, но общее количество переменных атрибутов для каждого типа продукта относительно невелико.

Ограничения разреженных атрибутов

Однако этот подход к моделированию разреженных атрибутов имеет несколько ограничений: конкурирующие СУБД, в частности, решили не заимствовать эту идею для своих собственных движков. Ограничения включают в себя:

• Максимальное количество разреженных столбцов в таблице составляет 10 000, чего может быть недостаточно для некоторых реализаций, например для хранения клинических данных, где возможное количество атрибутов на порядок больше. Таким образом, это не решение для моделирования *всех* возможных клинических признаков пациента.
• Добавление новых атрибутов – одна из основных причин поиска модели EAV – по-прежнему требует администратора базы данных. Кроме того, не решается проблема создания пользовательского интерфейса для разреженных атрибутивных данных: упрощается только механизм хранения. * Могут быть написаны приложения для динамического добавления и удаления разреженных столбцов из таблицы во время выполнения: напротив, попытка выполнить такое действие в многопользовательском сценарии, когда другие пользователи/процессы все еще используют таблицу, будет предотвращена для таблицы без разреженных столбцов. Однако, хотя эта возможность обеспечивает мощь и гибкость, она провоцирует злоупотребления, и ее следует использовать разумно и нечасто.
  • Это может привести к значительному снижению производительности, отчасти потому, что любые скомпилированные планы запросов, использующие эту таблицу, автоматически становятся недействительными.
  • Динамическое добавление или удаление столбцов — это операция, которую следует проверять, поскольку удаление столбцов может привести к потере данных: разрешение приложению изменять таблицу без сохранения какого-либо отслеживания, включая обоснование действия, не является хорошей практикой разработки программного обеспечения.
• Ограничения SQL (например, проверки диапазона, проверки регулярных выражений) нельзя применять к разреженным столбцам. Единственная проверка, которая применяется, — это проверка правильности типа данных. Ограничения необходимо будет реализовать в таблицах метаданных и коде среднего уровня, как это делается в производственных системах EAV. (Это соображение также применимо и к бизнес-приложениям.)
• SQL Server имеет ограничения на размер строки при попытке изменить формат хранения столбца: общее содержимое всех столбцов атомарных типов данных, разреженных и неразреженных, в строке, содержащей данные, не может превышать 8016 байт, если эта таблица содержит разреженный столбец для данных, которые будут автоматически скопированы.
• Разреженные столбцы, которые содержат данные, требуют дополнительных затрат на хранение в размере 4 байтов на каждый столбец в дополнение к объему хранения самого типа данных (например, 4 байта для столбцов datetime). Это влияет на объем данных с разреженными столбцами, которые можно связать с данной строкой. Это ограничение размера смягчено для типа данных varchar, а это означает, что если кто-то достигает предела размера строки в производственной системе, его придется обойти, назначив разреженные столбцы как varchar, даже если они могут иметь другой внутренний тип данных. К сожалению, этот подход теперь подрывает проверку типов данных на стороне сервера.

Предложения облачных вычислений

Многие поставщики облачных вычислений предлагают хранилища данных на основе модели EAV, где с данным объектом может быть связано произвольное количество атрибутов. Роджер Дженнингс проводит подробное сравнение из них. В предложении Amazon, SimpleDB, тип данных ограничен строками, а данные, которые по своей сути не являются строками, должны быть преобразованы в строку (например, числа должны быть дополнены ведущими нулями), если вы хотите выполнять такие операции, как сортировка. Предложение Microsoft, хранилище таблиц Windows Azure, предлагает ограниченный набор типов данных: byte[], bool, DateTime, double, Guid, int, long и string [1] . Google App Engine [2] предлагает самое большое разнообразие типов данных: помимо разделения числовых данных на целые, длинные или плавающие, он также определяет пользовательские типы данных, такие как номер телефона, адрес электронной почты, геокод и гиперссылка. Google, но не Amazon или Microsoft, позволяет вам определять метаданные, которые предотвратят привязку недопустимых атрибутов к определенному классу объектов, позволяя вам создать модель метаданных.

Google позволяет вам работать с данными, используя подмножество SQL; Microsoft предлагает синтаксис запросов на основе URL-адресов, абстрагированный через поставщика LINQ ; Amazon предлагает более ограниченный синтаксис. Вызывает беспокойство то, что встроенная поддержка объединения различных сущностей посредством соединений в настоящее время (апрель 2010 г.) отсутствует во всех трех движках. Такие операции должен выполнять код приложения. Это может не вызывать беспокойства, если серверы приложений расположены рядом с серверами данных в центре обработки данных поставщика, но если бы они были географически разделены, то возник бы большой сетевой трафик.

Подход EAV оправдан только тогда, когда моделируемые атрибуты многочисленны и разрежены: если собираемые данные не соответствуют этому требованию, подход EAV по умолчанию поставщиков облачных услуг часто не подходит для приложений, которым требуется настоящая серверная база данных. (в отличие от простого средства постоянного хранения данных). Переоборудование подавляющего большинства существующих приложений баз данных, использующих традиционный подход к моделированию данных, на облачную архитектуру типа EAV потребует серьезной хирургической операции. Microsoft обнаружила, например, что ее база разработчиков приложений баз данных в основном неохотно инвестировала такие усилия. Поэтому в 2010 году Microsoft запустила премиум-предложение SQL Server Azure — полноценный реляционный механизм с доступом к облаку, который позволяет портировать существующие приложения баз данных с незначительными изменениями. По состоянию на начало 2020-х годов служба позволяет использовать физические базы данных стандартного уровня размером до 8 ТБ. также доступны «гипермасштабные» и «критически важные для бизнеса» предложения.

См. также

• Система атрибутов и ценностей
• Связанные данные
• Структура описания ресурсов (RDF)
• Семантическая сеть
• тройной магазин
• Медленно меняющееся измерение
• Датомический