Проектирование базы данных


 

 

Ниже рассматривается роль АБД на каждом из шести этапов жизненного цикла системы с базой данных.

До начала разработки базы данных предприятие должно решить, какие из оперирующих с данными областей подлежат, а какие не подлежат включению в единую систему с базой данных. Этот шаг, очевид­но, один из самых важных в разработке такой системы. Для получения картины единого ресурса данных предметной области и информационных потоков между различными системами, а также для составления плана разработки системы АБД должен проанализировать доступные ресурсы системы, данные, их источники, зависимости и взаимосвязи с другими системами.

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

План проектирования системы служит основой гарантии правильной разработки системы с базой данных. Этот план определяет направление развития предметной области, а потому он должен быть полным и охва­тывать все системы. Как и всякий перспективный план, его необходимо детализировать на первый год, дать поквартальное разбиение на два-три следующих года и погодовое разбиение на последующий период. Он должен периодически анализироваться и при необходимости пере­сматриваться. Администрация и пользователи с его помощью могут контролировать переход к использованию системы с базой данных. План следует динамично развивать и работать с ним постоянно.

Составление плана — это лишь первый шаг на пути создания системы с базой данных. Однако он служит фундаментом для развертывания всех дальнейших работ и требует серьезного внимания. Этот план позволя­ет логично подойти к определению порядка конвертирования и методики его выполнения. Определение порядка конвертирования необходимо не для получения «зримого» эффекта, а, что чрезвычайно важно, для вовлечения пользователей в процесс разработки базы данных. Это позво­лит пользователю не' просто наблюдать со стороны за ходом работ, а принимать в них, активное участие совместно с АБД.

Проектирование базы данных (этап 1)

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

В системе образования наиболее важными объектами являются студенты и преподаватели. В числе других важных объектов можно на­звать читаемые курсы, списки абитуриентов, расписание занятий, размер платы за обучение, денежные расходы и особые проекты. Эти объекты и их взаимосвязи должны быть определены на начальном этапе проектирования с участием АБД.

Эффективному решению указанных задач способствует словарь данных (СД), подробно рассматриваемый в гл. 3.

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

Проект должен быть легко расширяемым. Немногие предприятия могут позволить себе начать все сначала, если проект оказывается недостаточно гибким. В связи с необходимостью постоянного изменения и развития базы данных ее реструктуризация по мере добавления новых типов; данных и новых прикладных программ должна быть простой. В неко­торых системах управления базами данных предусмотрены средства реструктуризации. Если же их нет, то написание соответствующей про­цедуры (обычно называемой процедурой загрузки/разгрузки) возлагается на пользователя. АБД должен учитывать, что переход от традиционной «эры наборов данных» к внедрению технологии баз данных связан с уменьшением стоимости сопровождения и обеспечением дополнительных возможностей.

На рис. 2.4 представлены основные шаги проектирования. При логи­ческом проектировании АБД должен сконцентрировать свое внимание на причинах существования определенных взаимосвязей между объекта­ми, а не на способах их реализации в базе данных.

 

 

 

Материализация базы данных (этап 2)

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

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

Если в результате тестирования выявлено, что прототип отвечает эксплуатационным требованиям, можно проводить загрузку базы данных. Необходимо, однако, помнить, что прогнозирование эксплуатационных характеристик реальной базы данных с помощью прототипа представ­ляет чрезвычайно сложную задачу, для которой очень трудно правиль­но определить момент окончания работ. Хотя создание прототипа и желательно, в большинстве случаев для интерактивного режима модель не позволяет получить приемлемую оценку эксплуатационных характе­ристик полной базы данных. Причиной тому является отсутствие обоб­щенной математической процедуры оценки корректности модели. Особенно сложно построить адекватный тестовый пример загрузки из 50 или 100 асинхронных транзакций, осуществляющих доступ к базе данных. К трудным задачам следует отнести и полный учет реального количества информации в. базе данных. Множество задач прекрасно реализуется при числе записей порядка 1000, но «взрывается» при 100000. Кроме того, нельзя забывать и о том, что эксплуата­ционные характеристики зависят от размеров базы данных. Возможен прогон некоторых прикладных программ, прошедших этап конвертирова­ния (этап 3) или интеграции (этапы 3 и 4 на рис. 2.2, 2.3 и 2.5) на полной базе данных. Производится проверка соответствия эксплуата­ционных характеристик требованиям, предъявляемым к проекту полной базы данных. При неудовлетворительных результатах необходимо моди­фицировать проект базы данных. Если же результаты оказываются удовлетворительными, переходят к проверке средств обеспечения без­опасности, секретности и разграничения доступа на полной физической базе данных. В случае успешного тестирования этих средств выпол­няются работы этапа конвертирования (этапа 3) в полном объеме (рис. 2.2, 2.3. и 2.5).

Конвертирование существующих наборов данных и прикладных программ во вновь созданную базу данных (этап 3)

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

Интеграция конвертированных и новых прикладных программ для работы в среде вновь созданной базы данных (этап 4)

Этот этап может существенно пересекаться с этапом 3. Здесь необходимо обеспечить возможность простого изменения физической структуры базы данных, т. е. поддержку разработки прикладных программ надлежащим управлением базой данных, а не планированием разработки прикладных программ. Разработка прикладных программ не входит в обя­занности АБД. Например, в сфере банковских операций должна предусматриваться возможность добавления системы кредитных карточек нового типа. Если на этапе проектирования базы данных упустить это из виду, то, вероятно, придется вернуться к этапу проекти­рования, что может деморализовать группу АБД и причинить массу неудобств разработчикам прикладных программ.

Эксплуатация (этап 5)

На этапе эксплуатации все использующие базу данных прикладные программы работают с полной нагрузкой. Здесь должны быть задейство­ваны процедуры, обеспечивающие безопасность^ секретность и разграни­чение доступа к базе данных. Необходимо ввести процедуры восстановле­ния и повторного запуска при удовлетворении критерия оценки ка­чества эксплуатационных характеристик. На этом этапе эксперту по вопро­сам эксплуатации и экспер'гу по системным вопросам приходится выполнять большой объем работ.

Развитие, совершенствование и сопровождение (этап 6)

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

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

При значительны-х изменениях может потребоваться повторное проек­тирование базы данных. Однако в большинстве случаев для функциони­рующей базы данных в нем нет необходимости, а иногда оно просто невозможно. Наиболее часто выбираемый из практических соображений подход к решению проблемы состоит в «наложении заплат». В группе АБД на данном этапе основной" объем работ приходится на долю эксперта по прикладным программам.