В последнее время реляционные СУБД незначительно вытесняются системами с альтернативными моделями данных.
Частично это обусловлено целями повышения производительности за счет упрощения структур хранения.
С другой стороны, идет поиск путей расширения выразительных средств, в том числе за счет перехода к более богатым информационным моделям.
Ведь многие поняли, что повышение уровня абстракции предметной области на порядок расширяет сферу применения продукта в десятки раз и возможность занять множество смежных ниш, увеличивая порой количество клиентов на сотни и тысячи.
раз.
Первая часть: http://habrahabr.ru/blogs/sql/119317/ Реляционные, иерархические, сетевые, ключ-значения и т. д. СУБД определяют только модель данных, но мы более свободны в выборе информационной модели (не путать с моделью данных).
В любом случае потребуется декомпозиция и отображение элементов информационной модели в модель данных.
Например, классическая информационная модель IDEF1X состоит из следующих элементов: сущность, атрибут, связь «один-к-одному», связь «один-ко-многим», связь «многие-ко-многим», категоризация (отношения «один-к-одному»).
А реляционная модель данных СУБД имеет только отношения: таблица, поле и связь «один-ко-многим».
Сущность сопоставляется с одной или несколькими таблицами, все типы отношений представляются как один-ко-многим (другого типа в подавляющем большинстве СУБД просто нет), категоризация вводится способом, который я описал в первая часть статьи .
Что вам мешает поднять уровень абстракции? Прежде всего, разработчики вынуждены экспортировать часть информационной модели в приложение .
Это значит исправить эту часть модели, потеряв гибкость настройки под предметную область.
Решение этой проблемы я вижу во внедрении динамически интерпретируемых метамоделей, используемых параллельно с реляционным или другим хранилищем.
Метамодели снижают неопределенность в описании предметной области и позволяют убрать «места крепления» и избавиться от жесткой фиксации на специфике задач.
Я постарался собрать большую часть компонентов информационного моделирования, необходимых при разработке прикладных приложений.
В конце первой части была схема: 
Сейчас я объясню это более подробно.
В нижней строке диаграммы белым показаны компоненты, присутствующие в реляционной модели данных, а серым — компоненты, требующие декомпозиции или метаописания для размещения в СУБД.
Давайте рассмотрим их подробнее: Группировки сущностей Первое, чего часто не хватает, — это возможность объединять сущности предметной области в группы.
Приложение : сущности по своей природе не могут быть однородными, они принадлежат разным уровням абстракции одной предметной области или разным предметным областям, обслуживаемым одной базой данных, либо мы хотим выделить несколько кластеров/зон в предметной области.
Решения: использование префиксов в именах таблиц, раскрашивание структур базы данных в разные цвета, но чаще всего о группах «знает» программное обеспечение, работающее с базой данных, группировки «зашиты» в код и модель без кода не полная .
Группы атрибутов Кажется естественным группировать атрибуты сущностей в семантические блоки, которые связаны функционально, семантически или связаны с различными аспектами моделирования сущностей.
Приложение : Например, может быть удобно сгруппировать поля, связанные с адресом (страна, город, улица, дом, почтовый индекс и т. д.) или два поля описывают один атрибут (поскольку широта и долгота описывают атрибут «Координата»).
Решения: введение префиксов в имена полей, перечисление полей по порядку, но по сути этот аспект информационной модели «зашит» в пользовательский интерфейс и мы видим, что модель не обходится без интерфейса .
Группировки ссылок Связи между таблицами не всегда именуются, поэтому группировка связей по имени практически не встречается, но есть задачи, для которых это крайне необходимо.
Приложение : пример №1 — люди связаны «многие ко многим» через перекрестную таблицу, и нам нужно выделить некоторые связи как «родственные», а некоторые как «дружественные» или «рабочие».
Существует еще один распространенный случай (пример № 2) группировок, когда имеется несколько перекрестных таблиц «многие ко многим», и нам необходимо сгруппировать владельцев транспортных средств, владельцев недвижимости и владельцев домашних животных в несколько групп: бывшие владельцы, нынешние владельцы и лица, оспаривающие право собственности.
.
Решения: для случая №1 — просто введите флаг в кросс-таблице или добавьте каталог групп ссылок.
Для случая №2 — конечно можно вводить одни и те же флаги и каталоги для разных таблиц, но тогда хотелось бы выбрать всех «текущих владельцев» одним запросом.
Для этого мы можем применить абстрактную «свертку», как описано в первая часть .
Атрибуты и типы группировок Каждая из вышеперечисленных группировок может иметь свои признаки и типы, это кажется вполне естественным.
И для разных групп есть множество примеров и способов реализации.
Атрибуты ссылки Связи между сущностями далеко не однородны и уж точно не бинарные.
Возможно, нам потребуется прикрепить к ссылкам дату создания, силу ссылки или коэффициент достоверности информации, источник информации или пользователя (владельца ссылки) и другие атрибуты.
Приложение : Например, связь между специалистом и должностью может включать дату вступления в должность и назначенную зарплату.
Решения: Для описания атрибутов ссылок мы обычно используем поля таблиц, описывающие сами сущности, или поля таблиц ссылок.
То есть приложение будет «знать» и «отличать» по названию поля, где атрибут сущности, а где атрибут соединения.
Атрибут Атрибуты Такая тавтология, но не такой бред, если вдуматься, то во многих предметных областях атрибут сущности может иметь целый ряд собственных атрибутов.
Приложение : например, показания датчика можно дополнить оценкой погрешности, единицами изменения, временем считывания и ссылкой на сотрудника, который внес изменение или ввел данные в систему.
Решения: Обычно у них просто два, три и более полей в одной таблице, и на уровне пользовательского интерфейса или приложения уже подразумевается, что одно поле является атрибутом другого.
Типы ссылок Наиболее важным, на мой взгляд, компонентом информационной модели является тип связи между сущностями.
Именно эта характеристика чаще всего «зашита» в приложение и пользовательский интерфейс, а иногда вообще нигде явно не определена и обрабатывается непосредственно пользователем, отводя его внимание.
Приложение : выделим несколько типов (не полный список): один-к-одному, многие-ко-многим, соединение со справочником, соединение типа «Мастер-Деталь», соединение типа «контейнер» и т.д. Решения: связь с каталогом может быть реализована в пользовательском интерфейсе в виде поля со списком или автоинкрементного поля ввода; Master-Detail можно реализовать с помощью всплывающих окон, нескольких сеток, древовидной сетки или поля со списком и сетки и многими другими способами.
В зависимости от того, «какой» это «Мастер-Деталь», например, можно вывести журнал, сгруппированный по дате, купленным товарам или слабым связям – например, данные о людях, проживающих в гостиничных номерах.
Если мы сравним связь «гостиницы» и «номера» со связью «номера» и «гостей», то заметим, что номера являются неотъемлемой частью отеля, но связь с гостями – это более «мягкие», хотя и то, и другое можно назвать «Мастер-Деталь».
А вообще, про классификацию связей можно написать отдельную статью, приведя примеры структур БД и экранов приложений.
Таким образом, мы имеем целый ряд элементов информационной модели, которые размещаются в приложениях, интерфейсах, шаблонах, по сути являясь частью модели.
Именно для того, чтобы отделить их от чисто программных и системных решений, нужен слой метамодели.
В этом случае СУБД используется как физическое хранилище двух уровней абстракции: данных и метамодели.
Динамическая интерпретация метамодели во время выполнения приложения позволяет связать несколько уровней абстракции в единое целое.
В третьей части я планирую рассмотреть примеры использования метамодели в прикладных задачах.
Спасибо за внимание.
Теги: #база данных #dbms #rdbms #базы данных #реляционные базы данных #метаданные #метамодель #абстракция #sql
-
Как Эффективно Управлять Erp-Проектом
19 Oct, 24 -
Меррифилд, Роберт Брюс
19 Oct, 24 -
Очередь Авторской Книги
19 Oct, 24 -
Впф 4.0. Что Нового? Часть 5
19 Oct, 24 -
Новые Глифы Или Иероглифы Будущего
19 Oct, 24 -
Из Html В Pdf – Легко! Обзор Конвертера
19 Oct, 24 -
Итоги Акции «Береги Свои Глаза С Малых Лет»
19 Oct, 24 -
Невский Экспресс – Терроризм Или Халатность?
19 Oct, 24
