Разработка информационной системы деятельности отдела гарантийного ремонта товаров фирмы "Народная торговая компания" - Программирование, компьютеры и кибернетика курсовая работа

Главная

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

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


посмотреть текст работы


скачать работу можно здесь


полная информация о работе


весь список подобных работ


Нужна помощь с учёбой? Наши эксперты готовы помочь!
Нажимая на кнопку, вы соглашаетесь с
политикой обработки персональных данных

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.


По дисциплине: «Информационные системы в экономике»
Разработка информационной системы деятельности отдела гарантийного ремонта товаров фирмы «Народная торговая компания»
Курсовая работа предназначена для закрепления теоретических знаний и получения практических навыков по вопросам создания и использования информационных систем в управлении.
Исходными информационными данными в экономических системах являются документы, отражающие процессы, происходящие в предметной области.
Учитывая, что любой документ в экономической системе (предметной области) служит средством отображения ее состояния, можно утверждать, что в информационных системах множество таких документов во времени, позволяет фиксировать динамику состояния предметной области.
При выполнении курсовой работы, согласно варианту, должно быть принято следующее допущение - состав атрибутов и их значения в предлагаемом документе является условным и обеспечивает в информационных системах полноту данных о предметной области.
На основании заданной формы документа необходимо, в конечном итоге представить информационные данные множества таких документов в таблице, как схеме базы данных, используя теоретические знания проектирования информационных систем.
Тематика курсовой работы предполагает знание содержания таких понятий, как атрибуты документа, составная единица информации (ненормализованная, нормализованная), таблица (отношение), универсальная таблица (отношение), домены атрибутов, целостность данных (проблема корректировки, вставки и удаления данных в БД), функциональные зависимости между атрибутами таблицы, диаграмма функциональных зависимостей, детерминанты, нормальные формы таблицы, потенциальные, первичные и внешние ключи таблицы.
Вариант 9. Разработать прикладное программное обеспечение деятельности отдела гарантийного ремонта товаров фирмы "Народная торговая компания". Это предприятие -- лидер продаж кондиционеров, телевизоров и другой бытовой техники в городе. Хорошо известно, что техника часто выходит из строя, причем уже в период гарантийного срока, а в этом случае продавец товара должен бесплатно отремонтировать его. Ежедневно в отдел гарантийного ремонта обращается несколько десятков человек, купивших технику в этой компании. Вы, скорее всего, также побывали в отделе гарантийного ремонта, что очень поможет при разработке программного обеспечения.
База данных создается на предприятии.
1.1 Описание предметной области, цели и задачи управления
Предметная область «Народная торговая компания» представляет собой процесс по ремонту бытовой техники в гарантийный период. База данных создается на уровне филиалов компании для учета проданного товара и отремонтированного товара.
Основные сущности предметной области: филиалы, товары, изготовители, покупатели, продажа, ремонт.
Филиалы характеризуются названием филиала, его регистрационным номером, ИНН и адресом, а также кто является руководителем данного филиала и какое количество работающих на ремонте.
Товары характеризуются штрих-кодом товара, названием, категорией, датой изготовления, так же предоставляется фото товара, изготовитель и страна-производитель.
Изготовители характеризуются наименованием изготовителя, ИНН, его адресом, номерами факса и телефона, а также адресами электронной почты и Web-страницы.
Покупатели характеризуются идентификатором покупателя, его ФИО, адресом и признаком, который показывает, является лицо физическим или юридическим.
Продажа состоит в учете стоимости товара, даты покупки и гарантийном периоде товара.
Ремонт характеризуется номером накладной, датой приема товара на ремонт, стоимостью ремонта, отмечается оставшийся гарантийный срок и примечание, которое показывает, что было сделано в данном товаре.
Задача управления состоит в учете компанией отремонтированного товаров.
Цель управления: создание на филиале системы, обеспечивающей полный учет отремонтированных товаров.
Для решения данной задачи управления необходимы следующие информационные данные: о товарах, о том, когда был куплен товар, его гарантийный срок и дата приема товара на ремонт.
1.2 Функциональная структура документа как элемента информационного пространства предметной области
В результате обследования предметной области установлено:
§ В документе фиксируется информация о конкретной компании с филиалами, на которых обеспечивается продажа и гарантийный ремонт бытовой техники;
§ В базе данных зафиксирована информация обо всех филиалах, т.к. данная база составляется на уровне компании;
§ Указанные филиалы занимаются продажей бытовой техники и приемом ее на ремонт;
§ Название филиалов фиксируются регистрационным номером, начиная с 1;
§ В базе данных фиксируются изготовители бытовой техники, которые продаются данной компанией;
§ Изготовитель определяется индикационным номером;
§ Компания располагает данными о товарах и покупателях;
§ Товар определяется штрих-кодом, указанным в документе;
§ Наименования отдельных видов товаров не являются уникальными, конкретный вид товара определяется лишь его штрих-кодом;
§ Продажа данной продукции фиксируется на филиалах и определяется штрих-кодом товара и датой продажи;
§ Наименования отдельных покупателей не уникальны, конкретный покупатель определяется с помощью его идентификатора;
§ Гарантийный ремонт фиксируется на филиалах, где указывается дата приема и получения, а так же оставшийся срок гарантии;
§ Ремонт определяется примечанием и из этого указывается стоимость ремонта.
Теперь дадим качественную и количественную характеристику каждому из обозначенных выше атрибутов, представив данную информацию в табличном виде.
Таблица 1. Характеристика атрибутов документа
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 будет иметь следующий вид
Составная единица информации, содержащая данные в приведенной выше форме, представляет собой не нормализованную СЕИ. Это объясняется тем, что атрибуты 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 или реляционную схему базы данных, представленную одной таблицей:
2.1 Универсальная таблица: проблемы вставки, удаления, корректировки информационных данных
При эксплуатации базы данных естественным является обеспечение возможности пополнения такой базы новыми информационными данными по любому виду информации, удаления некоторых информационных данных из базы и корректировки отдельных информационных данных. При этом компьютерная база данных должна все это обеспечить без нарушения целостности данных.
База данных, состоящая из одной таблицы, с большой вероятностью будет иметь указанные проблемы.
Рассмотрим подробнее на предмет наличия проблем вставки, удаления и корректировки полученную в предыдущих разделах таблицу Warranty repairs. Данная универсальная таблица по определению может быть базой данных.
Однако, согласно теории проектирования, все таблицы базы данных, в том числе, если такая база состоит из одной таблицы, не должны содержать проблем вставки, удаления, корректировки.
Проверим данное утверждение на нашем примере.
Проблема вставки может возникнуть при вводе какого-либо нового вида информации.
Так, в таблицу Warranty repairs нельзя ввести такой вид товара, который бы не был отремонтирован, но числился в накладной. Если же, все-таки включить информацию о таком товаре, то появится новый кортеж с пустыми значениями некоторых атрибутов.
В этом случае информационные данные в таблице Warranty repairs будут представлены в следующем виде:
Из свойств таблицы следует недопустимость пустых значений атрибутов, а значит, проблема вставки в данной таблице существует. Таким образом, нельзя ввести в базу данных информацию только о товаре, хотя информация данного вида предусмотрена. Такая база данных требует дальнейших преобразований ввиду наличия проблемы вставки.
Проблема удаления заключается в том, что при удалении какого-либо атрибута удаляется вся строка. В этом случае может быть утеряна информация, которая в приведенной базе данных присутствует в единственном числе. Рассмотрим на примере базы данных по таблице 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. можно определить характер связей между основными сущностями:
Т.е., один филиал может ремонтировать множество видов товаров.
Исходя из характера данной связи, можем сказать, что конкретный покупатель может совершить ремонт, купленных товаров в данной компании, неоднократно.
Т.е. один клиент, зафиксированный в базе данных, может приносить бытовую технику на ремонт некое количество раз.
Т.е. имеющейся в базе данных клиент может приобрести разные виды товаров данной компании.
Согласно данной связи, товар с одним и тем же штрих-кодом может ремонтироваться на разных филиалах разними покупателями данного товара.
Характер связи между данными сущностями определяет, что товар определенного штрих-кода есть не в единственном экземпляре и его могут приобрести несколько клиентов.
Т.е. конкретный изготовитель может производить различные виды бытовой техники.
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: стоимость товара одинакова для товаров с одним и тем же штрих-кодом.
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.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 являются:
Таблица Warranty repairs находится в 1НФ, т.к. она составлена на основе нормализованной СЕИ в табличной форме.
Таблица Warranty repairs не находится в 2 НФ: имеются неполные функциональные зависимости. Соответственно, далее приведенная таблица не находится ни в 3НФ, ни в нормальной форме Бойса-Кодда.
В силу того, что данная таблица находится в 1НФ, она не может быть элементом базы данных из-за наличия проблем вставки, удаления, корректировки.
Для устранения указанных проблем следует произвести декомпозицию таблицы Warranty repairs для получения таблиц-проекций, которые находились бы в НФБК.
Далее для проведения декомпозиции таблицы определим потенциальные ключи и детерминанты на диаграмме функциональных зависимостей между атрибутами таблицы Warranty repairs и отобразим их в виде перечня следующего вида:
Таблица 3.1. Потенциальные ключи и детерминанты функциональных зависимостей таблицы Warranty repairs
Из перечня, приведенного в таблице 3.1., видно, что не все детерминанты являются одновременно потенциальными ключами, т. е. данная таблица не находится в НФБК.
В связи с этим необходимо выполнить декомпозицию таблицы Warranty repairs на две таблицы: FILIAL (IDfiliala, Filial, InnFilial, Chief, Capacity, Address, Phone) и Т 1 (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.


Рис. 3.1 Диаграмма ФЗ таблицы FILIAL
Данная таблица FILIAL по определению находится в НФБК, т.к. единственный детерминант IDfilial одновременно является ее ключом.
Таблица Т 1 (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 Диаграмма ФЗ между атрибутами таблицы Т 1
Теперь составим перечень потенциальных ключей и детерминантов для таблицы Т 1 (табл. 3.2.)
Таблица 3.2. Перечень потенциальных ключей и детерминантов таблицы функциональных зависимостей Т 1
Из перечня, приведенного в табл. 3.2., видим, что не все детерминанты таблицы являются ее потенциальными ключами. В связи с этим необходимо выполнить декомпозицию таблицы Т 1 на две таблицы: Repair (RepairID, CostRepair, Comment, Guarantee, StartDate, StopDate) и Т 2 (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.


Рис. 3.3 Диаграмма ФЗ таблицы Repair
Данная таблица находится по определению в НФБК, т.к. единственный детерминант RepairID одновременно является потенциальным ключом таблицы. Диаграмма ФЗ таблицы Т 2 (Goods, GoodsID, Categoty, Country, Company, Picture, INNcompany, AddressComp, DateStart, Period, DateBuy, Cost, Fax, PhoneCompany, Email, Web, Customer, CustomerID, AddressCust, Sign) в таком случае имеет вид (рис. 3.4.)
Рис. 3.4 Диаграмма ФЗ между атрибутами таблицы Т 2
Теперь составим перечень потенциальных ключей и детерминантов для таблицы Т 2 (табл. 3.3.).
Таблица 3.3 Перечень потенциальных ключей и детерминантов таблицы функциональных зависимостей Goods
Исходя из данных табл. 3.3., видим, что не все детерминанты таблицы являются ее потенциальными ключами. В связи с этим необходимо выполнить декомпозицию таблицы Т 2 . Поскольку данная таблица находится в чистой транзитивной зависимости, то разделим ее на три таблицы: 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.


Рис. 3.5 Диаграмма ФЗ таблицы GOODS
Данная таблица находится по определению в НФБК, т.к. единственный детерминант GoodsID одновременно является ключом таблицы.
Диаграмма функциональных зависимостей таблицы CUSTOMER (Customer, CustomerID, AddressCust, Sign) имеет вид, представленный на рисунке 3.6.


Рис. 3.6. Диаграмма ФЗ таблицы CUSTOMER
Данная таблица находится по определению в НФБК, т.к. единственный детерминант CustomerID одновременно является ключом таблицы.
Диаграмма функциональных зависимостей таблицы COMPANY (Fax, PhoneCompany, Email, Web, INNcompany, AddressComp, Company) имеет вид, представленный на рисунке 3.7.


Рис. 3.7. Диаграмма ФЗ таблицы COMPANY
Данная таблица находится по определению в НФБК, т.к. единственный детерминант INNCompany одновременно является ключом таблицы.
3.2 Полнота и целостность схемы базы данных
После осуществления декомпозиции исходной таблицы Warranty repairs необходимо проверить полученные в результате таблицы на предмет сохранения полноты и целостности данных. Для проверки на сохранность функциональных зависимостей исходной универсальной таблицы Warranty repairs в таблицах полученной схемы базы данных необходимо составить перечень функциональных зависимостей по форме (табл. 3.4.)
Таблица 3.4. Функциональные зависимости в полученной схеме базы данных
Потерь функциональных зависимостей не наблюдается.
Итак, мы убедились в полноте данных по итогам декомпозиции. Для определения целостности данных составим схему данных нашего отношения (рис. 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.12.).
В работе разработана информационная система, позволяющая компании координировать процесс гарантийного ремонта на филиалах. Инструментом разработки выступил ППП MS Access.
В ходе работы были использованы следующие методы:
БД «Народная торговая компания» не содержит проблем удаления, вставки и корректировки, что делает ее простой, удобной и эффективной в использовании.
Таким образом, разработанная информационная система позволяет компании вести учет купленных и отремонтированных товаров.
1. Андриенко В.Н., Берсуцкий Я.Г., Скобелев В.Г., Томяковский А.С. Системы баз данных. Экономически
Разработка информационной системы деятельности отдела гарантийного ремонта товаров фирмы "Народная торговая компания" курсовая работа. Программирование, компьютеры и кибернетика.
Реферат На Тему Культура Стародавнього Єгипту
Доверие Сочинение 5 Класс
Реферат На Тему Россия 21 Веке
Курсовая работа по теме Повышение эффективности использования оборотных средств
Текст Огэ О Доброте Для Сочинения
Эссе Компания Глори Мед Эстетик
Эссей Ооо
Курсовая работа по теме Расчет теплопритоков холодильника
Сочинение по теме Гуманизм романов Ф.М.Достоевского "Преступление и наказание"
Дипломная работа: Оценка кредитоспособности заёмщика
Сочинение В Формате Огэ По Литературе
Реферат: Готический рельеф
Реферат по теме Анализ доходов организации
Курсовая работа по теме Товароведная характеристика и потребительские свойства майонеза
Договор Купли Продажи Предприятия Курсовая 2022
Курсовая работа по теме Конкуренция, ее виды и роль в рыночном механизме
Сочинение По Русскому Ночь Фонарь Улица Аптека
Курсовая работа: Cовременные направления деятельности транснациональных банков. Скачать бесплатно и без регистрации
Реферат На Тему Производство Коньячных Спиртов
Реферат по теме Инвентаризация: порядок организхации и проведения
Методология исторической науки - История и исторические личности курс лекций
Власть и свобода - Политология реферат
Сучасні тенденції злиття та поглинання провідних ТНК світу - Международные отношения и мировая экономика презентация