Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ,

МОЛОДЕЖИ И СПОРТА УКРАИНЫ

ДОНЕЦКИЙ НАЦИОНАЛЬНЫЙ УНИВЕРСИТЕТ

КАФЕДРА ЭКОНОМИЧЕСКОЙ КИБЕРНЕТИКИ

КУРСОВАЯ РАБОТА

По дисциплине: «Информационные системы в экономике»

Разработка информационной системы деятельности отдела гарантийного ремонта товаров фирмы «Народная торговая компания»

Донецк - 2011г.

ВВЕДЕНИЕ

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

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

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

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

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

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

ВАРИАНТ ЗАДАНИЯ ДЛЯ ВЫПОЛНЕНИЯ КУРСОВОЙ РАБОТЫ

Вариант 9. Разработать прикладное программное обеспечение деятельности отдела гарантийного ремонта товаров фирмы "Народная торговая компания". Это предприятие -- лидер продаж кондиционеров, телевизоров и другой бытовой техники в городе. Хорошо известно, что техника часто выходит из строя, причем уже в период гарантийного срока, а в этом случае продавец товара должен бесплатно отремонтировать его. Ежедневно в отдел гарантийного ремонта обращается несколько десятков человек, купивших технику в этой компании. Вы, скорее всего, также побывали в отделе гарантийного ремонта, что очень поможет при разработке программного обеспечения.

База данных создается на предприятии.

РАЗДЕЛ 1. ИНФОРМАЦИОННОЕ ПРОСТРАНСТВО ПРЕДМЕТНОЙ ОБЛАСТИ «НАРОДНАЯ ТОРГОВАЯ КОМПАНИЯ»

1.1 Описание предметной области, цели и задачи управления

Предметная область «Народная торговая компания» представляет собой процесс по ремонту бытовой техники в гарантийный период. База данных создается на уровне филиалов компании для учета проданного товара и отремонтированного товара.

Основные сущности предметной области: филиалы, товары, изготовители, покупатели, продажа, ремонт.

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

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

Изготовители характеризуются наименованием изготовителя, ИНН, его адресом, номерами факса и телефона, а также адресами электронной почты и Web-страницы.

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

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

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

Задача управления состоит в учете компанией отремонтированного товаров.

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

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

1.2 Функциональная структура документа как элемента информационного пространства предметной области

В результате обследования предметной области установлено:

§ В документе фиксируется информация о конкретной компании с филиалами, на которых обеспечивается продажа и гарантийный ремонт бытовой техники;

§ В базе данных зафиксирована информация обо всех филиалах, т.к. данная база составляется на уровне компании;

§ Указанные филиалы занимаются продажей бытовой техники и приемом ее на ремонт;

§ Название филиалов фиксируются регистрационным номером, начиная с 1;

§ В базе данных фиксируются изготовители бытовой техники, которые продаются данной компанией;

§ Изготовитель определяется индикационным номером;

§ Компания располагает данными о товарах и покупателях;

§ Товар определяется штрих-кодом, указанным в документе;

§ Наименования отдельных видов товаров не являются уникальными, конкретный вид товара определяется лишь его штрих-кодом;

§ Продажа данной продукции фиксируется на филиалах и определяется штрих-кодом товара и датой продажи;

§ Наименования отдельных покупателей не уникальны, конкретный покупатель определяется с помощью его идентификатора;

§ Гарантийный ремонт фиксируется на филиалах, где указывается дата приема и получения, а так же оставшийся срок гарантии;

§ Ремонт определяется примечанием и из этого указывается стоимость ремонта.

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

Таблица 1. Характеристика атрибутов документа

