Разработка баз данных Этапы разработки баз данных

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

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

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

• разработка логической модели данных;

• разработка физической модели данных;

• разработка собственно базы данных.

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

Модель предметной области – это записанные знания об объектах реального мира, которыми необходимо управлять наиболее рациональным образом. Эти знания могут быть представлены как в чисто текстовом виде, так и с использованием методологий структурного функционального моделирования - SADT, IDEF0, IDEF3, методологий и стандартов описания состава, структуры и взаимосвязей используемой в деятельности предприятия информации – IDEF1, DFD и соответствующих инструментальных case-средств – BPWin, AIO WIN, ProCap, ProSim, SmartER.

Логическая модель данных описывает понятия предметной области и их взаимосвязи и является прототипом будущей базы данных. Логическая модель разрабатывается в терминах информационных понятий, но без какой-либо ориентации на конкретную СУБД. Наиболее широко используемым средством разработки логических моделей баз данных являются диаграммы «сущность-связь» - Entity-Relationship (ER-диаграммы). Следует заметить, что логическая модель данных, представленная ER-диаграммами, в принципе, может быть преобразована как в реляционную модель данных, так и в иерархическую, сетевую, постреляционную.

Физическая модель данных строится на базе логической модели и описывает данные уже средствами конкретной СУБД. Отношения, разработанные на стадии логического моделирования, преобразуются в таблицы, атрибуты в столбцы, домены в типы данных, принятых в выбранной конкретной СУБД. На этапах логического и физического моделирования, как правило, используется стандарт IDEF1X и case-средства ERWin или SmartER. Указанные инструментальные средства проектирования поддерживают несколько десятков наиболее популярных СУБД. Результатом физического моделирования является генерация программного кода базы данных на соответствующем выбранной СУБД диалекте структурированного языка запросов SQL.

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

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

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