Целостность и сохранность баз данных.

Целостность и сохранность баз данных.

1 Введение. 4

1.1 Информация, данные, знания. Терминология. 5

1.2 Автоматизированная информационная система. 8

1.3 Предметная область информационной системы.. 10

1.4 Назначение и основные компоненты системы баз данных. 13

1.5 Уровни представления баз данных. Понятия схемы и подсхемы.. 13

2 Модели данных. 15

2.1 Понятие модели данных. 15

2.1.1 Типы структур данных. 16

2.1.2 Операции над данными. 18

2.1.3 Ограничения целостности. 18

2.2 Сетевая модель данных (СМД) 19

2.3 Иерархическая модель данных (ИМД) 21

2.4 Реляционная модель данных (РМД) 23

2.4.1 Понятие отношения. 23

2.4.2 Схема отношения. 24

2.4.3 Достоинства и недостатки РМД.. 27

2.4.4 Операции реляционной алгебры. Язык манипулирования данными для реляционной модели 27

2.5 Другие модели данных. 31

2.5.1 Объектно-реляционная модель данных. 31

2.5.2 Объектно-ориентированная модель данных. 32

3 Обзор современных систем управления базами данных (СУБД) 33

3.1 Классификация СУБД.. 33

3.2 Правила Кодда для реляционной СУБД (РСУБД) 35

3.3 Основные функции реляционной СУБД.. 37

3.4 Администрирование базы данных. 37

3.5 Словарь-справочник данных. 38

4 Язык SQL. Изучение одной из современных СУБД по выбору - Microsoft SQL Server 39

4.1 Введение в SQL.. 39

4.2 Типы данных SQL. 43

4.3 DDL: создание и модификация базы данных. 44

4.4 DDL: Индексирование базы данных. 45

4.5 DML: Команды модификации данных. 46

4.6 DML: Выборка данных. Поиск. 47

4.7 DML: Выборка из нескольких таблиц. 48

4.8 DML: Вычисления внутри SELECT. 49

4.9 DML: Групировка данных. 50

4.10 DML: Cортировка данных. 50

4.11 DML: Операция объединения. 51

4.12 Использование представлений. 51

4.13 Другие возможности SQL. 52

4.14 Создание форм и отчетов. 53

5 Элементы проектирования баз данных. 55

5.1 Требования к проекту базы данных. 55

5.2 Этапы проектирования базы данных. 56

5.3 Инфологическое проектирование. 61

5.3.1 Проектирование с использованием метода "сущность-связь". 63

5.3.2 Объединение локальных представлений. 64

5.4 Определение требований к операционной обстановке. 66

5.5 Выбор СУБД и инструментальных программных средств. 66

5.6 Логическое проектирование БД.. 67

5.7 Физическое проектирование БД.. 67

5.8 Автоматизация проектирования БД.. 67

5.9 Проектирование реляционной базы данных. 68

5.10 Преобразование ER-диаграммы в схему БД.. 68

5.11 Выявление нереализуемых связей. 70

5.12 Определение первичных ключей. 71

5.13 Определение типов данных атрибутов. 71

5.14 Описание ограничений целостности. 72

5.15 Аномалии модификации данных. 73

5.15.1 Нормализация и декомпозиция отношений. 73

5.15.2 Первая нормальная форма (1НФ). 75

5.15.3 Функциональные зависимости. Вторая нормальная форма (2НФ). 76

5.15.4 Транзитивные зависимости. Третья нормальная форма (3НФ). 77

5.15.5 Денормализация отношений. 79

6 Физическая организация базы данных. 81

6.1 Механизмы среды хранения и архитектура СУБД.. 81

6.2 Структура хранимых данных. 82

6.3 Управление пространством памяти и размещением данных. 83

6.4 Виды адресации хранимых записей. 85

6.5 Способы размещения данных и доступа к данным в РБД.. 86

6.5.1 Способы доступа к данным.. 87

