Архитектор
0,0
рейтинг
16 мая 2011 в 00:49

Разработка → Применение метамодели при проектировании баз данных с несколькими абстрактными слоями

SQL*
Классический подход предусматривает разработку структур баз данных, где все сущности информационной модели находятся на одном абстрактном уровне, являются однородными. Однако, сложные и слабо-структурированные предметные области приводят реляционную декомпозицию к комбинаторному взрыву, непропорциональному росту количества таблиц и связей. А динамические предметные области, в которых ежедневные изменения являются нормой жизненного цикла, требуют постоянного реинженеринга структуры реляционной базы данных.

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

(рис. 1)

Для простоты объяснений возьмем предметную область, понятную каждому (см. рис. 1). Желтым цветом обозначены сущности, а зеленым – перекрестные связи между ними (многие-ко-многим). Имеем две иерархии, организационная: компания, подразделение, отдел (мы можем расширить ее в дальнейшем, вводя новые уровни иерархии). А вторая иерархия классифицирует деятельность: отрасль, направление, специализация (ее мы тоже можем расширять). Но для упрощения мы ограничимся тремя звеньями в каждой иерархии, и уже при такой ограниченной информационной модели выявим необходимость в поднятии уровня абстракции.

Идеалистичная модель предметной области показана на рис. 1, однако, на практике, может оказаться, что специализации нужно привязывать не только к отделам, но и к подразделениям или даже к компаниям (в разных организациях это по-разному, структура крайне динамична и не стабильна при первоначальной кажущейся простоте). Таким образом, проанализировав и обобщив структуру нескольких десятков компаний, можно прийти к следующей диаграмме (см. рис. 2). Три сущности в одной иерархии могут связываться с тремя сущностями в другой, почти произвольно (всех комбинаций 9), одна связь в данном случае не применяется, и мы можем исключить ее, получив 8 типов связей многие-ко-многим. Ситуация усложняется когда каждая из связей должна иметь еще и несколько групп атрибутов, определяющих параметры количества должностных позиций, требования к сотрудникам, нормы сертификации и оклады (взято для примера, на самом деле информационная модель гораздо сложнее).

(рис. 2)

На рисунке 2 мы видим, что даже ER-диаграмма такой модели становится сложной для понимания, а если каждая из связей получают еще по 3-5 групп параметров, то перекрестных таблиц становится порядка двух-четырех десятков, что вообще сложно отобразить на схеме. Кроме того, создавать программный код и интерфейсы пользователя для работы с базой данных такой сложности становится очень проблематично, а при необходимости вносить в них постоянные изменения, такой программный продукт получает огромную стоимость владения и организационные трудности в сопровождении.

Переход к более высокой степени абстракции позволяет нам выделить сущность высшего порядка “структурное подразделение” или “организационная иерархия”, которая отобразится в структуре базы данных в таблицу с рекурсивной ссылкой (сама на себя; поле обычно называемое ParentId или аналогично). Из такой таблицы мы можем развернуть иерархию, с неограниченной вложенностью. То же происходит и со второй иерархией, мы выделяем сущность более высокого порядка “классификация деятельности” (см. рис. 3). Таким образом, мы сделали свертку связей, превратив 8 отношений “многие-ко-многим” в одно такое отношение. Но в данном случае, при обобщении, была потеряна семантика, а именно: связь между компаниями и специализациями не нужна (в данном примере), а так как компании являются структурными подразделениями в “организационной иерархии”, а специализации входят в “классификацию деятельности”, то по диаграмме на рисунке 3, такая связь возможна. Однако, информационная система, должна запрещать пользователю создавать связь такого типа на логическом уровне, что является аспектом целостности информации и является обязательной функцией СУБД.

(рис. 3)

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

(рис. 4)

При введении параметров связей (даже нескольких групп параметров) мы должны модифицировать структуру рисунка 3, разбив связи на три. Причем, метаданные определяют логические ограничения на установку связей, чтобы отобразить семантику предметной области: каждая компания занимается отраслями и направлениями; подразделения и отделы могут заниматься отраслями, направлениями и специализациями; подразделения и отделы (но не компании) имеют определенные должности; компании и подразделения (но не отделы) направлены на удовлетворение спроса других субьектов рынка, принадлежащих отраслям и направлениям (но не специализациям). Таким образом, например, связь с группой атрибутов “должности” между компанией и специализацией логически запрещена. Перекрестные таблицы базы данных будут содержать только одну группу параметров для нескольких типов связей, как показано на рис. 4.

