Классический подход предполагает разработку структур базы данных, где все объекты информационной модели находятся на одном абстрактном уровне и однородны.
Однако сложные и слабо структурированные предметные области приводят реляционную декомпозицию к комбинаторному взрыву, непропорциональному увеличению количества таблиц и связей.
А динамичные предметные области, в которых ежедневные изменения являются нормой жизненного цикла, требуют постоянного реинжиниринга структуры реляционной базы данных.
В таких условиях повышение уровня абстракции может лишь частично решить проблему, поскольку при переходе от конкретики к абстрактной модели теряется специфика предметной области.
Следовательно, вам необходимо хранить два логически связанных уровня абстракции в одной базе данных.
Логическую связь должен осуществлять метауровень, определяющий параметры взаимно однозначного отображения одного абстрактного слоя модели на другой.
(Рисунок 1)
Для простоты объяснения возьмем понятную каждому предметную область (см.
рис.
1).
Сущности обозначены желтым цветом, а перекрестные связи между ними (многие ко многим) — зеленым.
У нас есть две иерархии, организационные: компания, подразделение, отдел (в будущем мы можем ее расширить, вводя новые уровни иерархии).
А вторая иерархия классифицирует виды деятельности: отрасль, направление, специализация (это тоже можно расширить).
Но для простоты ограничимся тремя звеньями в каждой иерархии и даже при такой ограниченной информационной модели выявим необходимость повышения уровня абстракции.
Идеалистическая модель предметной области представлена на рис.
1, однако на практике может оказаться, что специализации нужно привязывать не только к отделам, но и к подразделениям или даже к компаниям (в разных организациях это разное; структура чрезвычайно динамичен и неустойчив, несмотря на свою первоначальную кажущуюся простоту).
Таким образом, проанализировав и обобщив структуру нескольких десятков компаний, можно прийти к следующей диаграмме (см.
рис.
2).
Три сущности в одной иерархии могут быть связаны с тремя сущностями в другой почти произвольно (всего существует 9 комбинаций), одно отношение в данном случае не применимо, и мы можем его исключить, в результате получается 8 типов «многие-ко-многим».
отношения.
Ситуация усложняется, когда каждое из связей должно иметь еще и несколько групп атрибутов, определяющих параметры количества должностей, требования к сотрудникам, стандарты сертификации и заработной платы (на примере, в действительности информационная модель гораздо больше сложный).
(рис.
2) На рисунке 2 мы видим, что даже ER-диаграмма такой модели становится трудной для понимания, а если каждое из связей получает еще 3-5 групп параметров, то кросс-таблиц становится около двух-четырех десятков, что вообще затруднительно.
для отображения на схеме.
Кроме того, создание программного кода и пользовательских интерфейсов для работы с базой данных такой сложности становится весьма проблематичным, а при необходимости вносить в них постоянные изменения такой программный продукт влечет за собой огромную стоимость владения и организационные трудности при его сопровождении.
Переход на более высокую степень абстракции позволяет нам изолировать сущность более высокого порядка «структурную единицу» или «организационную иерархию», которая будет отображаться в структуре базы данных в таблицу с рекурсивной ссылкой (на самого себя; поле обычно называется ParentId или похожий).
Из такой таблицы мы можем расширить иерархию с неограниченной вложенностью.
То же самое происходит и со второй иерархией; выделим суть «классификации видов деятельности» более высокого порядка (см.
рис.
3).
Таким образом, мы сделали свертку отношений, превратив 8 отношений «многие-ко-многим» в одно такое отношение.
Но в данном случае при обобщении была потеряна семантика, а именно: связь между компаниями и специализациями не нужна (в данном примере), а поскольку компании являются структурными подразделениями в «организационной иерархии», а специализации входят в «организационную иерархию», а специализации входят в «организационную иерархию».
классификация видов деятельности», то согласно схеме на рисунке 3 такая связь возможна.
Однако информационная система должна запретить пользователю создание такого типа соединения на логическом уровне, что является аспектом целостности информации и является обязательной функцией СУБД.
(рис.
3) Логический уровень обеспечивается метамоделью предметной области и динамически интерпретируется на уровне приложения, что придает системе дополнительную гибкость, поскольку логику предметной области можно изменять без изменения программного кода.
Чтобы разрешить или запретить определенный вид коммуникации на логическом уровне, достаточно просто указать это в формальных терминах метамодели.
(рис.
4) При введении параметров соединения (даже нескольких групп параметров) необходимо видоизменить структуру рисунка 3, разделив соединения на три.
Более того, метаданные определяют логические ограничения на установление связей с целью отображения семантики предметной области: каждая компания занимается отраслями и направлениями; подразделения и департаменты могут заниматься отраслями, областями и специализациями; подразделения и департаменты (но не компании) имеют определенные должности; компании и подразделения (но не ведомства) нацелены на удовлетворение спроса других субъектов рынка, принадлежащих к отраслям и направлениям (но не специализациям).
Так, например, логически запрещена связь по группе атрибутов «должность» между компанией и специализацией.
Кросс-таблицы базы данных будут содержать только одну группу параметров для нескольких типов отношений, как показано на рисунке.
4. 
(рис.
5) Но возникает вопрос, где хранить атрибуты сущности? Ведь таблица «Организационная иерархия» может содержать только группу атрибутов, общих для всех сущностей более низкого порядка абстракции: компании, подразделения, отдела.
А все непересекающиеся атрибуты следует размещать в отдельных таблицах, чтобы не создавать ненормализованную структуру с большим количеством «пустых» ячеек.
Таким образом, мы приходим к необходимости иметь в одной базе данных с нашей иерархической таблицей несколько таблиц более низкого уровня абстракции.
И они будут связаны с ней общим (точнее, идентичным) первичным ключом во всей группе таблиц, объединенных отношением один к одному с таблицей «организационная иерархия».
Такая связь (см.
рис.
5) предусматривает наличие записи с соответствующим первичным ключом из «организационной иерархии» только в одной из четырех таблиц.
Графическое представление отношений «один к одному» или «дискриминатор супертипа и сибтипа» взято из нотации IDEF1, используемой в большом количестве CASE-инструментов для разработки информационных моделей баз данных (ErWin, Logic Works, Rational Rose, ER/Studio и т. д.).
(рис.
6) Описание элементов метамодели (на рис.
6): Профиль – сущность или профиль – отображение второго порядка объекта предметной области.
Профиль имеет сквозной идентификатор, который используется для ссылки на него во всей информационной системе; однако URI используется для внешних ссылок.
Шаблон — шаблон, аналог класса в объектной модели с поддержкой множественного и непрямого наследования.
Множественность заключается в том, что каждый профиль может наследовать от нескольких шаблонов, а косвенное наследование выражается в возможности прикрепления к шаблонам «вкладок» — групп свойств, при этом шаблоны могут не наследовать вкладки друг от друга, а получать вкладки из любой шаблон другой ветки классификации.
URI – уникальный идентификатор профиля, используемый для внешних ссылок на объекты предметной области, свойства объектов, соединения и методы.
URI позволяет обращаться ко всем элементам метамодели и всем элементам информационной модели предметной области.
Тип отношения – тип соединения профиля.
Связь – связь между двумя или более профилями (на втором уровне абстракции) или двумя или более сущностями (на уровне реляционной модели).
Связь — ссылка на профиль (сущность), позволяющая включить в связь несколько профилей.
Вкладка – группа свойств профиля, отображаемых в реляционной модели в виде таблицы базы данных.
Свойство – свойство профиля, отображается в реляционной модели, чаще всего, в виде поля базы данных, однако для справочников и классификаторов свойство может отображаться во «внешнем ключе» или в справочной таблице и «множестве» -ко-многим» на вкладке профиля.
Тип – тип данных, присвоенный атрибуту профиля (сущности).
Метод – метод или функция, реализующая бизнес-логику профиля.
На втором уровне абстракции модели мы можем прийти к развалу реляционной структуры базы к еще большему обобщению (см.
рис.
6).
На рисунке мы видим элементы метамодели, где желтый и зеленый цвета отвечают за сущности и связи соответственно, а группа серых таблиц отвечает за атрибуты сущностей.
Данная структура подходит для подавляющего большинства предметных областей в области прикладных информационных систем.
Это структура метаданных, описывающая структуру таблиц в более общих категориях, что позволяет программному обеспечению опираться не на структуру базы данных или метаданные, а на структуру метамодели, то есть на абстракцию второго порядка.
Однако метамодель не обладает достаточной специфичностью для решения прикладных задач и нуждается в детализации, что и происходит на первом абстрактном уровне (см.
рис.
4).
Таким образом, у нас есть две структуры базы данных на разных уровнях абстракции, хранящиеся в одной базе данных параллельно.
Связь между ними происходит посредством сквозных уникальных идентификаторов, поскольку Профиль — это абстрактная сущность второго порядка, связанная со всеми сущностями первого порядка отношением «один-к-одному» (или «супертип-и-сибтип»).
-дискриминатор», см.
рис.
5 и пояснения выше).
Продолжение во второй части.
Для обсуждения добавляю еще одну схему, которая будет описана во второй части: 
Спасибо за внимание.
Теги: #база данных #dbms #базы данных #реляционные базы данных #метаданные #метамодель #абстракция #sql
-
Устранение Неисправностей Microsoft Word
19 Oct, 24 -
А Теперь Обещанное Задание Посложнее
19 Oct, 24 -
Что Может Пойти Не Так В Игровом Дизайне
19 Oct, 24 -
Блог На Node.js
19 Oct, 24 -
Матрикснет В Рекламной Сети Яндекса
19 Oct, 24
