Проект реляционной базы данных Интернет-магазина

Недостатки реляционной модели

Достоинства реляционной модели

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

· При проектировании реляционных баз данных применяются строгие правила, базирующиеся на математическом аппарате.

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

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

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

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

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

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

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

· свести к минимуму избыточность хранения информации;

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

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

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

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

· создать для каждой сущности по одной таблице. Для каждой сущности, которая выступает во взаимоотношениях с другими сущностями как «один-ко-многим» или «один-к-одному», указать один столбец в качестве первичного ключа;

· для каждой сущности, которая выступает как «многие-к-одному» во взаимоотношениях с хотя бы с одной сущностью, указать в качестве внешних ключей первичные ключи каждой из родительских сущностей.

· задать первичный ключ для каждой сущности, выступающей во взаимоотношениях как «многие-к-одному».

Применим этот подход к построению логической модели базы данных Интернет-магазина.

Концептуальная модель (рис. 7.20 и табл.7.1) дает пять сущностей, из которых три – КНИГА, ПОКУПАТЕЛЬ и КУРЬЕР – выступают во взаимоотношениях только как «один-ко-многим». Первичные ключи для них уже определены: это ISBN-код книги, Код покупателя и Код курьера соответственно.

Сущность ЗАКАЗ выступает во взаимоотношении «многие-к-одному» с сущностями ПОКУПАТЕЛЬ и КУРЬЕР и во взаимоотношении один-ко-многим с сущностью КОРЗИНА ЗАКАЗА. Атрибуты Код покупателя и Код курьера сущности ЗАКАЗ являются первичными ключами сущностей ПОКУПАТЕЛЬ и КУРЬЕР и поэтому являются внешними ключами отношения ЗАКАЗ.

Первичным ключом отношения ЗАКАЗ является Код заказа.

Сущность КОРЗИНА ЗАКАЗА выступает во взаимоотношении «многие-к-одному» с сущностями ЗАКАЗ и КНИГА. Атрибуты Код заказа и ISBN-код книги сущности КОРЗИНА ЗАКАЗА являются первичными ключами сущностей ЗАКАЗ и КНИГА и поэтому являются внешними ключами отношения КОРЗИНА ЗАКАЗА.

Первичным ключом отношения КОРЗИНА ЗАКАЗА является совокупность атрибутов Код заказа, ISBN-код книги.

Логическая схема совокупности полученных отношений представлена на рис.7.23. Здесь жирным шрифтом выделены первичные ключи, а курсивом – внешние ключи.

Рис. 7.23 Логическая схема отношений

Теперь нужно проверить соответствие отношений третьей нормальной форме. Для нее должны быть выполнены следующие условия:

1. Отсутствуют многозначные атрибуты.

2. Все неключевые атрибуты отношения зависят от полного первичного ключа, а не от какой-то его части.

3. Все неключевые атрибуты отношения зависят только от первичного ключа и не зависят от других неключевых атрибутов.

Многозначность атрибутов снята на этапе концептуального проектирования. Так, мы предположили, что для каждого покупателя будет записан только один телефон, а не несколько. Если желательно вводить несколько телефонов, то нужно создавать новое отношение ТЕЛЕФОН и связывать его с отношением ПОКУПАТЕЛЬ. То же относится и к авторам книг. Все авторы книги будут вводиться одной строкой, и, следовательно, анализ продаж книг по отдельным авторам будет затруднителен. Если же такой анализ необходим, следует включить в базу данных дополнительное отношение АВТОРЫ. Для простоты картины мы этого делать не будем.

Неполная зависимость атрибутов. На этапе концептуального проектирования мы также устранили неполную зависимость атрибутов от первичного ключа для сущности ЗАКАЗ. Если в описание заказа включить заказанные книги, то первичным ключом будет совокупность атрибутов Код заказа, ISBN-кода книги. Тогда такие атрибуты как Дата заказа, Покупатель зависят только от кода заказа, а атрибут Количество экземпляров книги в заказе определяется и заказом и ISBN-кодом книги, то есть является атрибутом новой сущности КОРЗИНА ЗАКАЗА (см.рис. 7.18).

Зависимость от неключевых атрибутов. Рассмотрим отношение ЗАКАЗ из нашего примера. В нем присутствуют неключевые атрибуты Тип доставки и Цена доставки, причем цена доставки определяется типом доставки. Здесь мы имеем избыточность данных, так как цена доставки хранится для каждого заказа, хотя достаточно было ввести ее один раз при описании доставки данного типа. Кроме того, имеется так называемая аномалия модификации: при изменении в записи заказа значения атрибута Тип доставки всякий раз нужно изменять значение цены доставки.

Для устранения этих аномалий нужно устранить функциональную зависимость между неключевыми атрибутами. В результате исходное отношение разбивается на два, представленные в табл. 7.4, - ЗАКАЗ и ЦЕНА ДОСТАВКИ. Здесь для отношения ЗАКАЗ приведены не все неключевые атрибуты. Дублирование данных по ценам доставки и аномалия корректировки вида доставки здесь устранены. Цены для каждого вида доставки вводятся и корректируются независимо от конкретного заказа.

Таблица 7.4 Результат приведения отношения ЗАКАЗ к третьей нормальной форме
ЗАКАЗ			ЦЕНА ДОСТАВКИ
Код заказа	Код покупа-теля	Дата доставки	Тип доставки	Адрес доставки	Код курьера		Тип доставки	Цена доставки
		08/06/2001	Курьером по Москве	ул. Зеленая, 2-4		Курьером по Москве
		08/06/2001	Курьером по Москве	ул. Новая, 11-5		Курьером по области
		09/06/2001	Курьером по области	Зеленоград, ул. Новаторов, 3		Курьером по С.-Пб.
		09/06/2001	Курьером по С.-Пб.	Московский пр-т 12-125
		09/06/2001	Курьером по Москве	Пл. Ильича,15-68

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

ПОКУПАТЕЛЬ (Код покупателя, Организация, Фамилия, Имя, Отчество, Адрес электронной почты, Почтовый адрес)

ПОКУПАТЕЛЬ-ТЕЛЕФОН (Код покупателя, Телефон)

КНИГА (ISBN-код книги, Раздел литературы, Название, Авторы, Издательство, Год издания, Цена)

ЗАКАЗ (Код заказа, Код покупателя, Форма оплаты, Дата заказа, Дата доставки, Дата исполнения, Тип доставки, Код курьера, Адрес доставки, Примечание)

ЦЕНА ДОСТАВКИ (Тип доставки, Цена доставки)

КОРЗИНА ЗАКАЗА (Код заказа, ISBN-код книги, Количество экземпляров в заказе)

КУРЬЕР (Код курьера, Фамилия, Имя, Отчество, Дата рождения, Дата приема на работу, Рабочая смена)

Здесь ключевые атрибуты выделены жирным шрифтом, а внешние ключи – курсивом.

Связи между отношениями и соответствующие первичные и внешние ключи представлены на рис. 7.24.

Рис. 7.24. Логическая модель базы данных Интернет-магазина

Дата добавления: 2014-12-29