. Физические модели данных

Физические модели данных описывают то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Физических моделей данных не так много, как логических, а самыми популярными среди них являются обобщающая модель (unifying model) и модель па­мяти кадров (frame memory).

Концептуальное моделирование

Как показывает изучение трехуровневой архитектуры СУБД, концептуальная схема является "сердцем" базы данных. Она поддерживает все внешние представле­ния, а сама поддерживается средствами внутренней схемы. Однако внутренняя схема является всего лишь физическим воплощением концептуальной схемы. Именно концептуальная схема призвана быть полным и точным представлением требований к данным некоторого предприятия¹. В противном случае определенная часть информации о предприятии будет упущена или искажена, в результате чего могут возникнуть трудности при попытках полной реализации одного или нескольких внешних представлений.

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

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

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

Реляционная модель впервые была предложена Э.Ф.Коддом (E.F.Codd) в 1970 году в его основополагающей статье "Реляционная модель данных для больших совместно используемых банков данных". В настоящее время публикацию этой статьи принято счи­тать поворотным пунктом в истории развития систем баз данных, хотя следует заметить, что еще раньше была предложена модель, основанная на множествах (Childs, 1968). Цели создания реляционной модели формулировались следующим образом:

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

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

• Расширение языков управления данными за счет включения операций над множествами.

Структура реляционных данных

Отношение Это плоская таблица, состоящая из столбцов и строк.

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

Атрибут Это поименованный столбец отношения.

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

Например, информация о кафедрах ВУЗа может быть представлена отношением КАФЕДРА, включающим столбцы с атрибутами Код, Название, Тел, ФИО зав.каф., Фотография заведующего. Аналогично, информация о преподавателях может быть представлена в виде отношения ПРЕПОДАВАТЕЛИ, включающим столбцы с атрибутами Таб.номер, ФИО препод., Уч. Степень, Уч. Звание, Код кафедры. На рисунке 10 показаны примеры отношений КАФЕДРА и ПРЕПОДАВАТЕЛИ. Как видно, каждый столбец содержит значения одного и того же атрибута – например столбец Код содержит только номера существующих кафедр.

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

Домены представляют собой чрезвычайно мощный компонент реляционной модели. Каждый атрибут реляционной базы данных определяется на некотором домене. Домены могут отличаться для каждого из атрибутов, но два и более атрибутов могут определяться на одном и том же домене. На рис.10 вверху условно показаны домены для всех атрибутов отношения КАФЕДРА. Обратите внимание, что атрибуты Код и Телефон имеют разные домены, хотя эти атрибуты состоят из наборов цифр. Но эти цифровые наборы по-разному организованы. Если бы в этом отношении был также атрибут Факс, то он определялся бы из того же домена, что и атрибут Тел. Обратите внимание, что в любой момент времени в доменах могут существовать значения, которые не будут реально представлены значениями соответствующего атрибута.

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

Кортеж Это строка отношения.

Элементами отношения являются кортежи, или строки, таблицы. В отношении КАФЕДРА каждая строка содержит пять значений, по одному для каждого атрибута. Кортежи могут располагаться в любом порядке, при этом отношение будет оставать­ся тем же самым, а значит, и иметь тот же смысл.

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

Домены

Код Название Телефон ФИО Фотографии

Атрибуты

КАФЕДРА

Код	Название	ТЕЛ	ФИО зав. каф.	Фотография заведующего
01	Информатики	310-47-74	Игнатьев В.В	Точечный рисунок1
02	Математики	310-47-15	Иванов И.И.	Точечный рисунок2
03	Истории	310-47-16	Смирнова И.В.	Точечный рисунок3
04	Иностранного яз	310-47-17	Жданова А.Е.	Точечный рисунок4