Основные модели, используемые при разработке БД

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

Информационная система представлена в виде совокупности таблиц. Строки в каждой таблице - это кортеж неструктурированных единиц данных, "атрибутов". Набор кортежей, составляющий таблицу, образует математическое отношение. Таким образом, модель данных представляется множеством таблиц-отношений (называемых также R-таблицами); отсюда название "реляционная", т.е. модель, представленная отношениями.

Атрибуты строк-кортежей (и таблиц-отношений) - это значения из заданных наравне с таблицами областей определения ("доменов"). Разные столбцы в одной и той же или в разных таблицах могут иметь одну и ту же область определения, а могут - разные.

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

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

· базовые операции

o ограничение - исключение из таблицы некоторых строк;

o проекция - исключение из таблицы некоторых столбцов;

o декартово произведение - из двух таблиц получается третья по принципу декартова произведения двух множеств строк;

o объединение - объединение множеств строк двух таблиц;

o разность - разность множеств строк двух таблиц;

o присвоение - именованной таблице присваивается значение выражения над таблицами;

· производные операции

o группа операций соединения;

o пересечение - пересечение множеств строк двух таблиц;

o деление;

o разбиение;

o расширение - добавление новых столбцов в таблицу;

o суммирование - в новой таблице с меньшим, чем в исходной, числом строк, строки получены как агрегирование (например, суммирование по какому-то столбцу) строк исходной.

Помимо "основных" таблиц, составляющих первоначальную основу БД, приведенные операции позволяют получать выводимые таблицы -представления, получаемые в результате применения операций.

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

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

Е. Кодд, автор реляционного подхода, в конце 70-х гг. предложил правила соответствия произвольной СУБД реляционной модели, дополнив основные понятия реляционных баз данных определениями, важными для практики:

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

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

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

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

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

5. Правило полноты языка работы с данными. Сколько бы много в СУБД ни поддерживалось языков и режимов работы с данными, должен иметься по крайней мере один язык, выражаемый в виде командных строк в некотором удобном синтаксисе, который бы позволял формулировать:

· определение данных,

· определение правил целостности,

· манипулирование данными (в диалоге и из программы),

· определение выводимых таблиц (в том числе возможности их модификации),

· определение правил авторизации,

· границы транзакций.

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

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

8. Правило физической независимости. Диалоговые операторы и прикладные программы на логическом уровне не должны страдать от каких-либо изменений во внутреннем хранении данных или в методах доступа СУБД.

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

10. Правило сохранения целостности. Диалоговые операторы и прикладные программы не должны изменяться при изменении правил целостности в БД (задаваемых языком работы с данными и хранимых в системном каталоге).

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

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

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

Объектно-ориентированная модель

Основные понятия объектно-ориентированной модели данных:

• объекты, обладающие внутренней структурой и однозначно идентифицируемые уникальным внутрисистемным ключом;
• классы, являющиеся по сути типами объектов;
• операции над объектами одного или разных типов, называемые "методами";
• инкапсуляция структурного и функционального описания объектов, позволяющая разделять внутреннее и внешнее описания (в терминологии предшествовавшего объектному модульного программирования - "модульность" объектов);
• наследуемость внешних свойств объектов на основе соотношения "класс-подкласс".

К достоинствам объектно-ориентированной модели относятся следующие:

· возможность для пользователя системы определять свои сложные типы данных (используя имеющийся синтаксис и свойства наследуемости и инкапсуляции);

· наличие наследуемости свойств объектов;

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

К недостаткам объектно-ориентированной модели можно отнести:

· отсутствие строгих определений; разное понимание терминов и различия в терминологии;

· модель не исследована столь тщательно математически, как реляционная;

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

Модель "объектов-ролей"

В отличие от реляционной в данной модели нет атрибутов, а основные понятия - это объекты и роли, описывающие их.

Роли могут быть как "изолированные", присущие исключительно какому-нибудь объекту, так и существующие как элемент какого-либо отношения между объектами. Модель служит для понятийного моделирования, что отличает ее от реляционной модели. Для описания модели помимо графического языка разработано подмножество естественного языка, не допускающее неоднозначностей, и, таким образом, пользователь (заказчик) не только общается с аналитиком на естественном языке, но и видит представленный на том же языке результат его работы по формализации задачи.