№	Поле	Тип	Размер	Описание
1	IDfilial	Числовой	1	Регистрационный номер филиала
2	Filial	Текстовый	20	Название филиала предприятия
3	InnFilial	Текстовый	10	ИНН филиала предприятия
4	Chief	Текстовый	60	Руководитель филиала
5	Capacity	Числовой	3	Количество работающих на ремонте
6	Address	Текстовый	60	Адрес филиала предприятия
7	Phone	Текстовый	12	Номер телефона филиала
8	GoodsID	Текстовый	15	Штрих-код товара
9	Goods	Текстовый	40	Название товара или прибора
10	Categoty	Текстовый	20	Категория (утюг, миксер)
11	Country	Текстовый	20	Страна-производитель
12	Company	Текстовый	40	Изготовитель
13	Picture	Поле объекта OLE	Авто	Фотография товара или прибора
14	INNcompany	Текстовый	10	ИНН изготовителя
15	AddressComp	Текстовый	60	Адрес изготовителя
16	DateStart	Дата/время	Авто	Дата изготовления товара
17	Period	Числовой	4	Гарантийный период
18	DateBuy	Дата/время	Авто	Дата покупки
19	Cost	Денежный	15	Стоимость товара
20	Fax	Текстовый	12	Номер факса компании
21	PhoneCompany	Текстовый	12	Телефон компании
22	Email	Текстовый	20	Адрес электронной почты компании
23	Web	Текстовый	20	Адрес Web-страницы
24	CostRepair	Денежный	15	Стоимость ремонта
25	CustomerID	Числовой	5	Идентификатор покупателя
26	Customer	Текстовый	60	Покупатель
27	AddressCust	Текстовый	60	Адрес покупателя
28	Comment	Поле Memo	Авто	Примечания (что было сделано)
29	Sign	Логический	1	Признак покупателя (юр./физ. лицо)
30	Guarantee	Числовой	5	Оставшийся гарантийный срок
31	StartDate	Дата/время	Авто	Дата приемки в ремонт
32	StopDate	Дата/время	Авто	Дата получения
33	RepairID	Текстовый	6	Номер накладной

1.3 Построение составной единицы информации (СЕИ)

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

В аналитической форме модель СЕИ, построенная на основе документа, будет иметь следующий вид:

Warranty repairs (1, n) (Filial (1, m) (Filial, IDfilial, InnFilial, Chief, Capacity, Address, Phone) (Repair (1, k) (CostRepair, Comment, Guarantee, StartDate, StopDate, RepairID) (Customer (Customer, CustomerID, AddressCust, Sign); Goods (1, j) (Goods, GoodsID, Categoty, Country, Company, Picture, INNcompany, AddressComp, DateStart, Period, DateBuy, Cost, Fax, PhoneCompany, Email, Web))))

где:

Warranty repairs, Filial, Repair, Customer, Goods- название составных единиц информации. Соответственно, составная единица информации Warranty repairs представляет документ в целом и включает в себя составную единицу Filial, который в свою очередь включает в себя Repair, включающий в себя составные единицы Goods и Customer с их соответствующими атрибутами;

(1, n) - возможное количество от 1 до n документов данного вида;

(1, m) - допустимое количество филиалов от 1 до m.

(1, k) - возможное количество накладных по ремонту от 1 до k на каждом филиале.

(1, j) - потенциальное количество товаров от 1 до j, полученных на ремонт.

В графической форме СЕИ будет иметь вид:

Warranty repairs

1 2 … n

Filial

1 2 … m

Repair

1 2 k

Goods Customer

1 2 j

Далее заполним полученную в табличной форме составную единицу информации информационными данными. Тогда значение табличной формы СЕИ Warranty repairs будет иметь следующий вид

Warranty repairs

Filial

Filial

IDfilial

InnFilial

Chief

Capacity

Address

Phone

Repair

CostRepair

Comment

Guarantee

StartDate

StopDate

RepairID

Customer

Goods

Customer

CustomerID

AddressCust

Sign

Goods

GoodsID

Categoty

Country

Company

Picture

INNcompany

AddressComp

DateStart

Period

DateBuy

Cost

Fax

PhoneCompany

Email

Web

Domo

2

0609173001

Ткачев С. Н.

24

г. Донецк, пр. Ильича, 18

(0622) 959748

-

Чистка фильтров

3 мес.

15.04.2011

20.04.2011

150406

Ивонов И. И.

04875

М-30, пл. Грибиниченко 3/45

Физ. лицо

Philips GC 3321

25648730

утюг

Китай

Magnum

Приложено

5260036661

г. Липецк, ул. Терешковой, 35Б

25.03.2009

2 года

30.07.2009

249 грн

(4742) 345784

(4742) 517624

istyle-gorod@mail.ru

www.istyle.su

Lux

4

1146758222

Тицкий В. А.

15

г. Макеевка, пр. Ленина, 140-А

(06232) 225748

150 грн

Замена звуковой панели

0 мес.

24.05.2011

30.05.2011

240501

Ильяшенко А. А.

05746

М-30, пл. Грибиниченко 4/123

Физ. лицо

Bosch WAA 20262

42124016

Стиральная машина

Германия

BoschServis

Приложено

7615487223

г. Троицк, Калужское шоссе, 22

12.08.2007

3 года

09.09.2007

899 грн

(495) 7759402

(495) 7759503

bosch-servis@mail.ru

www.bosch.ru

-

Чистка трубок

1 год

25.05.2011

27.05.2011

250501

Bosch KAN 56V45

45712264

Холодильник

Приложено

17.03.2009

3 года

28.06.2009

10033 грн

