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

Содержание:

ВВЕДЕНИЕ

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

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

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

— интеграция крупных проектов;

— промышленное производство на собственном заводе (включая уникальные продукты и серийное производство компьютерной техники);

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

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

— сервис и поддержка клиентов во всех субъектах РФ.

Как и в собственности любой крупной производственных компании, у Kraftway есть свой склад хранения и производства товаров. Информация о содержимом, а также документация хранится и обслуживается системой Home Management System (далее — HMS), структура которой имеет некоторые недостатки.

Задача, поставленная компанией, описывается следующими требованиями:

1. Провести анализ существующих информационных систем компании для выявления решения, компенсирующего недочеты;
2. Разработать дополнительное программное обеспечение для интеграции систем: поставки, HMS, БД бухгалтерии при возможности;
3. Обеспечить хранение информации о поставках и партиях, а также возможность хранения изображений или ссылок на изображения документов различных типов.

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

ГЛАВА 1 ТЕОРЕТИЧЕСКИЕ АСПЕКТЫ РАЗРАБОТКИ КЛИЕНТСКИХ ПРОГРАММ

1.1 HMS

Существующая система обслуживания склада HMS основана на системе Infor ERP SyteLine [1], которая, как основа отраслевых решений компании Фронтстеп, является информационной системой, предназначенной для управления ресурсами среднемасштабных промышленных предприятий. Отрасли применения включают производство электроники, на которой специализируется Kraftway. В круг выполняемых системой Infor ERP SyteLine задач входит:

— хранение, анализ и сбор информации по всем взаимоотношениям с клиентом;

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

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

HMS обеспечивает выполнение широкого круга задач, но по причине того, что является вторичным продуктом компании Фронтстеп, настройка и интеграция которого в деятельность Krafway осуществлялась в 2010 году, с течением времени в ней выявились недостатки, компенсировать которые призвано дополнительное программное обеспечение.

Приемка товаров — начальная операция, связанная с движением товара на складе и возникновением материальной ответственности [2].

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

Второй этап приемки характеризуется проверкой количества доставленных партий товаров (взвешивание, проверка заполненности тарных единиц, подсчет штучных товаров).

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

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

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

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

Разработка базы данных осуществляется в течение нижеприведенных этапов [3]:

1. Инфологическое проектирование.
2. Определение требований к системе.
3. Выбор инструментальных и программных средств, таких как: система управления базой данных (СУБД) и др.
4. Логическое проектирование.
5. Физическое проектирование.

1.2 Инфологическое проектирование

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

Основная цель создания дополнительного ПО — обеспечение хранения этой дополнительной информации [4]. В основе анализа предметной области (ПрО) лежит следующая документация:

1. информация по поставкам;
2. информация по партиям;
3. сопроводительные документы по заказам.

Также в базе данных должна фигурировать информация о:

1. Продукции;
2. Месте хранения;
3. Производителе;
4. Поставщиках;
5. Ответственных за товар / Сотрудниках;
6. Документах.

При этом информация, хранимая в новой базе данных, не должна дублироваться.

Сущность является объектом, информация о котором будет храниться в базе данных.

Для создания ER-диаграммы [5] необходимо выделить сущности предметной области:

1. Информация по поставкам (Контрагент, Заказ, Ответственный за заказ, Главная организация, тип заказов, Департамент, Гарантия, Количество партий в поставке);
2. Информация по партиям (Внешний Артикул от поставщика, Внутренний артикул компании, Модель, Имя, Завод, Производитель, Страна, Дата производства (год), Годен до, Дата разгрузки, Внутренний код партии, Количество поставок в партии);
3. Изображения (Идентификатор, Имя документа, Статус актуальности, Автор);
4. Хранение ссылок на изображения разных типов (Идентификатор, Ссылка на изображение);
5. Комментарии (Идентификатор, Текст, Статус актуальности).

3.3 Создание ER-диаграммы

На Рис. 1 приведена полученная ER-диаграмма. Информация о продукте хранится в сущности «Поставки». Как было объяснено выше, одна партия может быть разделена на несколько поставок, а также в одной поставке может находиться несколько партий, поэтому связь между этими сущностями определяется как «M:N», «многие-ко-многим» [6].

Так как информация о продукте хранится в партиях, то и изображения продукта и документов должны быть привязаны к этой же сущности. У одного продукта может быть несколько изображений (фотографий), поэтому реализуется связь «1:M», «один-ко-многим» [7].

