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

Текст из файла (страница 6)

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

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

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

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

– компания;

– часовой пояс;

– город;

– улица;

– дом;

– цель посещения;

– вид запроса;

– вид операции.

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

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

– ID сотрудника, для обозначения конкретного сотрудника;

– ID операции для обозначения операции в выполнение, которой этот сотрудник вовлечён.

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

2.2 Проектирование АРМ

Как указывалось, выше разработка АРМ будет осуществляться с использованием фреймворка JSF. Также в разработке используется подход к программированию MVC. Этот подход подразумевает наличие модели для хранения данных, контроллера для управления логикой приложения, а также представления для отображения результатов для пользователя. Таким образом для большинства страниц можно будет выделить три основных компонента – модель, представление и контроллер, назначение которых описано выше.

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

В этом подразделе будет сформирована общая архитектура АРМ, т.е. будут определены основные структурные элементы – модели, представления и контроллеры и взаимодействия между ними, а также обобщённое содержимое для основных элементов архитектуры. Конкретное содержание того или иного представления будет рассмотрено в разделе разработки АРМ.

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

– вход в систему для авторизованных пользователей;

– определение роли пользователя и в соответствии с ней формирование его возможностей в системе;

– у любого авторизованного пользователя АРМ будет возможность создания нового запроса, поиска запросов и их редактирования, а также добавления новых видов запросов;

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

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

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

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

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

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

– страница определения поискового фильтра;

– страница просмотра результатов поиска;

– страница добавления записи;

– страница просмотра конкретной записи.

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

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

– блок отвечающий за представление сущности адреса;

– блок отвечающий за представление сущности городов;

– блок отвечающий за представление сущности улиц;

– блок отвечающий за представление сущности часовых поясов;

– блок отвечающий за представление сущности компаний;

– блок отвечающий за представление сущности принадлежности сотрудника к складу;

– блок отвечающий за представление сущности журнала операций;

– блок отвечающий за представление сущности журнала информации о складах;

– блок отвечающий за представление сущности журнала операций;

– блок отвечающий за представление сущности видов операций;

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

– блок отвечающий за представление сущности связи операций и сотрудниках дороги;

– блок отвечающий за представление сущности партий единиц товара;

– блок отвечающий за представление сущности информации о единицах товара;

– блок отвечающий за представление сущности журнала учёта единиц товара на складе;

– блок отвечающий за представление сущности журнала запросов;

– блок отвечающий за представление сущности видов запросов;

– блок отвечающий за процесс авторизации пользователя;

– блок отвечающий за представление сущности журнала посещений;

– блок отвечающий за представление сущности целей посещений.

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

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

Архитектура программного обеспечения полученная в процессе проектирования АРМ, представлена в приложении Д.

3 Разработка АРМ складского рабочего

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

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

Разработка базы данных будет осуществляться, как указывалось ранее при помощи СУБД MySQL. Для создания базы данных потребуется создать таблицы, отображающие структуру базы данных, изображённую в приложении Г, и, для возможности демонстрации корректности работы приложения осуществить заполнение созданных таблиц данными.

За создание таблиц в MySQL отвечает следующая команда:

create TABLE (...).

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

primary key.

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

foreign key(T1.FK) references T2(T2.PK).

Таким образом код для создания таблицы журнала операций будет выглядеть следующим образом:

create table OperationJournal

Характеристики

Список файлов ВКР