Проектирование АИС. 
Автоматизированная информационная система учета офисной техники

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

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

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

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

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

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

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

принцип непротиворечивости — заключается в обоснованности и согласованности элементов;

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

Для построения модели данных был использован мощный и удобный инструмент — Computer Associates ERwin. ERwin имеет два уровня представления модели — логический и физический. ERwin позволяет проводить процессы прямого и обратного проектирования БД, выравнивать модель и содержимое системного каталога после редактирования. ERwin интегрируется с популярными средствами разработки клиентской части — PowerBuilder, Visual Basic, Delphi, что позволяет автоматически генерировать код приложения, который полностью готов к компиляции и выполнению [9].

Логический уровень — это абстрактный взгляд на данные. На нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире. Объекты модели, представляемые на логическом уровне, называются сущностями и атрибутами. Данная модель может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД [9, 10].

Основные компоненты диаграммы ERwin — это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности — строка в таблице, а атрибуту колонка таблицы [9].

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

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах [9, 10].

Нормализация — процесс проверки и реорганизации сущностей и атрибутов с целью удовлетворения требований к реляционной модели данных. Нормализация позволяет быть уверенным, что каждый атрибут определен для своей сущности, значительно сократить объем памяти для хранения информации и устранить аномалии в организации хранения данных. В результате проведения нормализации должна быть создана структура данных, при которой информация о каждом факте хранится только в одном месте. Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам — формализованным требованиям к организации данных. Известно четыре нормальных формы [11]:

первая нормальная форма (1NF): сущность находится в первой нормальной форме тогда и только тогда, когда все атрибуты содержат атомарные значения. Среди атрибутов не должно встречаться повторяющихся групп, то есть несколько значений для каждого экземпляра;

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

третья нормальная форма (3NF): сущность находится в третьей нормальной форме, если она находится во второй нормальной форме и никакой не ключевой атрибут не зависит от другого не ключевого атрибута (не должно быть взаимозависимости между не ключевыми атрибутами).

нормальная форма Бойса-Кодда (усиленная 3NF): отношение находится в усиленной 3NF тогда и только тогда, когда каждый детерминант отношения является возможным ключом.

В проекте использовалась логико-физическая модель.

ER-диаграмма системы на логическом уровне представлена на рисунке 2.1.

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

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

Разработанная модель находится в 3-й нормальной форме, так как:

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

В качестве СУБД выбрана Microsoft Access.

ER-диаграмма системы на физическом уровне представлена на рисунке 2.2.

Рисунок 2.2 — ER-диаграмма системы на физическом уровне Описание таблиц базы данных приведено в таблице 2.1.

Таблица 2.1 Описание таблиц базы данных.