6.5.2 Индексирование данных. Индексированные файлы.. 87

6.5.3 Способы организации индексов. 89

6.5.4 Многоуровневые индексы на основе В-дерева. 89

6.5.5 Использование индексов. 92

6.5.6 Хеширование. Хешированные файлы.. 94

6.5.7 Методы хеширования. 94

6.5.8 Разрешение коллизий. 95

6.5.9 Использование хеширования. 96

6.5.10 Кластеризация данных. 97

6.5.11 Принцип организации кластеров. 97

6.5.12 Использование кластеризации. 98

7 Многопользовательский доступ к данным.. 99

7.1 Механизм транзакций. 99

7.2 Взаимовлияние транзакций. 102

7.3 Уровни изоляции транзакций. 104

7.4 Блокировки. 105

7.5 Временные отметки. 107

7.6 Многовариантность. 107

8 Защита баз данных. 108

8.1 Целостность и сохранность баз данных. 108

8.2 Обеспечение безопасности данных. 109

8.2.1 Виды сбоев. 110

8.2.2 Средства физической защиты данных. 111

8.2.3 Восстановление базы данных. 111

8.3 Защита от несанкционированного доступа. 112

9 Оптимизация реляционных запросов. 115

9.1 Этапы оптимизации запросов в реляционных СУБД.. 115

9.2 Преобразования операций реляционной алгебры.. 118

9.3 Методы оптимизации. 120

9.3.1 Метод оптимизации, основанный на синтаксисе. 120

9.3.2 Метод оптимизации, основанный на стоимости. 121

9.3.3 Примеры использования методов оптимизации запросов. 123

9.4 Настройка приложений. 125

Введение

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

Различают АИС, основанные на знаниях, и АИС, основанные на данных. К первым можно отнести, например, экспертные системы (ЭС), интеллектуальные системы поддержки принятия решений (СППР) и т.п. Ко вторым – всевозможные прикладные системы, которые сейчас активно используются и на предприятиях, и в учреждениях. Такие прикладные системы применяются очень широко, и в рамках данного курса наше внимание будет сосредоточено именно на системах, которые основаны на данных.

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

1. Разработка методов конструирования и эксплуатации систем, предназначенных для коллективного использования.
2. Возможность собирать, хранить и обрабатывать большое количество данных о реальных объектах и явлениях, то есть оснащение этих систем "памятью".

Массив данных общего пользования в системах, основанных на данных, называется базой данных. База данных (БД) является моделью предметной области информационной системы.

На заре развития вычислительной техники обрабатываемые данные являлись частью программ: они располагались сразу за кодом программы в так называемом сегменте данных (рис. 1.1,а). Следующим шагом стало хранение данных в отдельных файлах (рис. 1.1,б). Недостатком этих двух подходов являлась зависимость программ от данных: сведения о структуре данных включались в код программы. При изменении структуры данных необходимо было вносить изменения в программу.

Рис.1.1. Развитие принципов обработки данных

Логичным продолжением этой эволюции является перенос описания данных в массив данных (рис. 1.1,в). Это позволило обеспечить независимость данных от программ.

Основным принципом организации баз данных является совместное хранение данных и их описания.

Описание данных называют метаданными. Метаданные хранятся в части базы данных, которая называется каталогом или словарём-справочником данных (ССД). Зная формат метаданных, можно запрашивать и изменять данные без написания дополнительных программ.

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

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

Модель данных является инструментом моделирования произвольной предметной области.

Понятие модели данных

Модель данных – это совокупность правил порождения структур данных в базе данных, операций над ними, а также ограничений целостности, определяющих допустимые связи и значения данных, последовательность их изменения [6]. Итак, модель данных состоит из трёх частей:

1. Набор типов структур данных.

Здесь можно провести аналогию с языками программирования, в которых тоже есть предопределённые типы структур данных, такие как скалярные данные, вектора, массивы, структуры (например, тип struct в языке Си) и т.д.

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