Составная единица информации, содержащая данные в приведенной выше форме, представляет собой не нормализованную СЕИ. Это объясняется тем, что атрибуты CostRepair, Comment, Guarantee, StartDate, StopDate, RepairID, Goods, GoodsID, Categoty, Picture, DateStart, Period, DateBuy, Cost, имеют кортежи значений по сравнению с атрибутами Filial, IDfilial, InnFilial, Chief, Capacity, Address, Phone, Customer, CustomerID, AddressCust, Sign, Country, Company, INNcompany, Fax, PhoneCompany, Email, Web AddressComp, которые имеют по одному значению в каждом документе представленном в таблице. Такая не нормализованная СЕИ не может быть таблицей базы данных. Соответственно появляется объективная необходимость ее нормализации. Для этого пустые строки табличной формы составной единицы информации заполняются недостающими данными, в результате чего полученная нами СЕИ может быть таблицей базы данных.

Итак, после нормализации получим следующую универсальную таблицу Warranty repairs или реляционную схему базы данных, представленную одной таблицей:

Warranty repairs

Filial

Filial

IDfilial

InnFilial

Chief

Capacity

Address

Phone

Repair

CostRepair

Comment

Guarantee

StartDate

StopDate

RepairID

Customer

Goods

Customer

CustomerID

AddressCust

Sign

Goods

GoodsID

Categoty

Country

Company

Picture

INNcompany

AddressComp

DateStart

Period

DateBuy

Cost

Fax

PhoneCompany

Email

Web

Domo

1

0609173001

Ткачев С. Н.

24

г. Донецк, пр. Ильича, 18

(0622) 959748

-

Чистка фильтров

3 мес.

15.04.2011

20.04.2011

150406

Ивонов И. И.

04875

М-30, пл. Грибиниченко 3/45

Физ. лицо

Philips GC 3321

25648730

утюг

Китай

Magnum

Приложено

5260036661

г. Липецк, ул. Терешковой, 35Б

25.03.2009

2 года

30.07.2009

249 грн

(4742) 345784

(4742) 517624

istyle-gorod@mail.ru

www.istyle.su

Lux

4

1146758222

Тицкий В. А.

15

г. Макеевка, пр. Ленина, 140-А

(06232) 225748

150 грн

Замена звуковой панели

0 мес.

24.05.2011

30.05.2011

240501

Ильяшенко А. А.

05746

М-30, пл. Грибиниченко 4/123

Физ. лицо

Bosch WAA 20262

42124016

Стиральная машина

Германия

BoschServis

Приложено

7615487223

г. Троицк, Калужское шоссе, 22

12.08.2007

3 года

09.09.2007

899 грн

(495) 7759402

(495) 7759503

bosch-servis@mail.ru

www.bosch.ru

Lux

4

1146758222

Тицкий В. А.

15

г. Макеевка, пр. Ленина, 140-А

(06232) 225748

-

Чистка трубок

1 год

25.05.2011

27.05.2011

250501

Ильяшенко А. А.

05746

М-30, пл. Грибиниченко 4/123

Физ. лицо

Bosch KAN 56V45

45712264

Холодильник

Германия

BoschServis

Приложено

7615487223

г. Троицк, Калужское шоссе, 22

17.03.2009

3 года

28.06.2009

10033 грн

(495) 7759402

(495) 7759503

bosch-servis@mail.ru

www.bosch.ru

РАЗДЕЛ 2. УНИВЕРСАЛЬНАЯ ТАБЛИЦА КАК БАЗА ДАННЫХ

2.1 Универсальная таблица: проблемы вставки, удаления, корректировки информационных данных

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

База данных, состоящая из одной таблицы, с большой вероятностью будет иметь указанные проблемы.

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

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

Проверим данное утверждение на нашем примере.

Проблема вставки

Проблема вставки может возникнуть при вводе какого-либо нового вида информации.

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

В этом случае информационные данные в таблице Warranty repairs будут представлены в следующем виде:

Warranty repairs

Filial

Filial

IDfilial

InnFilial

Chief

Capacity

Address

Phone

Repair

CostRepair

Comment

Guarantee

StartDate

StopDate

RepairID

Customer

Goods

Customer

CustomerID

AddressCust

Sign

Goods

GoodsID

Categoty

Country

Company

Picture

INNcompany

AddressComp

DateStart

Period

DateBuy

Cost

Fax

PhoneCompany

Email

Web

Domo

1

0609173001

Ткачев С. Н.

24

г. Донецк, пр. Ильича, 18

(0622) 959748

-

Чистка фильтров

3 мес.

15.04.2011

20.04.2011

150406

Ивонов И. И.

04875

М-30, пл. Грибиниченко 3/45

Физ. лицо

Philips GC 3321

25648730

утюг

Китай

Magnum

Приложено

5260036661

г. Липецк, ул. Терешковой, 35Б

25.03.2009

2 года

30.07.2009

249 грн

(4742) 345784

(4742) 517624

istyle-gorod@mail.ru

www.istyle.su

Lux

4

1146758222

Тицкий В. А.

15

г. Макеевка, пр. Ленина, 140-А

(06232) 225748

150 грн

Замена звуковой панели

0 мес.

24.05.2011

30.05.2011

240501

Ильяшенко А. А.

05746

М-30, пл. Грибиниченко 4/123

Физ. лицо

Bosch WAA 20262

42124016

Стиральная машина

Германия

BoschServis

Приложено

7615487223

г. Троицк, Калужское шоссе, 22

12.08.2007

3 года

09.09.2007

899 грн

(495) 7759402

(495) 7759503

bosch-servis@mail.ru

www.bosch.ru

Lux

4

1146758222

Тицкий В. А.

15

г. Макеевка, пр. Ленина, 140-А

(06232) 225748

-

Чистка трубок

1 год

25.05.2011

27.05.2011

250501

Ильяшенко А. А.

05746

М-30, пл. Грибиниченко 4/123

Физ. лицо

Bosch KAN 56V45

45712264

Холодильник

Германия

BoschServis

Приложено

7615487223

г. Троицк, Калужское шоссе, 22

17.03.2009

3 года

28.06.2009

10033 грн

(495) 7759402

(495) 7759503

bosch-servis@mail.ru

www.bosch.ru

Bosch HMT 85GL53

12125784

Микроволновая печь

Германия

BoschServis

Приложено

7615487223

г. Троицк, Калужское шоссе, 22

20.03.2011

3 года

-

3620 грн

(495) 7759402

(495) 7759503

bosch-servis@mail.ru

www.bosch.ru

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

Проблема удаления

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

Итак, если по какой-то причине (к примеру, потеря сведений о продаже товара за 15.04.2011) мы удалим первую строку таблицы Warranty repairs (в которой фиксируется ремонт утюга Philips GC 3321 клиентом Ивановым И. И.), то из полученной БД будет безвозвратно утеряна информация о наличии данного клиента, т.к. в других строках таблицы информация о нем не содержится. Следовательно, можем говорить о наличии проблемы удаления в такой базе данных.

Проблема корректировки

Проблема корректировки данных определяется наличием необоснованной их избыточности. В полученной таблице Warranty repairs такая избыточность присуща атрибутам Filial, IDfilial, InnFilial, Chief, Capacity, Address, Phone, Customer, CustomerID, AddressCust, Sign, которые повторяются много раз в таблице, что повышает вероятность допущения ошибки при вводе и исправлении данных. Следствием этого может стать нарушение целостности данных в таблице. Таким образом, в БД, построенной по таблице Warranty repairs присутствуют все три проблемы (вставки, удаления и корректировки).

2.2 Формулировка ограничений на связи между сущностями предметной области

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

Итак, основными сущностями будут:

§ Филиалы - определяется атрибутами IDfilial, Filial, InnFilial, Chief, Capacity, Address, Phone.

§ Товары - идентифицируется атрибутом GoodsID, Goods, Categoty, Country, Company, Picture, DateStart.

§ Изготовители - идентифицируется атрибутами Company, INNcompany, AdddressComp, Fax, PhoneCompany, Email, Web.

§ Продажа - определяется атрибутами: CustomerID, GoodsID, Cost, DateBuy, Period.

§ Клиенты - определяется атрибутами Sign, CustomerID, Customer, AddressCust.

§ Ремонт - идентифицируется атрибутами RepairID, InnFilial, CustomerID, GoodsID, StopDate, Guarantee, Comment, CostRepair, StartDate. При это атрибут RepairID определяет номер документа, фиксирующего ремонт с указанными при помощи остальных атрибутов параметры.

На основании пунктов 1.2., 1.3., 2.1. можно определить характер связей между основными сущностями:

1. (Филиалы - Ремонт) - 1 : m

Т.е., один филиал может ремонтировать множество видов товаров.

2. (Клиенты - Ремонт) - 1 : m

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

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

3. (Клиенты - Продажа) - 1 : m

Т.е. имеющейся в базе данных клиент может приобрести разные виды товаров данной компании.

4. (Товары - Ремонт) - 1 : m

Согласно данной связи, товар с одним и тем же штрих-кодом может ремонтироваться на разных филиалах разними покупателями данного товара.

5. (Товары - Продажа) - 1 : m

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

6. (Изготовитель - Товары) - 1 : m

Т.е. конкретный изготовитель может производить различные виды бытовой техники.

