Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Разработка базы данных пекарни

Разработка базы данных пекарни

Автоматизация ведения учета, оформления документации для заключенных договоров и заказов, хранения разнородной информации для мини-пекарни "Хлебушко". Проектирование базы данных. Установление дополнительных логических связей. Запросы к базе данных.

Рубрика Программирование, компьютеры и кибернетика
Вид курсовая работа
Язык русский
Дата добавления 03.10.2016
Размер файла 2,0 M
рефераты на заказ со скидкой

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

Содержание

  • 1. Анализ деятельности предприятия
  • 1.1 Общая характеристика предприятия
  • 1.2 Организационная структура мини-пекарни "Хлебушко"
  • 1.3 Связи с внешними организациями
  • 1.4 Задачи разрабатываемой базы данных
  • 2. Проектирование базы данных
  • 2.1 Концептуальное проектирование
  • Определение сущностей
  • Назначение описательных атрибутов и ключей
  • Определение связей между сущностями
  • Построение концептуальной схемы
  • Составление справочника задач
  • 3. Логическое проектирование
  • 3.1 Установление дополнительных логических связей
  • 3.2 Отображение концептуально-инфологической модели на реляционную модель
  • 3.3 Нормализация отношений
  • Проверка отношений на соответствие первой нормальной форме
  • Проверка отношений на соответствие второй нормальной форме
  • Проверка отношений на соответствие третьей нормальной форме
  • Построение итоговой логической модели базы данных
  • 3.4 Физическое проектирование
  • 3.5 Заполнение базы данных
  • 4. Запросы к базе данных
  • 4.1 Запрос "Добавление поставщика"
  • 4.2 Запрос "Добавление заказчика"
  • 4.3 Запрос "Добавление сотрудника"
  • 4.4 Запрос "Добавление договора"
  • 4.5. Запрос "Добавление заказа"
  • 4.6 Запрос "Добавление сырья"
  • 4.7 Запрос "Добавление продукции"
  • 4.8 Запрос "Выявление сотрудников, работающих в определенную смену"
  • 4.9 Запрос "Внесение данных о состоянии заказа"
  • 4.10 Запрос "Выдача данных о сертификатах качества сырья"
  • 4.11 Запрос "Выдача данных о количестве рабочих дней сотрудников, работающих посменно"
  • 4.12 Запрос "Выдача данных о заказах на определенный день"
  • 4.13 Запрос "Выдача данных о сумме к оплате по каждому заказу на определенный день"
  • 4.14 Запрос "Выдача данных о сумме к оплате по каждому договору"

1. Анализ деятельности предприятия

1.1 Общая характеристика предприятия

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

Организационно-правовая форма ведения деятельности предприятия: "Индивидуальный предприниматель". Форма налогообложения - упрощенная система налогообложения, доходы минус расходы, 15%.

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

1.2 Организационная структура мини-пекарни "Хлебушко"

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

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

база информация автоматизация логическая связь

Производственный блок пекарни занимается непосредственно замесом теста, формовкой и выпечкой хлебобулочных изделий согласно предоставленным заявкам от заказчиков. Сотрудники производственного блока: технолог, разрабатывающий оригинальную рецептуру; пекари и кондитеры, занимающие изготовлением продукции (3 человека в смену); уборщица. Все сотрудники производственного блока подчиняется мастеру производства.

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

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

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

1.3 Связи с внешними организациями

В ходе своей деятельности пекарня взаимодействует с различными внешними субъектами и контролирующими инстанциями: поставщики, заказчики, Инспекция Федеральной Налоговой службы России (ИФНС), Пенсионный фонд России (ПФР), Санэпидемстанция (СЭС), Роспотребнадзор.

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

Заказчики - это юридические лица (розничные магазины), которым пекарня в соответствии с заявками доставляет готовую продукцию для реализации.

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

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

СЭС контролирует, чтобы все производственные части пекарни соответствовали определенным требованиям, относящимся к пищевым производствам.

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

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

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

1.4 Задачи разрабатываемой базы данных

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

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

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

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

· хранение информации о сотрудниках и их трудовых обязанностях;

· хранение информации заказчиках и их заказах

· хранение информации о поставщиках и их договорах

· выдача информации по запросу заключенных договоров с поставщиком

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

· внесение данных о новом заказчике, поставщике, сотруднике

