Модели данных

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

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

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

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

Это привело к необходимости поиска иных способов практического использования иерархических и сетевых СУБД. Новые СУБД появились в конце 60-х годов и отличались от предыдущих простотой организации и наличием весьма удобных языков манипулирования данными. Главным недостатком этих СУБД стало ограничение количества файлов для хранения данных, количества связей между ними, длины записи и количества ее полей.

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

2. Реляционный подход

Еще в конце 60-х годов стали появляться работы, в которых обсуждались возможности применения различных табличных даталогических моделей данных. Особый интерес вызвала статья сотрудника фирмы IBM д-ра Э.Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, June 1970), в которой впервые был применен термин "реляционная модель данных".

Так как Э. Кодд по образованию был математиком, он предложил для обработки данных использовать аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Ему удалось показать, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение - relation (англ.) [6,7].

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

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

Рассмотрим конкретный пример для первого случая: при организации транзитного рейса, целесообразно задать запрос: "Выдать рейсы, в которых время вылета из Челябинска в Египет больше времени прибытия из Свердловска в Стамбул".

Отношение на доменах D1, D2, ..., Dn (не обязательно, чтобы все они были различны) состоит из заголовка и тела. На рис. 3 приведен пример отношения для расписания движения самолетов.

Заголовок состоит из такого фиксированного множества атрибутов A1, A2, ..., An, что существует взаимно однозначное соответствие между этими атрибутами Ai и определяющими их доменами Di (i=1,2,...,n).

Рисунок 2. Отношение с математической точки зрения (Ai - атрибуты, Vi - значения атрибутов)

Тело состоит из меняющегося во времени множества кортежей. В свою очередь, каждый кортеж состоит из множества пар атрибут-значений (Ai:Vi), (i=1,2,...,n), по одной такой паре для каждого атрибута Ai в заголовке. Для любой заданной пары атрибут-значение (Ai:Vi) Vi является значением из единственного домена Di, который связан с атрибутом Ai.

Степенью отношения называют число его атрибутов. Отношение степени один называют унарным, степени два - бинарным, степени три - тернарным, ..., а степени n - n-арным.

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

Поскольку отношение - это множество, а множества по определению не содержат совпадающих элементов, то никакие два кортежа отношения не могут быть дубликатами друг друга в любой произвольно-заданный момент времени. Пусть R - отношение с атрибутами A1, A2, ..., An. Говорят, что множество атрибутов K=(Ai, Aj, ..., Ak) отношения R является возможным ключом R тогда и только тогда, когда происходит выполнение двух независимых от времени условий:

1.Уникальность: в произвольный заданный момент времени никакие два различных кортежа R не имеют одного и того же значения для Ai, Aj, ..., Ak.

2.Минимальность: ни один из атрибутов Ai, Aj, ..., Ak не может быть исключен из K без нарушения уникальности.

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

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

Отношение - Таблица (иногда Файл), Кортеж - Строка (иногда Запись), Атрибут - Столбец, Поле.