Министерство образования и науки Республики Казахстан

ВОСТОЧНО-КАЗАХСТАНСКИЙ РЕГИОНАЛЬНЫЙ УНИВЕРСИТЕТ

Кафедра «Техника, энергетика и информационные системы»

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

к курсовой работе

по дисциплине «Проектирование баз данных»

На тему: Разработка базы данных учета и анализа реализации строительных материалов из магазина

Выполнил: студент гр.07-101-ВТ

Чепурнова Зинаида

Проверил: Кривоногова Л. М.

Усть-Каменогорск, 2010
СОДЕРЖАНИЕ

1. 
   ВВЕДЕНИЕ
   

Предмет разработки: база данных «Магазин строительных материалов»

Общая цель разработки: база данных «Магазин строительных материалов» должна позволять вводить, изменять, удалять и выводить в виде отчетов на экран.

Основные задачи разработки:

1. 
   Разработать таблицы и представления;
   
2. 
   Разработать отчеты для вывода информации;
   
3. 
   Реализовать разработку с помощью заданного программного инструментария.
   

Программный инструментарий: Microsoft Visual FoxPro 6.0.

2. ОСНОВНАЯ ЧАСТЬ
2.1. Описание и системный анализ предметной области

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

Магазин носит название «СтройСити». К нему прикреплены несколько складов, на которых работают кладовщики. Важно знать, сколько людей здесь работает, их возраст и оклад. У каждого работника имеется свой индивидуальный номер удостоверения личности. Поставщики поставляют товар на склады, откуда потом его реализуют продавцы. Необходимо вести учет того, какой товар поставляется, в каком количестве и по какой цене. А так же через какое время его реализовали, сколько и с какого склада – можно определить по паспортным данным кладовщика. Кроме того, после поставки товара, необходимо обновлять записи о его количестве и, возможно, цене. И, соответственно, должен удаляться реализованный товар. Была бы полезна информация о том, какова общая сумма всех товаров на каждом складе, сколько дней он там лежит.

Установим атрибуты, которые должны содержаться в базе данных. Для каждого атрибута должно быть определено множество возможных значений. Перечислим имена атрибутов и их краткие характеристики:
Адрес – место нахождения склада или поставщика (пример возможного значения: г.Усть-Каменогорск, ул.Пролетарская,57).

Телефон – телефон склада, поставщика (возможное значение: 76-61-85).

РНН – регистрационный номер налогоплательщика (пример возможного значения: 181811641729).

Фамилия – фамилия работника или клиента магазина.

Имя – имя работника или клиента магазина.

Отчество – отчество работника или клиента магазина.

Номер удостоверения личности – паспортные данные работника магазина (пример возможного значения: 3805 351501).

Дата рождения – год рождения работника магазина (пример возможного значения: 1973).

Должность – должность, занимаемая работником магазина (возможные значения: директор, продавец, кладовщик, охранник).

Оклад – оклад работников (диапазон возможных значений: 3000-15000 тг.).

Код товара – индивидуальный код товара (пример возможного значения: 325).

Наименование товара – наименование товара (пример возможных значений: Ламинат, Линолеум, Керамическая плитка, MDF, Цемент, Сайдинг).

Кол-во – количество товара, находящегося на складе, проданного или поступившего (диапазон: 1-1000).

Производитель – название страны, производящей продукцию (возможные значения: Россия, Италия ).

№ склада – номер склада (№1, №2).

Название фирмы – название фирмы поставщика (пример: «Вальтек»).

Накладная № - номер накладной по поставке (пример: 128).

№ кассового чека – номер кассового чека продажи (8938).

Дата – дата поставки или реализации (пример: 18.09.2005).

Цена – цена товара (пример возможного значения: 50тг.).
При обследовании предметной области выделен атрибутивный состав, приведенный в Таблице 1.
Таблица 1. Множество атрибутов

