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

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

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

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

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

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

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

В настоящее время существуют три уровня абс тракции для опреде-ления структуры базы данных:

• концептуальный;

• логический;

• физический.

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

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

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

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

Логической называется версия концептуальной модели, которая мо-жет быть обеспечена средствами СУБД.

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

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

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

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

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