Такими операциями являются: создание и модификация структур данных, внесение новых данных, удаление и модификация существующих данных, поиск данных по различным условиям.

1. Набор общих правил целостности, которые прямо или косвенно определяют множество непротиворечивых состояний базы данных и/или множество изменений её состояния.

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

Теперь рассмотрим подробнее наборы, составляющие модель данных.

Типы структур данных

Структуризация данных базируется на использовании концепций "агрегации" и "обобщения". Один из первых вариантов структуризации данных был предложен Ассоциацией по языкам обработки данных (Conference on Data Systems Languages, CODASYL) (рис. 2.1).

Рис.2.1 Композиция структур данных по версии CODASYL

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

Агрегат данных – поименованная совокупность элементов данных внутри записи, которую можно рассматривать как единое целое. Агрегат может быть простым (включающим только элементы данных, рис. 2.2,а) и составным (включающим наряду с элементами данных и другие агрегаты, рис. 2.2,б).

Рис.2.2 Примеры агрегатов: а) простой и б) составной агрегат

Запись – поименованная совокупность элементов данных или эле-ментов данных и агрегатов. Запись – это агрегат, не входящий в состав никакого другого агрегата; она может иметь сложную иерархическую структуру, поскольку допускается многократное применение агрегации. Различают тип записи (её структуру) и экземпляр записи, т.е. запись с конкретными значениями элементов данных. Одна запись описывает свойства одной сущности ПО (экземпляра). Иногда термин "запись" за-меняют термином "группа".

Пример записи, содержащей сведения о сотруднике, приведён на рис. 2.3.

Рис.2.3 Пример записи типа СОТРУДНИК

Эта запись имеет несколько элементов данных (Номер пропуска, Должность, Пол и т.д.) и три агрегата: простые агрегаты ФИО и Адрес и повторяющийся агрегат Телефоны. (Повторяющийся агрегат может включаться в запись произвольное число раз).

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

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

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

Рис. 2.4 Пример диаграммы Бахмана для фрагмента БД "Город"

Здесь запись типа ПОЛИКЛИНИКА является владельцем записей типа ЖИТЕЛЬ и они связаны групповым отношением диспансеризация. Запись типа ОРГАНИЗАЦИЯ также является владельцем записей типа ЖИТЕЛЬ и они связаны групповым отношением работают. Записи типа РЭУ и типа ЖИТЕЛЬ являются владельцами записей типа КВАРТИРА с отношениями соответственно обслуживают и проживают. Таким образом, запись одного и того же типа может быть членом одного отношения и владельцем другого.

База данных – поименованная совокупность экземпляров групп и групповых отношений. Это самый высокий уровень структуризации данных.

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

Операции над данными

Модель данных определяет множество действий, которые допустимо производить над некоторой реализацией БД для её перевода из одного состояния в другое. Это множество соотносят с языком манипулирования данными (Data Manipulation Language, DML).

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

По типу производимых действий различают следующие операции:

• идентификация данных и нахождение их позиции в БД;
• выборка (чтение) данных из БД;
• включение (запись) данных в БД;
• удаление данных из БД;
• модификация (изменение) данных БД.

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

Ограничения целостности

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

Неявные ограничения определяются самой структурой данных. Например, тот факт, что запись типа СОТРУДНИК имеет поле Дата рождения, служит, по существу, ограничением целостности, означающим, что каждый сотрудник организации имеет дату рождения, причём только одну.

Явные ограничения включаются в структуру базы данных с помощью средств языка контроля данных (DCL, Data Control Language). В качестве явных ограничений чаще всего выступают условия, накладываемые на значения данных. Например, номер паспорта является уникальным, заработная плата не может быть отрицательной, а дата приёма сотрудника на работу обязательно будет меньше, чем дата его перевода на другую работу.