№	НАИМЕНОВАНИЕ АТРИБУТА	ИДЕНТИФИКАТОР
1	Адрес клиента	Адр_клт
2	Адрес склада	Адр_скл
3	Адрес поставщика	Адр_пост
4	Наименование фирмы	Наим_фирм
5	Дата покупки	Дата_пок
6	Дата реализации	Дата_реализ
7	№ кассового чека	Ном_кас_чека
8	Накладная №	Ном_наклад
9	Цена при покупке	Цена_пок
10	Стоимость при продаже	Стоим_прод
11	№ склада	Ном_склада
12	Производитель	Произв
13	Количество купленного товара	Кол_куп
14	Количество проданного товара	Кол_прод
15	Наименование товара	Наим_тов
16	Код товара	Код_тов
17	Оклад	Оклад
18	Должность	Долж
19	Дата рождения	Дата_рожд
20	Код работника	Код_раб
21	Код клиента	Код_клт
22	Отчество работника	Отч_раб
23	Имя работника	Имя_раб
24	Фамилия работника	Фам_раб
25	Фамилия клиента	Фам_клт
26	Имя клиента	Имя_клт
27	Отчество клиента	Отч_клт
28	РНН поставщика	РНН
29	Телефон клиента	Тел_клт
30	Телефон склада	Тел_склада
31	Телефон поставщика	Тел_пост

2.2 Исследование документооборота
В результате решения задачи необходимо выполнить разработку подсистемы ведения данных и спроектировать следующие входные документы (запросы пользователей):

• 
  Справка по учету поставщиков товара;
  
• 
  Ведомость о поставках товара;
  
• 
  Справка об учете товара на складе;
  
• 
  Справка о реализации товара;
  
• 
  Ведомость о работниках магазина.
  

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

Таблица 2. Использование атрибутов в запросах

№	Идентификатор атрибута	Запросы
		Справка по учету поставщиков товара	Ведомость о поставках товара	Справка об учете товара на складе	Справка о реализации товара	Ведомость о работниках магазина
1	Адр_клт				*
2	Адр_скл			*		*
3	Адр_пост	*	*
4	Наим_фирм	*	*
5	Дата_пок		*
6	Дата_реализ				*
7	Ном_кас_чека				*
8	Ном_наклад		*
9	Цена_пок		*
10	Стоим_прод				*
11	Ном_склада			*		*
12	Произв			*
13	Кол_куп		*
14	Кол_прод				*
15	Наим_тов	*	*	*	*
16	Код_тов	*	*	*	*
17	Оклад					*
18	Долж					*
19	Дата_рожд					*
20	Код_раб					*
21	Код_клт				*
22	Отч_раб					*
23	Имя_раб					*
24	Фам_раб					*
25	Фам_клт				*
26	Имя_клт				*
27	Отч_клт				*
28	РНН	*	*
29	Тел_клт				*
30	Тел_склада			*		*
31	Тел_пост	*

2.3. Инфологическое проектирование БД.
2.3.1. Выделение сущностей

Для разработки инфологической модели предметной области необходимо:

• 
  Выделить сущности;
  
• 
  Выделить атрибуты (информационные элементы).
  

Выделим следующие сущности: ПЕРСОНАЛ, ТОВАР, ОПЕРАЦИЯ КУПЛИ, ОПЕРАЦИЯ ПРОДАЖИ.
На основании обследования предметной области и необходимых запросов выделим следующие сущности с атрибутами (ключевые атрибуты выделены подчеркиванием):

