Scientific journal

Modern high technologies

ISSN 1812-7320

"Перечень" ВАК

ИФ РИНЦ = 0,940

Организационная структура системы управления современными организациями должна оптимизировать производственные и технологические процессы, повышать эффективность функционирования предприятия и конкурентоспособность организации [6]. Большая часть данных, используемых для управления деятельностью предприятий и организаций, формируется в виде документов, представляющих те или иные объекты заданной предметной области [5]. Информационные ресурсы современных автоматизированных систем управления (АСУ) преимущественно организованы в базы данных (БД), реализованные на основе реляционной модели и управляемые системой управления базами данных СУБД [4].

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

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

Рост сложности проблем проектирования современных баз данных и необходимость их решать в сжатые сроки определяет актуальность разработки комплексных методов и средств, позволяющих решать проектные задачи на качественно новом уровне. Одной из наиболее широко распространенных методологий проектирования баз данных является методология проектирования реляционных баз данных (РБД). В области разработки РБД развитие методов и средств их проектирования связано с созданием таких подходов, которые обеспечили бы, кроме реализации традиционных технологий, эффективное использование технологий человеко-машинного проектирования, использование существующей информации в рассматриваемой предметной области [1].

Несмотря на серьезные теоретические и практические разработки, выполненные в области реляционных моделей данных [3], в настоящее время не сложилось устоявшейся, непротиворечивой, четко формализованной теории проектирования РБД. Одной из существенных причин такого положения вещей является то, что основное достоинство существующей теории – проектирование прикладной модели, абстрагируясь от инструментальной СУБД и содержимого таблиц данных, неизбежно приводит к ряду недостатков проектных решений.

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

С другой стороны, большая часть информации, в том числе и информация табличного вида (ИТВ) или данные табличного вида (ДТВ), находится вне баз данных и даже вне ЭВМ.

Комплексное использование новых методов решения задач при проектировании РБД на основе использования существующей ИТВ и интерактивное взаимодействие разработчика и средств проектирования, ориентированное на оперативное решение проектных задач, позволит организовать проектирование на качественно новом уровне [1].

Нормализация заполненных таблиц

В табл. 1 представлен общий вид заполненной реляционной таблицы (общий вид отношения).

Здесь A = {A1, A2, …, Ai …, Aj, …, Ak} – множество атрибутов (заголовков) таблицы (отношения).

a = ((a11, a12 , …, a1i, …, a1j, …, a1k),

(a21, a22 , …, a2i, …, a2j, …, a2k), …,

(an1, an2 , …, ani, …, anj, …, ank), …,

(am1, am2 , …, ami, …, amj, …, amk)) – множество кортежей значений атрибутов.

В данном представлении множество «a» представляет собой множество записей таблицы.

Если это же множество представить следующим образом:

a = ((a11, a21 , …, an1, …, am1),

(a12, a22 , …, an2, …, am2), …,

(a1i, a2i , …, ani, …, ami), …,

(a1j, a2j , …, anj, …, amj), …,

(a1k, a2k, …, ank, …, amk)),

то в таком представлении множество «а» является множеством значений атрибутов А, где k – степень отношения; m – мощность отношения.

Таблица 1

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

Как правило, в литературе рассматриваются четыре нормальные формы [3]. В несколько упрощенном виде они звучат следующим образом:

1. Все атрибуты отношения должны быть неделимы (атомарны).

2. Все неключевые атрибуты зависят от ключевого атрибута.

3. Неключевые атрибуты не должны зависеть друг от друга.

4. Между атрибутами не должно быть множественных зависимостей.

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

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

Рассмотрим создание автоматизированной системы учета данных (АСУД), основанной на построении ИТВ третьей нормальной формы для управления отгрузкой программного обеспечения для строительных организаций.

АСУД предприятия должна представлять собой совокупность получаемой и предоставляемой информации, математических моделей, технических, программных, технологических средств, предназначенных для обработки информации. Использование автоматизированных информационных систем позволяет: оптимизировать планы работы, быстро вырабатывать решения, четко маневрировать информационными, материальными, финансовыми и другими ресурсами предприятия. Вся обработка информации является объектом автоматизации с применением современных средств и способов связи, вычислительной техники и программного обеспечения [7].

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

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

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

Модель предметной области показана на рисунке.

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

Поиск производится по параметрам таблицы в разделах меню: ключи, виды цен, индексы, отгрузки, а также по клиентам. Фильтрация осуществляется путем сортировки требуемой информации от невостребованной. Возможно в индексах, ключах, базах, видах цен и отгрузках. Вывод данных на печать осуществляется через Microsoft Office Word. Менеджер может распечатать отчеты реализации сертификатов на индексы, отчет об отгрузке сертификатов и отчет об индексах.

Модель предметной области

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

На этапе инфологического проектирования используется неформальная модель предметной области типа «сущность – связь». Эта модель позволяет моделировать объекты ПО, взаимоотношения объектов. Основное назначение неформальной модели «сущность – связь» ? семантическое описание предметной области и представление информации для обоснования выбора видов моделей и структур данных, которые в дальнейшем будут использованы в системе. Для построения модели типа «сущность – связь» используются три основных конструктивных элемента для представления составляющих ПО – сущность, атрибут и связь.

Для представления инфологической модели предметной области могут использоваться два варианта: спецификационная форма инфологической модели ПО, графическая диаграмма инфологической модели ПО.

Рассмотрим связи между сущностями. На основе взаимодействия сущностей в предметной области можно определить отношения между ними (табл. 2).

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

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

Таблица 2

Связи между сущностями

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

Заключение

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

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