База данных «Склад промышленных товаров»

Характеристики товара могут совпадать, но индивидуальный код товара в ведомость  на товар совпадать не может.

Каждый товар имеет  индивидуальные характеристики:

а) Код товара;

б) Наименование товара;

в) Гарантийный срок обслуживания;

г) Доставка;

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

а) Название фирмы;

б) Страна;

в) Юридический адрес;

г) Телефон или факс.

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

О каждом сотруднике следует знать:

а) Код сотрудника;

б) Ф.И.О.

в) Должность.

 

2.2 Требования к информационной системе

 

С базой данных должны работать следующие группы пользователей:

1) Сотрудник;

2) Администрация;

3) Проверяющие органы.

При работе с системой сотрудник должен иметь возможность  решать следующие задачи:

Принимать новые ведомости и вносить их данные в базу данных;

1) Просматривать имеющиеся на складе товары от всех производителей, так и товар от отдельной фирмы;

2) Проверять остатки товара для прогнозирования закупок;

3) Регистрировать новых поставщиков, которые раньше не поставляли товар на склад;

4) Контролировать поступления товара.

Администрация должна иметь возможность:

1) Просматривать прием товара;

2) Контролировать правильность заполнения ведомости;

3) Для выбранной даты получить перечень поступившего товара.

Проверяющие органы должны иметь возможность:

1) Получать сведения о стоимости товара и торговых наценок;

2) Контролировать законность покупки товара;

3) Контролировать правильность заполнения документов. 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3 Постановка задачи на разработку базы данных

 

3.1 Семантическая модель данных

 

Разработку модели начнем с выделения основных сущностей  и связей между ними.

Прежде всего, существует сущность «Ведомость». Каждая ведомость имеет уникальный номер, который является ее ключом, и ряд атрибутов, которые взяты из описания предметной области. Наименование товара может повторяться. Для этого вводится сущность «Товар», которая будет содержать описания всех данных о товаре, которые не обходимы. Каждое наименование имеет уникальный код товара, который указывает на именование товара и его индивидуальные характеристики. Код товара и будет являться первичным ключом.

Между сущностями «Товар» и «Ведомость» существует связь (1:М), обязательная с двух сторон. Один товар может оформляться в разных ведомостях. Исходя из этого мы используем связь (1:М). Если на складе поступил товар, то необходима ведомость, подтверждающая поступление товара на склад. Это означает, что со стороны сущности «Ведомость» связь обязательная. Также товар поступивший на склад не может находится без оформленной ведомости, поэтому и со стороны «Товар» связь обязательна.

Один сотрудник может  заполнять за смену много экземпляров  ведомостей. При этом нам необходимо знать какой сотрудник заполнял данную ведомость. Для этого мы вводим дополнительную сущность «Сотрудник». Первичным ключом будет являться Код сотрудника.

Из анализа предметной области известно, что каждый сотрудник заполняет несколько ведомостей. Для отражения этой ситуации нам надо провести связь между сущностями «Ведомость» и «Сотрудник», т.к. у нас сотрудник за смену может заполнить не одну ведомость, а несколько ведомостей. При этом одну ведомость заполняет только один сотрудник поэтому тут устанавливается связь между сущностями  «Сотрудник»  и «Ведомость» (1:М). Между этими сущностями связь будет обязательна только с одной стороны, стороны сущность «Ведомость». Со стороны сущности «Сотрудник» связь необязательна, т. к. не все сотрудники внесенные в БД могут заполнять ведомость.   

Товар поступает от поставщиков. Определенный товар поставляет поставщик. Поэтому нам необходимо знать сведения, которые будут являться дополнительными атрибутами («Фирма», «Страна», «Адрес», «Телефон»). Первичным ключом будет являться Фирма. 

Чтобы знать  все сведения о поставщике мы вводим сущность «Поставщик». Один поставщик поставляет большое разнообразие товаров. Поэтому мы должны установить связь между двумя сущностями «Поставщик» и «Товар» (1:М). Каждый товар поставляет определенный поставщик и товар не может быть получен просто так. Поэтому устанавливаем обязательную связь с двух сторон.

Семантическая модель предметной области «Склад промышленных товаров» представлена на рисунке.1, а наборы атрибутов сущностей – на рисунке.2. Ключевые атрибуты выделены курсивом.

 

 

                                        М           М

                                  

                  

 

 

                 1                                                                              1

 

   М

 

   1

 

Рисунок 1 – Семантическая модель

 

Ведомость	Поставщик
№Ведомости	КодФирмы
Кол-во Товара	Страна
Стоимость Единицы	Адрес
Дата Составления	Телефон
Сотрудник	Товар
Код Сотрудника	Код Товара
Ф.И.О.	Наименование
Должность	Доставка
	Гарантийный Срок

 