· внесение данных по новому договору, заказу

· внесение данных о новом сырье, продукции

· изменение данных о заказчиках, поставщиках, сотрудниках, договорах и др.

2. Проектирование базы данных

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

2.1 Концептуальное проектирование

Определение сущностей

После рассмотрения задач, которые БД должна решать, были выделены следующие сущности, необходимые для ее проектирования:

1. "Поставщики" - содержит общую информацию о поставщиках

2. "Заказчики" - общая информация о точках сбыта готовой продукции

3. "Сотрудники" - информация о сотрудниках предприятия

4. "Договоры" - данные о договорах, заключенных с поставщиками

5. "Сырье" - информация о сырье, предоставленном поставщиком по договору

6. "Продукция" - информация об ассортименте производимой продукции, цене и т.д.

7. "Заказы" - информация о заявке на производство продукции от заказчика

Назначение описательных атрибутов и ключей

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

Описание атрибутов сущности "Поставщики" приведено в таблице 1. "ID_Поставщика" является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 1 - Атрибуты сущности "Поставщики"

Название атрибута

Описание атрибута

Тип

Пример

ID Поставщика

Уникальный идентификатор

Счетчик

41

Название

Название фирмы-поставщика

Символы

ООО Ека-Торг

Адрес

Юридический адрес поставщика

Текст

г. Свободный, ул. Лени9на, д.12

ИНН

Идентификационный номер налогоплательщика

Число

1353623657

Телефон

Номер телефона

Символы

22-75-43

Примечание

Дополнительные сведения

Текст

Не доступен в субботу

Описание атрибутов сущности "Заказчики" приведено в таблице 2. "ID Заказчика" является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 2 - Атрибуты сущности "Заказчики"

Название атрибута

Описание атрибута

Тип

Пример

ID Заказчика

Уникальный идентификатор

Счетчик

12

Название

Название фирмы-заказчика

Символы

ОАО Продлайн

Адрес

Юридический адрес заказчика

Текст

г. Шимановск, ул. Амурская, д.11

ИНН

Идентификационный номер налогоплательщика

Число

7483697534

Телефон

Номер телефона

Символы

22-71-35

Примечание

Дополнительные сведения

Текст

После 21.00 не беспокоить

Описание атрибутов сущности "Сотрудники" приведено в таблице 3. "ID Сотрудника" является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 3 - Атрибуты сущности "Сотрудники"

Название атрибута

Описание атрибута

Тип

Пример

ID Сот

рудника

Уникальный идентификатор

Счетчик

12

Фамилия

Фамилия сотрудника

Символы

Иванов

Имя

Имя сотрудника

Символы

Иван

Отчество

Отчество сотрудника

Символы

Иванович

Должность

Должность сотрудника

Текст

Пекарь

Смена

Номер рабочей смены сотрудника

Число

1

ИНН

Идентификационный номер налогоплательщика

Число

1458769549

Телефон

Номер телефона

Символы

22-71-35

Адрес

Адрес сотрудника

Текст

г. Шимановск, ул. Пушкина д.11 кв.3

Примечание

Дополнительные сведения

Текст

Уволен

Описание атрибутов сущности "Сырье" приведено в таблице 4. "ID Сырья" является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 4 - Атрибуты сущности "Сырье"

Название атрибута

Описание атрибута

Тип

Пример

ID Сырья

Уникальный идентификатор

Счетчик

1

Название

Наименование сырья

Текст

Мука хлебопекарная

Вес

Вес сырья в кг. (Объем в л)

Число

100

Цена

Цена за кг/л в руб.

Число

26

Срок хранения

Срок годности сырья

Дата

10.2019

Номер сертификата качества

Номер сертификата качества

Число

124686

Примечание

Дополнительные сведения

Текст

Нет на складе

Описание атрибутов сущности "Продукция" приведено в таблице 5. "ID Продукции" является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 5 - Атрибуты сущности "Продукция"

Название атрибута

Описание атрибута

Тип

Пример

ID Продукции

Уникальный идентификатор

Счетчик

13

Название

Наименование продукции

Символы

Хлеб "Фронтовой"

Вес

Вес продукции в г.

Число

250

Цена

Цена в руб., по которой хлебопекарня отпускает продукцию

Число

16

Дата изготовления

Дата изготовления