У изображения обязательно должна быть ссылка на его хранение, поэтому реализуется связь «1:1», «один-к-одному». Что касается комментариев — их может быть много, но показываться в интерфейсе пользователю должен только один, определенный статусом. При этом, все комментарии должны быть сохранены в памяти, поэтому между этими сущностями — связь «1:M», «один-ко-многим».

Рис. 1. ER-диаграмма базы данных

После доработки было решено, что сущность «Изображения» следует дублировать, чтобы получить сущность «Документы» для отдельного их хранения. Ссылки на документы также хранятся отдельно. Характеристики новых сущностей:

1. Документы (Идентификатор, Имя документа, Статус актуальности, Автор);
2. Хранение ссылок на изображения разных типов (Идентификатор, Ссылка на изображение).

Усовершенствованная ER-диаграмма показана на Рис. 2. У поставки может быть несколько сопроводительных документов, поэтому связь между этими сущностями такая же, как и между поставками и изображениями.

Что касается ссылок — у каждого документа своя ссылка на место хранения, поэтому реализуется связь «один-к-одному».

Рис. 2. Доработанная ER-диаграмма базы данных

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

1.3 Требования, предъявляемые к системе

Для открытия БД у клиента требуется наличие браузера (Internet Explorer 10 для Windows Server 2010) [8]:

1. Процессор: Компьютер с 32-разрядным (x86) или 64-разрядным (x64) процессором с тактовой частотой 1 ГГц.
2. Операционная система: Windows Server 2010.
3. Память: 512 МБ.
4. Свободное место на жестком диске: 200 МБ.
5. Дисплей: монитор Super VGA разрешением 800 x 600 или выше с отображением 256 цветов;
6. Периферийные устройства: модем или подключение к Интернету.
7. Мышь Microsoft Mouse, Microsoft IntelliMouse или совместимое указывающее устройство.

Таковые определяются требованиями к Microsoft Server 2012 (ниже представлен минимум) [9]:

1. Процессор: 64-разрядный процессор с тактовой частотой 1,4 ГГц.
2. ОЗУ: 512 МБ.
3. Требования к месту на диске: 32 ГБ.
4. Адаптер Gigabit Ethernet (10/100/1000 Base-T).
5. Дисковод DVD-дисков (если операционная система будет устанавливаться с DVD-диска).

Следующие элементы не являются безусловно обязательными, но необходимы для некоторых компонентов:

1. Монитор SuperVGA (1024x768) или с более высоким разрешением.
2. Клавиатура и мышь Microsoft (или другое совместимое указывающее устройство).
3. Доступ к Интернету (может потребоваться дополнительная оплата).

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

ГЛАВА 2 РАЗРАБОТКА ПРОГРАММЫ

2.1 Выбор инструментальных и программных средств

Требования к программной и информационной совместимости

1. Программа для работы с базой данных должна представлять собой самостоятельный исполняемый модуль.
2. Реализуемая база данных должна обеспечивать интеграцию с существующей складской системой и БД бухгалтерии; компенсировать отсутствие партийного учета; обеспечивать хранение дополнительной информации о заводах-изготовителях, стране и годе производства и других данных о продукте [10].

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

1. База данных должна работать под управлением MS SQL Server 2012 [11] в многопользовательском режиме в среде Windows Server 2010.
2. Программное обеспечение должно быть написано на языке SQL.
3. Интерфейс должен быть реализован в среде Microsoft Visual Studio.

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

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

• 1. Преобразование ER-диаграммы в схему базы данных

Вследствие существования связи «многие-ко-многим» была образована вспомогательная сущность [12] «Партии-Поставки», однако в процессе тестирования было выяснено, что нет нужны хранить информацию о поставках отдельно, и более продуктивное решение — частично перенести данные во вспомогательную сущность, частично избавиться от некоторых атрибутов. Следовательно, в сущность «Партии-Поставки» были добавлен Идентификатор, Код задания (который создается при добавлении новой записи в БД), Количество партий в поставке.

Также было решено, что целесообразнее привязать сущность «Комментарий», как и сущность «Документы», к той же вспомогательной сущности «Партии-Поставки».

В сущность «Комментарий» был добавлен атрибут «pr_no», являющийся дубликатом идентификатора пользователя в основной базе данных. Так как прямая связь между базами данных была сложно осуществимой, было решено сделать копию.

Полученная схема базы данных приведена на Рис. 3.

Рис. 3. Схема базы данных

В таблицах 1-8 представлено составление реляционных отношений.

