Файл: БегичеваС.В. БеляеваО.Б. Метод.указания к курсовой работе Базы данных.pdf

6 

Необходимо  обосновать  связи  и  отношения  между  объектами,  указать  степень 

связи, кардинальность связи. 

Концептуальная  модель  обеспечивает  интегральное  представление  о  предметной 

области и имеет слабо формализованный характер, отображает информационные объекты, 

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

На данном этапе проектирования разработчик еще может выбрать модель данных и 

СУБД для реализации базы данных.  

Выбор логической модели данных.  

Необходимо  перечислить  классические  и  современные  модели  данных,  выбрать 

модель данных, обосновать свой выбор. 

Логическое проектирование 

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

Логическое  проектирование  БД,  то  есть  описание  БД  в  терминах  принятой 

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

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

модели).  

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

нормализовать до 3 НФ. 

Выбор СУБД 

Необходимо  выбрать  СУБД  для  реализации  базы  данных,  спроектированной  на 

основе  выбранной  модели  данных,  обосновать  свой  выбор.  Для  начинающих 

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

однопользовательской. 

Физическое проектирование базы данных 

Физическое проектирование базы данных - эффективное размещения базы данных 

на внешних носителях для обеспечения наиболее эффективной работы приложения. 

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

типов  данных,  свойств  полей,  поддерживаемых  выбранной  СУБД,  обосновать  выбор 

индексных полей. 

Реализация базы данных 

Необходимо показать схему базы данных. 

Создать  запросы  разных  типов:  перекрестные,  итоговые,  графические 

представления  (запросы).  Запросы  (представления)  оформить  в  виде  табличных  форм, 

диаграмм. 

7 

Сформировать  необходимые  формы  (диалоговые  окна)  для  заполнения  таблиц  и 

просмотра запросов, отчетов. 

Сформировать отчеты с детализацией, в т.ч.итоговые отчеты – с итогами по двум 

уровням группировки. 

Сформировать  навигационное  меню  для  просмотра  таблиц,  форм,  запросов  и 

отчетов. 

Пример проектирования базы данных 

Рассмотрим этапы проектирования базы данных на конкретном примере. В нашей 

работе  мы  проведем  проектирование  и  реализуем  в  СУБД  MS  Access  базу  данных 

небольшой фирмы-дилера, торгующей трубной продукцией.  

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

системе  и  анализа  предметной  области  информационной  системы,  целью  которых 

является  описание  объектов,  информацию  о  которых  в  рамках  выделенного  бизнес-

процесса необходимо хранить в базе данных. 

1.1 

АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ 

В  деятельности  фирмы-дилера,  осуществляющей  продажу  трубной  продукции, 

можно выделить, к примеру, несколько основных бизнес-процессов: прием заказа на сбыт 

готовой продукции, контроль выполнения заказа клиента, поставка продукции со склада.  

В курсовой работе необходимо выбрать один (реже два) бизнес-процесса. В данной 

курсовой  работе  будет  реализована  база  данных  для  автоматизации  бизнес-процесса 

«оформление  заказа  на  поставку  продукции».  Исполнителем  этого  бизнес-процесса 

является менеджер отдела продаж, который будет одним из пользователей проектируемой 

базы данных. 

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

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

заявки  от  покупателей  и  обеспечивать  выполнение  заказов,  устанавливая  связь  с 

поставщиками. Поставщики, с которыми работает фирма, находятся в Екатеринбурге или 

Свердловской  области.  Фирма  не  имеет  собственного  склада:  заказанная  продукция 

берется  непосредственно  со  склада    поставщика.  Причем  некоторые  виды  труб  есть  в 

наличии  постоянно,  и  поставка  осуществляется  в  ближайшее  время,  другие  виды  надо 

заказывать специально и на выполнение заказа отводятся определенные сроки.   

Выходные  документы  рассматриваемого  бизнес-процесса  в  дальнейшем 

предоставляются покупателю, на склад, в бухгалтерию, начальнику отдела продаж. 

8 

Привести примеры. 

Менеджеры фиксируют каждый заказ и следят за его выполнением.  Для контроля 

выполнения  заказа  пользователю-менеджеру  необходима  информация  о  состоянии 

выполнения  заказа,  о  статусе  платежа  клиента.  Далее  перечисляются  все  выходные 

документы, необходимые менеджеру. 

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

решений, является руководитель отдела продаж. 

Руководитель отдела продаж должен получать отчетность по оформленным заказам 

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

и  рентабельности  каждой  сделки,  о  спросе  за  прошедшую  неделю  на  различные  виды 

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

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

На  следующем  шаге  необходимо  дать  понятие  бизнес-правила [1]  и 

сформулировать  бизнес-правила  для  выбранного  бизнес-процесса.  В  таблице 1 

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

курсовой работе не обязательно. 

Таблица 1 – Бизнес-правила 

№ 

Определение правила 

Тип 

правила 

1 

Заказ оформляется на известного клиента.  

Факт 

2 

Закупка обычно производится у постоянных поставщиков 

Факт 

3 

Ассортимент поставщика может включать более одного наименования 

товаров, каждый товар может поставляться разными поставщиками.  

Факт 

4 

Поставка товара заказчику осуществляется на условиях предоплаты. 

Факт 

5 

Клиент в одном заказе может заказать несколько товаров. 

Факт 

6 

Каждый вид изделия поставляется только одним поставщиком. 

Факт 

7 

При  оформлении  заказа  указываются  данные  о  заказчике;  дате 

размещения  заказа;  дате  исполнения  заказа;  статусе  заказа,  ФИО 

менеджера,  принявшего  заказ.  Заказ  может  содержать  заявку  на 

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

содержит  данные  о  наименовании  трубы  (ГОСТ);  диаметре  трубы; 

стенке  трубы;  цене  входящей  (цене  поставщика);  цене  исходящей 

(цене,  по  которой  был  выставлен  на  продажу  товар);  поставщике; 

количестве заказанного изделия.  

Факт 

9 

8 

Цена  исходящая  (цена  продажи)  назначается  фирмой-дилером.  Цена 

исходящая превышает цену входящую (цену закупки) на 10%  

Факт 

9 

Дата  выполнения  заказа  должна  быть  больше,  чем  дата  размещения 

заказа.  

Факт 

10  Заказ имеет статус «в рассмотрении», в случае, если менеджер принял 

заказ от клиента, но не отправил заявку на фирму-поставщика. 

Вывод 

11  Заказ имеет статус «принят», в случае, если заказ принят к исполнению 

поставщиком. 

Вывод 

12  Заказ имеет статус «оплачен», в случае, если заказ оплачен клиентом. 

Вывод 

13  Заказ имеет статус «отказано», в случае, если заказ отклонен по каким-

либо причинам 

Вывод 

14  В  последний  рабочий  день  недели  каждый  менеджер  должен 

представить  отчет  о  работе  за  прошедшую  неделю  руководителю 

отдела 

Активатор 

информации 

15  Рентабельность сделки рассчитывается по формуле: 

%

100

_

_

_

входящая

цена

входящая

цена

исходящая

цена

ость

рентабельн

Вычисление 

16  Сведения о выполненных заказах сохраняются в течение года. 

Факт 

На  основании  проанализированной  информации  перечислим  основные  задачи, 

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

ввод  и  корректировка  данных  об  объектах  предметной  области 

информационной системы; 

оформление заказа на поставку продукции; 

вывод необходимых отчетов. 

Проанализируем атрибуты сущностей предметной области. 

Такие характеристики заказа, как дата размещения; дата исполнения; статус и ФИО 

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

в список атрибутов. 

Для  каждого  вида  трубной  продукции  нас  интересуют  следующие  данные: 

наименование  трубы  (ГОСТ),  диаметр  трубы,  стенка  трубы,  цена  входящая  и  цена 

исходящая.  Перечисленные  характеристики  будут  являться  атрибутами  сущности,  т.к. 

каждая из них будет однозначно относится к каждому наименованию изделия.   

Обозначим атрибуты объекта «Заказчик». По каждой фирме-заказчику для работы 

менеджеру необходима следующая информация: наименование, ФИО руководителя, адрес 

10 

и телефон.  Этот набор данных уникален для каждой фирмы и образует набор атрибутов 

сущности «Заказчик».  

Список  атрибутов  сущности  «Поставщик»  аналогичен  подобному  списку  для 

сущности «Заказчик», а именно: наименование, ФИО руководителя, адрес и телефон.   

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

данных  перечислим  в  таблице  2  выделенные  объекты  предметной  области  и  свойства 

объектов, информацию о которых необходимо хранить в проектируемой базе данных.  

Таблица 2 – Объекты предметной области  

Объект 

предметной 

области 

Свойства объекта предметной области 

Заказ 

Заказчик, дата размещения заказа, дата исполнения заказа,  статус заказа, 

ФИО менеджера 

Заказчик 

Наименование, имя руководителя, адрес, телефон 

Товар 

Наименование трубного изделия (ГОСТ), диаметр трубы,  стенка трубы, 

цена входящая, цена исходящая 

Поставщик 

Наименование, имя руководителя, адрес, телефон 

Далее  рекомендуется  описать  область  значений,  которую  могут  принимать 

выделенные атрибуты.  

1.2  КОНЦЕПТУАЛЬНОЕ МОДЕЛИРОВАНИЕ 

Целью  концептуального  моделирования  является  представление  информации  в 

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

базы данных. 

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

которого  является  модель  «сущность-связь».  Конструктивными  элементами  ER-модели 

являются сущности, атрибуты и связи.  

На  данном  этапе  моделирования  необходимо  выбрать  систему  обозначений  в 

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

нотаций  Чена  (обозначение  сущностей,  связей  и  атрибутов)  и  Мартина  (обозначение 

степеней и кардинальностей связей).  

Число  экземпляров  сущностей,  которое  может  быть  ассоциировано  через  набор 

связей с другим экземпляром сущности, называется степенью связи (типом отношений). 

Известны типы отношений: один ко многим, один к одному, многие ко многим.