Также различают статические и динамические ограничения целостно-сти. Статические ограничения присущи всем состояниям ПО, а динамические определяют возможность перехода ПО из одного состояния в другое. Примерами статических ограничений целостности могут служить требование уникальности индивидуального номера налогоплательщика (ИНН) или задание ограниченного множества значений атрибута "Пол" ('м' и 'ж'). В качестве примера динамического ограничения целостности можно привести правило, которое распространяется на поля-счётчики: значение счётчика не может уменьшаться.

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

В настоящее время разработано много различных моделей данных. Основные – это сетевая, иерархическая и реляционная модели.

Сетевая модель данных (СМД)

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

Связи между записями в СМД выполняются в виде указателей, т.е. каждая запись хранит ссылку на другую однотипную запись (или признак конца списка) и ссылки на списки подчинённых записей, связанных с ней групповыми отношениями. Таким образом, в каждой вершине записи хранятся в виде связного списка. Если список организован как однонаправленный, запись имеет ссылку на следующую однотипную запись в списке; если список двунаправленный – то на следующую и предыдущую однотипные записи.

Групповые отношения характеризуются следующими признаками:

1. Способ упорядочения подчинённых записей

Поддерживаются три способа упорядочения:

• Очередь – добавление в конец списка (FIFO – first input, first output).
• Очередь – добавление в конец списка (FIFO – first input, first output).
• Сортировка по значению ключа. При этом задаётся ключев Очередь – добавление в конец списка (FIFO – first input, first output).
• ое поле (группа полей), и вновь поступившая запись добавляется в упорядоченный список в соответствии со значением этого поля (значением ключа).
1. Режим включения подчинённых записей.

Режим включения бывает автоматический и ручной.

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

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

1. Режим исключения подчинённых записей

Режим исключения определяется классом членства. Различают три класса членства – фиксированный, обязательный и необязательный:/p>

• Записи с обязательным членством должны быть удалены до удаления записи–владельца: владелец, к которому прикреплена хотя бы одна запись с обязательным членством, не может быть удалён.
• Записи с фиксированным членством удаляются вместе с записью–владельцем.
• Записи с необязательным членством при удалении записи–владельца останутся в БД.

Рассмотрим фрагмент БД "Предприятие" (рис. 2.5). Здесь записи типов ОТДЕЛЫ и ОРГАНИЗАЦИИ-ЗАКАЗЧИКИ являются владельцами записей типа ПРОЕКТЫ и они связаны групповыми отношениями соответственно выполняют и заказывают. Записи типов ОТДЕЛЫ и ПРОЕКТЫ являются владельцами записей типа СОТРУДНИКИ и они связаны групповыми отношениями работают и выполняются. Записи типа СОТРУДНИКИ являются владельцами записей типа ДЕТИ.

Рис. 2.5. Пример фрагмента сетевой БД "Предприятие"

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

В СМД связи 1:n между разными сущностями реализуются с помощью групповых отношений, а связи 1:n между атрибутами сущности – в рамках записи. Для реализации связей типа n:m вводится вспомогательный тип записи и две связи 1:n.

В СМД применяются следующие операции над данными:

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

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

• от текущего экземпляра записи определённого типа к следующему экземп-ляру записи этого же типа;
• из текущей вершины в любую вершину, с которой текущая связана групповым отношением.

Навигация в СМД может начинаться с любой записи.

Наиболее распространенной и стандартизованной из реализаций СМД является модель CODASYL. В соответствии с ней описание схемы БД осуществляется на языке COBOL, а манипулирование данными – с помощью включающего языка программирования высокого уровня. Примером се-тевой СУБД является система Integrated Database Management System (IDMS).

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

Иерархическая модель данных (ИМД)

Иерархическая модель позволяет строить БД с иерархической древовидной структурой. Структура ИМД описывается в терминах, аналогичных терминам сетевой модели данных (версия CODASYL). Группу в ИМД принято называть сегментом. В основе ИМД лежит понятие дерева.

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

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

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

В иерархических моделях данных используется ориентация древо-видной структуры от корня к листьям. Графическая диаграмма концептуальной схемы базы данных называется деревом определения. Пример иерархической базы данных приведён на рис. 2.6. Каждая некорневая вершина в ИМД связана с родительской вершиной (сегментом) иерархическим групповым отношением. Каждая вершина дерева соответствует типу сущности ПО. Тип сущности характеризуется произвольным количеством атрибутов, связанных с ней отношением 1:1. Атрибуты, связанные с сущностью отношением 1:n, образуют отдельную сущность (сегмент) и переносятся на следующий уровень иерархии. Реализация связей типа n:m не поддерживается.

Рис. 2.6. Пример фрагмента иерархической базы данных

Тип вершины определяется типом сущности и набором её атрибутов. Каждая вершина дерева хранит экземпляры сущностей – записи. Следствием внутренних ограничений иерархической модели является то, что каждому экземпляру зависимой группы в БД соответствует уникальное множество экземпляров родительских записей – по одному экземпляру (записи) каждого типа вершин вышестоящих уровней.

По сравнению с СМД иерархическая имеет ограниченный набор режимов включения и исключения подчинённых записей. Это определяется обязательностью связей: в дереве не может быть «висячих» вершин, не связанных с вершиной верхнего уровня (кроме корневой). Поэтому ИМД не поддерживает необязательный класс членства и ручной режим включения записей.

В ИМД предусмотрены специальные способы навигации. Передвижение по дереву всегда начинается с корневой вершины, от которой можно перейти на конкретный экземпляр записи любой вершины следующего уровня. Эта вершина становится текущей вершиной, а экземпляр – текущей записью. От этой записи можно перейти к другой записи данной вершины, к экземпляру записи родительской вершины или к экземпляру записи подчинённой вершины. Т.о., попасть в любую вершину можно, только проделав полный путь по дереву от корня. Связи между записями в ИМД обычно выполнены в виде ссылок (т.е. хранятся адреса связанных записей).

Корневая запись дерева должна содержать ключ с уникальным значением. Ключи некорневых записей должны иметь уникальные значения только в экземплярах групповых отношений, т.е. на одном и том же уровне иерархии в разных ветвях дерева могут быть экземпляры записей с одинаковыми ключами. Это объясняется тем, что каждая запись идентифицируется полным сцепленным ключом, который образуется путём конкатенации всех ключей экземпляров родительских записей. Например, для студента (рис. 2.6) ключ – это (Шифр_факультета+Номер_курса+Номер_группы+Номер_зачётной_книжки).

Основным недостатком ИМД является дублирование данных. Оно вызвано тем, что каждая сущность (атрибут) может относиться только к одной родительской сущности. Например, если в БД хранятся данные о детях сотрудников, а на предприятии работает и отец, и мать ребёнка, то сведения об этом ребёнке нужно хранить дважды. Аналогичная ситуация возникает, если нужно отразить в БД связь «многие-ко-многим». Дублирование данных может вызвать нарушение логической целостности БД при внесении изменений в эти данные.

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

В качестве примера типичного представителя иерархических СУБД можно привести систему IMS (Information Management System, IBM).

Сетевая и иерархическая модели данных относятся к базам данных I-го поколения (60-е – начало 70-х гг. XX века). Эти модели не смогли в полной мере реализовать независимость данных от программ. Из-за особенностей их организации структура запросов к данным в таких системах определяется наличием связей между записями.

Следующее, II-е поколение баз данных основано на реляционной модели.

Реляционная модель данных (РМД)

Понятие отношения

Реляционная модель данных была предложена в 1970 г. математиком Эдгаром Коддом (Codd E.F.). РМД является наиболее широко распространенной моделью данных и единственной из трёх основных моделей данных, для которой разработан теоретический базис с использованием теории множеств.

Базовой структурой РМД является отношение, основанное на декарто-вом произведении доменов. Домен – это множество значений, которое может принимать элемент данных (например, множество целых чисел, множество дат, множество комбинаций символов длиной N и т.п.). Домен может задаваться перечислением элементов, указанием диапазона значений, функцией и т.д.

Пусть D1, D2 ,…, Dk – произвольные конечные и не обязательно различ-ные множества (домены). Декартово произведение этих множеств определяется следующим образом:

D₁×D₂×...×D_k={(d₁, d₂,...,d_k | d_i Î D_i, I=1,...,k)}

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

Пример. Для доменов D₁ = (1, 2), D₂ = (A, B, C) декартово произведение D = D₁×D₂ будет таким: D = {(1,A), (1,B), (1,C), (2,A), (2,B), (2,C)}

Подмножество декартова произведения доменов называется отношением.

Отношение содержит данные о сущностях определённого типа. Поясним это на примере. Если построить произведение трёх доменов Должности ('директор', 'бухгалтер', 'водитель', 'продавец'), Оклады (x | 20000?x?80000), Надбавки (1.1, 1.2, 1.3), то мы получим 4*60001*3=720012 комбинаций. Но реально отношение «Штатное расписание» содержит по одной строке на каждую должность, т.е. является именно подмножеством декартова произведения доменов.

Элементы отношения называют кортежами (или записями). Каждый кортеж отношения соответствует одному экземпляру сущности определённого типа. Элементы кортежа принято называть атрибутами (или полями).

Схема отношения

Отношение обладает двумя основными свойствами:

1. В отношении не должно быть одинаковых кортежей, т.к. это множество.
2. Порядок кортежей в отношении несущественен.

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

Отношение удобно представлять как таблицу, где строка является кортежем, а столбец соответствует домену (рис. 2.7, отношение СТУДЕНТЫ). Количество строк в таблице (кортежей в отношении) называется мощностью отношения, количество столбцов (атрибутов) – арностью.

Группа	ФИО студента	Номер зачетной книжки	Год рождения	Размер стипендии
C-72	Волкова Елена Павловна	С-12298		1550.00
C-91	Белов Сергей Юрьевич	С-12299		1400.00
.....
C-72	Фролов Юрий Вадимович	С-14407

Рис.2.7. Пример табличной формы представления отношения

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

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

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

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

Ключ отношения – это атрибут (группа атрибутов), значения которого классифицируют или идентифицируют кортеж. Например, значение атрибута Группа отношения СТУДЕНТЫ позволяет выделить среди всех студентов института студентов конкретной группы. Если ключ состоит из нескольких атрибутов, он называется составным. Если значения ключа уникальны в рамках столбца отношения, то такой ключ называется потенциальным. Потенциальных ключей может быть несколько (или не быть ни одного), но для отношения выделяется один основной ключ – первичный. Первичный ключ идентифицирует экземпляр сущности, его значение должно быть уникальным (unique) и обязательным (not null). (На рис. 2.7 первичный ключ выделен полужирным шрифтом). Неуникальные ключи ещё называют вторичными.

РМД не поддерживает групповые отношения (по версии CODASYL). Для связей между отношениями используются внешние ключи. Внешний ключ (foreign key) – это атрибут подчинённого (дочернего) отношения, который является копией первичного (primary key) или уникального (unique) ключа родительского отношения. (Пример – отношение ОЦЕНКИ, связанное с отношением СТУДЕНТЫ внешним ключом Номер зачётной книжки, рис. 2.8).

Номер зачетной книжки	Дисциплина	Оценка
C-12298	Программирование
C-1229891	Дискретная математика
C-14407	Программирование
.....

Рис.2.8. Связь отношений "Оценки" и "Студенты" по внешнему ключу

Если связь необязательная, то значение внешнего ключа может быть неопределённым (null).

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

Подмножество декартова произведения доменов называется отношением.

Внешний ключ – это ограничение целостности, в соответст<