Информационная модель и ее отображение на модель данных.

Построение модели данных

ТИПОВОЕ АВТОМАТИЗИРОВАННОЕ ПРОЕКТИРОВАНИЕ. СТАДИЯ РАЗРАБОТКИ ПРОЕКТОВ.

ЛЕКЦИЯ 9.

Использование продуктов третьих фирм

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

Техническое проектирование – 2 этап. Основные задачи и особенности этапа. Проектирование базы данных (логическое проектирование)

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

· схема базы данных (на основании информационной модели, разработанной на этапе анализа). Схема БД содержит описание всех ее объектов: пользователей, их привилегий, таблиц, индексов, ограничений, хранимых процедур и т.п. При этом создаются не только определения этих объектов, но и сами объекты, с которыми потом работают разработчики;

· набор спецификаций модулей системы (строятся на базе функциональных моделей).

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

Работа проектировщиков базы данных в значительной степени зависит от качества информационной модели, построенной на этапе анализа предметной области. Казалось бы, дело это простое: сущности становятся таблицами, а атрибуты сущностей — столбцами таблиц; определяются типы и ограничения данных, ключи различного вида. НО аналитики, как правило, не вникают в особенности реализации той или иной СУБД, поэтому при проектировании схемы базы данных проектировщик может столкнуться с конструкциями в информационной модели, которые не реализуемы или трудно реализуемы в выбранной СУБД. Приведем несколько примеров ограничений реализации СУБД:

· В информационной модели определен атрибут, представляющий собой строку длиной в 500 символов. По этому атрибуту часто осуществляется поиск в информационной системе; объем данных велик. В СУБД можно индексировать строки символов не длиннее чем 128 или 256 символов. Если осуществлять поиск без индекса, то время ответа информационной системы существенно превышает допустимое, вследствие чего придется изменить описание сущности.

· Две диаграммы потока данных описывают различные бизнес-процессы, работающие над одними и теми же данными. Допустим, первая диаграмма описывает выписку товара со склада, а вторая — сложный отчет, отражающий состояние склада. Один процесс интенсивно модифицирует данные, второй работает в режиме чтения данных, но требует согласованности данных в течение длительного времени. Каждый из процессов описывается транзакцией над данными. В СУБД уровни изолированности транзакций реализованы так, что читающие транзакции конфликтуют с модифицирующими транзакциями. Это приводит к остановке выписки товаров со склада на время выполнения отчета, что неприемлемо для заказчика. Здесь может потребоваться очень серьезное изменение информационной модели.

Информационная модель не должна содержать никаких непонятных конструкций, которые нельзя реализовать в рамках выбранной СУБД. Следует отметить, что информационная модель создается для того, чтобы на ее основе можно было построить модель данных, то есть должна учитывать особенности реализации выбранной СУБД. Если те или иные особенности СУБД не позволяют отразить в модели данных то, что описывает информационная модель, значит, надо менять информационную модель, так как производитель СУБД вряд ли будет оперативно менять собственно СУБД ради вашего конкретного проекта (хотя и такие, правда единичные, случаи имели место).

Подобных примеров, когда не только информационная модель, но и другие продукты анализа не могут быть перенесены автоматически на модель данных, можно привести множество. Каждый такой случай инициирует изменение информационной модели. Решение проблемы определяется возможностями СУБД, выбранной для реализации проекта. Если проблем, не разрешаемых в рамках данной СУБД, накапливается очень много, то проектировщики могут поставить вопрос о смене СУБД. Такой вопрос поднимается именно на стадии проектирования, поскольку если уже разработчики столкнутся с подобными проблемами, то цена смены СУБД будет выше. Ясно, что одинаковых СУБД не бывает: то, что хорошо работает в одной, может плохо работать или вообще не работать в другой.

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