Автоматизация расчета прибыли производства дизайнерской мягкой мебели из велюра за месяц

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

МИНИСТЕРСТВО НАУКИ И ВЫСШЕГО ОБРАЗОВАНИЯ

РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное автономное образовательное учреждение высшего образования

«ТЮМЕНСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ»

ИНСТИТУТ МАТЕМАТИКИ И КОМПЬЮТЕРНЫХ НАУК

Кафедра ИНФОРМАЦИОННЫХ СИСТЕМ

Отчёт

Тема: “Автоматизация расчёта прибыли производства дизайнерской мягкой мебели из велюра за месяц”

Выполнил студент группы 21.06-1

Е.А. Игнатова

Проверила: доцент кафедры ИС, к.т.н.

Л.Н. Бакановская

Тюмень 2022



Содержание

1. Описание предметной области

2. Контекстная диаграмма предметной области

3. Физическая модель предметной области



1. Описание предметной области

Рассматриваемая предметная область - автоматизация расчёта прибыли производства дизайнерской мягкой мебели из велюра. А именно, база данных должна обеспечивать процесс расчёт доходов фирмы за месяц. Доходы компания получает посредством продажи различной мебели оптом или в розницу. Связи между сущностями неидентифицирующие, за исключением таблиц «Клиент» - «Заказ» - «Продукт» (Рисунок 2). Реализация продукции производится посредством продажи в сети магазинов, где клиент лично совершает подпись договора при покупке.

Клиент

Продукт

Вид товара

Материал

Наполнитель

Механизм трансформации

Заказ

Расход

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

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

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

Клиент

ID клиента;

Фамилия;

Имя;

Отчество;

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

Материал

ID вида материала;

Материал;

ID покупки (FK).

Продукт

ID продукта;

Название продукта;

Количество;

Цена;

Цвет;

Высота;

Ширина;

Длина;

Фото;

ID вида (FK);

ID материала (FK);

ID наполнителя (FK);

ID механизма (FK).

Расход

ID покупки;

Стоимость покупки;

Название;

Количество.

Наполнитель

ID наполнителя;

Наполнитель;

ID покупки (FK).

Механизм трансформации

ID механизма;

Механизм;

ID покупки (FK).

Заказ

ID клиента (FK);

ID товара (FK);

Стоимость заказа;

Количество позиций;

Дата покупки;

Время покупки.

Вид товара

ID вида товара;

Вид товара.

2. Контекстная диаграмма предметной области

Рисунок 1 - Контекстная диаграмма.

Таблицы «Заказ» и «Расход» нам необходимы для выполнения цели автоматизации. Они учувствуют в расчёте чистой выручки, по формуле: Сумма(Стоимость заказа*Количество позиций) - (Сумма(Стоимость покупки*Количество)). Эта формула используется при составлении отчёта, в конце месяца отчёт отправляется начальству.

Исходя из диаграммы можно сделать вывод о том, что в процессе разработки моделей в нотации IDEF1X (Рисунок 2) возникнет две связи многие-ко-многим. Обосновать это можно, во-первых, тем, что один Клиент может выбрать несколько продуктов и один продукт могут выбрать несколько клиентов, во-вторых, продукт может быть сделан из нескольких материалов, и множество продуктов может состоять только из одного материала.

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

Логическая модель предметной области

Рисунок 2 - Логическая ER - диаграмма в нотации IDEF1X.

Нормализация базы данных

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

Первая нормальная форма (1НФ):

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

Вторая нормальная форма (2НФ):

Требование этой формы заключается в следующем: Отношение находится во 2НФ, если оно находится в 1НФ и каждый не ключевой атрибут неприводимо зависит от первичного ключа (ПК). В представленной базе данных все атрибуты неприводимо зависят от первичного ключа.

Третья нормальная форма (3НФ):

Требование этой формы заключается в следующем: Отношение находится в 3НФ, когда находится во 2НФ и каждый не ключевой атрибут нетранзитивно зависит от первичного ключа. В представленной базе данных каждый не ключевой атрибут нетранзитивно зависим от первичного ключа. Пример соблюдения третьей нормальной формы можно наблюдать в отношении «Продукт» - «Материал», продукт не зависит от материала, а материал не зависит от продукта.

Ограничения целостности

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

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

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

ID клиента

ID продукта

ID вида продукта

ID механизма

ID наполнителя

ID материала

ID покупки

Следующие атрибуты не могут нести в себе null-значения и не допускаются повторения. Декларативное ограничение.

Название продукта

Фото Механизм

Наполнитель Материал

Вид продукта

Вид продукта -- это уникальное поле. Тип - поле, которое содержит варианты: диван, пуф, кресло.

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

Ниже представлены ограничения целостности по связям отношений:

Рисунок 3 - General (1) - Кардинальность отношений «Клиент» - «Заказ»

Рисунок 4 - Rl Actions (1) - Относительные действия отношений «Клиент» - «Заказ»



Рисунок 5 - General (2) - Кардинальность отношений «Продукт» - «Заказ»

Рисунок 6 - Rl Actions (2) - Относительные действия отношений «Продукт» - «Заказ»

Рисунок 7 - General (4) - Кардинальность отношений «Механизм» - «Продукт»



Рисунок 8 - Rl Actions (4) - Относительные действия отношений «Механизм» - «Продукт»

Рисунок 9 - General (5) - Кардинальность отношений «Наполнитель» - «Продукт»



Рисунок 10 - Rl Actions (5) - Относительные действия отношений «Наполнитель» - «Продукт»

Рисунок 11 - General (6) - Кардинальность отношений «Вид продукта» - «Продукт»

Рисунок 12 - Rl Actions (6) - Относительные действия отношений «Вид продукта» - «Продукт»



Рисунок 13 - General (7) - Кардинальность отношений «Продукт» - «ПродуктМатериал»

Рисунок 14 - Rl Actions (7) - Относительные действия отношений «Продукт» - «ПродуктМатериал»

Рисунок 15 - General (8) - Кардинальность отношений «Материал» - «ПродуктМатериал»



Рисунок 16 - Rl Actions (8) - Относительные действия отношений «Материал» - «ПродуктМатериал»

Рисунок 17 - General (9) - Кардинальность отношений «Расход» - «Материал»

Рисунок 18 - Rl Actions (9) - Относительные действия отношений «Расход» - «Материал»



Рисунок 19 - General (10). Кардинальность отношений «Расход» - «Наполнитель»

Рисунок 20 - Rl Actions (10). Относительные действия отношений «Расход» - «Наполнитель»



Рисунок 21 - General (11). Кардинальность отношений «Расход» - «Механизм»

Рисунок 22 - Rl Actions (11). Относительные действия отношений «Расход» - «Механизм»



3. Физическая модель предметной области

Рисунок 3 - Физическая ER - диаграмма.

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

Типы данных

Далее в таблицах представлены типы данных атрибутов с их обоснованием и примером:

Таблица 1 - Типы данных атрибутов сущности «Вид продукта».

Вид товара
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	ID вида товара	INTEGER (PK)	Первичный ключ уникально идентифицирует строку в таблице.	5
2	Вид товара	VARCHAR(60)	VARCHAR потому что вид - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Пуф



Таблица 2 - Типы данных атрибутов сущности «Клиент»

Клиент
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	ID клиента	INTEGER (PK)	Первичный ключ уникально идентифицирует строку в таблице.	13
2	Фамилия	VARCHAR(60)	VARCHAR, потому что фамилия - небольшая небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Петров
3	Имя	VARCHAR(60)	VARCHAR, потому что имя - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Иван
4	Отчество	VARCHAR(60)	VARCHAR, потому что отчество - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Иванович
5	Номер телефона	INTEGER	INETEGER, потому что номер телефона - последовательность чисел NOT NULL	78665421365

Таблица 3 - Типы данных атрибутов сущности «Заказ»

Заказ
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	Стоимость заказа	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	6000
2	Количество позиций	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	5
3	Время покупки	DATETIME	DATETIME, потому что атрибут несет в себе время NOT NULL	16:11
4	Дата покупки	DATE	DATE, потому что атрибут несёт в себе дату NOT NULL	16.08.2022
5	ID клиента	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	1
6	ID продукта	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	2



Таблица 4 - Типы данных атрибутов сущности «Материал»

Материал
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	ID вида материала	INTEGER (PK)	Первичный ключ уникально идентифицирует строку в таблице.	1
2	Материал	VARCHAR(60)	VARCHAR потому что вид - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Пуф
3	ID покупки (FK)	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	1

Таблица 5 - Типы данных атрибутов сущности «Механизм трансформации»

Механизм трансформации
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	ID механизма	INTEGER (PK)	Первичный ключ уникально идентифицирует строку в таблице.	1
2	Механизм	VARCHAR(60)	VARCHAR потому что вид - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	клик-кляк
3	ID покупки (FK)	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	1

Таблица 6 - Типы данных атрибутов сущности «Продукт»

Продукт
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	ID продукта	INTEGER (PK)	Первичный ключ уникально идентифицирует строку в таблице.	1
2	Название продукта	VARCHAR(60)	VARCHAR, потому что название - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Диван Холо
3	Количество	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	10
4	Цена	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	6000
5	Цвет	VARCHAR(60)	VARCHAR, потому что цвет - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Черный
6	Высота	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	1
7	Длина	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	2
8	Ширина	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	3
9	Фото	LARGE BINARY	LARGE BINARY - массив двоичных данных, специальный тип данных, используемый для хранения изображений NOT NULL	-
10	ID вида	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	12
11	ID материала	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	34
12	ID наполнителя	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	5
13	ID механизма	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	1

Таблица 7 - Типы данных атрибутов сущности «Расход»

Расход
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	ID покупки	INTEGER(PK)	Первичный ключ. Тип INTEGER, т.к. данный тип содержит возможности serial к уникальности и не повторяемости.	1
2	Название	VARCHAR(60)	VARCHAR, потому что название - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Массив ясени 2x2
3	Количество	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	10
4	Стоимость покупки	INTEGER	INTEGER, потому что атрибут несет в себе целое число NOT NULL	6000

Таблица 8 - Типы данных атрибутов сущности «Наполнитель»

Наполнитель
№ п/п	Наименование атрибута	Тип данных	Подробное обоснование с примером по экземпляру	Пример
1	ID вида материала	INTEGER (PK)	Первичный ключ уникально идентифицирует строку в таблице.	1
2	Наполнитель	VARCHAR(60)	VARCHAR потому что наполнитель - небольшая последовательность символов в TEXT и CHAR нет нужды NOT NULL	Пух
3	ID покупки (FK)	INTEGER (FK)	Внешний ключ, данные берутся из другой таблицы	1

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

...