Модель сущность – атрибут – значение - Entity–attribute–value model

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

EAV также известен как модель объект – атрибут – значение, вертикальная модель базы данных, и открытая схема.

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

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

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

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

пример

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

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

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

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

(<пациент XYZ, 01.05.98, 9:30>, <Температура в градусах Фаренгейта>, «102») (<пациент XYZ, 01.05.98, 9:30 утра>, <Наличие кашля>, " Верно ") (<пациент XYZ, 05.01.98, 9:30>, <Тип кашля>,« С мокротой, желтоватыми, с полосами крови ») (<пациент XYZ, 05.01.98, 9:30 >, <Пульс в ударах в минуту>, «98») ...

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

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

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

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

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

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

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

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

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

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

Организация

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

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

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

Атрибут

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

Значение

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

История

EAV, как универсальное средство представление знаний, возникла с концепцией "списки ассоциаций " (пары атрибут-значение ). Обычно используемые сегодня, они были впервые представлены на языке LISP.^[1] Пары атрибут-значение широко используются для различных приложений, таких как файлы конфигурации (с использованием простого синтаксиса, например атрибут = значение). Пример использования EAV вне базы данных приведен в UIMA (Архитектура управления неструктурированной информацией), стандарт, теперь управляемый Фонд Apache и работает в таких областях, как обработка естественного языка. Программное обеспечение, которое анализирует текст, обычно размечает («аннотирует») сегмент: пример, приведенный в учебном пособии UIMA, представляет собой программу, которая выполняет признание названного лица (NER) в документе, аннотируя текстовый сегмент "Президент Буш" тройкой значений атрибута аннотации. (Человек, ФИО, «Джордж Буш»).^[2] Такие аннотации могут храниться в таблице базы данных.

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

Группа в Колумбийско-пресвитерианском медицинском центре была первой, кто использовал ядро базы данных как основу системы EAV.^[7]

Открытый исходный код TrialDB клиническое исследование система управления данными Надкарни и др. первым использовал несколько таблиц EAV, по одной для каждой СУБД тип данных.^[8]

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

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

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

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

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

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

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

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

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

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

Метаданные

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

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

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

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

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

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

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

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

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

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

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

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

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

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

(Первая часть этого раздела - прецизионный справочной статьи Дину / Надкарни в Центре,^[18] к которому читатель направлен за более подробной информацией.)

Моделирование 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 (обсуждается ниже) применимо, когда максимальное количество атрибутов на объект относительно невелико, а общий объем разреженных данных данные также столь же скромны. Примером такой ситуации являются проблемы с захватом переменных атрибутов для разных типов продуктов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Первоначально постулировали Майер, Ульман и Варди,^[24] «Универсальная модель данных» (UDM) стремится упростить запрос сложной реляционной схемы наивными пользователями, создавая иллюзию, что все хранится в одной гигантской «универсальной таблице». Это достигается за счет использования отношений между таблицами, поэтому пользователю не нужно беспокоиться о том, какая таблица и какой атрибут содержит. C.J. Date, однако,^[25] указал, что в обстоятельствах, когда таблица многократно связана с другой (например, в генеалогических базах данных, где отец и мать человека также являются отдельными лицами, или в некоторых бизнес-базах данных, где все адреса хранятся централизованно, а организация может иметь разные адреса офисов и адреса доставки), в схеме базы данных недостаточно метаданных для определения однозначных соединений. Когда UDM был коммерциализирован, как в SAP BusinessObjects, это ограничение обходится путем создания «юниверсов», которые являются реляционными представлениями с предопределенными объединениями между наборами таблиц: разработчик «юниверсов» устраняет неоднозначные объединения, включая несколько раз связанную таблицу в представление, используя разные псевдонимы.

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

XML и JSON

Реализация Open Schema может использовать столбец XML в таблице для сбора переменной / разреженной информации.^[27] Подобные идеи можно применить к базам данных, которые поддерживают JSON -значные столбцы: разреженные, иерархические данные могут быть представлены в виде JSON. Если база данных поддерживает JSON, например PostgreSQL и (частично) SQL Server 2016 и более поздние версии, то атрибуты можно запрашивать, индексировать и объединять. Это может обеспечить повышение производительности более чем в 1000 раз по сравнению с наивными реализациями EAV.,^[28] но не обязательно делает все приложение базы данных более надежным.

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

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

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

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

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

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

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

Графические базы данных

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

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

PostgreSQL: столбцы JSONB

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

В схеме БД на основе JSONB всегда меньше таблиц: можно вкладывать пары атрибут-значение в поля типа JSONB таблицы сущностей. Это делает схему базы данных простой для понимания, а запросы SQL - краткими.^[32]Программный код для управления объектами базы данных на уровне абстракции оказывается намного короче.^[33]

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

Microsoft SQL Server 2008 предлагает (проприетарную) альтернативу EAV.^[34] Столбцы с атомарным типом данных (например, столбцы numeric, varchar или datetime) могут быть обозначены как редкий просто включив слово SPARSE в определение столбца оператора CREATE TABLE. Разреженные столбцы оптимизируют хранение значений NULL (которые теперь вообще не занимают места) и полезны, когда большинство записей в таблице будут иметь значения NULL для этого столбца. Также оптимизированы индексы для разреженных столбцов: индексируются только строки со значениями. Кроме того, содержимое всех разреженных столбцов в определенной строке таблицы может быть объединено в один столбец XML (набор столбцов), содержимое которого имеет форму [ содержимое столбца ] * .... Фактически, если набор столбцов определяется для таблицы как часть оператора CREATE TABLE, все разреженные столбцы, определенные впоследствии, обычно добавляются к нему. Это имеет интересное следствие, что оператор SQL ВЫБРАТЬ * из <имя таблицы> не будет возвращать отдельные разреженные столбцы, а объединит их все в один столбец XML, имя которого совпадает с именем набора столбцов (который, следовательно, действует как виртуальный вычисляемый столбец). Редкие столбцы удобны для бизнес-приложений, таких как информация о продукте, где применимые атрибуты могут сильно варьироваться в зависимости от типа продукта, но где общее количество переменных атрибутов для каждого типа продукта относительно невелико.

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

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

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

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

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

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

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

Одно из ограничений SQL Azure заключается в том, что с января 2015 г. размер физических баз данных ограничен 500 ГБ.^{[Обновить]}.^[36] Microsoft рекомендует разбивать наборы данных большего размера на несколько физических баз данных и обращаться к ним с помощью параллельных запросов.

Смотрите также

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

использованная литература