Microsoft Access

лабораторная работа

1.1 Пример проектирования базы данных

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

Этап 1. Определение типов сущностей.

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

Этап 2. Определение типов связей.

Установим связи между объектами. Один покупатель может неоднократно покупать товары. Поэтому между объектами ПОКУПАТЕЛЬ и ОТПУСК имеется связь "один - ко - многим". Каждый покупатель может приобрести несколько различных товаров. Поэтому между объектами ТОВАР и ОТПУСК имеется связь "один - ко - многим".

Этап 3. Определение атрибутов и связывание их с типами сущностей и связей.

Распределим признаки, указанные в задании, по выделенным типам сущностей. К объекту ТОВАР относятся такие характеристика как название, тип, цена. К объекту ПОКУПАТЕЛЬ - имя, фирма, город, телефон. Тип сущности ОТПУСК может быть охарактеризован такими признаками как дата и количество проданного товара.

Этап 4. Определение доменов (допустимых значений) атрибутов.

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

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

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

Для таблицы ОТПУСК первичным ключом является поле НомерПокупки, т.к. однозначно определяет дату, покупателя и другие элементы данных.

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

Установим связи между таблицами. Один покупатель может неоднократно покупать товары. Поэтому между таблицами ПОКУПАТЕЛЬ и ОТПУСК имеется связь "один - ко - многим" по полю КодПокупателя.

Каждый покупатель может приобрести несколько различных товаров. Поэтому между таблицами ТОВАР и ОТПУСК имеется связь "один - ко -многим" по полю КодТовара.

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

Делись добром ;)