Проектирование структуры реляционных баз данных
Автор работы: Пользователь скрыл имя, 08 Декабря 2012 в 14:51, курс лекций
Описание работы
База
данных – это поименованная совокупность взаимосвязанных данных,
находящихся под управлением системы управления базами данных (СУБД).
СУБД – это комплекс программных и языковых средств, необходимых для
создания баз данных, поддержания их в актуальном состоянии и организации
поиска в них необходимой информации.
Файлы: 1 файл
2. Проектирование структуры реляционных
баз данных
2.1. Основные понятия экономических информационных систем (ЭИС)
Модели баз данных
База
данных – это поименованная совокупность взаимосвязанных данных,
находящихся под управлением системы управления базами данных (СУБД).
СУБД – это комплекс программных и языковых средств, необходимых для
создания баз данных, поддержания их в актуальном состоянии и организации
поиска в них необходимой информации.
Модель данных – это совокупность структур данных и операций по их
обработке. Разработано множество различных моделей данных, но на практике
используют три основных. Выделяют иерархическую, сетевую и реляционную
модели данных.
Реляционная модель данных
Основная идея реляционной модели данных заключается в том, чтобы
представить любой набор данных в виде двумерной таблицы. В простейшем
случае реляционная модель описывает единственную двумерную таблицу, но
чаще всего эта модель описывает структуру и взаимоотношения между
несколькими различными таблицами.
Основоположником теории реляционных баз данных считается сотрудник
фирмы IBM доктор Э.Кодд, опубликовавший в 1970 г. статью A Ralational Model
of Data for Large Shared Data Banks (Реляционная модель данных для больших
коллективных банков данных). В этой статье впервые был использован термин
«реляционная модель данных», что и положило начало реляционным базам
данных. Теория реляционных баз данных, разработанная доктором Э.Коддом,
имеет под собой мощную математическую основу, описывающую правила
эффективной организации данных.
Реляционной считается такая база данных, в которой все данные представлены
для пользователя в виде прямоугольных таблиц значений данных, и все операции
над базой сводятся к манипуляции с таблицами. Таблица состоит из столбцов
(колонок, полей) и строк (записей). Таблица отражает тип объекта реального
мира (сущность), а каждая ее строка – конкретный объект.
2.2. Нормализация базы данных и ее необходимость
В качестве примера рассмотрим таблицу
ПРОДАЖИ
, которая содержит:
сведения о покупателях;
дату заказа и количество заказанного товара;
дату выполнения заказа и количество проданного товара;
характеристику проданного товара (наименование, стоимость, категория).
Таблицу
ПРОДАЖИ
можно рассматривать как однотабличную базу данных.
Рис.2.1. Однотабличная база данных ПРОДАЖИ.
Проблемы
избыточности
данных
Основной недостаток однотабличной базы данных состоит в том, что в ней
содержится значительное количество повторяющейся информации. Такая
избыточность данных ведет к возникновению следующих проблем:
1. Потребуется значительное время на ввод повторяющихся данных.
2. Наличие повторяющейся информации приведет к неоправданному увеличению
базы данных. В результате снизится скорость выполнения запросов.
3. При многократном вводе повторяющихся данных возрастает вероятность
ошибки. При больших размерах таблиц поиск ошибок будет занимать
значительное время.
Процесс уменьшения избыточности информации в БД называется нормализацией. В
теории нормализации разработаны достаточно формализованные подходы к
разбиению данных на несколько таблиц и организации между ними взаимосвязей.
Теория
нормализации
Теория нормализации оперирует с пятью нормальными формами отношений (от
1НФ до 5НФ включительно). Эти формы предназначены для уменьшения
избыточной информации, при этом каждая последующая нормальная форма должна
удовлетворять требованиям предыдущей формы и некоторым дополнительным
условиям. При практическом проектировании баз данных четвертая и пятая формы,
как правило, не используются, поэтому ограничимся рассмотрением первых трех
нормальных форм.
Первичный
ключ
В таблице
ПРОДАЖИ
поле КодПокуп может быть выбран в качестве первичного
ключа (primary key, РК). Значению поля КодПокуп соответствуют:
единственные значения полей Фамилия, Имя, Отчество, Телефон, Индекс,
Страна, Область, Город, Адрес, Предпр, Руководит, Кредит;
N значений полей КодТов, ДатаЗаказ, Заказано, ДатаПрод, Продано, Цена,
Категория, НаимТов (где N - количество заказов у данного покупателя).
1НФ
Отношение имеет первую нормальную форму (1НФ), если оно удовлетворяет
следующим требованиям:
1) отношение должно иметь уникальный первичный ключ;
2) должна иметься однозначная зависимость каждого атрибута отношения от
первичного ключа;
3) должны отсутствовать повторяющиеся группы атрибутов.
Для устранения повторяющихся групп (каждый покупатель может иметь N заказов)
разобьем таблицу
ПРОДАЖИ
на две таблицы (Рис.3.2):
таблицу
ПОКУПАТЕЛЬ
, каждая строка которой содержит сведения об
одном из покупателей;
таблицу
ЗАКАЗ
, каждая строка которой содержит сведения об одном из N
заказов каждого из покупателей.
N
Рис.2.2. База данных "Продажи" в 1НФ
Для таблицы
ПОКУПАТЕЛЬ
создается простой первичный ключ, основанный на
поле КодПокуп. Для исключения повторяющихся записей в таблице
ЗАКАЗ
следует
образовать составной первичный ключ, содержащий поля КодПокуп, КодТовара и
ДатаЗаказ.
2НФ
Отношение имеет вторую нормальную форму (2НФ), если оно соответствует 1НФ и
не содержит неполных функциональных зависимостей (ФЗ). Неполная ФЗ - это две
зависимости:
1) ключ таблицы определяет некоторый ее неключевой атрибут;
2) часть ключа определяет этот же неключевой атрибут.
Из определения следует, что понятие 2НФ применимо только к отношениям,
имеющим составной ключ.
Таблица
ЗАКАЗ
, имеющая составной ключ, не находится в 2НФ, поскольку
неключевые поля НаимТов, Цена и Категория однозначно определяются частью
составного ключа КодТовара (рис. 2.3). Т.е. имеется неполная ФЗ.
Для приведения таблицы к 2НФ выделим из таблицы
ЗАКАЗ
таблицу
ТОВАРЫ
,
которая будет содержать информацию о товарах каждого типа.
1
3НФ
Отношение имеет третью нормальную форму (3НФ), если оно соответствует 2НФ
и среди его атрибутов отсутствуют транзитивные ФЗ. Транзитивные ФЗ - это две
зависимости:
1) ключ отношения определяет некоторый неключевой атрибут;
2) этот неключевой атрибут определяет другой неключевой атрибут.
В таблице
ПОКУПАТЕЛЬ
(рис. 2.4) неключевое поле Руководит содержит имена
руководителей компаний, которые однозначно определяются другим неключевым
полем Предпр. Т.е. существует транзитивная ФЗ. Для приведения таблицы
ПОКУПАТЕЛЬ
к 3НФ создается новая таблица
КОМПАНИЯ
.
Рис.2.4. База данных "Продажи" в 3НФ
Требование нормализации всех таблиц в реляционной базе данных не является
обязательным. Разбить таблицу на более мелкие (теоретически - свести ее к 3НФ)
практически может потребоваться в следующих случаях:
некоторая информация из этой таблицы используется не очень часто;
нельзя давать доступ к некоторым данным любым желающим
Рис.2.3. База данных "Продажи" в 2НФ
Внешний ключ
Результатом нормализации является получение базы данных в виде набора
отдельных таблиц. В схеме данных особенно важно определить, как будут
взаимодействовать различные таблицы. В реляционной базе данных связь
между таблицами устанавливается с помощью связующих полей (см. Рис.3.5).
Рис.2.5. Многотабличная база данных с эффективной структурой
PK
FK
FK
PK
FK
PK
Внешний ключ (foreign key, FK) - это поле в таблице, которое соответствует
первичному ключу в другой таблице. Поскольку у каждого клиента может быть
несколько заказов, а каждый заказ принадлежит только одному клиенту, то
между таблицами
ПОКУПАТЕЛЬ
и
ЗАКАЗ
устанавливается связь один-ко-
многим. Поскольку каждый товар может присутствовать в нескольких заказах,
а каждый заказ связан только с одним товаром, то между таблицами
ТОВАРЫ
и
ЗАКАЗ
также устанавливается связь один-ко-многим. Между таблицами
ПОКУПАТЕЛЬ
и
КОМПАНИЯ
существует связь один-к-одному, поскольку
компания, в которой работает покупатель, имеет одно определенное
руководство.
Использование внешних ключей обеспечивает эффективность работы
приложений:
1. Поддержка соответствующих значений первичного и внешнего ключа
обеспечивает целостность данных:
реляционная база данных не позволит добавить в таблицу строку, если
заданное в ней значение внешнего ключа не совпадает ни с одним
значением соответствующего первичного ключа, например, в таблицу
ЗАКАЗ
нельзя ввести строку с неправильным полем КодПокуп - т.е.
хранить заказы для несуществующих покупателей;
реляционная база данных не позволит удалить из таблицы строку с
первичным ключом, если в базе с этим же значением имеется
соответствующий внешний ключ, например, в таблице
ПОКУПАТЕЛЬ
нельзя удалить запись о покупателе, у которого имеются заказы - т.е.
имеются соответствующие ему строки в таблице
ЗАКАЗ
.
2. Задаваемые при создании таблиц связи первичных ключей с внешними
ключами используются для объединения данных из нескольких таблиц.
Внешний ключ позволяет реализовать операцию поиска парных строк между
таблицами. Например, объединяя таблицы
ПОКУПАТЕЛЬ
и
КОМПАНИЯ
с
помощью внешнего ключа Предпр, можно получить полную информацию о
покупателе.
Задание 2
1. Используя теорию нормализации, для заданного варианта предметной области
спроектировать многотабличную базу с эффективной структурой.
2. Изобразить таблицы со схемой взаимосвязи между ними.
Информация о работе Проектирование структуры реляционных баз данных