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

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

Модель является представлением "реального мира" объектов и событий, а также существующих между ними связей. Это некоторая абстракция, в которой акцент делается на самых важных и неотъемлемых аспектах деятельности организации, а все второстепенные свойства игнорируются. Модель должна отражать основные концепции представленные в таком виде, который позволит проектировщикам и пользователям базы данных обмениваться конкретными и недвусмысленными мнениями о своем понимании роли тех или иных данных в этой организации.

Модель данных рассматривается как сочетание трех компонентов:

• Структурная часть – набор правил, по которым может быть построена база данных.

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

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

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

Все модели данных подразделяются на три категории:

• объектные (object-based) модели данных;

• модели данных на основе записей (record-based);

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

Объектные модели данных

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

Наиболее общие типы объектных моделей данных:

• Модель типа “сущность-связь” или ER-модель (Entity-Relationship model).

• Семантическая модель.

• Функциональная модель.

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

В настоящее время ER-модель стала одним из основных методов концептуального проектирования баз данных.

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

В таком случае говорят, что объект инкапсулирует состояние и поведение.

Модели данных на основе записей

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

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

Существует три основных типа логических моделей данных на основе записей:

• реляционная модель данных (relational data model);

• сетевая модель данных (network data model);

• иерархическая модель данных (hierarchical data model).

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

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

Краткий обзор истории реляционной модели

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

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

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

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

Хотя интерес к реляционной модели обусловлен несколькими разными причинами, все же наиболее значительные исследования были проведены в рамках трех проектов с очень разной судьбой. Первый из них разрабатывался в конце 70-х годов в исследовательской лаборатории корпорации IBM в городе Сан-Хосе, штат Калифорния, под руководством Астрахана, результатом которого стало создание системы под названием "System R", являвшейся прототипом истинной реляционной СУБД. Этот проект был задуман с целью получить реальные доказательства практичности использования реляционной модели посредством реализации предусматриваемых ею структур данных и операций. Этот проект также зарекомендовал себя как важнейший источник информации о таких проблемах реализации, как управление параллельностью, оптимизация запросов, управление транзакциями, обеспечение безопасности и целостности данных, технология восстановления, учет человеческого фактора и разработка пользовательского интерфейса. Выполнение проекта стимулировало публикацию многих научно-исследовательских статей и создание других прототипов реляционных СУБД. В частности, работа над проектом System R дала толчок проведению таких важнейших разработок, как:

