Построение информационной системы на примере организации

- дата заключения договора;

- ФИО сотрудника, заключившего  договор;

- наименование поставщика;

- наименование потребителя.

При работе с полученной информацией были введены следующие сущности и поля:

Сущность «Поставщики» хранит в себе информацию о поставщиках электроэнергии и включает в себя следующие поля:

- наименование поставщика;

- адрес поставщика;

- телефон поставщика;

- номер договора;

- количество закупленной электроэнергии;

- цена закупки.

Сущность «Потребители» хранит в себе информацию о потребителях электроэнергии и включает в себя следующие поля:

- наименование потребителя;

- адрес потребителя;

- телефон потребителя;

- номер договора;

- количество потребленной электроэнергии;

- цена электроэнергии.

Сущность «Должники» хранит в себе информацию о потребителях, вовремя не оплативших счета за потребленную электроэнергию и включает в себя следующие поля:

- наименование должника;

- адрес должника;

- телефон должника;

- сумма задолженности;

- номер договора.

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

- номер договора;

- дата заключения договора;

- ФИО сотрудника, заключившего  договор;

- наименование поставщика;

- наименование потребителя.

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

- ФИО сотрудника;

- адрес сотрудника;

- телефон сотрудника;

- должность.

 

2.2 Разработка логической модели

 

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

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

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

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

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

Отношения в наших таблицах находится в 3НФ, что показано на рисунке 4

 

 

Потребители

Поставщики

Договоры

Сотрудники

Должники

 

 

Рисунок 4 – Отношение 3НФ

 

 

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

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

Ниже приведена логическая модель базы данных «Учет работы с клиентами» (Рисунок 5):

 

 

 

 

 

 

 

Рисунок 5 – Логическая модель базы данных «Учет работы с клиентами»

 

2.3 Разработка физической модели

 

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

Для представления информации используется несколько форм. Табличная форма представления информации является наиболее распространенной  и понятной. Кроме того, такие семантические более сложные формы, как деревья и сети, путем введения некоторой избыточности могут быть сведены к табличным. При этом данные также будут представлены в форме двумерных таблиц. Такой реляционный подход, в основе которого лежит принцип разделения данных и связей, обеспечивает с одной стороны независимость данных, а с другой – более простые способы реализации хранения и обновления. На рисунке 6 представлены таблицы базы данных «Учет работы с клиентами».

 

 

«Потребители»

«Поставщики»

«Договоры»

«Сотрудники»

«Должники»

 

 

Рисунок 6 – Таблицы базы данных «Учет работы с клиентами»

 

2.4 Описание пользовательского интерфейса

 

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

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

В понятие пользовательского интерфейса компьютерной системы входят следующие составляющие:

а) графическая среда – картинка на экране;

б) набор управляющих элементов пользовательского интерфейса и их расположение на экране;

в) технологии взаимодействия пользователя с системой.

Управляющие элементы пользовательского интерфейса – это графические элементы (кнопки, списки, диалоговые окна и т.п.), которые позволяют осуществлять какие-либо действия с компьютерной системой (например, выбирать пункты и свойства объектов).  

Основные требования к пользовательскому интерфейсу:

- функциональность (соответствие  задачам пользователя); 

- соответствие технологии;

- понятность и логичность;

- обеспечение высокой скорости работы пользователя;

- обеспечение защиты от человеческих  ошибок;

- быстрое обучение пользователя;

- субъективное удовлетворение  пользователя.

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

1) для повышения скорости выполнения работы:

- элементы управления должны быть заметными и понятными;

2) для уменьшения количества  ошибок пользователя:

- кнопки не должны быть слишком  маленького размера: на такую  кнопку сложно попасть;

- пользователь должен быть огражден от возможности нажать не на ту кнопку; 

- кнопки, опасные для пользователя, должны быть отключены;

- указание границ диапазона  вводимых пользователем значений;

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

3) для повышения субъективной  скорости выполнения работы:

- заполнение пауз между событиями.

На основе общих требований к пользовательскому интерфейсу сформирована система требований к его элементам управления.

Требования к названию (тексту) элементов управления:

- название элемента должно отражать  его функцию;

- названия элементов должны  быть краткими, но понятными пользователю;

- наиболее значимое слово должно  стоять в названии элемента  первым;

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

- если элемент меню служит  для запуска окна с продолжением  диалога, то в конце его названия  следует ставить многоточие;

- пиктограммами следует снабжать  только самые важные элементы меню.

Требования к расположению элементов управления:

- элементы меню следует группировать;

- группы следует разделять разделительными  полосками либо «визуальными  паузами»;

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

- терминационные кнопки (т.е. командные  кнопки, управляющие окном, например, «Ок», «Отмена», «Применить», «Закрыть») должны быть расположены либо  внизу окна, либо в правой его  части (т.е. в той части окна, которая сканируется взглядом в последнюю очередь);

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

Требования к оформлению чекбоксов и радиокнопок:

- не следует нарушать сложившуюся  традицию: чекбоксы выглядят как  квадраты, а радиокнопки - как кружки;

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

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

- в группе радиокнопок как  минимум одна радиокнопка должна  быть проставлена по умолчанию;

- каждая подпись чекбокса и  радиокнопки должна однозначно  показывать эффект от выбора соответствующего элемента;

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

- подписи к стоящим параллельно  кнопкам лучше стараться делать примерно одинаковой длины;

- все подписи лучше делать  позитивными (т.е. не содержащими  отрицания);

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

- если подпись не помещается  в одну строку, то индикатор  кнопки (кружок или квадрат) следует  выравнивать по первой строке  подписи;

- подписи к чекбоксам и радиокнопкам  должны быть нажимабельными (это связано с тем, что для быстроты и точности работы пользователю нужны большие кнопки);

- при необходимости заблокировать  элемент чекбокса или радиокнопки, желательно визуально ослаблять не только индикатор кнопки (квадрат или круг), но и подпись к нему.

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

 

 

Рисунок 7 – Пользовательский интерфейс

 

Для создания данной формы были произведены следующие операции:

- изменено название Form1 на ОАО «Кировэнергосбыт» (свойство Caption);

- изменен цвет формы (свойство Color);

- на форму вынесено 6 кнопок (Button), 1 метка (Label) и 1 рисунок (Image);

- при нажатии на одну из  кнопок открывается новая форма. Для достижения данного эффекта мы прописали следующий программный код (Рисунок 8):