2.3 Построение диаграммы функциональных зависимостей между атрибутами универсальной таблицы

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

Рассмотрим понятие функциональной зависимости на примере множеств.

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

С понятием функциональной зависимости тесно связано понятие детерминанта. Детерминантом называется атрибут или группа атрибутов, которая функционально определяет другой атрибут или их группу. В приведенном выше примере множеств А является детерминантом множества В.

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

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

Итак, диаграмма функциональных зависимостей универсальной нормализованной таблицы Warranty repairs (Filial, IDfilial, InnFilial, Chief, Capacity, Address, Phone, CostRepair, Comment, Guarantee, StartDate, StopDate, RepairID, Customer, CustomerID, AddressCust, Sign, Goods, GoodsID, Categoty, Country, Company, Picture, INNcompany, AddressComp, DateStart, Period, DateBuy, Cost, Fax, PhoneCompany, Email, Web).

Диаграмма функциональных зависимостей между атрибутами таблицы Warranty repairs будет иметь вид (рис. 2.1):

Рис. 2.1 Диаграмма функциональных зависимостей между атрибутами таблицы Warranty repairs

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

1. IDfilial > Filial: регистрационный номер филиала однозначно определяет один и тот же филиал.

2. IDfilial > InnFilial: ИНН филиала является уникальным для одного и того же филиала.

3. IDfilial > Chief: согласно установленным ограничения, руководитель для филиала с одним и тем же регистрационным номером является одним.

4. IDfilial > Capacity: количество работающих на определенном филиале одно и то же. В то же время на разных филиалах может совпадать количество работающих на ремонте.

5. IDfilial > Address: адрес уникален для каждого филиала.

6. IDfilial > Phone: номер телефона на одном и том же филиале один и тот же.

7. IDfilial > RepairID: регистрационный номер филиала однозначно определяет номер накладной по ремонту.

8. RepairID > CostRepair: согласно установленным ограничениям стоимость ремонта одна и та же для одного и того же номера накладной. В то же время стоимость ремонта может совпадать в разных номерах накладной.

9. RepairID > Comment: один и тот же номер накладной определяет одно и то же примечания в ремонте. Однако примечание может совпадать в разных накладных.

10. RepairID > Guarantte: оставшийся гарантийный период для одного и того же номера накладной один и тот же. В то же время данный период не уникален и может совпадать с другими номерами накладной.

11. RepairID > StartDate: в определенном номере накладной указывается определенная дата приема товара в ремонт.

12. RepairID > StopDate: дата получения одна и та же для одного и того же номера накладной. В то же время дата получения товара не уникальна и может встречаться в других накладных по ремонту.

13. RepairID > {GoodsID, INNcompany, CustomerID}: атрибут RepairID однозначно определяет в таблице совокупность атрибутов GoodsID, INNcompany, CustomerID.

14. GoodsID > Goods: штрих-код товара уникален для данного вида товара, поэтому если указан конкретный код во многих строках, то в этих строках таблицы всегда будет одно и тоже наименование товара.

15. GoodsID > Category: согласно установленным ограничениям категория для отдельного вида товара, определяемого его штрих-кодом, одна и та же. В то же время одна и та же категория может использоваться для различных товаров.

16. GoodsID > Country: страна-производитель для одного и того же товара является одной и той же. В то же время одна и та же страна-производитель может производить разные виды бытовой техники.

17. GoodsID > Picture: штрих-код товара уникален для каждого изображения товара.

18. GoodsID > DateStart: дата изготовления для товара с одним и тем же штрих-кодом является одинаковой.

19. GoodsID > Period: гарантийный период для одинаковых товаров одинаков.

20. GoodsID > Cost: стоимость товара одинакова для товаров с одним и тем же штрих-кодом.

21. GoodsID > DateBuy:

22. INNcompany > Company: ИНН изготовителя уникален для данного изготовителя, поэтому если указан конкретный ИНН во многих строках, то в этих строках таблицы всегда будет одно и тоже наименование изготовителя.

23. INNcompany > AdrressComp: для конкретного ИНН изготовителя уникальный адрес.

24. INNcompany > Fax: определенный изготовитель имеет свой назначенный номер факса.

25. INNcompany > PhoneCompany: определенным номером телефона обладает один изготовитель.

26. INNcompany > Email: адрес электронной почты для одного и того же изготовителя является одним и тем же.

27. INNcompany > Web: изготовитель обладает своей уникальной Web-страницей.

28. CustomerID > Customer: идентификатор покупателя уникален для каждого клиента.

29. CustomerID > AddressCust: согласно установленным ограничениям адрес для отдельного клиента, определяемого его идентификатором, один и тот же.