В Таблице 1 показаны атрибуты сущности «Поставки»: ID (который является первичным ключом), Модель, Имя модели, Артикул2 (код товара внутри компании), Производитель, Страна, Дата производства, Дата поставки, Гарантия, Проверка ОТК, Дата пригодности, Страна.

Стоит заметить, что Дата производства относится ко времени изготовления партии, а Дата поставки — ко времени приема партии на склад.

Таблица 1

«Партия»

Название	Тип данных	Примечание
ID	Числовой	ПК
Модель	Текстовый	Not null
Имя модели	Текстовый	Not null
Артикул2	Текстовый	Not null
Производитель	Текстовый
Дата производства	Дата
Дата поставки	Дата	Not null
Гарантия	Текстовый
Проверка ОТК	Числовой
Дата пригодности	Дата
Страна	Текстовый

В Таблице 2 показаны атрибуты вспомогательной сущности «Партии-Поставки»: ID (который является первичным ключом), ID Партии (ВнК к таблице «Партия»), ID Поставки, Количество партий в поставке, Код задания.

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

Таблица 2

«Партии-Поставки»

Название	Тип данных	Примечание
ID	Числовой	ПК
ID Партии	Числовой	ВнК к таблице «Партия»
ID Поставки	Числовой	Not null
Код задания	Числовой	Not null
Количество партий в поставке	Числовой	Default 1

В Таблице 3 показаны атрибуты сущности «Изображения»: ID (ПК), Название, Партия (ВнК к таблице «Партия»), Статус актуальности, Автор. Так как информация о том, кто добавляет изображение, не выводится пользователю, нет смысла реализовывать связь с таблицей пользователей основной БД.

Таблица 3

«Изображения»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null
Партия	Числовой	ВнК к Партия(ID)
Статус актуальности	Текстовый	Not null
Автор	Текстовый
Тип	Текстовый	Not null

В Таблице 4 показаны атрибуты сущности «Ссылки на изображения»: ID (ПК и ВнК к таблице «Изображения»), Ссылка на изображение, Изображение.

Таблица 4

«Ссылки на изображения»

Название	Тип данных	Примечание
ID	Числовой	ПК, ВнК к таблице «Изображения»
Ссылка	Гипперссылка	Not null
Изображение	Числовой

В Таблице 5 показаны атрибуты схожей сущности «Документы»: ID (ПК), Название, Поставка (ВнК к таблице «Партии-Поставки»), Статус актуальности, Автор.

Таблица 5

«Документы»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null
Партия-Поставка	Числовой	ВнК к к таблице «Партии-Поставки»
Статус актуальности	Текстовый	Not null
Автор	Текстовый
Тип	Текстовый	Not null

Таблица 6, характеризующая атрибуты сущности «Ссылки на документы», аналогична Таблице 4: ID (ПК и ВнК к таблице «Документ»), Ссылка на документ, Документ.

Таблица 6

«Ссылки на документы»

Название	Тип данных	Примечание
ID	Числовой	ПК, ВнК к таблице «Документы»
Ссылка	Гипперссылка	Not null
Документ	Числовой

В Таблице 7 показаны атрибуты сущности «Комментарий»: ID (ПК), ответственный за заказ, Текстовое поле, Статус актуальности, Партия-Поставка (ВнК к к таблице «Партии-Поставки»).

Таблица 7

«Комментарий»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null
Партия-Поставка	Числовой	ВнК к к таблице «Партии-Поставки»
Статус актуальности	Текстовый	Not null
Автор	Текстовый

• 1. Нормализация

По схеме БД видно, что существует две связи 1:1, что является денормализацией [13]. Следует объединить таблицы:

1. «Изображения» и «Ссылки на изображения».
2. «Документы» и «Ссылки на документы».

Также было найдено дублирование данных в сущностях:

1. «Партия» (атрибут «Страна»);
2. Изображения (атрибут «Тип»);
3. Документы (атрибут «Тип»).

Для нормализации до четвертой нормальной формы были выделены следующие сущности.

В Таблице 8 показаны атрибуты сущности «Страна»: ID (ПК), Название.

Таблица 8

«Страна»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null

Следовательно, после нормализации сущность «Партия» (Таблица 9) лишится текстового атрибута, который заменится более простым текстовым полем, который станет внешним ключом для таблицы «Страна».

Таблица 9

«Партия»

