Восходящее проектирование и нисходящее проектирование.

Пример проектирования реляционной БД

Постановка задачи

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

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

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

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

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

Рассмотрим следующую задачу: пусть необходимо обеспечить сбор и обработку данных по результатам сдачи экзаменов и зачетов студентами факультета. Организация данных должна обеспечивать (слайд 2):

выполнение текущего учебного плана;

формирование ведомостей по отдельным дисциплинам для групп студентов;

формирование листов зачетных книжек студентов;

формирование сводной ведомости курса;

расчет среднего балла по дисциплинам и т.п.

 

13.2. Восходящее проектирование (универсальное отношение)

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

Сессия (ФИО студента, № зачетной книжки, Дисциплина, Семестр, Форма отчетности, Количество часов, Оценка, Дата сдачи, ФИО преподавателя, Должность преподавателя, Кафедра).

Применим правила нормализации к универсальному отношению «Сессия» (слайд 4).

1. Определение первичного ключа таблицы.

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

№ зачетной книжки, Дисциплина, Семестр, Форма отчетности.

2. Выявление атрибутов, функционально зависящих от части составного ключа.

Каждый из атрибутов - ФИО преподавателя, Должность преподавателя, Кафедра и Количество часов - функционально зависит только от атрибутов Дисциплина, Семестр и Форма отчетности, т.е. этот атрибут вместе с совокупностью атрибутов первичного ключа составит вторую таблицу:

Учебный план (Дисциплина, Семестр, Форма отчетности, Количество часов, ФИО преподавателя, Должность преподавателя, Кафедра).

Из исходной таблицы при этом удаляются атрибуты ФИО преподавателя, Должность преподавателя, Кафедра и Количество часов:

Сводная ведомость (ФИО студента, № зачетной книжки, Дисциплина, Семестр, Форма отчетности, Оценка).

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

Учебный план (№ Уч. план, Дисциплина, Семестр, Форма отчетности, Кол-во часов, ФИО преподавателя, Должность преподавателя, Кафедра).

Сводная ведомость (ФИО студента, № зачетной книжки, № Уч. план, Оценка).

В таблице «Сводная ведомость» осталась еще одна частичная функциональная зависимость: № зачетной книжки → ФИО студента. Ликвидировав эту зависимость, получим еще одну таблицу – «Студенты»:

Студенты (№ зачетной книжки, ФИО студента)

Ликвидация ФЗ приведет к изменению таблицы «Результаты сессии»:

Сводная ведомость (№ зачетной книжки, № Уч. план, Оценка)

3. Выявление транзитивных зависимостей

В таблице «Учебный план» выявляются следующие транзитивные зависимости:

№ Уч. план → ФИО преподавателя

ФИО преподавателя → Должность преподавателя

ФИО преподавателя → Кафедра

Применив второй шаг процедуры нормализации, получим таблицу «Преподаватели»:

Кадровый состав (ФИО преподавателя, Должность преподавателя, Кафедра)

Следует иметь в виду, что в этом случае в рамках ПрО считается, что атрибут ФИО преподавателя однозначно (уникально) характеризует конкретного преподавателя.

Итак, получили следующую декомпозицию (слайд 5):

Учебный план (№ Уч. план, Дисциплина, Семестр, Форма отчетности, Кол-во часов, ФИО преподавателя)

Студенты (№ зачетной книжки, ФИО студента)

Кадровый состав (ФИО преподавателя, Должность преподавателя, Кафедра)

Сводная ведомость (№ зачетной книжки, № Уч. план, Оценка)

 

Такой декомпозиции на самом деле достаточно для того, чтобы преобразовать исходную таблицу к совокупности нормализованных таблиц (все полученные таблицы приведены к 3НФ и к НФБК).

Нисходящее проектирование