30. CustomerID > Sign: признак покупателя для отдельного клиента, определяемого его идентификатором, один и тот же. В то же время один и тот же признак может использоваться для разных клиентов.

РАЗДЕЛ 3. ПРОЕКТИРОВАНИЕ СХЕМЫ БАЗЫ ДАННЫХ С ИСПОЛЬЗОВАНИЕМ МЕТОДА ДЕКОМПОЗИЦИИ

3.1 Реализация алгоритма декомпозиции универсальной таблицы

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

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

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

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

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

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

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

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

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

Теперь перейдем к анализу таблицы Warranty repairs на предмет ее нахождения в НФБК.

Итак, потенциальным ключом таблицы Warranty repairs является {IDfilial, RepairID}. Такой потенциальный ключ функционально определяет все остальные атрибуты в таблице. Так как указанный потенциальный ключ один в данной таблице Warranty repairs, то ее первичным ключом будет являться он же.

Детерминантами в таблице Warranty repairs являются:

§ IDfilial

§ RepairID

§ GoodsID

§ CustomerID

§ INNcompany

Таблица Warranty repairs находится в 1НФ, т.к. она составлена на основе нормализованной СЕИ в табличной форме.

Таблица Warranty repairs не находится в 2 НФ: имеются неполные функциональные зависимости. Соответственно, далее приведенная таблица не находится ни в 3НФ, ни в нормальной форме Бойса-Кодда.

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

Для устранения указанных проблем следует произвести декомпозицию таблицы Warranty repairs для получения таблиц-проекций, которые находились бы в НФБК.

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

Таблица 3.1. Потенциальные ключи и детерминанты функциональных зависимостей таблицы Warranty repairs

Потенциальные ключи	Детерминанты
IDfilial, RepairID	IDfilial
	RepairID
	GoodsID
	CustomerID
	INNcompany

Из перечня, приведенного в таблице 3.1., видно, что не все детерминанты являются одновременно потенциальными ключами, т. е. данная таблица не находится в НФБК.

В связи с этим необходимо выполнить декомпозицию таблицы Warranty repairs на две таблицы: FILIAL (IDfiliala, Filial, InnFilial, Chief, Capacity, Address, Phone) и Т₁ (Goods, GoodsID, Categoty, Country, Company, Picture, INNcompany, AddressComp, DateStart, Period, DateBuy, Cost, Fax, PhoneCompany, Email, Web, Customer, CustomerID, AddressCust, Sign, CostRepair, Comment, Guarantee, StartDate, StopDate, RepairID).

Диаграмма функциональных зависимостей таблицы FILIAL (IDfiliala, Filial, InnFilial, Chief, Capacity, Address, Phone) имеет вид, представленный на рисунке 3.1.

учет документ атрибут база данные

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 3.1 Диаграмма ФЗ таблицы FILIAL

Данная таблица FILIAL по определению находится в НФБК, т.к. единственный детерминант IDfilial одновременно является ее ключом.

Таблица Т₁ (Goods, GoodsID, Categoty, Country, Company, Picture, INNcompany, AddressComp, DateStart, Period, DateBuy, Cost, Fax, PhoneCompany, Email, Web, Customer, CustomerID, AddressCust, Sign, CostRepair, Comment, Guarantee, StartDate, StopDate, RepairID) в таком случае имеет вид (рис. 3.2.)



Рис. 3.2 Диаграмма ФЗ между атрибутами таблицы Т₁

Теперь составим перечень потенциальных ключей и детерминантов для таблицы Т₁ (табл. 3.2.)

Таблица 3.2. Перечень потенциальных ключей и детерминантов таблицы функциональных зависимостей Т₁

Потенциальные ключи	Детерминанты
IDfilial, RepairID	IDfilial
	RepairID
	GoodsID
	CustomerID
	INNcompany

Из перечня, приведенного в табл. 3.2., видим, что не все детерминанты таблицы являются ее потенциальными ключами. В связи с этим необходимо выполнить декомпозицию таблицы Т₁ на две таблицы: Repair (RepairID, CostRepair, Comment, Guarantee, StartDate, StopDate) и Т₂ (Goods, GoodsID, Categoty, Country, Company, Picture, INNcompany, AddressComp, DateStart, Period, DateBuy, Cost, Fax, PhoneCompany, Email, Web, Customer, CustomerID, AddressCust, Sign).

Диаграмма функциональных зависимостей таблицы Repair (RepairID, CostRepair, Comment, Guarantee, StartDate, StopDate) имеет вид, представленный на рисунке 3.3.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 3.3 Диаграмма ФЗ таблицы Repair

