Разработка БД «Веломагазин»

Постановка задачи

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

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

Исходные данные:10 моделей велосипедов, 10 клиентов, 17 заказов Предметная область: Продажа велосипедов Входная информация: каталог велосипедов, бланк заказа, сведения о клиентах Выходная информация: запросы, формы, отчеты по срезам Клиент, Велосипед, Заказ Количественные ограничения: БД содержит информацию о 10 моделях велосипедов, о 10 клиентах, каждый клиент сформировал не менее 2-х заказов.

Разработка информационно-логической модели БД «Веломагазин»

При традиционной организации деятельность веломагазин находит свое отражение в таких документах как:

• — каталог велосипедов, содержащий все необходимые характеристики, модели;
• — бланк-заказа (договор купли-продажи) содержит всю информацию о заключенной сделке и сведения о клиенте;
• — карточка клиента (как правило, заполняется для постоянных клиентов) включает подробную информацию о клиенте. Ручная обработка всей информации без использования вычислительной техники не может выполняться оперативно, требует значительных временных и трудозатрат. Использование базы данных «Веломагазин» позволит оперативно накапливать, систематизировать и эффективно обрабатывать информацию по различным срезам, формировать отчеты, выявлять слабые звенья в системе продаж.

На первом этапе проектирования БД определяют: цель создания БД, ее функции и примерный перечень информации.

Целью создания БД «Веломагазин» является автоматизация учета информации по продаже велосипедов.

Функции проектируемой БД:

хранение информации о клиентах магазина;

хранение информации о продаваемых велосипедах;

хранение информации о сформированных заказах;

обновление и добавление информации;

анализ информации по различным срезам (клиент, велосипед, заказ) выдача итоговой информации в виде отчетов.

На основе анализа первичных документов предметной области можно выделить примерный перечень информации проектируемой БД :

фамилия, имя, отчество клиента магазина дата рождения, страна проживания, город проживания, телефон клиента модель велосипеда, характеристики велосипеда (количество передач, материал, цвет, тип велосипеда, страна производитель и т. п.).

заводская цена велосипеда издержки (транспортные и предпродажные) дата формирования заказа предоставляемые скидки, %.

сведения об оплате.

На втором этапе проектирования БД выделяют информационные объекты предметной области.

Функциональный анализ информации проектируемой БД позволяет выделить следующие информационные объекты: Клиент и Велосипед (рисунок 1).

Рисунок 1 — Информационные объекты предметной области «Продажа велосипедов».

В соответствии с понятиями реляционной СУБД каждому информационному объекту в проектируемой БД будет соответствовать таблица.

На третьем этапе проектирования БД определяют логическую структуру БД.

Реальные отношения между информационными объектами являются отношениями «многие-ко-многим». Такие отношения непосредственно не поддерживаются реляционными СУБД. Реальные отношения «многие-ко-многим» разбиваются на отношения «один-ко-многим» после ввода объекта-связки Заказ.

Для установления связей каждому объекту назначается ключ (ключевое поле). Причем ключи объектов Клиент и Велосиппед (первичные) должны присутствовать как внешние ключи в объекте Заказ (рисунок 2).

Рисунок 2 — Отношения 1: между информационными объектами В реляционной модели вышеуказанным информационным объектам соответствуют двумерные таблицы-отношения: Клиент, Велосипед, Заказ. Логические связи между двумерными таблицами осуществляются при помощи ключевых полей.

Важным требованием, предъявляемым к таблицам, является нормализация данных, которая позволяет минимизировать повторение данных.

Третья норма данных расширяет две предыдущие, неся в себе два правила:

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

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

Получен список полей для каждой таблицы.

Список полей с указанием типов данных приведен ниже.

Таблица Клиент (главная таблица) Код клиента (счетчик, поле первичного ключа) Фамилия (текстовый) Имя (текстовый) Отчество (текстовый) Дата рождения (дата время) Страна проживания (текстовый) Город проживания (текстовый) Телефон (текстовый) Таблица Велосипед (главная таблица) Код модели (числовой, поле первичного ключа) Тип велосипеда (текстовый) Модель (числовой) Цвет (текстовый) Количество передач (числовой) Материал (текстовый) Страна производитель (текстовый) Заводская цена (денежный) Транспортные издержки (денежный) Предпродажные издержки (денежный) Таблица Заказ (таблица-связка) Код заказа (счетчик, поле первичного ключа) Код клиента (числовой, поле внешнего ключа) Код Велосипеда (числовой, поле внешнего ключа) Дата заказа (дата/время) Скидка, %(числовой, процентный формат) Оплачено (логический) На рисунке 3 приведена информационно-логическая модель заданной предметной области.

Рисунок 3 — Информационно-логическая модель предметной области.