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

Проектирование БД представляет собой длительный, трудоёмкий, слабо формализованный процесс, от которого зависит жизнеспособность и эффективность проектируемой базы, её способность к развитию. Проектирование БД выполняется, как правило, коллективом разработчиков и включает следующие этапы:

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

• проектирование и кодирование;

• тестирование и сопровождение.

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

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

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

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

Вторая нормальная форма. Для приведения отношений ко второй нормальной форме введем понятие функциональной зависимости.Функциональная зависимость полей— это зависимость, при которой в строке определенному значению ключевого поля соответствует только одно значение не ключевого поля. В случае составного ключа вводится понятие функционально полной зависимости. Прифункционально полной зависимостине ключевое поле зависит от составного ключа, но не зависит от любого поля, входящего в составной ключ. Например, в отношении СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА) первичным ключом является совокупность полей ФАМИЛИЯ + ИМЯ + ОТЧЕСТВО. Поля ФАКУЛЬТЕТ, КУРС, ГРУППА функционально полно зависят от составного ключа.

Отношение находится во второй нормальной форме, если оно находится в первой нормальной форме, и каждое не ключевое поле функционально полно зависит от составного ключа. Например, в отношении УСПЕВАЕМОСТЬ (НОМЕР ЗАЧЕТКИ, ФАМИЛИЯ, ДИСЦИПЛИНА, ОЦЕНКА) составным ключом является совокупность НОМЕР ЗАЧЕТКИ + ДИСЦИПЛИНА. Это отношение находится в первой нормальной форме, но оно не находится во второй нормальной форме, так как поле ФАМИЛИЯ не имеет полной функциональной зависимости от составного ключа. Для перевода этого отношения во вторую нормальную форму необходимо исключить из него поле ФАМИЛИЯ, так как оно функционально зависит от НОМЕРА ЗАЧЕТКИ. Т.е. исходное отношение необходимо разбить на два связанных отношения УСПЕВАЕМОСТЬ (НОМЕР ЗАЧЕТКИ, ДИСЦИПЛИНА, ОЦЕНКА) и СПИСОК (НОМЕР ЗАЧЕТКИ, ФАМИЛИЯ). Связь здесь осуществляется по полю НОМЕР ЗАЧЕТКИ.

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

Например, в отношении СТУДЕНТ (ФАМИЛИЯ, ФАКУЛЬТЕТ, НАЗВАНИЕ вуза, АДРЕС) поле АДРЕС транзитивно (через поле НАЗВАНИЕ вуза) зависит от ключа ФАМИЛИЯ. При заполнении экземплярами такого отношения поле Адрес будет многократно повторяться. Для устранения транзитивной зависимости в классе используется «расщепление» отношения на несколько новых. Например, отношение СТУДЕНТ расщепляется на два: СТУДЕНТ (ФАМИЛИЯ, ФАКУЛЬТЕТ, НАЗВАНИЕ вуза) и ВУЗ (НАЗВАНИЕ вуза, АДРЕС), связь по полю НАЗВАНИЕ вуза.

Процесс нормализации заканчивается созданием схемы данных, в которой указываются все нормализованные таблицы с их полями и взаимосвязями между ними. Дальнейшая работа над проектом – кодирование– связана с реализацией базы в среде конкретной СУБД, выбираемой с учётом требований заказчика и намеченной архитектуры ИС. Например, применительно к СУБД MS Access, задается формат файла базы данных, создаются таблицы и другие объекты БД. Access обладает ручными (режим Конструктора) и автоматизированными (с помощью Мастеров) средствами создания объектов. Автоматизированные средства более наглядные и производительные. Ручные – более трудоёмкие, требуют дополнительных знаний об инструментах и возможностях СУБД, но и более гибкие.

Тестированиедолжен проходить любой программный продукт, тем более такой, как БД. При тестировании с использованием реальных данных обнаруживаются возможные ошибки, собираются статистические данные для определения показателей качества и надёжности созданного программного обеспечения.

Сопровождениеявляется самым продолжительным этапом жизненного цикла любой БД. Основные действия на этом этапе сводятся к наблюдению за созданной системой и поддержке её нормального функционирования.