Данная таблица находится по определению в НФБК, т.к. единственный детерминант RepairID одновременно является потенциальным ключом таблицы. Диаграмма ФЗ таблицы Т₂ (Goods, GoodsID, Categoty, Country, Company, Picture, INNcompany, AddressComp, DateStart, Period, DateBuy, Cost, Fax, PhoneCompany, Email, Web, Customer, CustomerID, AddressCust, Sign) в таком случае имеет вид (рис. 3.4.)



Рис. 3.4 Диаграмма ФЗ между атрибутами таблицы Т₂

Теперь составим перечень потенциальных ключей и детерминантов для таблицы Т₂ (табл. 3.3.).

Таблица 3.3 Перечень потенциальных ключей и детерминантов таблицы функциональных зависимостей Goods

Потенциальные ключи	Детерминанты
IDfilial, RepairID	IDfilial
	RepairID
	GoodsID
	CustomerID
	INNcompany

Исходя из данных табл. 3.3., видим, что не все детерминанты таблицы являются ее потенциальными ключами. В связи с этим необходимо выполнить декомпозицию таблицы Т₂. Поскольку данная таблица находится в чистой транзитивной зависимости, то разделим ее на три таблицы: GOODS (Cost, Picture, DateStart, Period, DateBuy, Goods, GoodsID, Categoty, Country), CUSTOMER (Customer, CustomerID, AddressCust, Sign) и COMPANY (Fax, PhoneCompany, Email, Web, INNcompany, AddressComp, Company).

Диаграмма функциональных зависимостей таблицы GOODS (Cost, Picture, DateStart, Period, DateBuy, Goods, GoodsID, Category, Country) имеет вид, представленный на рисунке 3.5.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 3.5 Диаграмма ФЗ таблицы GOODS

Данная таблица находится по определению в НФБК, т.к. единственный детерминант GoodsID одновременно является ключом таблицы.

Диаграмма функциональных зависимостей таблицы CUSTOMER (Customer, CustomerID, AddressCust, Sign) имеет вид, представленный на рисунке 3.6.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 3.6. Диаграмма ФЗ таблицы CUSTOMER

Данная таблица находится по определению в НФБК, т.к. единственный детерминант CustomerID одновременно является ключом таблицы.

Диаграмма функциональных зависимостей таблицы COMPANY (Fax, PhoneCompany, Email, Web, INNcompany, AddressComp, Company) имеет вид, представленный на рисунке 3.7.

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

Рис. 3.7. Диаграмма ФЗ таблицы COMPANY

Данная таблица находится по определению в НФБК, т.к. единственный детерминант INNCompany одновременно является ключом таблицы.

3.2 Полнота и целостность схемы базы данных

После осуществления декомпозиции исходной таблицы Warranty repairs необходимо проверить полученные в результате таблицы на предмет сохранения полноты и целостности данных. Для проверки на сохранность функциональных зависимостей исходной универсальной таблицы Warranty repairs в таблицах полученной схемы базы данных необходимо составить перечень функциональных зависимостей по форме (табл. 3.4.)

Таблица 3.4. Функциональные зависимости в полученной схеме базы данных

ФУНКЦИОНАЛЬНЫЕ ЗАВИСИМОСТИ	НАЗВАНИЕ ТАБЛИЦ
УНИВЕРСАЛЬНЫЕ ТАБЛИЦЫ	СХЕМА БД
IDfilial > Filial IDfilial > InnFilial IDfilial > Chief IDfilial > Capacity IDfilial > Address IDfilial > Phone	IDfilial > Filial IDfilial > InnFilial IDfilial > Chief IDfilial > Capacity IDfilial > Address IDfilial > Phone	FILIAL
RepairID > CostRepair RepairID >IDfilial RepairID >GoodsID RepairID >CustomerID RepairID > Comment RepairID > Guarantte RepairID > StartDate RepairID > StopDate	RepairID > CostRepair RepairID >IDfilial RepairID >GoodsID RepairID >CustomerID RepairID > Comment RepairID > Guarantte RepairID > StartDate RepairID > StopDate	REPAIR
GoodsID > Goods GoodsID > Category GoodsID > Country GoodsID > Picture GoodsID > DateStart GoodsID > Period GoodsID > DateBuy GoodsID > Cost	GoodsID > Goods GoodsID > Category GoodsID > Country GoodsID > Picture GoodsID > DateStart GoodsID > Period GoodsID > DateBuy GoodsID > Cost	Goods
INNCompany > PhoneCompany INNCompany > AddressComp INNCompany > Company INNCompany > GoodsID INNCompany > Email INNCompany > Fax INNCompany > Web	INNCompany > PhoneCompany INNCompany > AddressComp INNCompany > Company INNCompany > GoodsID INNCompany > Email INNCompany > Fax INNCompany > Web	company
CustomerID > Customer CustomerID > AddressCust CustomerID > Sign	CustomerID > Customer CustomerID > AddressCust CustomerID > Sign	customer

Потерь функциональных зависимостей не наблюдается.

FILIAL IDfilial	Filial	InnFilial	Chief	Capacity	Address	Phone

REPAIR
RepairID	IDfilial	GoodsID	CustomerID	Comment	Guarantte	CostRepair	StartDate	StopDate

GOODS
GoodsID	Goods	Category	Country	INNCompany	Picture	DateStart	Period	DateBuy	Cost

COMPANY
INNCompany	Company	AddressComp	PhoneCompany	Fax	Email	Web

CUSTOMER
CustomerID	Customer	AddressCust	Sign

Итак, мы убедились в полноте данных по итогам декомпозиции. Для определения целостности данных составим схему данных нашего отношения (рис. 3.8.).

Рис. 3.8. Схема данных

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

1. Определим список товаров одной категории (с условием, что она повторяется больше 3-х раз) и выясним их названия, страну-производителя и гарантийный срок:

Создаем запрос «Повторяющиеся записи», используя поля: Goods, GoodsID, Category, Country, Period. В режиме конструктора в поле «Условия отбора» вводим >3. Полученный запрос реализуем в форме (рис. 3.9).

Рис. 3.9. Часто покупаемая категория товаров

2. Создадим справку о товарах, в которой будет указываться контактная информация сервисных центров.

Создадим форму, используя поля: Category, Goods, Company, Web, Email, PhoneCompany. В итоге мы получим удобное представление об информационной справке по товаром (рис. 3.10).

Рис. 3.10. Фрагмент «Информационная справка»

3. Создадим форму «Представление о товарах» (рис. 3.11.), в которой будем использавать поля: Category, Goods, Cost, Picture.



Рис. 3.11. Фрагмент «Представление о товарах»

4. Создадим отчет по накладным для каждого филиала. Для этого будем использовать таблицу REPAIR с атрибутами: IDfilial, RepairID, GoodsID, Guarante, CostRepair. Данный отчет будет показывать какой филиал и на какую сумму произвел ремонт товаров за определенный период (рис. 3.11.).



Рис. 3.11. Фрагмент отчета

В завершении для удобства работы создаем Главную кнопочную форму, позволяющую быстро перемещаться по функциональным элементам БД (рис. 3.12.).



Рис. 3.12. Кнопочная форма БД

Заключение

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

В ходе работы были использованы следующие методы:

@ анализ,

@ синтез,

@ абстрагирование,

@ моделирование,

@ нормализация,

@ графический.

БД «Народная торговая компания» не содержит проблем удаления, вставки и корректировки, что делает ее простой, удобной и эффективной в использовании.

Таким образом, разработанная информационная система позволяет компании вести учет купленных и отремонтированных товаров.

Литература

1. Андриенко В.Н., Берсуцкий Я.Г., Скобелев В.Г., Томяковский А.С. Системы баз данных. Экономические приложения.- Донецк: ДонГУ, 2000.- 213 с.

2. Дейт К. Дж. Введение в системы баз данных/ Пер. с англ.-6-е изд.- К.: Диалектика, 2000.-784 с.

3. Ульман Дж.Д. , Уидом Дж. Введение в системы баз данных.- М.ЛОРИ, 2000.-374 с.

4. Джеймс Р. Грофф, Пол Н. Вайнберг. SQL: полное руководство: пер.с англ. - К.: Издательская группа BHV, 1999.-608 с.

5. Вейскас Д. Эффективная работа с Microsoft Access 2. Спб.: Питер Пресс,1995.- 856с.

6. Кормен Т., Лейзерсон Ч., Ривест Р. Алгоритмы: построение и анализ. - М: Центр непрерывного математического образования, 2000. - 960 с.

7. Атре Ш. Структурный подход к организации баз данных. - М. : Финансы и статистика, 1984.

8. Дрибас В.П. Реляционные модели баз данных. - Минск, Изд-во БГУ, 1982.

9. Мартин Дж. Организация баз данных в вычислительных системах. - М. Мир, 1980.

10. Тиори Т., Фрай Дж. Проектирование структуры баз данных. - М.: Наука, 1985.

11. Хансен Г., Хансен Дж. Базы данных. Разработка и управление.- М. БИНОМ, 1999.-699 с.

12. Горев А., Ахаян Р., Макашарипов С. Эффективная работа с СУБД - СПб.: Питер, 1997. - 704 с.

Размещено на Allbest.ru