Проектирование базы данных
Ниже рассматривается роль АБД на каждом из шести этапов жизненного цикла системы с базой данных.
До начала разработки базы данных предприятие должно решить, какие из оперирующих с данными областей подлежат, а какие не подлежат включению в единую систему с базой данных. Этот шаг, очевидно, один из самых важных в разработке такой системы. Для получения картины единого ресурса данных предметной области и информационных потоков между различными системами, а также для составления плана разработки системы АБД должен проанализировать доступные ресурсы системы, данные, их источники, зависимости и взаимосвязи с другими системами.
Анализ всех систем дает возможность заранее установить наличие конфликтов из-за права владения данными, избыточных источников, неоднозначности или противоречивости группирования данных, в результате чего отпадает необходимость в поиске компромиссных решений на более поздних стадиях разработки системы. На основе подробной информации о системах и процедурах эксплуатации можно составить план последовательного перехода к применению базы данных. В зависимости от сложности межсистемных связей предметной области, числа объектов данных, доступных ресурсов и позиции администрации этот план может быть рассчитан на. пятилетку и даже на более длительный период.
План проектирования системы служит основой гарантии правильной разработки системы с базой данных. Этот план определяет направление развития предметной области, а потому он должен быть полным и охватывать все системы. Как и всякий перспективный план, его необходимо детализировать на первый год, дать поквартальное разбиение на два-три следующих года и погодовое разбиение на последующий период. Он должен периодически анализироваться и при необходимости пересматриваться. Администрация и пользователи с его помощью могут контролировать переход к использованию системы с базой данных. План следует динамично развивать и работать с ним постоянно.
Составление плана — это лишь первый шаг на пути создания системы с базой данных. Однако он служит фундаментом для развертывания всех дальнейших работ и требует серьезного внимания. Этот план позволяет логично подойти к определению порядка конвертирования и методики его выполнения. Определение порядка конвертирования необходимо не для получения «зримого» эффекта, а, что чрезвычайно важно, для вовлечения пользователей в процесс разработки базы данных. Это позволит пользователю не' просто наблюдать со стороны за ходом работ, а принимать в них, активное участие совместно с АБД.
Проектирование базы данных (этап 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)
Это — последний этап жизненного цикла системы с базой данных. Практически в любой области постоянно происходят изменения. Изменения могут иметь место в сфере коммерческой деятельности в результате ее расширения или сокращения либо могут быть связаны с разного рода реорганизациями.
Сопровождение означает приспособление к изменениям. В большинстве случаев работа по сопровождению не обязательно требует больших трудозатрат. Если база данных обладает достаточной гибкостью, этап сопровождения скорее всего будет не самым сложным.
При значительны-х изменениях может потребоваться повторное проектирование базы данных. Однако в большинстве случаев для функционирующей базы данных в нем нет необходимости, а иногда оно просто невозможно. Наиболее часто выбираемый из практических соображений подход к решению проблемы состоит в «наложении заплат». В группе АБД на данном этапе основной" объем работ приходится на долю эксперта по прикладным программам.