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

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

2. Внутренние ограничения реляционной модели данных.

3. Перечислить и кратко охарактеризовать основные операции реляционной алгебры.

Глава 4. Вопросы проектирования реляционных баз данных Цели проектирования базы данных. Этапы проектирования

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

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

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

1. Обеспечить возможность хранения в базе всех данных, необходимых для решения поставленных задач.

2. Разработать структуры данных с учетом внутренних ограничений модели данных, поддерживаемой конкретной СУБД.

Этапы работ

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

1. Обозначить круг задач, для решения которых создается база данных.

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

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

4. Составить списки характеристик (атрибутов) информационных объектов.

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

Пример.

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

Этапы работ.

1. Задачи, для решения которых создается база данных.

1. Учет всех книг, поступающих и хранимых в библиотеке.

2. Учет всех читателей, пользующихся библиотекой.

3. Учет всех операций обмена (выдачи и возврата) книг.

4. Поиск книги по какой-то ее характеристике (жанр, автор, название, год издания).

5. Поиск данных читателя.

6. Определение книг, пользующихся повышенным спросом.

7. Определение задолжников.

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

Книги Жанры Читатели Обмен книг

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

Книги(Номер_книги, Автор, Название, Код_жанра, Год_издания, Издательство, Цена)

Жанр(Код_жанра, Название_жанра, описание_жанра)

Читатель(Номер_билета, ФИО, Адрес, Телефон, Дата рождения, Пол)

Обмен_книг (Номер_операции, Номер_книги, Номер_билета,Дата выдачи,Дата возврата)

Приведение данных предметной области в соответствие требованиям модели данных, поддерживаемой конкретной СУБД

1.Уникальность записи в таблице. Первичный ключ отношения. Внешний ключ.

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

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

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

Для каждой таблицы обязательно определяется первичный ключ. Роль уникального идентификатора в описании информационных обьектов предметной области Библиотека играют атрибуты Номер_книги, Код_жанра, Номер_билета, Номер_операции). Это простые, не составные, первичные ключи.

Иногда для идентификации экземпляра объекта недостаточно ключа, состоящего из одного атрибута. Например, в колледже есть несколько компьютерных классов. В каждом классе стоит 9 компьютеров. Каждый компьютер имеет индивидуальный номер от 1 до 9. Определить конкретный компьютер только по этому номеру в колледже нельзя, так как номера повторяются в каждом классе. Для уникальной идентификации компьютера требуется знать номер класса+номер машины. Эти атрибуты и являются первичным ключом отношения, хранящего информацию о компьютерах. В данном случае первичный ключ составной.

Другая важная роль первичного ключа состоит в том, что он служит для связывания таблиц. Например, в таблице Жанр есть атрибут Код_жанра. Он играет роль первичного ключа. В таблице Книги тоже есть атрибут Код_жанра. В этой таблице он является внешним ключом. Он пришел извне. Из таблицы Жанр. Если мы свяжем таблицы Книги и Жанр по этому атрибуту, из конкретной записи таблицы Книги возьмем значение атрибута код_жанра и найдем это значение в таблице Жанры, то узнаем название и описание данного жанра. Что нам дает такая связь? Она позволяет не перегружать таблицу Книги излишними подробностями о другом информационном обьекте (именно о жанре), но позволяет быстро эти подробности узнать, по значению атрибута-связки.

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

Важное правило!

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

2. Отсутствие избыточности данных в таблицах.

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

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

Студент	Куратор	Телефон куратора
Иванов	Орлов	222
Петров	Орлов	222
Сидоров	Соколов	333

В таблице дублируются фамилия куратора (Орлов) и телефон куратора(222). Имеет ли место избыточность? Избыточные данные – это данные, удаление которых не ведет к потере информации. Если мы удалим фамилию куратора в какой-либо записи, мы потеряем информацию о том, кто является куратором у конкретного студента. Следовательно, эти данные не являются избыточными. Далее. Телефон можно узнать и из первой записи таблицы, и из второй. Значит ли это, что из какой-то записи эти данные можно удалить? Если в одной из записей убрать информацию о телефоне, возникнет противоречие. Из одной записи будет следовать, что телефон у куратора есть и он такой, а из другой записи -  что телефона нет вообще. Фактически, такое противоречие - это тоже потеря данных. В то же время  оставить структуру таблицы прежней нельзя, т.к. она заключает в себе возможность возникновения ошибки. Если изменится телефон  и это изменение будет внесено  не во все записи, то  данные снова станут противоречивы. Так операции удаления и исправления данных в ситуации избыточности могут породить ошибку. А если потребуется удалять не отдельные значения, а записи? Например, студент Иванов получил все двойки и был отчислен. Мы удалили запись. Та же участь постигла и Петрова. Мы опять удалили запись. Что получилось в результате?    Из таблицы исчезли данные о кураторе!  Стремясь удалить данные об отчисленных студентах, мы удалили данные о кураторе и потеряли информацию. Следовательно, структура рассматриваемой таблицы не является верной,  она не отвечает внутренним ограничениям реляционной модели. Поэтому попытка манипулирования данными таблицы приводит к возникновению аномалий (ошибок).  Таблицу следует декомпозировать, чтобы исключить избыточность, порождающую ошибку,  а именно разделить на две таблицы следующим образом:

Студент	Куратор
Иванов	Орлов
Петров	Орлов
Сидоров	Соколов

Куратор	Телефон куратора
Соколов	333
Орлов	222

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

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