Название	Тип данных	Примечание
ID	Числовой	ПК
Модель	Текстовый	Not null
Имя модели	Текстовый	Not null
Артикул2	Текстовый	Not null
Производитель	Текстовый
Дата производства	Дата
Дата поставки	Дата
Гарантия	Текстовый
Проверка ОТК	Числовой
Дата пригодности	Дата
Страна	Числовой	ВнК к таблице «Страна»

Тем же самым способом была произведена нормализация сущностей «Изображения» и «Документы». В Таблице 10 показаны атрибуты сущности «Тип изображения».

Таблица 10

«Тип изображения»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null

Следовательно, в отношении «Изображения» текстовое поле заменяется более коротким числовым, который будет являться внешним ключом к таблице «Тип изображения». Также после объединения с таблицей «Ссылки на изображения» появится атрибут «Ссылка».

Таблица 11

«Изображения»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null
Партия	Числовой	ВнК к Партия(ID)
Статус актуальности	Текстовый	Not null
Автор	Текстовый
Тип	Числовой	ВнК к таблице «Тип изображения»
Ссылка	Текстовый	Not null

Аналогичные действия проводятся для нормализации отношения «Документы». Изменения представлены в Таблицах 12-13.

Таблица 12

«Тип документа»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null

Таблица 13

«Документы»

Название	Тип данных	Примечание
ID	Числовой	ПК
Название	Текстовый	Not null
Партия-Поставка	Числовой	ВнК к к таблице «Партии-Поставки»
Статус актуальности	Текстовый	Not null
Автор	Текстовый
Тип	Числовой	ВнК к таблице «Тип документа»
Ссылка	Текстовый	Not null

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

Рис. 4. Схема БД после нормализации

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

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

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

Название БД в системе компании: Erp_PurchaseLot.

Данные таблиц базы данных приведены в Приложении 1.

1. Триггер «articul2» является проверкой на ввод и на обновление артикула [14]. Ограничения таковы: вводимые символы должны быть цифрами, а их длина должна быть не больше тринадцати. При неправильном вводе пользователь видит сообщение об ошибке.
2. Триггер «task_num» является аналогичной проверкой на ввод кода задания. Требования: вводимые символы должны быть цифрами, а их длина должна быть не больше шести. Результатом неправильного ввода является сообщение об ошибке.

Код созданных триггеров приведен в Приложении 2.

На Рис. 5 показан скрин диаграммы БД из MS Server 2012.

Рис. 5. Диаграмма базы данных

1. Представления [15].

В интерфейсе была реализована связь основной БД с дополнительным модулем. Это было сделано через представления. На Рис. 6 показано представление dbo.v_PoReceiptTasks. Оно состоит из двух атрибутов:

— task_id (код задачи, который создается при занесении нового заказа в БД);

— pr_no (идентификатор для связи с другими таблицами).

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

Рис. 6. Представление dbo.v_PoReceiptTasks

На Рис. 7 показано представление dbo.v_PoReceiptItems. Оно состоит из четырех атрибутов:

— pr_no (тот же идентификатор из представления dbo.v_PoReceiptTasks);

— pi_no (идентификатор для связи с другими таблицами);

— ri_no (не использующийся на данный момент идентификатор);

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

Рис. 7. Представление dbo.v_PoReceiptItems

На Рис. 8 показано представление dbo.v_PoReceipt. Оно состоит из двух атрибутов:

— pr_no (тот же идентификатор из представления dbo.v_PoReceiptTasks).

— pm_no (идентификатор для связи с другими таблицами).

Рис. 8. Представление dbo.v_PoReceipt

На Рис. 9 показано представление dbo.v_PoMainItems, состоящее из двух атрибутов:

— pi_no (тот же идентификатор, что и в представлении dbo.v_PoReceiptItems);

— sku (артикул товара).

Рис. 9. Представление dbo.v_PoMainItems

На Рис. 10 показано представление dbo.v_PoMain. В нем содержатся такие атрибуты, как:

— pm_no (тот де идентификатор, который содержится в представлении dbo.v_PoReceipt);

— order_number (номер заказа);

— co_name (название компании-поставщика);

— responsible_no (идентификатор ответственного за заказ менеджера).

Рис. 10. Представление dbo.v_PoMain

Источником этих представлений является база данных ERP_Purchase, схема которой приведена в Приложении 3.

На Рис. 11 — представление dbo.ArticulInfo. Оно состоит из таких значимых атрибутов:

— (артикул товара внутри компании, атрибут sku представления dbo.v_PoMainItems);

— ManufactureName (код производителя)