(рис. 5)

Но возникает вопрос, где хранить атрибуты сущностей? Ведь в таблице “Организационная иерархия” может содержаться только группа атрибутов, общая для всех сущностей низшего порядка абстракции: компания, подразделение, отдел. А все не пересекающиеся атрибуты должны быть вынесены в отдельные таблицы, чтобы не создавать ненормализованную структуру с большим количеством “пустых” ячеек. Таким образом, мы приходим к необходимости иметь несколько таблиц более низкого уровня абстракции в одной базе с нашей иерархической таблицей. А связаны они будут с ней общим (точнее, одинаковым) первичным ключом во всей группе таблиц, объединенных связью “один-к-одному” с таблицей “организационная иерархия”. Такая связь (см. рис. 5) предусматривает наличие записи с соответствующим первичным ключом из “организационной иерархии” только в одной из четырех таблиц. Графическое изображение связи “один-к-одному-из” или “supertype-and-sybtype-discriminator” взята из нотации IDEF1, применяемой в большом количестве CASE-средств разработки информационных моделей баз данных (ErWin, Logic Works, Rational Rose, ER/Studio и д.р.).

(рис. 6)

Описание элементов метамодели (на рис. 6):

Profile – сущность или профиль, является отображением второго порядка объекта предметной области. Профиль имеет сквозной идентификатор, использующийся для ссылок на него в рамках всей информационной системы, однако, для внешних ссылок используется URI.
Template – шаблон, аналог класса в объектной модели с поддержкой множественного наследования и непрямого наследования. Множественное заключается в том, что каждый профиль может наследовать от нескольких шаблонов, а непрямое наследование выражается в возможности прикрепления к шаблонам “табов” – групп свойств, при этом шаблоны могут не наследовать табы друг от друга, а получать табы от любого шаблона другой ветви классификации.
URI – уникальный идентификатор профиля, использующийся для внешних ссылок на объекты предметной области, свойства объектом, связи и методы. URI позволяет адресовать все элементы метамодели и все элементы информационной модели предметной области.
Relation Type – тип связи профилей.
Relation – связь между двумя или более профилями (на втором уровне абстракции) или двумя и более сущностями (на уровне реляционной модели).
Link – ссылка на профиль (сущность), позволяющая включать в связи несколько профилей.
Tab – группа свойств профиля, отображается в реляционную модель в виде таблицы базы данных.
Property – свойство профиля, отображается в реляционную модель, чаще всего, в виде поля базы данных, однако для справочников и классификаторов свойство может отображаться в “foreign key” или же в справочную таблицу и связь “многие-ко-многим” с табом профиля.
Type – тип данных, назначенный атрибуту профиля (сущности).
Method – метод или функция, реализует бизнес-логику профиля.

На втором уровне абстракции модели мы можем прийти к свертке реляционной структуры базы к еще большему обобщению (см. рис. 6). На рисунке мы видим элементы метамодели, где желтый и зеленый цвета, отвечают соответственно за сущности и связи, а группа серых таблиц отвечает за атрибуты сущностей. Такая структура подходит для подавляющего большинства предметных областей в сфере прикладных информационных систем. Это структура метаданных, которая описывает структуру таблиц в более обобщенных категориях, что позволяет программному обеспечению опираться не на структуру базы данных и не на метаданные, а на структуру метамодели, то есть на абстракцию второго порядка. Однако, метамодель не имеет достаточной конкретики для решения прикладных задач и нуждается в детализации, что и происходит на первом абстрактном уровне (см. рис. 4). Таким образом, мы имеем две структуры базы, на разных уровнях абстракции, хранящихся в одной БД параллельно. Связь же между ними происходить по сквозным уникальным идентификаторам, так как, Profile – это есть абстрактная сущность второго порядка, связанная со всеми сущностями первого порядка связью “один-к-одному-из” (или “supertype-and-sybtype-discriminator”, см. рис. 5 и объяснения выше).

Продолжение будет во второй части.

Для обсуждения добавляю еще одну схему, которая будет описана во второй части:


