CC BY
225
УДК 004.652
ЮЛ. Рогозов, АХ. Свиридов, С.А. Кучеров, Ю.А. Жибулис
ПОДХОД К РЕАЛИЗАЦИИ БД СО СТАТИЧЕСКОЙ СТРУКТУРОЙ НА ОСНОВЕ МОДЕЛИ ДАННЫХ EAV
Предлагается подход к реализации структуры базы даны (БД) на основе модели данных Entity-Attribute-Value (EAV). Подход позволяет организовать такую схему БД, которая является неизменной (статической) независимо от состава и структуры хранимых данных, а также устранить недостатки существующих реализаций EAV.
Entity-atribute-value модель; статическая структура БД; FV-ст^ктура.
U.I. Rogozov, A.S. Sviridov, S.A. Kucherov, U.A. Zhibulis
THE APPROACH TO REALIZATION OF STATIC STRUCTURE DB ON THE BASIS OF EAV DATA MODEL
Approach to realization of static structure DB on the basis of EAV data model is offered. The approach allows organizing such DB scheme, which is invariable (static) irrespective of stored data structure and obviating lacks of existing EAV realizations.
Entity-atribute-value model; static DB structure; FV- structure.
. ,
каждая из которых подходит для выполнения определенного круга задач, ограниченного возможностями данной модели по параметрам, определяющим эффективность ее использования. Целью данной статьи является рассмотрение особенно-EAV , -ных динамически изменяется в процессе использования БД, и определение подхода к ее реализации.
Наиболее широко использующаяся на данный момент реляционная модель данных является неэффективной при использовании среды «быстрой» разработки приложений либо создании БД для хранения данных с динамически изменяющей. : сущностей и их атрибутов заранее неизвестен и потенциально велик, но фактическое их количество, используемое в базе данных, сравнительно мало.
В реляционной модели данных отдельная таблица представляет собой от,
. ,
идентична физической структуре, любое изменение структуры хранимых данных влечет за собой переработку как логической, так и физической структуры БД. Это говорит о том, что БД имеет динамическую структуру. Использование динамической структуры требует временных и финансовых затрат на доработку и оптимизацию новой БД и информационной системы (ИС) в целом.
Модель данных EAV. С целью устранения подобной проблемы целесообразно применять модель данных, позволяющую отделить физическую структуру ,
, .
Подобной моделью является модель данных EAV (Entity-Attribute-Value), в основе которой лежит идея создания фиксированного набора таблиц в БД, не изменяемого
. EAV
приводит к отличиям в процессе создания БД (рис. 1).
Отличие в процессе создания БД заключается в следующем:
1. Реляционная модель (^адиционный подход). На первом этапе разработки создается Б-Я-модель данных, отражающая логическую структуру будущей БД. После процесса нормализации производится переход к физической структуре, которая фактически идентична логической. Последним этапом является непосредственная реализация в виде реляционной БД.
2. БАУ-модель. Отличия логического уровня реализации от физического позволяют для конкретной предметной области получить статическую струк-
, .
Достоинства модели данных БАУ, являющиеся также отличительными особенностями данной модели, рассматриваются ниже. Важность достоинств этой модели постоянно подталкивает разработчиков искать подходы к устранению существующих у нее недостатков. В данной статье предлагается один из таких подходов.
I
\
\
а б
Рис. 1. Процесс создания БД
БАУ -
цы, содержащей три столбца [1]:
♦ сущность - внешний ключ в таблицу описания сущности;
♦ атрибут - внешний ключ в таблицу описания атрибутов;
♦ значение - значение атрибута для конкретной связки сущность-атрибут. Из этого видно, что в отличие от реляционных баз данных, где для каждого
атрибута существует отдельная колонка, ряды в которой хранят множество харак-, БАУ - -
, , БАУ
.
БАУ .
пользователь взаимодействует с системой в терминах логической схемы, а не фи, , , -
дели. Фактически метаданные используются для настройки поведения системы.
БАУ . -
венной подсхеме в пределах базы данных: внешние ключи в таблицах данных
ссылаются на таблицы в пределах этой подсхемы. Поскольку бизнес-логика находится в метаданных, а не явно в схеме базы данных, то она менее очевидна для , .
Из особенностей модели данных EAV вытекают следующие достоинства [1]:
♦ гиб кость. Нет никаких ограничений для числа атрибутов у сущности. Число атрибутов может расти, поскольку база данных развивается без модернизации схемы;
пространственно-эффективное хранение для разреженных данных: Нет необходимости единожды резервировать место для атрибутов, значения которых являются пустыми;
формат физических данных с частичным самоописанием данных;
. -тему для поиска информации о любом интересующем объекте без предварительного указания категории, к которой он относится.
EAV -
ных и применяемыми подходами к ее реализации. В отличие от реляционной мо-EAV , -
ных, который требует дополнительных операций преобразования. На рис. 2 показан способ реализации EAV на примере ИС Trial DB [2].
♦
♦
♦
Рис. 2. Упрощенная схема Trial DB
В результате анализа приведенной схемы можно выделить следующие недостатки БАУ [3]:
♦ структурная сл ожность запросов. В отличие от реляционных БД, при вы, БАУ- ,
по одной сущности необходимо работать с тремя и более таблицами: таблицей описания сущности, таблицей описания атрибута, таблицей
.
данных и таблицами метаданных. Структурная сложность запросов также повышает трудоемкость процесса их построения;
♦ быстродействие операций с данными. Во-первых, для представления данных в привычной для восприятия пользователем колоночной форме необходимо выполнить операцию «поворота» - преобразования данных из строк, в виде которых они хранятся в EAV, в столбцы и склеивание данных столбцов; во-вторых, каждый новый запрос к данным необходи-. -, .
EAV
обладает еще одним существенным недостатком: она обеспечивает статичность только на уровне атрибутов сущностей. На изменение структуры БД не влияет только изменение набора атрибутов, а набор сущностей является фиксированным, заранее определяется предметной областью, и его изменение влечет изменение .
Задачей подхода к реализации, описываемого ниже, является создание такой ,
, ,
EAV.
Подход к реализации статической структуры на основе EAV-модели
данных. Подход предусм атривает хранение, представление данных в виде совокупности сущностей и их атрибутов в виде фактов (Fact), которые характеризуются значениями (Value). Структура БД в таком случае носит имя Fact-Value (FV).
FV- , ,
на рис. 3.
Данные
Рис. 3. FV-структура БД
БУ-структуру можно условно разделить на две части: данные и метаданные. В области данных хранятся непосредственно значения фактов, причем количество таблиц соответствует количеству используемых типов данных. Метаданные, описывающие данные и определяющие логику их хранения, представлены в виде трех таблиц:
1. Иерархический справочник. Содержит информацию о хранимых данных (имена атрибутов и сущностей, краткие описания и т.д.). Так же посредством этой таблицы определяются типы данных для конкретного атрибута, осуществляется иерархия вида «страна - город - улица - дом».
2. Справочник атрибутов сущностей. Сохранение связи между сущностью и
.
3. Факт. Организация связи Факт-Значение.
БУ-структура позволяет строго ограничить количество таблиц в БД на уровне трех таблиц метаданных и нескольких таблиц данных (5-7 таблиц), что позволяет независимо от количества хранимых сущностей и атрибутов ограничить структурную сложность запроса, повышая тем самым производительность системы, - чем меньше количество таблиц, с которыми работает запрос на выборку данных, тем меньше время его работы. Наличие хранимых процедур, осуществляющих выпол-
( , , ), -печивает БУ-структура, также повышает производительность работы БД за счет отсутствия необходимости компилировать каждый запрос. Вместо этого для выборки данных из БД используется передача параметров хранимым процедурам.
Обобщим отличия реализации БД на основе ЕАУ-модели данных и БУ-структуры (табл. 1).
1
Отличия ЕУ-структуры от ЕАУ
Особенность ЕАУ БУ-структура
Структура данных При изменении набора атрибутов структура БД не изменяется. При изменении набора сущностей структуры БД меняется При изменении набора атрибутов структура БД не изменяется. При изменении набора сущностей структуры БД не меняется
Скорость работы Компиляция каждого запроса в процессе выборки данных Однократная компиляция хранимых процедур
Структура запроса Запрос с объединением нескольких таблиц для выборки данных по одной сущности Вызов хранимых процедур и передача им параметров, по которым необходима выборка
Таким образом, применяя на физическом уровне (см. рис. 1,6) FV-структуру,
EAV, -
биться статичности структуры БД в процессе эксплуатации и эволюции ИС.
FV- -
граммного средства «Примиус» [4,5]. По экспертным оценкам, в результате про-FV- -
ботки ИС в 2-4 раза, а также повышения производительности БД в 3-5 раз по
EAV.
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Prakash Nadkarni. «An Introduction to Entity-Attribute-Value Design for Generic Clinical Study Data Management Systems» // Center for Medical Informatics, Yale University Medical School, New Haven, CT.
2. Cynthia Brandt, Prakash Nadkarni. «Temporal query of attribute-value patient data: utilizing the constraints of clinical studies Aniruddha M. Deshpande» // International Journal of Medical Informatics. - 2003. - № 70.
3. Jacob Anh0j. «Generic Design of Web-Based Clinical Databases» // Journal of Medical Internet Research, 2004.
4. . ., . ., . . .
- // -
тропика, автоматизация, управление. - 2008. - № 1 (82).
5. . ., . ., . . .
// -
управляющие системы. - 2008. - Т. 6. - № 3.
Рогозов Юрий Иванович
Технологический институт Федерального государственного образовательного учреждения высшего профессионального образования «Южный федеральный университет» в г. Таганроге.
E-mail: rogozov@tsure.ru.
347928, г. Таганрог, пер. Некрасовский, 44.
Тел.: 88634371787.
Свиридов Александр Славьевич E-mail: sviridov@tsure.ru.
Тел.: 88634371787.
Кучеров Сергей Александрович
E-mail: sergey. kutcherov@gmail.com.
Тел.: 89281922577.
Жибулис Юрий Алексеевич E-mail: sharkru@mail.ru.
Тел.: 88634371787.
Rogozov Jury Ivanovich
Taganrog Institute of Technology - Federal State-Owned Educational Establishment of Higher Vocational Education “Southern Federal University”.
E-mail: rogozov@tsure.ru.
44, Nekrasovskiy, Taganrog, 347928, Russia.
Phone: 88634371787.
Sviridov Alexander Slavevich
E-mail: sviridov@tsure.ru.
Phone: 88634371787.
Kucherov Sergey Alexandrovich
E-mail: sergey.kutcherov@gmail.com.
Phone: 89281922577.
Gibulis Jury Alekseevich E-mail: sharkru@mail.ru.
Phone: 88634371787.
УДК 681.322
ДА. Белоглазое, ИХ. Коберси, В.И. Финаев СИНТЕЗ НЕЧЕТКИХ РЕГУЛЯТОРОВ
Рассматриваются особенности построения регуляторов для априори неопределенных объектов управления, показаны алгоритмы нечеткого вывода с примерами их реализации в среде Ыа11аЪ.
Неопределенность параметров; нечеткая логика; регулятор; алгоритмы.
