Модели данных
Основные понятия теории баз данных
Объектом называется элемент информационной системы, сведения о котором хранятся в базе данных.
Атрибут – это информационное отображение свойств объекта. Каждый объект характеризуется некоторым набором атрибутов.
Ключевым элементом данных называется такой атрибут (или группа атрибутов), который позволяет определить значения других элементов данных.
Запись данных (англ. эквивалент record) – это совокупность значений связанных элементов данных.
Первичный ключ – это атрибут (или группа атрибутов), который уникальным образом идентифицируют каждый экземпляр объекта (запись). Вторичным ключом называется атрибут (или группа атрибутов), значение которого может повторяться для нескольких записей (экземпляров объекта). Прежде всего вторичные ключи используются в операциях поиска записей.
Процедуры хранения данных в базе должны подчиняться некоторым общим принципам, среди которых в первую очередь следует выделить:
• целостность и непротиворечивость данных, под которыми понимается как физическая сохранность данных, так и предотвращение неверного использования данных, поддержка допустимых сочетаний их значений, защита от структурных искажений и несанкционированного доступа;
• минимальная избыточность данных обозначает, что любой элемент данных должен храниться в базе в единственном виде, что позволяет избежать необходимости дублирования операций, производимых с ним.
Набор принципов, определяющих организацию логической структуры хранения данных в базе, получил название модели данных. Модели баз данных определяются тремя компонентами:
• допустимой организацией данных;
• ограничениями целостности;
• множеством допустимых операций.
В теории систем управления базами данных выделяют модели трех основных типов: иерархическую, сетевую и реляционную.
Иерархическая модель позволяет строить базы данных с иерархической древовидной структурой. Эта структура определяется как дерево, образованное попарными связями. На самом верхнем уровне дерева имеется один узел, называемый корнем. Все элементы связаны отношениями подчиненности и при этом любой элемент может подчиняться только одному какому-нибудь другому элементу. Такую форму зависимости удобно изображать с помощью 
древовидного графа (схемы, состоящей из точек и стрелок, которая связана и не имеет циклов). Пример иерархической структуры базы данных приведен на рис. 2.1.
Основное достоинство иерархической модели – простота описания иерархических структур реального мира.
Типичным представителем семейства баз данных, основанных на иерархической модели, является Information Management System (IMS) фирмы IBM, первая версия которой появилась в 1968 году.
Концепция сетевой модели данных связана с именем Ч. Бахмана. Сетевой подход к организации данных является расширением иерархического. В иерархических структурах запись-потомок должна иметь в точности одного предка; в сетевой структуре данных потомок может иметь любое число предков (рис. 2.2). В ней элемент может быть связан с любым другим, без каких-либо ограничений. Сетевая БД состоит из набора записей, соответствующих каждому экземпляру объекта предметной области и набора связей между ними. Так, например, информация об участии сотрудников в проектах организации может быть представлена в сетевой БД (рис. 2.3). В данном примере сетевая модель хорошо отражает то, что в проекте могут участвовать разные сотрудники, и в то же время сотрудник может участвовать в различных проектах.
Рис. 2.3. Пример сетевой структуры БД
Примером системы управления данными с сетевой организацией является Integrated Database Management System (IDMS) компании Cullinet Software Inc., разработанная в середине 70-х годов. Она предназначена для использования на «больших» вычислительных машинах.
Среди достоинств систем управления данными, основанных на иерархической или сетевой моделях, могут быть названы их компактность и, как правило, высокое быстродействие, а среди недостатков – неуниверсальность, высокая степень зависимости от конкретных данных.
Концепции реляционной модели впервые были сформулированы в работах американского ученого Э. Ф. Кодда. Откуда происходит ее второе название – модель Кодда.
В реляционной модели объекты и взаимосвязи между ними представляются с помощью таблиц (рис. 2.4). Для ее формального определения используется фундаментальное понятие отношения. Собственно говоря, термин «реляционная» происходит от английского relation – отношение.
Реляционная модель опирается на систему понятий реляционной алгебры, важнейшие из которых: таблица, отношение, строка, столбец, первичный ключ. Все операции над реляционной базой данных сводятся к манипуляциям с таблицами. Таблица состоит из строк и столбцов и имеет имя, уникальное внутри базы данных. Таблица отражает тип объекта реального мира (сущность), а каждая ее строка (кортеж) – конкретный объект (рис. 2.5). Например, таблица «Сотрудники отдела» содержит сведения обо всех сотрудниках отдела, каждая ее строка – набор значений атрибутов конкретного сотрудника. Значения конкретного атрибута выбираются из домена (domain) – множества всех возможных значений атрибута объекта. Имя столбца должно быть уникальным в таблице. Столбцы расположены в таблице в соответствии с порядком следования их имен при ее создании. Любая таблица должна иметь по крайней мере один столбец. В отличие от столбцов строки не имеют имен. Порядок их следования в таблице не определен, а количество логически не ограничено. Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции – среди них не существует «первой» и «последней».
Рис. 2.5. Отношение реляционной базы данных
Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом. В таблице «Сотрудники отдела» первичным ключом служит столбец «Номер пропуска». В таблице не должно быть строк, имеющих одно и то же значение первичного ключа. Если таблица удовлетворяет этому требованию, она называется отношением.
Взаимосвязь таблиц в реляционной модели поддерживается внешними ключами. Внешний ключ – это столбец, значения которого однозначно характеризуют сущности, подставленные строками некоторого другого отношения, то есть задают значения их первичного ключа. Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.
Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют «данные о данных» (метаданные), например, описатели таблиц, столбцов и т. д. Метаданные также представлены в табличной форме и хранятся в словаре данных. Помимо таблиц в БД могут храниться и другие объекты, такие как экранные формы, шаблоны отчетов и прикладные программы, работающие с информацией базы данных.
Для пользователей информационной системы важно, чтобы база данных отражала предметную область однозначно и непротиворечиво. Если она обладает такими свойствами, то говорят, что БД удовлетворяет условию целостности. Чтобы добиться выполнения условия целостности, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности. Выделяют два основных типа ограничений целостности: целостность сущностей и целостность ссылок. Ограничение первого типа состоит в том, что любой кортеж отношения должен быть отличим от любого другого его кортежа, другими словами, любое отношение должно обладать первичным ключом. Это требование удовлетворяется автоматически, если в системе не нарушаются базовые свойства отношений. Ограничение целостности по ссылкам заключается в том, что внешний ключ не может быть указателем на несуществующую строку в таблице.
Важным преимуществом реляционной модели является то, что в ее рамках действия над данными могут быть сведены к операциям реляционной алгебры, которые выполняются над отношениями. Это такие операции, как объединение, пересечение, вычитание, декартово произведение, выборка, проекция, соединение, деление.
Важнейшей проблемой, решаемой при проектировании баз данных, является создание такой их структуры, которая бы обеспечивала минимальное дублирование информацией, упрощала процедуры обработки и обновления данных. Коддом был предложен некоторый набор формальных требований универсального характера к организации данных, которые позволяют эффективно решать перечисленные задачи. Эти требования к состоянию таблиц данных получили название нормальных форм. Первоначально были сформулированы три нормальных формы. В дальнейшем появилась нормальная форма Бойса–Кодда и нормальные формы более высоких порядков. Однако они не получили широкого распространения на практике.
В теории реляционных баз данных принято выделять следующую последовательность нормальных форм:
1) первая нормальная форма (1NF);
2) вторая нормальная форма (2NF);
3) третья нормальная форма (3NF);
4) нормальная форма Бойса–Кодда (BCNF);
5) четвертая нормальная форма (4NF);
6) пятая нормальная форма (5NF).
Каждой нормальной форме соответствует некоторый набор ограничений. Отношение находится в определенной нормальной форме, если оно удовлетворяет набору ограничений этой формы. Переводя структуру отношений БД в формы более высокого порядка, мы добиваемся удаления из таблиц избыточной неключевой информации.
Говорят, что отношение находится в первой нормальной форме, если все его атрибуты являются простыми.
Отношение находится во второй нормальной форме, если оно удовлетворяет требованиям первой нормальной формы, и каждый неключевой атрибут функционально полно зависит от ключа (однозначно определяется им).
Отношение находится в третьей нормальной форме, если оно удовлетворяет требованиям второй нормальной формы, и при этом любой неключевой атрибут зависит от ключа нетранзитивно. Заметим, что транзитивной называется такая зависимость, при которой какой-либо неключевой атрибут зависит от другого неключевого атрибута, а тот, в свою очередь, уже зависит от ключа.
Рассмотрим пример приведения отношения к третьей нормальной форме. Пусть небольшой фирме, занимающейся продажей комплектующих для компьютеров, требуется сохранять данные о заказах. Эти данные включают:
1) дату заказа;
2) номер заказа;
3) артикул (уникальный номер единицы товара);
4) наименование товара;
5) цену заказанного товара.
| Дата | Номер заказа | Артикул | Наименование | Цена |
| 01.09.98 | Процессор Pentium 233 MMX | |||
| 01.09.98 | M/B SOYO SY-5EAS ETEQ-6618 | |||
| 01.09.98 | DIMM 32 Mb | |||
| 01.09.98 | SVGA PCI 1Mb S3 TRIO 64+ | |||
| 01.09.98 | Процессор Pentium 233 MMX | |||
| 01.09.98 | DIMM 32 Mb | |||
| 02.09.98 | SVGA PCI 1Mb S3 TRIO 64+ | |||
| 02.09.98 | Процессор Pentium II 333 | |||
| 02.09.98 | DIMM 32 Mb | |||
| 02.09.98 | SVGA AGP S3 86C357 |
Нам необходимо нормализовать приведенную ниже таблицу. Заметим, что она уже находится в 1NF, так как все ее атрибуты являются простыми (атомарны). В СУБД дата – неделимый тип данных, поэтому, хотя дата заказа и состоит из 3 чисел, это – атомарный атрибут.
В одном заказе может оказаться несколько одинаковых наименований товара, например, можно заказать два одинаковых процессора, поэтому составной атрибут «Дата-НомерЗаказа-Артикул» не может быть первичным ключом.
Для того чтобы выполнить требования второй нормальной формы, надо добавить к таблице атрибут, который бы однозначно идентифицировал каждую единицу товара, входящую в заказ. Назовем такой атрибут «ID». Вот приведенное выше отношение в 2NF.
| ID | Дата | Номер заказа | Артикул | Наименование | Цена |
| 01.09.98 | Процессор Pentium 233 MMX | ||||
| 01.09.98 | M/B SOYO SY-5EAS ETEQ-6618 | ||||
| 01.09.98 | DIMM 32 Mb | ||||
| 01.09.98 | SVGA PCI 1Mb S3 TRIO 64+ | ||||
| 01.09.98 | Процессор Pentium 233 MMX | ||||
| 01.09.98 | DIMM 32 Mb | ||||
| 02.09.98 | SVGA PCI 1Mb S3 TRIO 64+ | ||||
| 02.09.98 | Процессор Pentium II 333 | ||||
| 02.09.98 | DIMM 32 Mb | ||||
| 02.09.98 | SVGA AGP S3 86C357 |
В этой таблице все атрибуты зависят от атрибута ID, но, кроме того, есть зависимость «Наименования» и «Цены» от «Артикула». Требование независимости атрибутов отношения не выполняются (3NF). Для приведения отношения в третью нормальную форму, таблицу требуется разбить на три отношения.
| ID | Дата | Номер заказа | Артикул |
| 01.09.98 | |||
| 01.09.98 | |||
| 01.09.98 | |||
| 01.09.98 | |||
| 01.09.98 | |||
| 01.09.98 | |||
| 02.09.98 | |||
| 02.09.98 | |||
| 02.09.98 | |||
| 02.09.98 |
| Артикул | Наименование |
| Процессор Pentium 233 MMX | |
| M/B SOYO SY-5EAS ETEQ-6618 | |
| DIMM 32 Mb | |
| SVGA PCI 1Mb S3 TRIO 64+ | |
| Процессор Pentium II 333 | |
| SVGA AGP S3 86C357 |
| Артикул | Цена |
Нормализация отношений – не пустая трата времени. Пусть в приведенном примере требуется изменить «Наименование» с «DIMM 32 Mb» на «DIMM 32 Mb SDRAM». В ненормализованном отношении пришлось бы искать и редактировать все строки, содержащие это наименование, а в нормализованной БД изменяется только одна строка одного отношения.
Подробнее с процессом нормализации и с требованиями нормальных форм старше третьей (3NF) можно ознакомиться в литературе по теории
реляционных БД.
Основным достоинством реляционной модели является ее простота. Именно благодаря ей она положена в основу подавляющего большинства реально работающих СУБД.