Дата

10.02.2016

Смена

Номер смены, выпустившей продукцию

Число

2

Примечание

Дополнительные сведения

Текст

Снято с производства

Описание атрибутов сущности "Договоры" приведено в таблице 6. "ID Договора" является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 6 - Атрибуты сущности "Договоры"

Название атрибута

Описание атрибута

Тип

Пример

ID Договора

Уникальный идентификатор

Счетчик

4

Дата

Дата принятия договора

Дата

12.03.2015

Примечание

Дополнительные сведения

Текст

В обработке

Описание атрибутов сущности "Заказы" приведено в таблице 7. "ID Заказа" является ключевым, так как однозначно определяет экземпляр сущности.

Таблица 7 - Атрибуты сущности "Заказы"

Название атрибута

Описание атрибута

Тип

Пример

ID Заказа

Уникальный идентификатор

Счетчик

8

Дата

Дата заказа

Дата

12.03.2015

Состояние

Доставлен заказ или нет

Символы

Доставлено

Определение связей между сущностями

Определим связи, возникающие между сущностями.

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

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

Рисунок 1 - Связь "Поставщики" - "Договоры"

2. "Заказчики" - "Заказы". Одному экземпляру сущности "Заказчики" соответствует несколько экземпляров сущности "Заказы", так как у одного заказчика может быть несколько заказов. Одному экземпляру сущности "Заказы" соответствует определенный экземпляр сущности "Заказчик", так как у данного заказа есть только один заказчик. Следовательно, устанавливается связь "один-ко-многим".

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

Рисунок 2 - Связь "Заказчики" - "Заказы"

3. "Договоры" - "Сырье". Одному экземпляру сущности "Договоры" соответствует несколько экземпляров сущности "Сырье", так как по одному договору может поставляться несколько видов сырья. Одному экземпляру сущности "Сырье" соответствует определенный экземпляр сущности "Договоры", так как данное сырье поставляется по определенному договору. Следовательно, устанавливается связь "один-ко-многим".

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

Рисунок 3 - Связь "Договоры" - "Сырье"

4. "Заказы" - "Продукция". Одному экземпляру сущности "Заказы" соответствует несколько экземпляров сущности "Продукция", так как один заказ включает несколько типов продукции. Одному экземпляру сущности "Продукция" соответствует несколько экземпляров сущности "Заказы", так как одинаковая продукция может поставляться по разным заказам. Следовательно, устанавливается связь "многие-ко-многим".

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

Рисунок 4 - Связь "Заказы" - "Продукция"

5. "Сотрудники" - "Заказы". Одному экземпляру сущности "Сотрудники" соответствует несколько экземпляров сущности "Заказы", так как один сотрудник может выполнять несколько заказов. Одному экземпляру сущности "Заказы" соответствует несколько экземпляров сущности "Сотрудники", так как один заказ могут выполнять несколько сотрудников. Следовательно, устанавливается связь "многие-ко-многим".

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

Рисунок 5 - Связь "Сотрудники" - "Заказы"

6. "Сотрудники" - "Договоры". Одному экземпляру сущности "Сотрудники" соответствует несколько экземпляров сущности "Договоры", так как один сотрудник может заключать несколько договоров. Одному экземпляру сущности "Договоры" соответствует определенный экземпляр сущности "Сотрудники", так как у каждого договора только один сотрудник, заключивший его. Следовательно, устанавливается связь "один - ко - многим".

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

Рисунок 6 - Связь "Сотрудники" - "Договоры"

Построение концептуальной схемы

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

Рисунок 7 - Концептуальная схема

Составление справочника задач

Исходя из описания функционирования предприятия и его основных звеньев, а также зная основные сущности базы данных и связи между ними, можно составить справочник задач. Справочник содержит в себе набор основных запросов к БД.

Таблица 8 - Справочник задач

№

Наименование задачи

Исполнитель

Частота решения

1

Внесение данных о новом поставщике

Директор

1 раз в месяц

2

Внесение данных о новом заказчике

Директор

1 раз в месяц

3

Внесение данных по новому договору

Директор

1 раз в месяц

4

Внесение данных по новому заказу

Директор

30 раз в месяц

5

Внесение данных о новом сырье

Мастер производства

1 раз в месяц

6

Внесение данных о новой продукции

Мастер производства

30 раз в месяц

7

Внесение данных о новом сотруднике

Директор

1 раз в месяц

8

Ведение учета оплаты по договорам и заказам

Бухгалтер

30 раз в месяц

9

Выдача данных о заказах на определенный день

Мастер производства

30 раз в месяц

10

Выявление сотрудников, работающих в определенную смену

Мастер производства

30 раз в месяц

11

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

Бухгалтер

1 раз в месяц

12

Выдача данных о сертификатах качества сырья

Директор

4 раза в месяц

13

Внесение данных о состоянии заказа (доставлен/ не доставлен)

Водитель-экспедитор

30 раз в месяц

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

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

3.1 Установление дополнительных логических связей

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

Таблица 9 - Справочник задач

№

Сущности

1

2

3

4

5

6

7

1

Поставщики

0

0

1

0

1

0

0

2

Заказчики

0

0

31

0

0

30

30

3

Сотрудники

1

31

0

31

5

31

120

4

Договоры

0

0

31

0

0

0

0

5

Сырье

1

0

5

0

0

0

0

6

Продукция

0

30

31

0

0

0

30

7

Заказы

0

30

120

0

0

30

0

Найдем среднее значение совместного использования сущностей по формуле:

,

где aij - частота совместного использования пары сущностей.

Получим:

Далее найдём пары сущностей, частота совместного использования которых больше R. Если прямой связи или связи через еще одну сущность таких сущностей не существует, то нужно ее создать.

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

3.2 Отображение концептуально-инфологической модели на реляционную модель

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

Сущность "Поставщики"

ID Поставщика

Название

Адрес

ИНН

Телефон

Примечание

Сущность "Договоры"

ID Договора

Дата

Примечание

Рисунок 8 - Связь "Поставщики" - "Договоры"

Отображение на реляционную модель:

Отношение "Поставщики"

ID Поставщика

Название

Адрес

ИНН

Телефон

Примечание

Отношение "Договоры"

ID Договора

ID Поставщика

Дата

Примечание

Рисунок 9 - Отношения "Поставщики" и "Договоры"

Рассмотрим сущности "Заказчики" и "Заказы". Между ними установлена связь типа "один-ко-многим" (рисунок 2). Поскольку простая связь исходит от сущности "Заказчики", то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 11.

Сущность "Заказчики"

ID Заказчика

Название

Адрес

ИНН

Телефон

Примечание

Сущность "Заказы"

ID Заказа

Дата

Состояние

Рисунок 10 - Связь "Заказчики" - "Заказы"

Отображение на реляционную модель:

Отношение "Заказчики"

ID Заказчика

Название

Адрес

ИНН

Телефон

Примечание

Отношение "Заказы"

ID Заказа

ID Заказчика

Дата

Состояние

Рисунок 11 - Отношения "Заказчики" и "Заказы"

Рассмотрим сущности "Договоры" и "Сырье". Между ними установлена связь типа "один-ко-многим" (рисунок 3). Поскольку простая связь исходит от сущности "Договоры", то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 13.

Сущность "Договоры"

ID Договора

Дата

Примечание

Сущность "Сырье"

ID Сырья

Название

Вес

Цена

Срок хранения

Номер сертификата качества

Примечание

Рисунок 12 - Связь "Договоры" - "Сырье"

Отображение на реляционную модель:

Отношение "Договоры"

ID Договора

ID Поставщика

Дата

Примечание

Отношение "Сырье"

ID Сырья

ID Договора

Название

Вес

Цена

Срок хранения

Номер сертификата качества

Примечание

Рисунок 13 - Отношения "Договоры" и "Сырье"

Рассмотрим сущности "Заказы" и "Продукция". Между ними установлена связь типа "многие-ко-многим" (рисунок 4). Избавимся от такого типа связи и приведем к виду "один-ко-многим" (рисунок 15). Получаем отношения, представленные на рисунке 16.

Сущность "Заказы"

ID Заказа

Дата

Состояние

Сущность "Продукция"

ID Продукции

Название

Вес

Цена

Дата изготовления

Смена

Примечание

Рисунок 14 - Связь "Заказы" - "Продукция"

Сущность "Заказанная_продукция"

ID Заказа

ID Продукции

Количество

Сущность "Заказы"

ID Заказа

ID Заказчика

Дата

Состояние

Сущность "Продукция"

ID Продукции

Название

Вес

Цена

Дата изготовления

Смена

Примечание

Рисунок 15 - Связь "один-ко-многим"

Отображение на реляционную модель:

Отношение "Заказы"

ID Заказа

ID Заказчика

Дата

Состояние

Отношение "Продукция"

ID Продукции

Название

Вес

Цена

Дата изготовления

Смена

Примечание

Отношение "Заказанная_продукция"

ID Заказа

ID Продукции

Количество

Рисунок 16 - Отношения "Заказы" и "Продукция"

Рассмотрим сущности "Сотрудники" и "Договоры". Между ними установлена связь типа "один-ко-многим" (рисунок 6). Поскольку простая связь исходит от сущности "Сотрудники", то согласно правилу отображения концептуальной модели на реляционную получаем отношения, представленные на рисунке 18.

Сущность "Сотрудники"

ID Сотрудника

Фамилия

Имя

Отчество

Должность

Смена

ИНН

Телефон

Адрес

Примечание

Сущность "Договоры"

ID Договора

ID Поставщика

Дата

Примечание

Рисунок 17 - Связь "Сотрудники" - "Договоры"

Отображение на реляционную модель:

Отношение "Сотрудники"

ID Сотрудника

Фамилия

Имя

Отчество

Должность

Смена

ИНН

Телефон

Адрес

Примечание

Отношение "Договоры"

ID Договора

ID Поставщика

ID Сотрудника

Дата

Примечание

Рисунок 18 - Отношения "Сотрудники" и "Договоры"

Рассмотрим сущности "Сотрудники" и "Заказы". Между ними установлена связь типа "многие-ко-многим" (рисунок 5). Избавимся от такого типа связи и приведем к виду "один-ко-многим" (рисунок 20). Получаем отношения, представленные на рисунке 21.

Сущность "Сотрудники"

ID Сотрудника

Фамилия

Имя

Отчество

Должность

Смена

ИНН

Телефон

Адрес

Примечание

Сущность "Заказы"

ID Заказа

Дата

Состояние

Рисунок 19 - Связь "Сотрудники" - "Заказы"

Сущность "Выполнение_заказа"

ID Заказа

ID Сотрудника

Сущность "Сотрудники"

ID Сотрудника

Фамилия

Имя

Отчество

Должность

Смена

ИНН

Телефон

Адрес

Примечание

Сущность "Заказы"

ID Заказа

Дата

Состояние

Рисунок 20 - Связь "один-ко-многим"

Отображение на реляционную модель:

Отношение "Сотрудники"

ID Сотрудника

Фамилия

Имя

Отчество

Должность

Смена

ИНН

Телефон

Адрес

Примечание

Отношение "Заказы"

ID Заказа

ID Заказчика

Дата

Состояние

Отношение "Выполнение_заказа"

ID Заказа

ID Сотрудника

Рисунок 21 - Отношения "Сотрудники" и "Заказы"

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

ID Поставщика

Название

Адрес

ИНН

Телефон

Примечание

Рисунок 22 - Отношение "Поставщики"

ID Заказчика

Название

Адрес

ИНН

Телефон

Примечание

Рисунок 23 - Отношение "Заказчики"

ID Договора

ID Поставщика

ID Сотрудника

Дата

Примечание

Рисунок 24 - Отношение "Договоры"

ID Заказа

ID Заказчика

Дата

Состояние

Рисунок 25 - Отношение "Заказы"

ID Сотрудника

Фамилия

Имя

Отчество

Должность

Смена

ИНН

Телефон

Адрес

Примечание

Рисунок 26 - Отношение "Сотрудники"

ID Продукции

Название

Вес

Цена

Дата изготовления

Смена

Примечание

Рисунок 27 - Отношение "Продукция"

ID Сырья

ID Договора

Название

Вес

Цена

Срок хранения

Номер сертификата качества

Примечание

Рисунок 28 - Отношение "Сырье"

ID Заказа

ID Продукции

Количество

Рисунок 29 - Отношение "Заказанная_продукция"

ID Заказа

ID Сотрудника

Рисунок 30 - Отношение "Выполнение_заказа"

3.3 Нормализация отношений

Следующим этапом логического проектирования является проверка полученного набора отношений на соответствие трем нормальным формам.

Проверка отношений на соответствие первой нормальной форме

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

Проверка отношений на соответствие второй нормальной форме

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

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

Рассмотрим функциональные зависимости атрибутов отношения "Поставщики" (рисунок 31).

Рисунок 31 - Функциональные зависимости отношения "Поставщики"

Отношение "Поставщики" находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения "Заказчики" (рисунок 32).

Рисунок 32 - Функциональные зависимости отношения «Заказчики»

Отношение «Заказчики» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Договоры» (рисунок 33).

Рисунок 33. Функциональные зависимости отношения «Договоры»

Отношение «Договоры» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Заказы» (рисунок 34).

ID Заказа

ID Заказчика

Дата

Состояние

Рисунок 34 - Функциональные зависимости отношения «Заказы»

Отношение «Заказы» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Сотрудники» (рисунок 35).

Рисунок 35. Функциональные зависимости отношения «Сотрудники»

Отношение «Сотрудники» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Продукция» (рисунок 36).

Рисунок 36- Функциональные зависимости отношения «Продукция»

Отношение «Продукция» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Сырье» (рисунок 37)

Рисунок 37. Функциональные зависимости отношения «Сырье»

Отношение «Сырье» находится во второй нормальной форме

Рассмотрим функциональные зависимости атрибутов отношения «Заказанная_продукция» (рисунок 38).

ID Заказа

ID Продукции

Количество

Рисунок 38 - Функциональные зависимости отношения «Заказанная_продукция»

Отношение «Продукция» находится во второй нормальной форме.

Рассмотрим функциональные зависимости атрибутов отношения «Заказанная_продукция» (рисунок 39).

ID Заказа

ID Сотрудника

Рисунок 39 - Функциональные зависимости отношения «Выполнение_заказа»

Отношение "Выполнение_заказа" находится во второй нормальной форме.

Проверка отношений на соответствие третьей нормальной форме

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

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

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

Рисунок 40 - Логическая модель базы данных

3.4 Физическое проектирование

На основании итоговой логической модели, опишем таблицы, которые будут реализованы в СУБД Microsoft SQL Server.

Таблица 10 - Проект таблицы "Поставщики"

Название поля

Тип данных

Размер

Индексирование

ID Поставщика

int

20

Да

Название

text

50

Нет

Адрес

text

200

Нет

ИНН

int

10

Нет

Телефон

char

20

Нет

Примечание

text

200

Нет

Таблица 11 - Проект таблицы "Договоры"

Название поля

Тип данных

Размер

Индексирование

ID Договора

int

20

Да

ID Поставщика

int

20

Нет

ID Сотрудника

int

20

Нет

Дата

datetime

>01.01.2016

Нет

Примечание

text

200

Нет

Таблица 12 - Проект таблицы "Заказчики"

Название поля

Тип данных

Размер

Индексирование

ID Заказчика

int

20

Да

Название

text

50

Нет

Адрес

text

200

Нет

ИНН

int

10

Нет

Телефон

char

20

Нет

Примечание

text

200

Нет

Таблица 13 - Проект таблицы "Заказы"

Название поля

Тип данных

Размер

Индексирование

ID Заказа

int

20

Нет

ID Заказчика

text

20

Нет

Дата

datetime

>01.01.2016

Нет

Состояние

text

100

Нет

Таблица 14 - Проект таблицы "Сотрудники"

Название поля

Тип данных

Размер

Индексирование

ID Сотрудника

int

20

Да

Фамилия

char

20

Нет

Имя

char

20

Нет

Отчество

char

20

Нет

Должность

text

20

Нет

Смена

int

20

Нет

ИНН

int

10

Нет

Телефон

char

20

Нет

Адрес

text

200

Нет

Примечание

text

100

Нет

Таблица 15 - Проект таблицы "Сырье"

Название поля

Тип данных

Размер

Индексирование

ID Сырья

int

20

Да

ID Договора

int

20

Нет

Название

text

100

Нет

Вес

int

4

Нет

Цена

decimal

(8,2)

Нет

Срок хранения

text

20

Нет

Номер сертификата качества

int

20

Нет

Примечание

text

200

Нет

Таблица 16 - Проект таблицы "Продукция"

Название поля

Тип данных

Размер

Индексирование

ID Продукции

int

20

Да

Название

text

100

Нет

Вес

int

4

Нет

Цена

decimal

(8,2)

Нет

Дата изготовления


Подобные документы

  • Разработка базы данных с использованием средств Microsoft Access для автоматизации процедур учета и формирования заказов на предприятии ООО "Озон"

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

    курсовая работа [358,5 K], добавлен 26.11.2012

  • Создание базы данных

    Создание таблиц базы данных с помощью MS Access "Страны Азии". Форма базы данных и запросы к выборкам данных. Модификация структуры таблиц, создания связей между главными таблицами, редактирование данных и проектирование форм для реальной базы данных.

    контрольная работа [723,9 K], добавлен 25.11.2012

  • Проектирование базы данных для ДЮСШ

    Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.

    курсовая работа [1,7 M], добавлен 04.06.2015

  • База данных по автоматизации деятельности строительной компании

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

    курсовая работа [1,2 M], добавлен 26.05.2015

  • Проектирование базы данных спортивной школы в СУБД Access

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

    курсовая работа [3,4 M], добавлен 08.09.2015

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

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

    курсовая работа [832,8 K], добавлен 23.02.2014

  • Моделирование базы данных для обработки заказов на косметику

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

    курсовая работа [1,4 M], добавлен 03.03.2015

  • Разработка баз данных

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

    курсовая работа [2,3 M], добавлен 26.09.2012

  • Разработка базы данных "Рабочее место дежурного инженера связи"

    Автоматизация работы дежурной службы телекоммуникационной компании. Спецификации сущностей, атрибутов, связей, ссылочной целостности и таблиц. Даталогическая модель базы данных. Запросы пользователей и SQL–запросы. Интерфейс конечного пользователя.

    курсовая работа [301,2 K], добавлен 16.02.2013

  • Создание базы данных в программе Microsoft Access

    Понятия основных компонентов базы данных Access. Таблицы, отчеты, макросы и модули, форма, запросы к базе и их виды. Типы данных. Создание базы данных "Кадры". Создание таблицы в режиме конструктора. Использование мастера подстановок для создания связей.

    курсовая работа [818,0 K], добавлен 10.03.2016

  • Создание базы данных поликлиники

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

    курсовая работа [3,1 M], добавлен 17.12.2014

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

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

    курсовая работа [700,0 K], добавлен 14.01.2015

  • Создание базы данных "Продажи книг"

    Системы управления базами данных: сущность и характеристика. Типы данных и свойства полей СУБД Access. Объекты базы данных: таблицы, схемы данных, формы, запросы, отчеты. Разработка и проектирование базы данных "Продажи книг" в среде Microsoft Access.

    курсовая работа [1,8 M], добавлен 04.02.2013

  • Разработка базы данных учеников МОУ СОШ № 12 на языке Delphi

    Автоматизированные базы данных в учебном процессе. Создание базы данных для МОУ СОШ № 12 с целью помощи в обеспечении централизованного управления, хранения информации об учениках. Требования к программе, условия эксплуатации. Программный код базы данных.

    дипломная работа [2,0 M], добавлен 25.03.2014

  • Учет и обработка данных об учебной литературе кафедры

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

    курсовая работа [113,2 K], добавлен 17.06.2014

  • Автоматизация базы данных для ООО "ОриенБанк"

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

    курсовая работа [4,7 M], добавлен 26.02.2010

  • Проектирование сетевой базы данных "Библиотека"

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

    курсовая работа [3,3 M], добавлен 01.07.2011

  • Разработка базы данных "Сеть ресторанов"

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

    курсовая работа [501,7 K], добавлен 02.12.2014

  • Разработка информационной системы "Аптека"

    Разработка базы данных для информационной поддержки деятельности аптеки с целью автоматизированного ведения данных о лекарствах аптеки. Проектирование схемы базы данных с помощью средства разработки структуры базы данных Microsoft SQL Server 2008.

    курсовая работа [3,6 M], добавлен 18.06.2012

  • Разработка базы данных учета движения готовой продукции на складе ООО "Перекрёсток"

    Необходимая документация при учете готовой продукции на складе ООО "Перекрёсток". Проектирование базы данных на основе нормализации. Схема данных и связи между таблицами в проектируемой базе данных. Обеспечение безопасности и целостности базы данных.

    дипломная работа [2,9 M], добавлен 15.01.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены