Разработка концепции, архитектуры построения и платформы реализации ИС

На рисунке 2.3 представлена топология локальной вычислительной сети (ЛВС) для ОАО «КорпСбор».

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

Рисунок 2.3 - Логическая схема сети ОАО "КорпСбор"

 

3 ИНФОРМАЦИОННОЕ ОБЕСПЕЧЕНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ

3.1 Описание концептуальной модели информационной базы

Для хранения данных в информационной системе используется реляционная  база данных под управлением СУБД Oracle 11g. Концептуальная схема структуры информационной базы приведена на рисунке 3.1.

В АИС «Корпусная мебель»  основными объектами являются Заказ, Детали, Материалы, Счет, Заказчик, Фурнитура, План раскроя, Акт о выполненных  работах.Рассмотрим отдельно каждый из объектов.

У сущности «Заказ» есть следующие атрибуты: Номер заказа, Дата поступления, Наименование заказа, Количество комплектов, Срок выполнения, Id заказчика, Id плана.

Сущность  «Детали» имеет следующие атрибуты: Id детали, Длина, Ширина, Наименование, Id заказа, Id материала, Количество.

Сущность  «Материал» имеет атрибуты: Наименование, Id материала, Цена за лист, Длина, Ширина.

Сущность  «Счет» имеет атрибуты: Id счета, Сумма к оплате, Id заказа.

Сущность  «Заказчик» имеет атрибуты: Id заказчика, ФИО, Адрес, Телефон.

Сущность  «Фурнитура» имеет атрибуты: Id фурнитуры, Наименование, Количество, Стоимость, Id заказа.

Сущность  «План раскроя» имеет атрибуты: Id плана, Файл-изображение (переменная строкового типа, в которой будет храниться ссылка на изображение с планом раскроя), Наименование.

Сущность  «Акт о выполненных работах» имеет  атрибуты: Id плана, Дата окончания работ, ФИО исполнителя, Id заказа.

Между объектами Заказ  и Детали максимальная мощность связи 1:N, т.е. одному заказу может принадлежать множество деталей.

 

Рисунок 3.1 - Концептуальная схема базы данных

 

Между объектами Детали и Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами Акт о выполненных работах и Заказ максимальная мощность связи 1:1, т.е. одному заказу может соответствовать 1 акт о выполнении работ.

Между объектами Заказ и Счет максимальная мощность связи 1:1, т.е. заказу может соответствовать только 1 счет.

Между объектами Заказ  и План раскроя максимальная мощность связи 1:N, т.е. в заказе может быть создано несколько планов раскроя.

Между объектами Заказ  и Заказчик максимальная мощность связи 1:N, т.е. у одного заказчика может быть множество заказов.

Между объектами Детали и  Материал максимальная мощность связи 1:N, т.е. на листе материала может быть множество деталей.

Между объектами Фурнитура и Заказ  максимальная мощность 1:N, т.е. одному заказу может соответствовать множество единиц фурнитуры.

3.2 Описание логической структуры информационной базы

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

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

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

 

Процесс преобразования отношений базы данных (БД) к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Общее назначение процесса нормализации заключается в следующем:

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

Устранение  избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов)[9].

В создании и развитии теории нормализации принимали участие  многие учёные. Однако первые три нормальные формы и концепцию функциональной зависимости предложил Э. Кодд.

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

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

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

Нормальная форма Бойса-Кодда (BCNF): переменная отношения находится в нормальной форме Бойса-Кодда (иначе — в усиленной третьей нормальной форме) тогда и только тогда, когда каждая ее нетривиальная и неприводимая слева функциональная зависимость имеет в качестве своего детерминанта некоторый потенциальный ключ.

Четвёртая нормальная форма (4NF): переменная отношения находится в четвёртой нормальной форме, если она находится в нормальной форме Бойса — Кодда и не содержит нетривиальных многозначных зависимостей.

Пятая нормальная форма (5NF): переменная отношения находится в пятой нормальной форме (иначе — в проекционно-соединительной нормальной форме) тогда и только тогда, когда каждая нетривиальная зависимость соединения в ней определяется потенциальным ключом (ключами) этого отношения[10].

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

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

 

 

Рисунок 3.2 – Логическая структура информационной базы

 

 

3.3 Описание физической реализации БД

Физическое  проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т.п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т.д.[11].

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

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

В конструкторе были созданы следующие таблицы: Details, Materials, invoice, Furnitur, Zakaz, Zakazchik, Design_cutting, Akt_work_perfomed. Физическая модель АИС «Корпусная мебель» представлена на рисунке 3.3.

Описание созданных таблиц базы данных приведены в таблицах 3.1-3.7.

 

 

 

Рисунок 3.3 - Физическая модель

 

Таблица 3.1 - Описание полей таблицы Zakaz

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_zakaz	Номер заказа	Integer	PK
Date_invite	Дата заказа	Date	-
Name_zakaza	Имя заказа	Varchar2(255)	-
quantity_komplects	Количество комплектов	Integer	-
Period_execution	Срок выполнения	Date	-
Id_zakazchik	Идентификационный номер заказчика	Integer	FK

 

Таблица 3.2 - Описание полей таблицы Zakazchik

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_zakazchik	Идентификационный номер заказчика	Integer	PK
FIO	ФИО заказчика	Varchar2(255)	-
Adress	Адрес заказчика	Varchar2(255)	-
Telephone	Телефон	Integer	-

 

Таблица 3.3 - Описание полей таблицы Details

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_det	Номер детали	Integer	PK
Name	Имя детали	Varchar2(255)	-
Dlina	Длина детали	Decimal(10,2)	-
Shirina	Ширина детали	Decimal(10,2)	-
Kolvo	Количество таких деталей в  проекте	Integer	-
Id_zakaz	Идентификатор заказа	Integer	FK
Id_mater	Идентификатор материала	Integer	FK

 

Таблица 3.4 - Описание полей таблицы Furnitur

Наименование поля БД	Описание поля	Тип данных	Примечание
id_furnit	Номер детали	Integer	PK
Name	Имя детали	Varchar2(255)	-
quantity	Количество	Integer	-
cost	Цена за штуку	Decimal(10,2)	-
Id_zakaz	Идентификатор заказа	Integer	FK

 

Таблица 3.5 - Описание полей таблицы Materials

Наименование поля БД	Описание поля	Тип данных	Примечание
id_mater	Номер листа	Integer	PK
Name	Имя детали	Varchar2(255)	-
Dlina	Длина	Decimal(10,2)	-
Cost_of_list	Цена за лист	Decimal(10,2)	-
Shirina	Идентификатор заказа	Decimal(10,2)	-

 

Таблица 3.6 - Описание полей таблицы invoice

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_schet	Идентификационный номер счета	Integer	PK
Date_invoice	Дата оплаты	Date	-
Summ_for_pay	Сумма к оплате	Decimal(10,2)	-
Summ_work	Оплата работы	Decimal(10,2)
Summ_of_materials	Затраты на материалы	Decimal(10,2)	-
Id_zakaz	Номер заказа	Integer	FK

 

Таблица 3.7 - Описание полей таблицы Akt_work_perfomed

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_act	Идентификационный номер счета	Integer	PK
Data_end	Дата выполнения	Date	-
FIO_worker	ФИО исполнителя	Varchar2(255)	-
Id_zakaz	Номер заказа	Integer	FK

 

Таблица 3.8 - Описание полей таблицы Design_cutting

Наименование поля БД	Описание поля	Тип данных	Примечание
Id_design	Идентификационный номер плана	Integer	PK
File_raskroy	Файл с планом раскроя	Blob	-
Name_design	Наименование плана	Varchar2(255)	-
Id_zakaz	Номер заказа	Integer	FK

 

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

 

Рисунок 3.4 – Пример заполнения таблиц в базе данных Oracle