Тарасов С. В. СУБД для программиста. Базы данных изнутри

Рис. 2. Организация связей между типами записей в сетевой модели

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

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

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

31

сводится лишь к поиску соответствующего значения первичного ключа, но и её можно принудительно отключать, например, в случае массированной загрузки данных.

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

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

Сетевая модель: плюсы и минусы

К преимуществам сетевой модели можно отнести следующие особенности:

стандартизация. Стандарт CODASYL определяет базовые понятия модели и формальный язык описания.

быстродействие сетевых БД данных сравнимо с таковым для иерархических БД.

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

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

Онедостатках уже было упомянуто:

жёсткость задаваемых структур и сложность реструктуризации схем БД.

32

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

Реляционная модель

Теоретические основы реляционной модели многократно и полно изложены в различных монографиях, книгах и статьях [1,2,4,11], поэтому в рамках данной главы ограничимся лишь минимальными описаниями. В дальнейшем мы будем расширять их, опираясь на практическую нужду.

Как и положено доминирующей на протяжении десятков лет массово внедрённойпарадигме, реляционнаямодельимеетсвойосновополагающий миф. Речь, конечно, идёт об известной работе Эдгара Кодда «Реляционная модель данных для больших совместно используемых банков данных»[17], опубликованной в CACM10 в 1970 году. «Да будет свет!» — сказал Кодд, и появился свет, и начали рождаться реляционные СУБД.

На самом деле, Кодд опирался на существовавшую и проработанную в рамках математической логики ещё в 19 веке теорию отношений [2,12]. В рамках этой теории было показано, что множество отношений замкнуто относительно некоторых специальных операций, то есть образует вместе с этими операциями абстрактную алгебру. В упрощённой формулировке это означает, что все возможные результаты операций над элементами множества отношений также являются отношениями.

Кроме того, Кодд начал свои публикации раньше, в 1969 году,

исследовательским отчётом «Derivability, Redundency, and Consistency of Relations Stored in Large Data Banks» в среде ограниченного круга подписчиков. В дальнейшем концепция эволюционировала, известный эксперт в области СУБД Майкл Стоунбрейкер отмечал [18], что «можно видеть четыре разных версии» модели:

версия 1, та самая упомянутая, составляющая основу отраслевого мифа, опубликована в статье в CACM в 1970 г.;

10CACM - Communications of the ACM, ежемесячный журнал сообществаAssociation for Computing Machinery (ACM), основанный в 1957 году.

33

версия 2, определена в статье по поводу Тьюринговской премии в

1981 г.;

версия 3, доопределена «дюжиной Кодда» — двенадцатью правилами и оценочной системой в 1985 году [19,20];

версия4, определенавопубликованнойв1990 году книгеКодда[21].

Из сказанного Стоунбрейкером становится понятным, что Кодд, как и положено учёному, в течение десятилетий продолжал исследования, пересматривая свои подходы и концепции. И полнота реализации теории в промышленных СУБД волновала её автора в меньшей степени, потому что «дюжина Кодда» до сих пор является актуальной для оценки соответствия, а последние стандарты SQL полностью не реализованы ни в одном продукте.

Таким образом, начиная изучать предмет данной главы, необходимо принять к сведению, что существуют два мира с условными названиями

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

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

Что же представляет собой отношение с более формальной точки зрения? Обратимся к первоисточнику [17].

34

Термин отношение используется в его общепринятом математическом смысле. Для заданных множеств S1, S2, ..., Sn (не обязательно различных) R является отношением на этих n множествах, если представляет собой множество кортежей степени n, у каждого из которых первый элемент взят из множества S1, второй — из множества S2 и т.д. Мы будем называть Sj j- тым доменом R. Говорят, что такое отношение R имеет степень n. Отношения степени 1 часто называют унарными, степени 2 — бинарными, степени 3 — тернарными и степени n — n-арными.

Для лучшего понимания столь лаконичного определения воспользуемся его графической интерпретацией.

Рис. 3. Отношение, как множество кортежей, заданных на доменах

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

35

Реляционная модель: плюсы и минусы

К преимуществам реляционной модели можно отнести следующие особенности:

теоретическая основа. Формально определяет базовые понятия модели, язык описания и операции над отношениями;

стандартизация. Стандарты SQL-NN (SQL-89, SQL-92, SQL-99 и

т. д.), имеющие несколько уровней полноты реализации, позволяют создавать приложения, переносимые между СУБД разных поставщиков;

полное разделение доступа к данным от способа их физической организации;

универсальность. Информационное моделирование сущностей реальногомираввиденаборасвязанныхтаблицявляетсядостаточно хорошим подходом в большинстве случаев;

простота манипуляции данными с точки зрения конечного пользователя;

SQL — развитый стандартизованный декларативный язык 4-го поколения.

Недостатки:

в общем случае, более низкое быстродействие по сравнению с сетевыми и иерархическими СУБД или другими подходами, обеспечивающими доступ к данным непосредственно на уровне их физической организации, например, индексированные файлы;

неполнота реализации стандартов SQL-NN, а также специфические языковые и процедурные расширения СУБД разных поставщиков, осложняющие переносимость приложений (так называемый vendor lock);

необходимость учёта некоторых особенностей модели на концептуальном уровне (ключи — идентификаторы сущностей), отсутствующая, например, в сетевой модели.

36

Другие подходы и модели данных

Модель «Сущность-атрибут-значение» (EAV)

В англоязычной терминологии модель САЗ (Сущность-Атрибут- Значение) носит название EAV (Entity-Atribute-Value). В русскоязычном сообществе разработчиков приложений баз данных подход обсуждался в 1990-х годах как «вертикальное хранение атрибутов», в противовес реляционной модели, где атрибуты располагаются горизонтально.

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

столбец «Сущность». Содержит уникальный идентификатор сущности. Также может представлять собой пару (идентификатор, временная метка) для отражения хронологии событий и фактов;

столбец «Атрибут». Название свойства сущности, как правило — ссылка (короткий идентификатор) на таблицу атрибутов в метаданных;

столбец «Значение». Непосредственно значение атрибута.

Использование реляционной терминологии «таблица» и «столбец» для описания модели САЗ вызвана, во-первых, стереотипом наиболее понятным для большинства разработчиков, во-вторых, тем фактом, что вертикальное хранение в большинстве известных автору случаев было реализовано средствами реляционной СУБД.

На самом деле не столь важно, сгруппированы ли тройки САЗ в длинную таблицу, или же речь идёт о записях, объединённых в двунаправленный список. Все они суть способы представления разреженной матрицы САЗ, столбцы которой представляют собой все определённые в системе атрибуты, строки — все имеющиеся сущности, а на пересечении строки и столбца находится соответствующее значение, если оно имеется.

37

Рис. 4. Представление САЗ в виде таблицы

Рис. 5. Матрица САЗ является разреженной

Немного углубясь в историю, можно обнаружить гораздо более древний и широко известный в классическом программировании подход ассоциативных массивов, состоящих из пар «ключ-значение». Этот путь прямиком приводит нас в 1960-е годы к языку Лисп. Базы данных, использующие такой поход, применялись ещё до эпохи массового распространения реляционных СУБД. Только и разница, что теперь вместо простого ключа используется составной. Записывали раньше в массив пару («Товар№795/Наименование», «Мука пшеничная в/с»), теперь же ключом ассоциативного списка становится пара атрибутов, а в программе оперируем уже тройками.

38

Развивая подход, получаем современные многомерные кубы, где ключом является набор величин, а значением — некоторая агрегированная величина. К кубам мы ещё вернёмся в следующих главах.

Обратимся к практической стороне использования модели. САЗ даёт возможность менять логическую схему данных, что называется, «на лету». Действительно, достаточно добавить в метаданные описание нового атрибута и связать его с типами сущностей, как все приложения могут считывать и записывать значения данного атрибута, не принимая во внимание структурные изменения. Для сравнения, в реляционной БД добавление колонки в таблицу вызовет изменение структуры соответствующих наборов данных на стороне приложения по горизонтали, в противном случае колонка останется невидимой.

Интереснуювозможностьпредставляютзапросыпозначенияматрибутов вне учёта сущностей. Например, следующий простой запрос выведет нам все сущности, у которых, во-первых, имеется атрибут «вес», а, во-вторых, этот вес находится в заданных рамках.

SELECT * FROM eav

WHERE attribite = 'Вес' AND value BETWEEN 10 AND 50

В рамках корпоративной БД, в результатах такого запроса можно будет обнаружить не только упакованные товары, но и разнообразные весовые коэффициенты, отгрузки, приёмки, характеристики сотрудников, параметры оборудования, рецептуры технологий и многое другое. Неплохой инструмент для исследования семантики.

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

Расширенная модель САЗ носит название EAV/CR (EAV with classes and relationships), то есть САЗ с классами (типами) и связями. В дальнейшем будем называть её РСАЗ.

39

РСАЗявнымобразом поддерживаетдлякаждойсущностипонятиекласса (типа). Это означает, что запросы теперь можно ограничивать только сущностями заданного типа, чтобы избежать приведённой выше неоднозначности выборки по значениям атрибутов.

Связи между сущностями также поддерживаются в явном виде, кроме того структура, задающая связи, подлежит унификации.

Ограниченияцелостностимогутбытьописанынауровнеметаданных, но способ их реализации не оговорён. Например, в реляционной БД таким механизмом могут являться триггеры таблиц метаданных.

Рис. 6. Пример реализации расширенной модели САЗ

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

11CRUD — от англ. Create-Retreive-Update-Delete, типы множественных запросов на создание, считывание, модификацию или удаление единичного экземпляра сущности.

40