ПЕРСОНАЛ (ФАМИЛИЯ РАБОТНИКА, ИМЯ РАБОТНИКА, ОТЧЕСТВО РАБОТНИКА, ДОЛЖНОСТЬ, ОКЛАД, КОД РАБОТНИКА, ДАТА РОЖДЕНИЯ)
ТОВАР (КОД ТОВАРА, НАИМЕНОВАНИЕ ТОВАРА, ПРОИЗВОДИТЕЛЬ, НОМЕР СКЛАДА, КОД РАБОТНИКА, АДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА)
ОПЕРАЦИЯ КУПЛИ (НОМЕР НАКЛАДОЙ, ДАТА ПОКУПКИ, СТОИМОСТЬ ПОКУПКИ, КОЛИЧЕСТВО ЗАКАЗАННОГО ТОВАРА, РНН ПОСТАВЩИКА, НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА, КОД ТОВАРА)
ОПЕРАЦИЯ ПРОДАЖИ (НОМЕР КАССОВОГО ЧЕКА, ДАТА РЕАЛИЗАЦИИ, КОЛИЧЕСТВО ПРОДАННОГО ТОВАРА, ЦЕНА ТОВАРА, ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА, КОД КЛИЕНТА,
КОД ТОВАРА)
2.3.2. Разработка инфологической модели «сущность-связь»

Название сущностей	Название связей
ПЕРСОНАЛ, ТОВАР	Продажа
ТОВАР, ОПЕРАЦИЯ КУПЛИ	Приобретение
ТОВАР, ОПЕРАЦИЯ ПРОДАЖИ	Реализация

После того, как выбраны сущности и заданы атрибуты, установлены связи между сущностями, проектируем концептуальную схему БД в виде ER-диаграммы (Рисунок 1), где сущности обозначаются прямоугольниками, а связи – ромбами.

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

«Строительный магазин»
Связь ПРОДАЖА является связью типа М:М, так как персонал (продавец, кладовщик) может продать несколько товаров, и в реализации товара задействовано несколько человек. Сущности ПЕРСОНАЛ и ТОВАР относятся к обязательному классу принадлежности, вследствие того, что товар должен обязательно реализовываться персоналом.

Связь ПРИОБРЕТЕНИЕ является связью типа М:М, так как поставляется товары нескольких наименований и различными поставщиками. Сущности ОПЕРАЦИЯ КУПЛИ
и ТОВАР в данной связи имеет обязательный класс принадлежности, так как у каждого товара обязательно есть свой поставщик.

Связь РЕАЛИЗАЦИЯ является связью типа М:М, так как клиенты могут приобретать множество товаров. Сущность ОПЕРАЦИЯ ПРОДАЖИ имеет обязательный класс принадлежности, так как товар обязательно приобретается клиентом. Сущность ТОВАР в данной связи имеет необязательный класс принадлежности, так как у каждого товара необязательно есть свой клиент.

2.4. Логическое проектирование БД
2.4.1. Нормализация отношений реляционной модели данных
Под нормализацией отношения подразумевается процесс приведения отношения к одной из так называемых нормальных форм (или в дальнейшем НФ).

 Для поддержания БД в устойчивом состоянии используется ряд механизмов, которые получили обобщенное название средств поддержки целостности. Эти механизмы применяются как статически (на этапе проектирования БД), так и динамически (в процессе работы с БД). Приведение структуры БД в соответствие этим ограничениям – это и есть нормализация.

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

 На практике, как правило, ограничиваются 3НФ, ее оказывается вполне достаточно для создания надежной схемы БД.

1. 
   ТОВАР (КОД ТОВАРА, НАИМЕНОВАНИЕ ТОВАРА, ПРОИЗВОДИТЕЛЬ, НОМЕР СКЛАДА, КОД РАБОТНИКА, АДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА)
   

• 
  Учет товара ведется по коду товара. Код товара – уникален и является первичным ключом.
  
• 
  Все атрибуты являются атомарными, следовательно, отношения находятся в 1НФ.
  
• 
  Первичный ключ – простой и функциональная зависимость всех неключевых атрибутов от первичного ключа – полная, следовательно, отношение находится во 2НФ.
  
• 
  Все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношение находится в 3НФ.
  

Но так как один и тот же товар может храниться на разных складах то часть атрибутов зависит от неключевого атрибута НОМЕР СКЛАДА.

НОМ_СКЛАДА àАДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА

Таким образом, зависимости КОД ТОВАРА à АДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА являются транзитивными. Следовательно нам необходимо провести декомпозицию отношения ТОВАР на отношения:
ТОВАР (КОД ТОВАРА, НАИМЕНОВАНИЕ ТОВАРА, ПРОИЗВОДИТЕЛЬ, НОМЕР СКЛАДА);
СКЛАД (НОМЕР СКЛАДА, АДРЕС СКЛАДА, ТЕЛЕФОН СКЛАДА, КОД РАБОТНИКА)
В данных отношениях все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношения находятся в 3НФ.

2. 
   ПЕРСОНАЛ (ФАМИЛИЯ РАБОТНИКА, ИМЯ РАБОТНИКА, ОТЧЕСТВО РАБОТНИКА, ДОЛЖНОСТЬ, ОКЛАД, КОД РАБОТНИКА, ДАТА РОЖДЕНИЯ)
   

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

код работника à [все атрибуты]

• 
  Учет персонала магазина ведется по личному номеру работника. Личный номер каждого работника – уникален. В данном отношении первичным ключом является атрибут код работника.
  
• 
  Все атрибуты являются атомарными, следовательно, отношение находится в 1НФ.
  
• 
  Первичный ключ – простой и функциональная зависимость всех неключевых атрибутов от первичного ключа – полная, следовательно, отношение находится во 2НФ.
  
• 
  Все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношение находится в 3НФ.
  

3. 
   ОПЕРАЦИЯ КУПЛИ (НОМЕР НАКЛАДОЙ, ДАТА ПОКУПКИ, СТОИМОСТЬ ПОКУПКИ, КОЛИЧЕСТВО ЗАКАЗАННОГО ТОВАРА, РНН ПОСТАВЩИКА, НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА, КОД ТОВАРА)
   

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

• 
  Все атрибуты являются атомарными, следовательно, отношение находится в 1НФ.
  

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

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

Но так как операции покупки товара могут выполняться у различных поставщиков то часть атрибутов зависит от неключевого атрибута РНН ПОСТАВЩИКА.

РНН ПОСТАВЩИКА  НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА

Таким образом зависимости НОМЕР НАКЛАДНОЙ  НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА являются транзитивными. Следовательно нам необходимо провести декомпозицию отношения ОПЕРАЦИЯ купли на отношения:

- поставщик (РНН ПОСТАВЩИКА, НАИМЕНОВАНИЕ ФИРМЫ, АДРЕС ПОСТАВЩИКА, ТЕЛЕФОН ПОСТАВЩИКА, КОД ТОВАРА);

- ОПЕРАЦИЯ купли (НОМЕР НАКЛАДОЙ, ДАТА ПОКУПКИ, СТОИМОСТЬ ПОКУПКИ, КОЛИЧЕСТВО ЗАКАЗАННОГО ТОВАРА, КОД ТОВАРА)

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

4. 
   ОПЕРАЦИЯ ПРОДАЖИ (НОМЕР КАССОВОГО ЧЕКА, ДАТА РЕАЛИЗАЦИИ, КОЛИЧЕСТВО ПРОДАННОГО ТОВАРА, ЦЕНА ТОВАРА, ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА, КОД КЛИЕНТА,
   КОД ТОВАРА)
   

Учет операций купли товара ведется по номеру кассового чека продажи товара, который является уникальным для каждой операции. Тогда в качестве первичного ключа можно использовать атрибут НОМЕР КАССОВОГО ЧЕКА.

• 
  Все атрибуты являются атомарными, следовательно, отношение находится в 1НФ.
  

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

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

Но так как операции продажи товара могут выполняться различным клиентам, то часть атрибутов зависит от неключевого атрибута КОД КЛИЕНТА.

КОД КЛИЕНТА  ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА

Таким образом зависимости НОМЕР КАССОВОГО ЧЕКА  ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА являются транзитивными. Следовательно нам необходимо провести декомпозицию отношения ОПЕРАЦИЯ ПРОДАЖИ на отношения:

