Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Informatika.pdf
Скачиваний:
240
Добавлен:
26.03.2015
Размер:
6.48 Mб
Скачать

§денежный тип для хранения денежных сумм. Данные этого типа имеют неко- торые особенности по сравнению с действительными числами и хранятся от- дельно;

§счётчик специальный тип данных для натуральных чисел с автоматическим наращиванием. Используется для порядковой нумерации записей;

§логический тип для хранения логических величин;

§поле объекта OLE – специальный тип данных, предназначенный для хранения мультимедийных объектов. Эти объекты, как и объекты полей MEMO, хранят- ся в специальном месте БД, а в поле объекта OLE хранится лишь ссылка на этот адрес;

§гиперссылка специальное поле для хранения адресов Web-объектов Интерне-

та. При щелчке на ссылке происходит запуск броузера и воспроизведение объ- екта в его окне.

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

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

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

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

Например, рассмотрим БД, состоящую из трёх связанных таблиц: СТУДЕНТ(номер

 

 

 

 

 

 

зачётной книжки, Ф., И., О., дата рождения,

СТУДЕНТ

 

СТИПЕНДИЯ

группа), СЕССИЯ(номер зачётной книжки,

 

оценка1, оценка2,…, оценка n, результаты

(N зачётной книжки)

 

(результаты сдачи сессии)

 

 

 

 

 

 

сдачи сессии), СТИПЕНДИЯ(результаты

 

 

 

 

 

 

сдачи сессии, размер стипендии). Отноше-

 

 

 

 

 

 

 

 

 

 

 

 

ния СТУДЕНТ и СЕССИЯ имеют совпа-

 

 

 

 

 

 

дающие ключи (номер зачётной книжки).

 

 

СЕССИЯ

 

 

 

 

 

 

Таблица СЕССИЯ имеет первичный ключ

 

(N зачётной книжки)

 

 

 

(результаты сдачи сессии)

 

 

номер зачётной книжки и содержит внеш-

 

 

 

 

 

 

 

 

 

ний ключ результаты сдачи сессии, кото-

Рис. 4.5. Связывание таблиц через ключи

рый обеспечивает её связь с таблицей СТИ-

 

 

 

 

 

 

ПЕНДИЯ (см. рис. 4.5).

Вреляционных базах данных определены три типа связей:

§один к одному (1:1);

§один ко многим (1:М);

§многие ко многим (М:М).

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

169

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

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

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

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

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

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

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

Различают шесть нормальных форм:

q1НФ первую нормальную форму;

q2НФ вторую нормальную форму;

q3НФ третью нормальную форму;

qНФБК нормальную форму Бойса - Кодда;

q4НФ четвёртую нормальную форму;

q5НФ пятую нормальную форму.

Каждая нормальная форма определяет ограничения на данные:

§1НФ, 2НФ, 3НФ ограничивают зависимость не первичных атрибутов от клю- чей;

§НФБК ограничивает зависимость первичных атрибутов;

§4НФ формирует ограничения на виды многозначных зависимостей;

§5НФ вводит другие типы зависимостей: зависимости соединения.

Каждая нормальная форма более высокого уровня предполагает, что анализируемое отношение уже находится в нормальной форме на уровне ниже рассматриваемого. Для реля- ционных баз данных необходимо, чтобы все отношения базы данных обязательно находи- лись в 1НФ, однако практически всегда стремятся довести уровень нормализации базы дан- ных хотя бы до 3НФ.

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

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

170

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

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

Вторая нормальная форма применяется к отношениям с составным ключом, т. е. к та- ким отношениям, первичный ключ которых состоит из двух или более атрибутов. Отноше- ние, у которого первичный ключ включает только один атрибут, всегда находится в 2НФ.

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

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

находится в первой нормальной форме, но не находится во второй, т. к. поля Оценка1, Оцен- ка2,…, Оценка n не находятся в полной функциональной зависимости от составного ключа, а лишь от его составной части. Для перевода этого отношения во вторую нормальную форму необходимо исключить из него поля Оценка1, Оценка2,…, Оценка n, т. е. исходное отноше- ние надо разбить на два вязанных отношения РЕЗУЛЬТАТЫ(номер зачётной книжки, Оцен- ка1, Оценка2,…, Оценка n) и СЕССИЯ(номер зачетной книжки, результаты сдачи сессии). Связь между ними будет осуществляться по полю Номер зачётной книжки (см. рис. 4.6).

 

 

 

 

 

 

 

 

 

 

 

Понятие третьей

нормальной формы

 

 

 

 

 

 

 

 

 

 

 

 

 

СТУДЕНТ

 

 

 

СТИПЕНДИЯ

связано с понятием транзитивной зависимо-

(N зачётной книжки)

 

 

 

(результаты сдачи сессии)

сти. Транзитивная зависимость наблюдается

 

 

 

 

 

 

 

 

 

 

 

в том случае, если одно из двух описательных

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

полей зависит от ключа, а другое описатель-

 

 

 

 

 

 

 

 

 

 

 

ное поле зависит от первого поля.

 

 

 

 

СЕССИЯ

 

 

 

 

 

 

 

 

 

 

Отношение будет находиться в третьей

 

 

 

(N зачётной книжки)

 

 

 

 

 

 

(результаты сдачи сессии)

 

 

 

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

второй нормальной форме, и каждое не клю-

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

чевое поле не транзитивно (т. е. напрямую)

 

 

РЕЗУЛЬТАТЫ

 

 

СЕССИЯ

 

зависит от первичного

ключа. Отношение

 

 

 

 

(N зачётной книжки)

 

СТУДЕНТ находится в третьей нормальной

 

 

(N зачётной книжки)

 

(результаты сдачи сессии)

 

 

 

 

 

 

 

 

 

форме. Если в состав описательных полей

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 4.6. Вторая нормальная форма отношений

этого информационного

объекта добавить

 

 

фамилию старосты группы староста, то поя-

 

 

 

 

 

 

 

 

 

 

 

вится транзитивная зависимость не ключевого поля Староста от ключа через не ключевое поле Группа.

Для устранения транзитивной зависимости описательных полей необходимо произве- сти расщеплениеисходного информационного объекта. В результате такого расщепления часть полей удаляется из исходного объекта и включается в состав других, новых информа- ционных объектов: СТУДЕНТ(номер зачётной книжки, Ф., И., О., дата рождения, группа), ГРУППА(группа, староста) (см. рис. 4.7).

171

СТУДЕНТ

N зачётной книжки Ф. И. О.

Дата рождения

СТУДЕНТ

ГРУППА

N зачётной книжки

Группа

Ф.

Староста

И.

 

= О.

+

Дата рождения

 

Группа

Группа

Староста

 

Рис. 4.7. Исключение транзитивной зависимости

4.4. Проектирование баз данных

Проектирование баз данных достаточно сложный процесс, содержащий обычно сле- дующие этапы:

§анализ предметной области;

§проектирование и кодирование БД;

§тестирование и сопровождение.

Анализ предметной области выполняется разработчиком БД совместно с заказчиком. В этом анализе описываются информационные объекты, принимаются правила организации и кодировки данных. Описывается список исходных и выходных данных, оговаривается ин- терфейс. На этом этапе собранные данные анализируются на предмет устранения дублиро- вания и противоречивости в данных, неоднозначности их определений и описаний, выявля- ются и формируются правила обработки информации и принятия решений.

Результатом этого этапа являются:

§список всех создаваемых и используемых элементов данных;

§перечень прикладных задач, их характеристик и используемых в них данных;

§список принимаемых решений в управлении описанных процессов;

§список возможных текущих изменений в БД.

Пользовательские модели представления данных должны быть интегрированы в кон- цептуальную модель данных. Наиболее известными подходами концептуализации являются анализ сущностей и представление знаний. При создании концептуальной схемы БД приме- няются два подхода: “нисходящийи восходящий”.

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

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

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

§рассмотрения объекта с различных точек зрения, выявления аспектов изучае- мого объекта с учётом их взаимосвязи;

§расчленения объекта на более простые подсистемы, т. к. каждая подсистема проще, чем вся система в целом;

172

Соседние файлы в предмете Информатика