Теоретические основы и структура базы данных

Прежде чем перейти к проектированию БД, изучим основные способы описания данных.

Каждый тип объектов предметной области характеризуется набором некоторых характеристик (аспектов описания), которые называются элементами данных. Пример: студент характеризуется фамилией, именем, отчеством, номером учебной группы, годом рождения и т. п. Если задаются конкретные значения элементов данных, то определяется конкретный объект предметной области. Пример: Романов Игорь Николаевич, 31 учебная группа, 1989 года рождения.

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

Рассмотрим два элемента данных – A и B. Будем считать, что

A – элемент данных, от которого направлена связь;

B – элемент данных, к которому направлена связь.

Графически это может быть изображено следующим образом:

Между этими элементами данных могут существовать отношения следующих типов.

Отношение «один – к – одному»(1:1) представляет собой тип связи, когда одно значение элемента данных A (от которого направлена связь) определяет одно и только одно значение элемента данных B (к которому направлена связь).

Примеры: 1) коды судов и адреса судов;

2) фамилия, имя, отчество судьи и его личный номер.

Отношение «один – ко – многим»(1:М) представляет собой тип связи, когда одно значение элемента данных A (от которого направлена связь) определяет несколько значений элемента данных B (к которому направлена связь); и каждое значение элемента данных B определяется одним значением элемента данных A.

Пример: номера квартир дома и список жильцов дома.

Отношение «многие – к – одному»(М:1)– это отношение, обратное отношению 1: М.

Отношение «многие – ко – многим»(M:М) представляет собой тип связи, когда одно значение элемента данных A (от которого направлена связь) определяет несколько значений элемента данных B (к которому направлена связь); и каждое значение элемента данных B может определяться несколькими значениями элемента данных A. Пример: отношения знакомства между людьми.

Основным признаком классификации БД является логическая модель данных.

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

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

Таблица 5.1

Обратимся теперь к описанию моделей данных. Существует три основные модели данных: сетевая, иерархическая и реляционная.

Сетевая модель данных – модель данных, предназначенная для представления данных сетевой структуры (рис. 5.1) и манипулирования ими. Такая модель обеспечивает представление данных о предметной области в виде элементов данных, которые могут быть связаны всеми типами отношений – 1:1, 1:М, М:1, М:M. В этой модели данных каждый элемент данных может иметь несколько «подчинённых» и несколько «старших». Достоинство сетевых моделей – минимальные затраты памяти, а недостаток – большое время поиска информации.

Иерархическая модель данных – модель данных, предназначенная для представления данных иерархической структуры (рис. 5.2) и манипулирования ими. Такая модель обеспечивает представление данных о предметной области в виде элементов данных, которые могут быть связаны отношениями 1:1 и 1:М. В этой модели данных каждый элемент данных может иметь несколько «подчинённых» и только одного «старшего». Достоинство иерархических моделей – большая скорость поиска информации, а недостаток – большие затраты памяти.

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

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

Основное понятие в реляционных моделях – реляционная таблица. Реляционная таблица – это таблица, у которой:

1) в каждом столбце хранятся значения одного элемента данных;

2) в каждой строке хранятся значения всех элементов данных, относящихся к одному объекту предметной области;

3) порядок строк и столбцов несущественен;

4) отсутствуют одинаковые строки.

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

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

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

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

Простой ключ – ключ, состоящий из одного элемента данных.

Составной ключ – ключ, содержащий более одного элемента данных.

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

Основные трудности при проектировании возникают:

· из-за сложности получения правильного описания данных и взаимосвязей между данными;

· из-за противоречивости требований к БД (например, с одной стороны, требуется сокращение объёма БД, а с другой стороны, ускорение поиска информации, хотя, как правило, одно исключает другое);

· из-за большого объёма вычислений и трудоёмкости используемых математических методов.

Процесс проектирования включает три самостоятельных этапа (рис. 5.3).

На этапе концептуального проектирования осуществляется сбор, анализ и редактирование требований к данным. Полученная в результате концептуальная модель – это представление о БД с точки зрения пользователя. Именно на этом этапе особенно значима и ответственна роль специалистов в предметной области.

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

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

Рассмотрим процесс проектирования БД для информационной системы «Преступные группировки». Эта БД должна обеспечивать автоматизацию следующих пользовательских функций:

· определение наиболее опасных преступных группировок;

· определение наиболее опасных членов преступных группировок;

· поиск информации о возможном месте нахождения членов группировок.

Будем считать, что пользователь на основе какого-либо формального или неформального метода определяет опасность группировки на основе следующих данных:

1 - условный номер группировки;

2 - район деятельности группировки;

3 - сферы деятельности группировки;

4 - активность группировки;

5 - продолжительность деятельности группировки;

6 - число членов группировки.

Исходные данные о преступной группировке с указанием типов отношений между элементами данных представлены графически на рис. 5.4.

Степень опасности члена группировки определяется по следующим данным (рис.5.5):

7 - фамилия, имя, отчество;

8 - группировка, в которую он входит;

9 - опасность этой группировки;

10 - сфера деятельности группировки;

11 - роль в группировке (лидер, скупщик краденного и т. д.);

12 - степень активности преступной деятельности;

13 - наличие судимости.

Для поиска места нахождения членов преступных группировок будем весьма упрощенно предполагать необходимость следующих данных (рис. 5.6):

14 - фамилия, имя, отчество;

15 - адрес;

16 - особые приметы;

17 - фамилии, имена, отчества знакомых;

18 - адреса знакомых.

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

Следующий шаг - редактирование - подразделяется на два этапа:

1) получение глобального представления данных;