- КЛИЕНТЫ (ФАМИЛИЯ КЛИЕНТА, ИМЯ КЛИЕНТА, ОТЧЕСТВО КЛИЕНТА, АДРЕС КЛИЕНТА, ТЕЛЕФОН КЛИЕНТА, КОД КЛИЕНТА);
- ОПЕРАЦИЯ ПРОДАЖИ (НОМЕР КАССОВОГО ЧЕКА, ДАТА РЕАЛИЗАЦИИ, КОЛИЧЕСТВО ПРОДАННОГО ТОВАРА, ЦЕНА ТОВАРА, КОД ТОВАРА)
В данных отношениях все неключевые атрибуты функционально зависят от первичного ключа, других функциональных зависимостей нет, следовательно, отношения находятся в 3НФ.
Таким образом, в результате приведения отношений к 3НФ получили следующие отношения: КЛИЕНТЫ, ПОСТАВЩИКИ, СКЛАД, ОПЕРАЦИЯ КУПЛИ, ОПЕРАЦИЯ ПРОДАЖИ, ТОВАР, ПЕРСОНАЛ.
Для организации информационной базы будем использовать реляционную СУБД. Поэтому должна быть разработана логическая структура реляционной базы данных, на основе которой будет осуществляться решение задачи.

Логическая структура реляционной базы данных определяется совокупностью логически взаимосвязанных реляционных таблиц. Каждая реляционная таблица имеет структуру, определяемую реквизитным составом одного из информационных объектов полученной ИЛМ. Логические связи таблиц соответствуют структурным связям между объектами. Логическая структура реляционной базы данных, построенная на основе полученной ИЛМ, приведена на рис.2. На этой схеме реляционные таблицы представлены структурой, определяемой составом и последовательностью полей (атрибутов). Ключи выделены подчеркиванием. Логические связи изображены линиями между одинаковыми ключами связи.


Рисунок 2. Реляционная модель БД
2.4.2 Разработка схем документов и запросов пользователей

1. 
   ТОВАР
   

Код товара	Наименование товара	Производитель
Число	Символ	Символ
10	30	30

2. 
   СКЛАД
   

Номер склада	Адрес склада	Телефон склада	Код работника
Число	Символ	Число	Число
3	50	11	10

3. 
   ПЕРСОНАЛ
   

Фамилия работника	Имя работника	Отчество работника	Должность	Оклад	Код работника	Дата рождения
Символ	Символ	Символ	Символ	Число	Число	Дата
20	15	20	30	6	10	8

4. 
   поставщик
   

РНН поставщика	Наименование поставщика	Адрес поставщика	Телефон поставщика	Код товара
Число	Символ	Символ	Число	Число
12	30	50	11	10

5. 
   ОПЕРАЦИЯ КУПЛИ
   

Номер накладной	Дата покупки	Стоимость покупки	Количество заказанного товара	Код товара	РНН поставщика
Число	Дата	Число	Число	Число	Число
10	8	8	4	10	12

6. 
   КЛИЕНТЫ
   

Фамилия клиента	Имя клиента	Отчество клиента	Адрес клиента	Телефон клиента	Код клиента
Символ	Символ	Символ	Символ	Число	Число
20	15	20	50	11	10

7. 
   ОПЕРАЦИЯ ПРОДАЖИ
   

Номер кассового чека	Дата реализации	Количество проданного товара	Цена товара	Код товара	Код клиента
Число	Дата	Число	Число	Число	Число
10	8	4	8	10	10

• 
  Справка по учету поставщиков товара
  

Для реализации этого запроса потребуются следующие данные:

• 
  Ведомость о поставках товара
  

Для реализации этого запроса потребуются следующие данные:

• 
  Справка по учету товара на складе
  

Для реализации этого запроса потребуются следующие данные:

• 
  Справка о реализации товара
  

Для реализации этого запроса потребуются следующие данные:

• 
  Ведомость о работниках магазина
  

Для реализации этого запроса потребуются следующие данные: