2.2. Проектирование ис

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

Существует много подходов к проектированию БД. Среди них выделяются подходы, ориентированные на структуру предметной области и подходы, ориентированные на действия (динамику), выполняемые в предметной области.

Первая группа методов известна давно и сводится к четырем следующим этапам:

• Системный анализ предметной области;

• Построение информационно- логической модели предметной области;

• Построение даталогической модели предметной области;

• Построение таблиц базы данных.

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

Во время анализа выявляются связи между свойствами объектов или/и объектами, а также ограничения, накладываемые на количественные характеристики объектов.

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

№ п\п	Объекты	Свойства	Связи	Ограничения
1	Преподаватель	Табельный номер Фамилия Имя Отчество Кафедра Предмет Стаж	студент
2	Студент	Номер зачетной книжки Фамилия Имя Отчество Группа Специализация	преподаватель
3	…	…	…	…
4	…	…	…	…

Информационно- логическая модель (Инфологическая) представляет собой графическое описание семантики предметной области.

Основными элементами в модели являются Сущность и Связь.

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

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

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

Связи отражают семантику предметной области. Они имеют имя, например, дипломное проектирование. Сущность в конкретной связи исполняет роль. Например, Преподаватель руководит, а студент пишет дипломный проект. Связи, могут отображать каким, образом взаимодействуют экземпляры одной сущности с экземплярами другой.

Так один преподаватель руководит несколькими студентами.

Типы связей: один к одному, один ко многим, многие ко многим.

Связи могут быть обязательными или необязательными.

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

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

Даталогическая модель определяет внутреннее представление данных с учетом особенностей конкретной СУБД.

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

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

Используя ДЛМ легко построить таблицы базы данных в конкретной СУБД.

Для небольших БД допускаются упрощение процедур их проектирования. Ниже приводится пример разработки БД для обеспечения деятельности двух сотрудников.