2) получение внутреннего представления данных.

Глобальное представление данных - это представление, содержащее полную совокупность требований к данным. Пользовательские функции, входящие во внешнее представление, могут задаваться разными пользователями, использующими различную терминологию. Поэтому элементы данных в них могут частично противоречить друг другу или дублироваться. Необходима идентификация элементов данных, входящих в разные пользовательские функции, и устранение противоречий в их описании. Например, 8 - «группировка» и 1 - «наименование группировки» очевидно одно и то же. То же можно сказать и о 7 и 14 - «фамилия, имя, отчество». 5 - «продолжительность деятельности группировки» лучше заменить «датой начала деятельности», чтобы этот элемент данных не зависел от времени заполнения БД. 2 - «район деятельности» целесообразно дополнить информацией 19 - «код района» для связи с уже существующими БД.

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

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

В рассматриваемом примере:

· дважды присутствует, т.е. дублируется, элемент данных «Сфера деятельности группировки» - 10 и 3;

· элемент данных 6 - «Число участников группировки» легко вычисляется по имеющимся данным;

· то же относится и к элементу данных 9 - «Опасность группировки».

Тогда внутреннее представление данных будет иметь следующий вид (рис. 5.8).

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

Рассмотрим теперь этап логического проектирования реляционной БД. Как уже было сказано, реляционные БД являются самыми распространёнными, несмотря на то, что обладают существенным недостатком: содержат огромное количество избыточной информации. При работе с такой БД возникает целый ряд проблем:

- тратится значительное время на ввод повторяющихся значений элементов данных;

- при изменении одного значения необходимо корректировать все строки, где оно повторяется;

- возрастает количество ошибок ввода;

- увеличивается время поиска информации в БД.

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

Реляционная таблица находится в первой нормальной форме (1NF), если в ней:

1) все элементы данных атомарные, т. е. представляют собой одиночные значения, а не их объединение;

2) отсутствуют повторяющиеся группы элементов данных, т.е. элементы данных, имеющие одинаковое смысловое значение, объединяются.

Реляционная таблица находится во второй нормальной форме (2NF), если:

1) она находится в первой нормальной форме;

2) любой неключевой элемент данных однозначно определяется полным набором ключевых элементов.

Для приведения таблицы к 2NF необходимо в каждой таблице:

· определить ключевые элементы данных;

· определить функциональные зависимости неключевых элементов данных от ключевых элементов;

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

· определить связанные между собой группы элементов данных и типы отношений между ними;

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

При построении 2NF следует помнить следующие правила:

· если ключ является простым (состоящим из одного элемента данных), то требование 2NF для этой группы элементов автоматически выполняется;

· если между группами элементов A и B существует связь типа 1:M, то для реализации этой связи группа элементов B дополняется ключевыми элементами данных группы элементов A;

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

Полученные в результате группы элементов данных представляют собой реляционные таблицы в 2NF.

Реляционная таблица находится в третьей нормальной форме (3NF), если:

1) она находится во второй нормальной форме;

2) ни один неключевой элемент данных не определяется с помощью другого неключевого элемента данных.

Для приведения к 3NF таблиц, уже приведенных к 2NF, необходимо в каждой таблице:

· определить транзитивные зависимости между элементами данных;

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

· определить связанные между собой группы элементов данных и типы отношений между ними;

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

Организация связей осуществляется таким же образом, как и при построении 2NF.

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

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

Рассмотрим на примере процесс приведения реляционных таблиц к третьей нормальной форме.

В полученной выше концептуальной модели базы данных неатомарным является элемент данных «Фамилия, имя, отчество». Он может быть разделен на атомарные так, чтобы не появились повторяющиеся группы полей (рис. 5.9). Ключевые элементы данных будем выделять серым цветом в таблицах и жирным шрифтом в тексте.

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

(8) ← (2,19,5), (A)

(8,3) ← (4), (В)

(7-1,7-2, 7-3) ← (11,12,13,15,16), (С)

(17) ← (18), (D)

где стрелка направлена от неключевых элементов группы к ключевым элементам.

Между данными группами можно выделить следующие отношения:

A → B типа 1:M,

A → C типа 1:M,

D → C типа M:M.

Таблица 1*

Рис. 5.9. Реляционная таблица в первой нормальной форме

В этом случае для организации связи между группами элементов по существующему правилу следует:

· включить ключевые поля группы A в группу B, что фактически уже осуществлено при определении функциональных зависимостей;

· включить ключевое поле группы A в группу C;

· создать так называемую «таблицу развязки» между группами D и C, которая составлена из ключевых элементов как группы D, так и группы С.

Тогда база данных примет вид, показанный на рис. 5.10.

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

Анализ таблиц 2*-6* (рис. 5.10) показывает, что указанному требованию не удовлетворяет только таблица 2*. Действительно,

(8) ← (2)←(19),

(8) ← (19)←(2).

Устранение этих зависимостей может быть осуществлено разбиением на следующие группы элементов данных:

(8) ← (19, 5), (E)

(19) ← (2), (F)

Для связи между группами элементов E и F использован элемент 19, как имеющий меньшую длину.

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

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

Контрольные вопросы

1. Автоматизированные рабочие места: назначение, состав, виды обеспечения.

2. Основные принципы создания АРМ.

3. Требования к современным базам данных.

4. Системы управления базами данных. Состав современных СУБД.

5. Что означает логическая и физическая независимость данных?

6. Каковы основные модели данных? В чём их отличие?

7. Типы отношений между элементами данных.

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

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

10. Какова цель нормализации логической схемы базы данных?

11. Отличия нормальных форм представления данных.