Спасибо за внимание.
Timur Shemsedinov @MarcusAurelius
карма
156,5
рейтинг 0,0
Архитектор
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (58)

  • 0
    Отличная статья, спасибо, буду ждать продолжения.

    Хотелось бы немного технических подробностей. Какие СУБД, какие средства доступа к данным удобнее применять.
    • 0
      Как по мне, особых ограничений нет, разве что СУБД нужна серьезная — MySQL вряд-ли будет нормально работать, много JOIN'ов.
      • 0
        > «много JOIN'ов»
        Необязательно использовать Join'ы. есть другой подход составления запросов
        • 0
          Есть подход при котором запросы можно составить так, данная структура будет нормально работать в MySQL?
  • +1
    Минус такой структуры — это падение производительности, даже на сравнительно простых операциях — даже чтоб получить значение какого-нибудь атрибута объекта потребуется несколько соединений. Потому для реализации нужны мощные СУБД — PostgreSQL, Oracle.
    • 0
      Я так понимаю логичнее иметь в СУБД уровень представлений (VIEW), и к нему уже делать SQL-запросы уровня бизнес-логики. Многие СУБД позволяют делать индексированные VIEW. Firebird, например.
      • +1
        Во-первых, такой уровень представлений резко увеличивает количество работы над БД. Но это еще ладно.

        Хуже то, что индексированные view — это немалая просадка по производительности при добавлении/изменении записи.
        • 0
          1. увеличивает работу над БД но уменьшает работу над клиентом. Хотя вместо VIEWшек возможно, лучше будет использовать динамически генерируемые SELECT'ы

          2. Зато выигрыш в SELECT'ах. Это проблема не вьюшек а индексов вообще. Естественно нужен сбалансированный подход
          • +2
            «увеличивает работу над БД но уменьшает работу над клиентом.»
            Мне показалось, что вся статья о том, как уменьшить работу над БД при сложной предметной области.

            «Хотя вместо VIEWшек возможно, лучше будет использовать динамически генерируемые SELECT'ы»
            Тогда вернемся к тому, с чего начали — повышение требований к СУБД с точки зрения производительности сложных запросов.

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

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

            (Entity-Value, правда, еще сильнее, но это детали)
            • +1
              >>Короче, речь о том, что такая модель заведомо сильнее загружает базу, нежели обычная.
              это верно

              Впрочем, зарплата программиста однозначно превысит расходы на любой мощный сервер в долгосрочной перспективе. А вот если решение тиражируемое, то тут не все так однозначно
            • 0
              А если метамодель и метаданные хранить в объектной базе, а фактические данные держать в реляционной, при этом генеря DDL и SQL из метаданных и метамодели?
              • 0
                … то получится современный ORM с миграциями, только маппинг лежит в БД. И на миграциях вы убьетесь.
          • 0
            За годы разработки прикладных систем у меня сложилось устойчивое мнение, которое конечно может оказаться неверным, что надо наоборот уменьшать работу над БД, ибо это приводит к использованию стыка технологий (SQL -> C# (Java)) намного чаще, что влечет к ошибкам переключения между этими двумя контекстами.

            Если же избавить прикладного программиста от рутинной работы с БД, то это будет качественный скачок в разработке.
            • 0
              Я в целом поддерживаю, с точки зрения дизайна ПО, SQL-запросы конечно портят всю картину.
              Однако, с точки зрения производительности куда ж без работы с БД? По специфике моей работы, наши продукты разворачивают порой на весьма убогом железе, где производительность СУБД является уже решающим фактором.
            • +1
              Это часто приводит к тому, что многие программисты просто не умеют использовать даже половины возможностей СУБД считая ее «тупым» хранилищем, из-за чего при работе с более-менее серьезными объемами данных приложения нещадно тормозят. В приложениях, которые ориентированы на работу с данными нужно очень внимательно относится к СУБД и стараться использовать их возможности по максимуму, хотя, естественно, такие решения менее универсальны, но как говорит один мой знакомый: «чем круглее кирпич, тем сложнее из него строить дома».
          • +1
            Существует подход, когда данная система используется только на периоде разработки, например, базы данных. А затем полученная схема «выгружается» в традиционную модель данных. Таким образом, получаем гибкость на периоде разработки и хорошую производительность в итоге. Но в данном случае, насколько я понимаю, речь идет о модели более близкой к т.н. Технологии Активных Объектов (отечественные разработки) и Active Object Modeling (зарубежной), ориентированных на быстро меняющийся бизнес.
            • 0
              >>Существует подход, когда данная система используется только на периоде разработки, например, базы данных

              очень интересная идея, как-то сам не догадался
            • 0
              Ну статические предметные области, для которых разработаны известные подходы уже не вызывают сложностей. Более того, классика встречается все реже, т.к. мир меняется более динамично и приходится или руками переделывать все время (что и происходит с общепринятыми подходами) или же придумывать новый тип автоматизации разработки, мне видится, что для БД — это должен быть путь введения метамоделей N-ного уровня (моногомерных абстракций). Это лучше чем реинжениринг всей БД при повышении гибкости.
              • +1
                А вы изучали модели, названия которых приведены в предыдущем комментарии? Просто ваш подход очень напоминает их. По этому поводу существует много статей, в которых описаны области применения, а также проблемы реализации.
                И по поводу статических предметных областей также существует много нерешенных проблем.
    • +1
      Наверно, я не достаточно раскрыл в статье, почему нагрузка не увеличится (или увеличится несущественно): в базу будут одновременно храниться несколько абстрактных слоев, то есть, классическая структура таблиц не поменяется, просто к ней еще добавится параллельно существующая структура с более высокими абстракциями. То есть, если у нас есть «Сотрудники», «Руководители» и «Персоны» — это три разных слоя. Не всякий сотрудник является руководителем, не всякая персона является сотрудником. Если мы хотим работать с сотрудниками, не заботясь о том, руководители они или исполнители, то в запросах будет фигурировать один уровень абстракции, если нам нужно работать с персонами (то есть со всеми физическими лицами) то в запросах будут таблицы более абстрактного слоя. Поэтому, такую штуку можно навернуть сверху почти на любую структуру БД. Единственные изменения, которые я вношу в нижние слои абстракции, это:
      — Во всех таблицах с сущностными будет не отдельный автоинкрементный ID, а сквозной на всю БД
      — Все таблицы, ссылающиеся на сущности любого порядка имеют Foreign Key указывающий на одну и ту же таблицу — на таблицу сущностный.
      Все же остальные связи в БД не меняются, например у справочников и логов, будут свои автоинкрементные Primary Key.
      • 0
        то есть, если у нас есть «Сотрудники», «Руководители» и «Персоны» — это три разных слоя

        Что-то не совсем понятно как это на уровне таблиц реализуется. Т.е. «руководитель» это СОТРУДНИК JOIN специфические_аттрибуты_руководителя?
        • 0
          Там получаются не совсем таблицы в традиционном понимании. Абстрактный подход позволяет укладывать разные струткры данных, не ограничиваясь традиционными реляционными или объектно-реляционными
          • 0
            Я тоже так предполагал по началу, но ТС пишет о том что
            классическая структура таблиц не поменяется, просто к ней еще добавится параллельно существующая структура с более высокими абстракциями

            вот это и не понятно. релизация на уровне таблриц БД интересна. На пальцах, если можно.
            • 0
              На пальцах слишком много получится. Можно посоветовать почитать про Технологию Активных Объектов и Active Object Modeling. Ну и про EAV и универсальную модель данных для более общих подходов.
            • 0
              В конце статьи прикрепил еще схему, где показаны все аспекты моделирования сущностей с использованием метамоделей, которые удалось собрать за последние 10 лет практического применения этих методов. В нижней строке белым помечены блоки, которые реализованы в СУБД, а серым, которых в СУБД нехватает для построения полноценных приложений на основе динамически-интерпретируемых метамоделей.
        • 0
          Каждый слой хранит только свои специфические атрибуты, поэтому у нас получается еще один аспект хранения «группа атрибутов». Группироваться они могут по уровню абстракции, по языку, по периоду валидности, по применению в задачах и еще по многим вещам. Если нам нужно выбрать из базы весь «профиль сущности», то мы делаем несколько независимых SELECT-ов, каждый из них отдает одну или несколько групп. Например экземпляров сущности «Паспорт» может быть несколько для каждого экземпляра «Персона», а вот «личное дело» в отделе кадров одно, а адресов может быть у него много да еще и каждый адрес может быть на нескольких языках. Я думаю JOIN тут не нужны. Лучше всего вынимать это несколькими запросами. Но случаев, когда мы работаем сразу с нескольким уровнями абстракции очень мало, чаще всего прикладная задача требует доступ только к одному аспекту сущности, поэтому SQL-запросы почти не изменятся.
          • 0
            теперь примерно понял, спасибо
  • 0
    Интересная идея, но ведь по сути получается что метамодель — это и есть метаданные структуры базы. Тот же MS SQL Server хранит все эти метаданные, и при желании их можно легко извлечь из базы и получить ту самую метамодель. Далее, анализируя метамодель, система может сама адаптироваться к изменениям.
    • 0
      Фокус в том, чтобы «на лету» менять эти метаданные с минимальными расходами
      • 0
        В таком случае надо писать свой редактор метамодели, который будет удобен и практичен во всех случаях.
        • 0
          Тут нужен скорее интерпретатор или транслятор такой модели. И он будет подходить далеко не для всех случаев. Кроме того, возникает очень много проблем такой реализации. Мы как раз проводим исследования на эту тему: www.interface.ru/home.asp?artId=24052
        • 0
          можно, но редактирование встроенной метамодели БД это очень затратный процесс, если нужно сделать что-то сложнее чем новое поле в таблице. Т.е. это перстройка индексов, перекачка данных между таблицами, генерация значений по-умолчанию и другие неприятные вещи.
    • 0
      СУБД не поддерживает многих аспектов метамодели, об этом будет вторая часть статьи. Например, когда у нас есть связь многие-ко-многим мы не можем по Foregn Key метаданным понять, является ли эта связь: Master-Detail или же это связь со справочником, или же с помощью этой связи построена многоязычность одной и той же сущности или связь представляет нечто другое. Всего типов связей, на которые можно разложить один единственный Many-to-Many есть два десятка, и по типу связи можно многое в приложении построить динамически и гибко. Таким образом метамодель в какой-то части повторяет метаданные в СУБД, а в какой-то части их дополнет или переопределяет.
      • +1
        Согласен про типы связей — это на уровень СУБД не имеет смысла выносить.

        Теория смотрится очень даже неплохо. Но главная загвоздка тут будет в практической реализации анализатора метамодели.
        • 0
          О! У нас в команде уже последние 10 лет все разрабатывается с применением элементов метамодели, но полной реализации пока нет, вот готовим фреймворк в данный момент, будет оупен-соурсным, дам на ознакомление )
          • 0
            на каком языке/фрэймворке?
            • 0
              Ранее это были Delphi и C#, теперь перешли на PHP и Java. Планируется поддержка разных языков, в т.ч. JavaScript+Node.js
          • 0
            Вот про фреймворк очень интересно. Сами в команде тоже готовим нечно подобное, но немного с другой стороны подходим к решению тех же проблем.
            • 0
              Основная идея такая:
              — берем готовую структуру реляционной базы и автоматически экстрактим из нее метаданные
              — доописываем метаданные, которых не хватает, чтобы построить полноценную метамодель
              — таким образом имеем два и более слоя абстракции в базе
              — если нужно менять структуру базы, то имеем специальную админку, где управляем метаданными, а структура в базе модифицируется уже автоматом
              — при передаче данных между системами, передаем данные + часть метамодели, включая струкутру, шаблоны, интерфейсы, поведение
              — часто используем динамическую интерпретацию метамодели, в частности, для динамического построения интерфейсов пользователя и гибкого сетевого взаимодействия
    • 0
      Есть такой продукт ASP.NET Dynamic Data — он как раз использует эти данные из MS SQL Server.
  • 0
    если я правильно понял, разнообразные типы данных (числа, строки и т.п.) будут храниться физически в одной таблице БД? Или делаете несколько хранилищ для разных типов?
    • +1
      В параметрических базах данных все атрибуты сущностей сливают или в одну таблицу или делают по таблице на каждый тип данных. Но это приводит к тому, что таблица-хранилище разрастается, его невозможно эффективно индексировать (в индекс попадают лишние данные) и нарушается реляционный принцип. По сути — все преимущества реляционного подходя теряются, запросы красиво строить уже нельзя, толпы JOIN-ов. Такие БД как раз получаются, как один из видов решения проблемы стыковки объектно-ориентированного программирования и реляционного подхода в СУБД. Но эффективны они только когда данных мало. Если мы имеем миллионы и сотни миллионов записей в таблицах, то тут уже ООП должно прогнуться под СУБД, вплоть до частичного отказа от принципов объектного подхода.
  • 0
    Добавлю еще пару ссылок по теме:
    Статья «Потерянная семантика» — blog.meta-systems.com.ua/2009/11/blog-post.html
    Статья «Интеграция на уровне вызовов или мета-данных?» — blog.meta-systems.com.ua/2009/10/blog-post_18.html
    Статья «Введение мета-уровеня» — blog.meta-systems.com.ua/2011/01/blog-post.html
    Статья «Метамодель в задачах интеграции информационных систем» — blog.meta-systems.com.ua/2010/07/blog-post.html
    Слайд к докладу «Слой ИС с динамической интерпретацией метаданных» — blog.meta-systems.com.ua/2011/01/blog-post_28.html
    И еще ссылки на Хабре:
    Статья «Интеграция информационных систем» — habrahabr.ru/blogs/refactoring/117468/
    • 0
      Мне показалось, что по ссылкам какой-то развод.
  • 0
    Это все очень клево, только не понятно зачем это все надо.


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

    В этом случае помогает очень простая вещь, упрощение предметной области путем выделения в ней специфичных предметных областей и связей между ними. Связи при этом должны быть выбраны так чтобы никоим образом не зависеть от специфичной области. При этом сама специфичная область от таких связей зависеть может. Банальный пример в рамках биллинга «услуга», понятно что услуга телефонной связи и услуга предоставления доступа в интернет обладают специфичными для них атрибутами, но так же у них есть и общие не специфичные. Они выносятся выше, а специфичные уже содержат связи с услугой.
    • +1
      Именно так, обобщение и повышение абстракции модели даже на один уровень, позволяют охватить в 10 раз больше различных предметных областей, отличающихся спецификой. А разработка информационных систем должна сводиться не к количественной эскалации использования паттернов, а к двум параллельным процессам: абстрагирование и индивидуализация. Где абстрагирование — это повышение абстракции, а индивидуалтзация, это реализация специфического функционала уже в рамках абстрактной модели более высокого порядка.
      • 0
        А вот попроще писать ну никак? Особенно вот UML сильно в тему тут. Большей части разработчиков двух уровней более чем за глаза, причем реализуемых при помощи механизма схем.
        • 0
          Это статья не про готовую технологию, а для разработчиков технологий. Когда будет релиз инструмента для разработки прикладных систем, то я его опишу простым языком. Там даже про уровни абстракции ничего не будет сказано, хочется сделать инструмент, приближенный к пользователю и с использованием популярной или бизнес- лексики.
          С такими темпами мы переучим Хабр использовать научную лексику и стиль статей)
          • 0
            Это статья не про готовую технологию, а для разработчиков технологий. Когда будет релиз инструмента для разработки прикладных систем, то я его опишу простым языком. Там даже про уровни абстракции ничего не будет сказано, хочется сделать инструмент, приближенный к пользователю и с использованием популярной или бизнес- лексики.

            Этой затеей уже занимаются не один год куча народу, в том числе и IBM. Пока ничего кроме жирного тормозного монстра мало применимого в реальной жизни никто не сделал. И тут вы на белом коне говорите мы то ух? Что-то мне слабо верится.

            С такими темпами мы переучим Хабр использовать научную лексику и стиль статей)

            Как говорил мой преподаватель математики, если вы не можете объяснить для бабушки грош цена вам как специалисту. Вот в данный момент мне более менее понятно про что статья, но вот зачем даже с учетом замечания о разработчиков технологий не понятно. Конкретных то методик не описано. Как выделять, почему стоит выделять именно так увы не указано.
            • 0
              Будет вторая часть статьи и есть ссылки на другие. Я ж не говорю, что мы так раз и все решили, мы уже более 10 лет понемногу реализуем, натыкаемся на проблемы и ищем решения, даже более эмпирическими методами, нежели логическими. Абсолютного решения не предлагаем, но некоторый пригодный к использованию подход есть.
              • +1
                Главное чтобы в вашей статье второй столько воды как в этой не было. Тут вот большая часть просто не поняла про что все это и зачем. Они нормальную форму Бойса-Кодда не осилили а вы тут им такую инфу да еще в таком тяжелом виде.
            • 0
              Еще по поводу IBM, а именно Lotus/Domino — думаю, что это одна из наиболее удачных и долгоиграющих систем с использованием динамической интерпретации модели. Система уже давно не имеет развития и новых версий более не будет, но на старых продуктах до сих пор решаются прикладные задачи такого уровня, как «современным» технологиям и не снилось. В общем, IBM-у респект.
              • 0
                Еще по поводу IBM, а именно Lotus/Domino — думаю, что это одна из наиболее удачных и долгоиграющих систем с использованием динамической интерпретации модели.

                Lotus/Domino то каким сюда боком? Буквально недавно на opennet публиковали информацию о новой системе IBM основанной на рисовании бизнес-правил. Я вот про нее. А Lotus/Domino все же хотя модель использовала эту была немного не про то. Ну и то что ее поддержку прекратили тоже как бе говорит нам, что не настолько он был удачен.
  • 0
    Классический подход предусматривает разработку структур баз данных, где все сущности информационной модели находятся на одном абстрактном уровне, являются однородными. Однако, сложные и слабо-структурированные предметные области приводят реляционную декомпозицию к комбинаторному взрыву, непропорциональному росту количества таблиц и связей. А динамические предметные области, в которых ежедневные изменения являются нормой жизненного цикла, требуют постоянного реинженеринга структуры реляционной базы данных.

    Реляционная модель является моделью логического уровня. Структуры тут не при чем. Классический подход предполагает, что в реляционной модели отражаются множества логических утверждений (предикатов) касательно фактов из предметной области, выраженные в виде «отношений». Аппарат реляционной алгебры даёт нам возможность комбинировать отношения, получая, таким образом, производные утверждения — в идеале, так же имеющие непустую интерпретацию в предметной области. Причём, РСУБД могут практически мгновенно производить вычисления, включающие миллионы таких предикатов, поэтому они так широко применяются для построения логического уровня приложений. Естественно, что при проектированнии логического уровня, краеугольным камнем является логическая непротиворечивость данных, которая достигается исключением аномалий из отношений с помощью рефакторнормализации.

    Подменив предметную область метамоделью, вы сможете извлекать из базы лишь утверждения касающиеся этой самой метамодели, а не вашей предметной области. Следовательно, лисапедить логический уровень метамодель будет самостоятельно. В общем случае это сложнее, чем кажется на первый взгляд (попробуйте реализовать пресловутый ACID). А в тривиальных — NoSQL в руки. =)
    • 0
      В РСУБД и так лежат метаданные, вопрос только в том, чтоб их дополнить.
      Абстрактную модель второго уровня предлагается хранить в БД параллельно с базовой абстракцией.
      Таким образом, мы полностью используем развитый аппарат реляционной алгебры и на базовом слое и на слое абстракции второго уровня. Связь между слоями предполагается через введение сквозного первичного ключа, общего для той части таблиц, которая представляет сущности.
      Информационная модель в РСУБД содержит, например, атрибуты сущностьей, типы атрибутов, связи сущностьей, и т.д. но такие вещи, как атрибуты связей или группы атрибутов или группы связей и т.д. (см последнюю иллюстрацию в статье) можно реализовать только надстройками.
  • 0
    А где описывается сам выполняемый код для работы с данными — логика приложения? В ней возможны ссылки на системные справочники.
    Например — есть форма заявки на что-либо с несколькими полями. Выбираем значение поля, например, «тип продукта» — и в зависимости от значения другое поле на этой форме становится видимым или нет.
    В нашем текущем проекте это всё тоже метаданные.
    • 0
      Если структура и параметры данных меняются динамически, то бессмысленно компилировать логику приложения и фиксировать ее таким образом. Как я предлагаю в статье про метамодели, можно выделить обобщенную логику (абстрактную модель или метамодель), она привязана не к конкретной задаче, а к широкому классу задач, вот ее нужно компилировать. Но выделенные в ходе абстрагирования метаданные могут содержать не только модификации для структуры и параметров данных, но и модификации для логики, для активного (или императивного) способа обработки, выражаемые в сценариях на динамических языках программирования. Эти самые языки мы можем разрабатывать под задачу и встраивать в свое ПО или брать уже готовые языки (что конечно предпочтительнее). Логика на в этих сценариях не делает системных вызовов, а вот логика в метамодели — может.

      Ваш пример с формой можно решать двумя путями:
      1. Выделить метаданные, а потом задавая и интерпретируя их, менять порядок обработки полей, правила обработки, например можно вынести регулярные выражения для валидации в метаданные, можно вынести декларативные правила валидации, которые управляют порядком проверки и условиями. Это декларативный путь, Вы применяете декларативные метаданные, можно их в JSON или XML передавать, а можно в своей специализированной грамматика.
      2. И второй вариант — активные (императивные) метаданные — сценарии, например на JS, о них я говорил выше.

      Но в общем случае, ни там ни другим не обойдешься, нужны и декларативные и активные метаданные.

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