• создание языка структурированных запросов SQL (это название произносят либо по буквам "S-Q-L", либо (иногда) с помощью мнемонического имени "See-Quel", который с тех пор приобрел статус формального стандарта ISO (International Organization for Standardization) и в настоящее время является фактическим отраслевым стандартом языка реляционных СУБД;

• создание различных коммерческих реляционных СУБД, которые впервые появились на рынке в начале 80-х годов, таких как DВ2 и SQL/DS корпорации IBM, а также ORACLE корпорации ORACLE Corporation.

Вторым проектом, который сыграл заметную роль в разработке реляционной модели данных, был проект INGRES (Interactive Graphics Retrieval System), работа над которым проводилась в Калифорнийском университете (город Беркли) почти в то же самое время, что и над проектом System R. Проект INGRES включал разработку прототипа РСУБД с концентрацией основного внимания на тех же общих целях, что и проект System R. Эти исследования привели к появлению академической версии INGRES, которая внесла существенный вклад в общее признание реляционной модели данных. Позже от данного проекта отпочковались коммерческие продукты INGRES фирмы Relational Technology Inc. (теперь СА-OpenIgress фирмы Computers Associates) и Intelligent Database Machine фирмы Britton Lee Inc.

Третьим проектом была система Peterlee Relational Test Vehicle научного центра корпорации IВМ, расположенного в городе Потерли, Великобритания. Этот проект был более теоретическим, чем проекты System R и INGRES. Его результаты имели очень большое и даже принципиальное значение, особенно в таких областях, как обработка запросов и оптимизация, а также функциональные расширения системы.

Коммерческие системы на основе реляционной модели данных начали появляться в конце 70-х - начале 80-х годов. В настоящее время существует несколько сотен типов различных реляционных СУБД как для мейнфреймов, так и для микрокомпьютеров, хотя многие из них не полностью удовлетворяют точному определению реляционной модели данных. Примерами реляционных СУБД для микрокомпьютеров являются СУБД Access и FохРrо фирмы Microsoft, Раrаdох и Visual dBase фирмы Borland, а также R:Ваsе фирмы Microrim.

Благодаря популярности реляционной модели многие не реляционные системы теперь обеспечиваются реляционным пользовательским интерфейсом, независимо от используемой базовой модели. Основная сетевая СУБД, система IDMS. теперь называется IDMS/R(или IDMS/SQL) и поддерживает реляционное представление данных. Другими СУБД для мейнфреймов, в которых поддерживаются некоторые реляционные компоненты, являются Model 204 фирмы Computer Corporation of America и АDАВА8 D фирмы Software AG.

Кроме того, позже были предложены некоторые расширения реляционной модели данных, предназначенные для "наиболее полного и точного выражения смысла данных(Codd, 1979) объектно-ориентированных понятий (Stonebraker and Row,1986),а также для поддержки дедуктивных возможностей (Gardarin and Valduries, 1989).

Рис. 1.2. Структура обработки информации в реляционной БД

Используемая терминология

Реляционная модель основана на математическом понятии отношения, физическим представлением которого является таблица.

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

К

А

Р

Д

И

Н

А

Л

Ь

Н

О

С

Т

Ь

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

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

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

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

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

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

Студент

Номер зачетки	Номер группы	Фамилия	Средний балл
ТЗ3106	ТЗ31	Иванов	5
ТЗ3217	ТЗ32	Петров	4
ТМ3115	ТМ31	Пушников	3,5
ТМ3220	ТМ32	Сидоров	4,5

Преподаватель

Табельный номер	Фамилия	Раб. телефон	Факс
4587	Бондаренко	456-37-85	456-86-27
2136	Воронин	474-96-35	474-85-12
5496	Анисимова	468-05-38	468-28-01

Рис. 1.4. Примеры отношений Студент и Преподаватель.

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

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

В табл. 1.1 представлены домены для атрибутов отношений Студент и Преподаватель. Хотя в отношении Преподаватель есть четыре атрибута, здесь показаны только три, потому что два атрибута, Раб. телефон и Факс, определены на одном и том же домене.

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

Таблица 1.1. Домены атрибутов отношений Студент и Преподаватель

Атрибут	Имя домена	Содержимое домена	Определение домена
Номер зачетки	НОМЕР_ЗАЧЕТКИ	Множество всех допустимых номеров зачеток студентов	Символьный: размер 6, диапазон ‘ТЗ3101’-‘ТИ3111’
Номер группы	НОМЕР_ГРУППЫ	Множество всех имеющихся групп	Символьный: размер 4, диапазон ‘ТЗ31’-‘ТИ31’
Фамилия	ФАМИЛИЯ_ СТУДЕНТА	Множество всех фамилий студентов	Символьный: размер 10
Фамилия	ФАМИЛИЯ_ ПРЕПОДАВАТЕЛЯ	Множество всех фамилий преподавателей	Символьный: размер 10
Средний балл	СРЕДНИЙ_БАЛЛ	Множество всех допустимых средних баллов студентов	Символьный: размер 3
Табельный номер	ТАБЕЛЬНЫЙ_ НОМЕР	Множество всех табельных номеров преподавателей	Символьный: размер 4
Раб. телефон	РАБОЧИЙ_ ТЕЛЕФОН_ФАКС	Множество всех номеров телефонов и факсов преподавателей	Символьный: размер 7
Факс	РАБОЧИЙ_ ТЕЛЕФОН_ФАКС	Множество всех номеров телефонов и факсов преподавателей	Символьный: размер 7

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

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

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

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

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

Элементами отношения являются кортежи, или строки, таблицы.

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

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

Кортежи называются расширением (extension), состоянием (state) или телом отношения, которое постоянно меняется.

Степень отношения определяется количеством атрибутов, которое оно содержит.

Отношение Студент, показанное на рис. 1.4, имеет четыре атрибута и, следовательно, его степень равна четырем. Это значит, что каждая строка таблицы является 4-арным кортежем, т.е. кортежем, содержащим четыре значения.

Отношение только с одним атрибутом имеет степень 1 и называется унарным отношением (или 1-арным кортежем). Отношение с двумя атрибутами называется бинарным, отношение с тремя атрибутами – тернарным, а для отношений с большим количеством атрибутов используется термин п-арный.

Определение степени отношения является частью заголовка отношения.

Кардинальность – это количество кортежей, которое содержит отношение.

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

Реляционная база данных – это набор нормализованных отношений.

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