При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации).
Рассмотрим все этапы проектирования информационной системы: от инфологического, до построения физической модели базы данных.
Процесс проектирования базы данных информационной системы разбивается на основные этапы:
· Инфологическое проектирование – сбор, анализ, описание объектов и связей между ними.
· Логическое проектирование – преобразование требований к данным в структуры данных. На выходе получаем структуру базы данных и спецификации прикладных программ.
· Физическое проектирование – определение особенностей хранения данных, методов доступа и т.д.
Для решения задач инфологического проектирования осуществляются следующие мероприятия: обследование предметной области, изучение ее информационной структуры; выявление всех фрагментов, каждый из которых характеризуется пользовательским представлением, информационными объектами и связями между ними, процессами над информационными объектами; моделирование и интеграция всех представлений.
Задача этапа логического проектирования состоит в разработке ее «логической» структуры в соответствии с инфологической моделью предметной области. В результате этого этапа создаются схемы базы данных концептуального и внешнего уровней архитектуры, специализированные на языках определения данных.
На стадии инфологического проектирования осуществляется обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка).
Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, логический и др.), конкретизация происходит на этапе физического проектирования.
Цель логического проектирования – применение принципов модели разработки приложения к конкретной задаче. Результат этого этапа – структура решения и связи между его элементами. Как правило, в результате логического проектирования определяется набор необходимых объектов, атрибутов и связей, принципы проектирования пользовательского интерфейса и логическая модель данных. (43, с. 290–294) Нормализация – это разбиение таблицы на две или более, обладающих лучшими свойствами при включении, изменении и удалении данных. Окончательная цель нормализации сводится к получению такого проекта базы данных, в котором каждый факт появляется лишь в одном месте, т.е. исключена избыточность информации. Это делается не столько с целью экономии памяти, сколько для исключения возможной противоречивости хранимых данных. Каждая таблица в реляционной БД удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное атомарное значение, и никогда не может быть множества таких значений. Любая таблица, удовлетворяющая этому условию, называется нормализованной. Фактически, ненормализованные таблицы, т.е. таблицы, содержащие повторяющиеся группы, даже не допускаются в реляционной БД. Интерфейс определяет переход от представления данных в БД к представлению, принятому среди пользователей, и обратно. В общем случае пользователи представляют данные в виде документов различных видов, от произвольных текстов до справок и таблиц фиксированного формата.
Интерфейс доступа конечного пользователя охватывает комплекс технических, организационных и программных решений, обеспечивающих в итоге унифицированность, хорошую понимаемость и надежность взаимодействия конечного пользователя с различными моделями персональных компьютеров. В процессе проектирования, как правило, возникает необходимость точного учета структур документов. Для полного представления этих структур могут использоваться средства описания данных БД. Тем самым облегчается процесс сопоставления БД и документов при организации интерфейса. Совместная реализация БД и интерфейса на единой концептуальной основе предполагает сопоставление соответствующих понятий концептуального описания с понятиями пользователей. Конкретные функциональные требования пользователей и предполагаемое их обеспечение отображаются понятием пользовательского представления данных. В общем случае пользовательское представление включает так называемое локальное внешнее представление функций обработки данных, а также определение форматов входных и выходных данных.
Проектирование базы данных – одна из наиболее ответственных трудных задач, связанных с созданием информационной системы. В результате ее решения должны быть определены и содержание базы данных, и эффективный с точки зрения всего сообщества будущих пользователей способ ее организации, и инструментальные средства управления данными.
Рассмотренные в предыдущей главе этапы проектирования являются ключевыми при создании автоматизированной информационной системы.
На этапе инфологического проектирования мною были составлены:
· Список исходных документов клиентов, с которыми работает менеджер по персоналу;
· Порядок обработки данных работников и работодателей;
· Список выходных данных, которые необходимы агентству для управления структурой своего предприятия;
Выяснив основную часть данных, которые необходимы менеджеру, приступаем к созданию структуры баз данных:
Ø Работа начинается с составления генерального списка полей;
Ø В соответствии с типом данных, размещаемых в каждом поле, определяется наиболее подходящий тип для каждого поля;
Ø Далее распределяются поля генерального списка по базовым таблицам. На первом этапе распределение производится по функциональному признаку. Цель обеспечить, чтобы ввод данных в одну таблицу производился на одном рабочем месте. Критерием дальнейшего деления полей является факт множественного повтора данных в соседних записях.
Ø В каждой таблице намечают ключевое поле. В качестве такового выбирают поле, данные которого повторяться не могут. Если в таблице нет никаких полей, которые можно было бы использовать как ключевые, вводится дополнительное поле типа «счетчик – оно не может содержать повторяющихся данные по определению.
Ø С помощью карандаша и бумаги расчерчивают связи между таблицами. Такой чертеж называется схемой данных.
Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.