— Country (страна);

— SkuName (название товара по артикулу);

— ID (уникальный первичный ключ).

Рис. 11. Представление dbo.ArticulInfo

База данных articul2 является источником представления, а именно — таблица dbo.articul (Рис. 12).

Рис. 12. База данных articul2

Представление dbo.v_PoPerson является информацией, взятой из таблицы dbo.Person (Рис. 13). Атрибут responsible_no представления dbo.v_PoMain является атрибутом p_no.

Рис. 13. Таблица dbo.Person

1. Вид.

На Рис. 14 показана Главная страница интерфейса. В поле «Код задачи» вводится task_id.

Рис. 14. Главная страница

Следующая страница является источником информации о поставках (Рис. 9). Через атрибут pr_no, полученный через task_id с главное станицы, происходит обращение в БД articul2, из которой берется информация об ответственном за заказ. Номер Заказа поставщику и Контрагент являются результатом обращения в представление dbo.v_PoMain.

Рис. 15. Информация по поставке

На Главной странице вводился task_id. Через представление dbo.v_PoReceiptTasks осуществляется поиск pr_no; этот атрибут через представление dbo.v_PoMainItems позволяет найти артикул товара (sku). При обращении в представление dbo.ArticulInfo происходит поиск информации по внутреннему артикулу компании, и выводится информация о товаре.

1. Реализация

Интерфейс реализован совместно с работником компании Kraftway.

Среда разработки: Visual Studio 2015.

Язык программирования: C#.

Была использована технология MVC5 (Model View Controller) [16]. В среде разработки были созданы модели, являющиеся аналогом таблиц созданной базы данных.

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

ЗАКЛЮЧЕНИЕ

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

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

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

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

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

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

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

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

СПИСОК ЛИТЕРАТУРЫ

1. TAdviser. Infor CloudSuite Industrial. URL: http://www.tadviser.ru/index.php/Продукт:Infor_CloudSuite_Industrial_(ранее_ERP_SyteLine) (дата обращения: 24.05.2018).
2. Государственный арбитраж при Совете Министров СССР. Инструкция о порядке приемки продукции производственно-технического назначения и товаров народного потребления по качеству. URL: http://www.consultant.ru/document/cons_doc_LAW_136661/ (дата обращения: 24.05.2018).
3. Гарсия-Молина Г. Система баз данных. Полный курс. М.: Вильямс, 2003. С. 21-23.
4. Карпова И.П. Базы данных. Учебное пособие. СПб: Питер, 2013.
5. Пушников А.Ю. Введение в системы управления базами данных. Часть 1. Реляционная модель данных. Учебное пособие. Уфа: Изд-е Башкирского ун-та., 1999.
6. Коннолли Т., Бегг Т. Базы данных. Проектирование, реализация и сопровождение. Теория и практика. М.: Вильямс, 2017.
7. Грабер М. SQL для простых смертных. М.: Лори, 2014. С. 90-92.
8. Microsoft. Требования к системе для Internet Explorer. URL: https://support.microsoft.com/ru-ru/help/11531/internet-explorer-system-requirements (дата обращения: 24.05.2018).
9. Microsoft. Требования к системе и информация об установке для Windows Server 2012 R2. URL: https://msdn.microsoft.com/ru-ru/library/dn303418(v=ws.11).aspx. (дата обращения: 24.05.2018).
10. Граничин О., Кияев В. Информационные технологии в управлении предприятием. Интеграция информационных систем предприятия. URL: http://www.intuit.ru/studies/courses/13833/1230/lecture/24065 (дата обращения: 17.12.2016).
11. Петкович Д. Microsoft SQL Server 2012. Руководство для начинающих. СПб.: БХВ-Петербург, 2013. С. 28-32.
12. Линн С. Администрирование Microsoft Windows Server 2012. СПб: Питер, 2014.
13. Карпова И.П. Проектирование реляционных баз данных: Методические указания к курсовому проектированию по курсу «Базы данных». М., 2010.
14. Ерохин А. ProfessorWeb. SQL Server 2012 и Transact-SQL. Триггеры. URL: https://professorweb.ru/my/sql-server/2012/level3/3_18.php (дата обращения: 24.05.2018).
15. Стружкин Н., Годин В. Базы данных. Проектирование. Учебник. М.: Юрайт, 2017
16. Рогачев С. Обобщенный Model-View-Controller. Представления. URL: http://rsdn.org/article/patterns/generic-mvc.xml (дата обращения: 24.05.2018).