Рисунок 2 – Набор атрибутов семантической модели

 

3.2 Логическая модель данных

 

Логическая модель данных является начальным прототипом будущей  базы данных. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (диаграммы сущность-связь).

Связь «Сотрудники - Ведомости» - так как связь  (1:М) и на стороне  М класс принадлежности сущности является обязательным, то по правилу  №4 строим две таблицы. Первичный  ключ сущности должен быть первичным  ключом соответствующей таблицы. Первичный ключ сущности «Сотрудники» (Код Сотрудника) на стороне 1 добавляется как атрибут в таблицу для сущности «Ведомости» на стороне М.

Связь «Товары - Ведомости» - так как связь  (1:М) и на стороне  М класс принадлежности сущности является обязательным, то по правилу №4 строим две таблицы. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности «Товары» (Код Товара) на стороне 1 добавляется как атрибут в таблицу для сущности «Ведомости» на стороне М.

Связь «Поставщики - Товары» - так как связь  (1:М) и на стороне М класс принадлежности сущности является обязательным, то по правилу №4 строим две таблицы. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности «Поставщики» (КодФирмы) на стороне 1 добавляется как атрибут в таблицу для сущности «Товары» на стороне М.

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

1. Минимизация избыточности данных
2. Минимальное использование отсутствующих значений
3. Предотвращение потери информации

Минимизировать избыточность данных позволяет процесс, называемый нормализацией таблиц. База данных считается эффективной, если все  ее таблицы находятся как минимум  в 3 НФ.

Проверяем на 1НФ.

Таблица находится в 1НФ, если все ее поля содержат только неделимые значения.

Таблицы Ведомость, Поставщик, Товар, Сотрудник удовлетворяют требованиям 1НФ.

Проверяем на 2НФ.

Таблица удовлетворяет  требованиям 2НФ, если она удовлетворяет  требованиям 1НФ и ее не ключевые поля функционально полно зависят от составного первичного ключа.

Так как у нас первичный  ключ не составной, таблицы соответствуют 2НФ.

Проверяем на 3НФ.

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

 В таблицах Ведомость, Сотрудник, Товар, Поставщик транзитивных зависимостей не наблюдается, следовательно, таблицы находятся в 3НФ, так как в них отдельно каждая запись есть отдельное независимое утверждение.

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

 

Рисунок 3 – Логическая модель данных

 

3.3 Определение физических характеристик атрибутов

 

Определим физические характеристики  атрибутов сущности «Ведомость», Физические атрибуты представлены в таблице 1.

 

Таблица 1 – Физические характеристики атрибутов сущности «Ведомость».

 

Характеристика Атрибут	Тип данных	Размер поля		Заполнение
№ Ведомости	Числовой	Длинное целое		Обязательное
Код товара	Числовой	Длинное целое		Необязательное
Код работника	Числовой	Длинное целое		Необязательное
Кол-во товара	Числовой	Длинное целое		Необязательное
Стоимость товара	Числовой	Длинное целое		Необязательное
Дата составления	Дата/время	Краткий формат даты	Необязательное

 

Определим физические характеристики  атрибутов сущности «Товар» Физические атрибуты представлены в таблице 2.

 

Таблица 2 – Физические характеристики атрибутов сущности «Товар».

 

Характеристика Атрибут	Тип данных	Размер поля	Заполнение
Код товара	Числовой	Длинное целое	Обязательное
Наименование	Текстовый	50	Необязательное
Доставка	Текстовый, Подстановка	50	Необязательное
КодФирмы	Текстовый, Подстановка	50	Необязательное
Гарантийный срок	Числовой	Длинное целое	Необязательное

 

Определим физические характеристики  атрибутов сущности «Поставщик» Физические атрибуты представлены в таблице 3.

 

Таблица 3 – Физические характеристики атрибутов сущности «Поставщик».

 

Характеристика Атрибут	Тип данных	Размер поля	Заполнение
КодФирмы	Текстовый, Подстановка	50	Обязательное
Страна	Текстовый, Подстановка	50	Необязательное
Адрес	Текстовый	50	Необязательное
Телефон	Текстовый	50	Необязательное

 

Определим физические характеристики  атрибутов сущности «Сотрудник» Физические атрибуты представлены в таблице 4.

 

Таблица 4 – Физические характеристики атрибутов сущности «Сотрудник».

 

Характеристика Атрибут	Тип данных	Размер поля	Заполнение
Код работника	Числовой	Длинное целое	Обязательное
ФИО	Текстовый	30	Необязательное
Должность	Текстовый	50	Необязательное