Тема 1.3 Цели и задачи
проектирования баз данных
Среди множества целей, стоящих перед
проектированием, следующие представляются наиболее важными:
1. Возможность хранения всех необходимых
данных в БД.
2. Исключение избыточности данных.
3. Сведение числа хранимых в БД
отношений к минимуму.
4. Нормализация отношений для упрощения
решения проблем, связанных с обновлением и удалением данных.
Цель 1: Возможность хранения всех
необходимых данных в БД.
Эта цель кажется очевидной, тем не менее
она очень важна. Предполагается, что БД должна содержать все данные,
представляющие интерес для пользователя, так что при проектировании следует
предусмотреть возможность размещения в БД всех необходимых данных. Первым шагом
в процессе проектирования является определение всех атрибутов, которые
впоследствии будут помещены в БД.
После определения атрибутов
проектировщик обдумывает, сколько отношений необходимо и какие атрибуты
включать в какие отношения. Кроме того, дополнительно необходимо решить,
следует ли предназначенные для хранения данные использовать для построения
одной базы или, возможно двух и более.
Цель 2: Исключение избыточности данных.
Сущность этой цели отнюдь не очевидна
для начинающего проектировщика БД. Ключ к ее пониманию заключается в уяснении
четкого различия между дублированием данных и избыточным дублированием.
Например, обратимся к отношению С - Н, приведенному на рис.3,а. Отношение имеет
два атрибута Слж# (табельный номер служащего) и Начк (начальник).
С – Н С - Н
|
Слж# |
Начк |
|
Слж# |
Начк |
|
Иванов |
Иванов |
|||
|
Петров |
Петров |
|||
|
Петров |
- |
|||
|
Иванов |
- |
а) б)
Рис.3. Дублирование данных, не
являющихся избыточными
В отношении содержатся данные,
указывающие непосредственного начальника каждого служащего предприятия. Фамилии
начальников могут неоднократно появляться в отношении. В действительности
фамилия начальника появляется один раз для каждого подчиненного ему служащего.
Хотя "Иванов" и "Петров" появляются дважды в отношении С-Н,
приведенном на рис.3,а, ни одна из дублируемых фамилий не является избыточной.
Причина отсутствия избыточности заключается в том, что при удалении одной из
фамилии из отношения будет утеряна информация. Например, на рис.3,б показано
отношение С-Н при удалении дублированных фамилий. В этом случае нет возможности
узнать фамилии начальников служащих с номерами 195 и 200.
На рис.4,а приведен пример отношения с
избыточным дублированием данных. Отношение С-Н-Т похоже на отношение С-Н, но
включает дополнительный атрибут Нтел., представляющий собой номер телефона
начальника. Предполагается, что каждый начальник имеет только один телефонный
номер. В этом экземпляре отношения номера телефонов Иванова и Петрова
появляются более чем один раз и дублированная информация о телефонных номерах
является избыточной. Причина избыточности в том, что если, скажем, удалить один
из номеров Иванова, эта информация может быть получена из других кортежей
отношения.
С-Н-Т С-Н-Т
|
Слж# |
Начк |
Нтел |
|
Слж# |
Начк |
Нтел |
|
Иванов |
Иванов |
|||||
|
Петров |
Петров |
|||||
|
Петров |
Петров |
- |
||||
|
Иванов |
Иванов |
- |
а) б)
С – Н Н - Т
|
Слж# |
Начк |
|
Начк |
Нтел |
|
Иванов |
Иванов |
|||
|
Петров |
Петров |
|||
|
Петров |
|
|||
|
Иванов |
в)
Рис.4. Исключение избыточных данных
На рис.4,б приведен пример того, как
будет выглядеть отношение С-Н-Т в случае замещения дублированных телефонных
номеров "нулями".
Данный метод устранения избыточности
неудовлетворен по двум причинам. Во-первых, пустых полей в БД следует избегать,
так как необходимы дополнительные усилия при программировании, направленные на
определение реальных значений "нулей". В рассматриваемом случае
чтение третьего кортежа <195, Петров> отношения не позволяет узнать
телефонный номер Петрова. Пользователь должен уметь находить в отношении другой
кортеж, для которого значение атрибута Начк является Петров, а значение
атрибута Нтел не является нулевым. Во-вторых, что более важно, отношение,
представленное на рис.4,б, имеет структуру, чреватую возникновением серьезных
проблем при удалении информации. Если служащий с номером Слж#=125 увольняется с
предприятия и кортеж <125, Иванов, 3051> будет удален из отношения
произойдет утеря телефонного номера Иванова, поскольку нигде более в отношении
он не представлен.
Рис.4,в показывает лучший способ
исключения избыточности телефонных номеров. Здесь отношение С-Н-Т заменяется
двумя отношениями, одно из которых содержит информацию о табельных номерах
служащих и фамилиях руководителей, а другое – информацию о начальниках и их
номерах телефонов.
Разбиение отношений представляет собой
стандартную процедуру проектирования, которая должна осуществляться при
соблюдении определенных ограничений, о чем речь далее.
Как следует из рис.4,в, служащий с
номером 125 теперь может быть удален из отношения С-Н без потери номера
телефона бывшего начальника этого служащего, хранимого в отношении Н-Т.
Цель 3: Сведение числа хранимых в БД
отношений к минимуму.
Эта цель обусловлена тем, что разбиение
одного отношения на два или более меньших отношений желательно с точки зрения
исключения определенных проблем, но это неудобно для пользователя. Таким
образом, нельзя допускать неограниченный рост числа отношений.
Цель 4: Нормализация отношений.
Для некоторых отношений очень важна
проблема удаления и обновления (например, обсуждавшаяся выше в цели 2 потеря
телефонного номера руководителя). Проектировщик должен уметь обнаруживать эти
потенциально опасные отношения и "нормализовать их" посредством
разбиения отношений предписанным образом. Нормализация представляет собой
разбиение одного отношения на два или более в соответствии со специальной
процедурой разбиения. Нормализация будет обсуждаться далее.
Цели 3 и 4 противоречат друг другу,
поэтому здесь требуется взаимный компромисс. Это будет частью завершающего
этапа проектирования.
Проектирование баз данных с использованием универсального отношения
Рассматриваемый метод проектирования
называют декомпозиционным методом.
Универсальное отношение
Предположим, что требуется разработать
небольшую БД для деканата института для учета успеваемости студентов,
проживающих в общежитии.
Первый шаг процесса проектирования
состоит в определении как всех атрибутов, наличие которых обязательно в БД, так
и связей между атрибутами.
Имена и условия, связанные с атрибутами,
хранение которых предполагается, определим следующим образом:
Сном: Номер студента. Целое значение,
уникальное для каждого студента института.
Сфам: Фамилия студента. Каждый студент
имеет только одну фамилию, но возможно, что одну фамилию носят несколько
студентов.
Кном: Номер комнаты в общежитии. В одной
комнате может проживать более одного студента.
Тном: Номер телефона студента. Каждая
комната общежития имеет один телефон и им пользуются все студенты, проживающие
в этой комнате.
Дисц: Название дисциплины. В БД будут
храниться данные о дисциплинах, по которым проведена итоговая аттестация
студента.
Семестр: Институтский семестр.
Представляет собой семестр, в котором данная дисциплина была завершена
студентом.
Возможно, что студент изучал одну и ту
же дисциплину в различных семестрах.
Оценка: Оценка за дисциплину. Оценка,
полученная студентом за определенную дисциплину в данном семестре.
На рис.5 представлена таблица с данными,
которые должны хранится в БД. Хотя на рисунке приведен пример в виде таблицы
данных, которые могут храниться в БД в некоторый момент времени, указанная
таблица отношением не является.
УСПЕВАЕМОСТЬ
|
Сном |
Сфам |
Кном |
Тном |
Дисц. |
Сем. |
Оценка |
|
Серов |
ВМ |
|||||
|
|
|
|
|
ТМ |
||
|
|
|
|
|
Физика |
||
|
Перов |
ВМ |
|||||
|
|
|
|
|
Химия |
||
|
|
|
|
|
ВТ |
||
|
Иванов |
ТМ |
|||||
|
Поляков |
ВМ |
Рис.5. Данные для размещения в БД
Для иллюстрации того, почему таблица на
рис.5 не является отношением, выделим одну "строку" из таблицы
(рис.6).
|
Серов |
ВМ |
|||||
|
|
ТМ |
|||||
|
Физика |
Рис.6. Одна "строка" таблицы,
приведенной на рис.5.
На этом рисунке значения четырех полей
Сном, Сфам, Кном и Тном - атомарные (атомарным называется неделимое значение, а
не множество, или кортеж, значений из некоторых доменов), в то время как
значения в полях Дисциплина, Семестр и Оценка - множественные.
Данная "строка" очевидным
образом отличается по форме от кортежей. Отличие в том, что не все поля строки
содержат атрибуты, значения которых атомарные. Для придания данным, приведенным
на рис.5, формы отношения необходимо реконструировать их таким образом, чтобы
каждый элемент кортежа имел атомарное значение. Обычно это удается сделать с
помощью простого процесса вставки (результат для данного случая показан на
рис.7). В результате этого процесса добавляется большой объем избыточных данных
– исключение избыточности достигается на следующих этапах проектирования.
УСПЕВАЕМОСТЬ
|
Сном |
Сфам |
Кном |
Тном |
Дисц. |
Сем. |
Оценка |
|
Серов |
ВМ |
|||||
|
Серов |
ТМ |
|||||
|
Серов |
Физика |
|||||
|
Перов |
ВМ |
|||||
|
Перов |
Химия |
|||||
|
Перов |
ВТ |
|||||
|
Иванов |
ТМ |
|||||
|
Поляков |
ВМ |
Рис.7. Данные из таблицы, приведенной на
рис.5, помещенные в корректное отношение.
Таблица на рис.7 представляет собой
экземпляр корректного отношения. Его называют универсальным отношением проектируемой
БД. В одно универсальное отношение включаются все представляющие интерес
атрибуты, и оно может содержать все данные, которые предполагается размещать в
БД в будущем. Для малых БД (включающих не более 20 атрибутов) универсальное
отношение может использоваться в качестве отправной точки при проектировании БД.
Справедливости ради следует заметить,
что большое количество атрибутов не является ограничивающим фактором при выборе
метода проектирования, так как на начальном этапе проектирования можно
воспользоваться обобщенными атрибутами, включающими в себя любое количество
атрибутов. Например, вместо атрибутов, характеризующих студента можно
использовать атрибут – характеристика студента, вместо атрибутов,
характеризующих технологический процесс можно использовать атрибут – характеристики
техпроцесса и т.д. На следующих этапах проектирования эти обобщенные
атрибуты должны быть раскрыты.
Основные этапы проектирования
Проектирование баз
данных
— это процесс создания схемы базы данных
и определения необходимых ограничений
целостности. Основными задачами проектирования баз данных являются:
•
Обеспечение
хранения в БД всей необходимой информации.
•
Обеспечение
возможности получения данных по всем необходимым запросам.
•
Сокращение
избыточности и дублирования данных.
•
Обеспечение
целостности данных (правильности их содержания): исключение противоречий в
содержании данных, исключение их потери и т.д.
Процесс
проектирования БД представляет собой последовательность переходов от
неформального словесного описания информационной структуры предметной области к
формализованному описанию объектов предметной области в терминах некоторой
модели. В общем случае можно выделить следующие этапы проектирования (рис. 13):
Тема 1.3 Цели и задачи
проектирования баз данных
Среди множества целей, стоящих перед
проектированием, следующие представляются наиболее важными:
1. Возможность хранения всех необходимых
данных в БД.
2. Исключение избыточности данных.
3. Сведение числа хранимых в БД
отношений к минимуму.
4. Нормализация отношений для упрощения
решения проблем, связанных с обновлением и удалением данных.
Цель 1: Возможность хранения всех
необходимых данных в БД.
Эта цель кажется очевидной, тем не менее
она очень важна. Предполагается, что БД должна содержать все данные,
представляющие интерес для пользователя, так что при проектировании следует
предусмотреть возможность размещения в БД всех необходимых данных. Первым шагом
в процессе проектирования является определение всех атрибутов, которые
впоследствии будут помещены в БД.
После определения атрибутов
проектировщик обдумывает, сколько отношений необходимо и какие атрибуты
включать в какие отношения. Кроме того, дополнительно необходимо решить,
следует ли предназначенные для хранения данные использовать для построения
одной базы или, возможно двух и более.
Цель 2: Исключение избыточности данных.
Сущность этой цели отнюдь не очевидна
для начинающего проектировщика БД. Ключ к ее пониманию заключается в уяснении
четкого различия между дублированием данных и избыточным дублированием.
Например, обратимся к отношению С - Н, приведенному на рис.3,а. Отношение имеет
два атрибута Слж# (табельный номер служащего) и Начк (начальник).
С – Н С - Н
|
Слж# |
Начк |
|
Слж# |
Начк |
|
Иванов |
Иванов |
|||
|
Петров |
Петров |
|||
|
Петров |
- |
|||
|
Иванов |
- |
а) б)
Рис.3. Дублирование данных, не
являющихся избыточными
В отношении содержатся данные,
указывающие непосредственного начальника каждого служащего предприятия. Фамилии
начальников могут неоднократно появляться в отношении. В действительности
фамилия начальника появляется один раз для каждого подчиненного ему служащего.
Хотя "Иванов" и "Петров" появляются дважды в отношении С-Н,
приведенном на рис.3,а, ни одна из дублируемых фамилий не является избыточной.
Причина отсутствия избыточности заключается в том, что при удалении одной из
фамилии из отношения будет утеряна информация. Например, на рис.3,б показано
отношение С-Н при удалении дублированных фамилий. В этом случае нет возможности
узнать фамилии начальников служащих с номерами 195 и 200.
На рис.4,а приведен пример отношения с
избыточным дублированием данных. Отношение С-Н-Т похоже на отношение С-Н, но
включает дополнительный атрибут Нтел., представляющий собой номер телефона
начальника. Предполагается, что каждый начальник имеет только один телефонный
номер. В этом экземпляре отношения номера телефонов Иванова и Петрова
появляются более чем один раз и дублированная информация о телефонных номерах
является избыточной. Причина избыточности в том, что если, скажем, удалить один
из номеров Иванова, эта информация может быть получена из других кортежей
отношения.
С-Н-Т С-Н-Т
|
Слж# |
Начк |
Нтел |
|
Слж# |
Начк |
Нтел |
|
Иванов |
Иванов |
|||||
|
Петров |
Петров |
|||||
|
Петров |
Петров |
- |
||||
|
Иванов |
Иванов |
- |
а) б)
С – Н Н - Т
|
Слж# |
Начк |
|
Начк |
Нтел |
|
Иванов |
Иванов |
|||
|
Петров |
Петров |
|||
|
Петров |
|
|||
|
Иванов |
в)
Рис.4. Исключение избыточных данных
На рис.4,б приведен пример того, как
будет выглядеть отношение С-Н-Т в случае замещения дублированных телефонных
номеров "нулями".
Данный метод устранения избыточности
неудовлетворен по двум причинам. Во-первых, пустых полей в БД следует избегать,
так как необходимы дополнительные усилия при программировании, направленные на
определение реальных значений "нулей". В рассматриваемом случае
чтение третьего кортежа <195, Петров> отношения не позволяет узнать
телефонный номер Петрова. Пользователь должен уметь находить в отношении другой
кортеж, для которого значение атрибута Начк является Петров, а значение
атрибута Нтел не является нулевым. Во-вторых, что более важно, отношение,
представленное на рис.4,б, имеет структуру, чреватую возникновением серьезных
проблем при удалении информации. Если служащий с номером Слж#=125 увольняется с
предприятия и кортеж <125, Иванов, 3051> будет удален из отношения
произойдет утеря телефонного номера Иванова, поскольку нигде более в отношении
он не представлен.
Рис.4,в показывает лучший способ
исключения избыточности телефонных номеров. Здесь отношение С-Н-Т заменяется
двумя отношениями, одно из которых содержит информацию о табельных номерах
служащих и фамилиях руководителей, а другое – информацию о начальниках и их
номерах телефонов.
Разбиение отношений представляет собой
стандартную процедуру проектирования, которая должна осуществляться при
соблюдении определенных ограничений, о чем речь далее.
Как следует из рис.4,в, служащий с
номером 125 теперь может быть удален из отношения С-Н без потери номера
телефона бывшего начальника этого служащего, хранимого в отношении Н-Т.
Цель 3: Сведение числа хранимых в БД
отношений к минимуму.
Эта цель обусловлена тем, что разбиение
одного отношения на два или более меньших отношений желательно с точки зрения
исключения определенных проблем, но это неудобно для пользователя. Таким
образом, нельзя допускать неограниченный рост числа отношений.
Цель 4: Нормализация отношений.
Для некоторых отношений очень важна
проблема удаления и обновления (например, обсуждавшаяся выше в цели 2 потеря
телефонного номера руководителя). Проектировщик должен уметь обнаруживать эти
потенциально опасные отношения и "нормализовать их" посредством
разбиения отношений предписанным образом. Нормализация представляет собой
разбиение одного отношения на два или более в соответствии со специальной
процедурой разбиения. Нормализация будет обсуждаться далее.
Цели 3 и 4 противоречат друг другу,
поэтому здесь требуется взаимный компромисс. Это будет частью завершающего
этапа проектирования.
Проектирование баз данных с использованием универсального отношения
Рассматриваемый метод проектирования
называют декомпозиционным методом.
Универсальное отношение
Предположим, что требуется разработать
небольшую БД для деканата института для учета успеваемости студентов,
проживающих в общежитии.
Первый шаг процесса проектирования
состоит в определении как всех атрибутов, наличие которых обязательно в БД, так
и связей между атрибутами.
Имена и условия, связанные с атрибутами,
хранение которых предполагается, определим следующим образом:
Сном: Номер студента. Целое значение,
уникальное для каждого студента института.
Сфам: Фамилия студента. Каждый студент
имеет только одну фамилию, но возможно, что одну фамилию носят несколько
студентов.
Кном: Номер комнаты в общежитии. В одной
комнате может проживать более одного студента.
Тном: Номер телефона студента. Каждая
комната общежития имеет один телефон и им пользуются все студенты, проживающие
в этой комнате.
Дисц: Название дисциплины. В БД будут
храниться данные о дисциплинах, по которым проведена итоговая аттестация
студента.
Семестр: Институтский семестр.
Представляет собой семестр, в котором данная дисциплина была завершена
студентом.
Возможно, что студент изучал одну и ту
же дисциплину в различных семестрах.
Оценка: Оценка за дисциплину. Оценка,
полученная студентом за определенную дисциплину в данном семестре.
На рис.5 представлена таблица с данными,
которые должны хранится в БД. Хотя на рисунке приведен пример в виде таблицы
данных, которые могут храниться в БД в некоторый момент времени, указанная
таблица отношением не является.
УСПЕВАЕМОСТЬ
|
Сном |
Сфам |
Кном |
Тном |
Дисц. |
Сем. |
Оценка |
|
Серов |
ВМ |
|||||
|
|
|
|
|
ТМ |
||
|
|
|
|
|
Физика |
||
|
Перов |
ВМ |
|||||
|
|
|
|
|
Химия |
||
|
|
|
|
|
ВТ |
||
|
Иванов |
ТМ |
|||||
|
Поляков |
ВМ |
Рис.5. Данные для размещения в БД
Для иллюстрации того, почему таблица на
рис.5 не является отношением, выделим одну "строку" из таблицы
(рис.6).
|
Серов |
ВМ |
|||||
|
|
ТМ |
|||||
|
Физика |
Рис.6. Одна "строка" таблицы,
приведенной на рис.5.
На этом рисунке значения четырех полей
Сном, Сфам, Кном и Тном - атомарные (атомарным называется неделимое значение, а
не множество, или кортеж, значений из некоторых доменов), в то время как
значения в полях Дисциплина, Семестр и Оценка - множественные.
Данная "строка" очевидным
образом отличается по форме от кортежей. Отличие в том, что не все поля строки
содержат атрибуты, значения которых атомарные. Для придания данным, приведенным
на рис.5, формы отношения необходимо реконструировать их таким образом, чтобы
каждый элемент кортежа имел атомарное значение. Обычно это удается сделать с
помощью простого процесса вставки (результат для данного случая показан на
рис.7). В результате этого процесса добавляется большой объем избыточных данных
– исключение избыточности достигается на следующих этапах проектирования.
УСПЕВАЕМОСТЬ
|
Сном |
Сфам |
Кном |
Тном |
Дисц. |
Сем. |
Оценка |
|
Серов |
ВМ |
|||||
|
Серов |
ТМ |
|||||
|
Серов |
Физика |
|||||
|
Перов |
ВМ |
|||||
|
Перов |
Химия |
|||||
|
Перов |
ВТ |
|||||
|
Иванов |
ТМ |
|||||
|
Поляков |
ВМ |
Рис.7. Данные из таблицы, приведенной на
рис.5, помещенные в корректное отношение.
Таблица на рис.7 представляет собой
экземпляр корректного отношения. Его называют универсальным отношением проектируемой
БД. В одно универсальное отношение включаются все представляющие интерес
атрибуты, и оно может содержать все данные, которые предполагается размещать в
БД в будущем. Для малых БД (включающих не более 20 атрибутов) универсальное
отношение может использоваться в качестве отправной точки при проектировании БД.
Справедливости ради следует заметить,
что большое количество атрибутов не является ограничивающим фактором при выборе
метода проектирования, так как на начальном этапе проектирования можно
воспользоваться обобщенными атрибутами, включающими в себя любое количество
атрибутов. Например, вместо атрибутов, характеризующих студента можно
использовать атрибут – характеристика студента, вместо атрибутов,
характеризующих технологический процесс можно использовать атрибут – характеристики
техпроцесса и т.д. На следующих этапах проектирования эти обобщенные
атрибуты должны быть раскрыты.
Основные этапы проектирования
Проектирование баз
данных
— это процесс создания схемы базы данных
и определения необходимых ограничений
целостности. Основными задачами проектирования баз данных являются:
•
Обеспечение
хранения в БД всей необходимой информации.
•
Обеспечение
возможности получения данных по всем необходимым запросам.
•
Сокращение
избыточности и дублирования данных.
•
Обеспечение
целостности данных (правильности их содержания): исключение противоречий в
содержании данных, исключение их потери и т.д.
Процесс
проектирования БД представляет собой последовательность переходов от
неформального словесного описания информационной структуры предметной области к
формализованному описанию объектов предметной области в терминах некоторой
модели. В общем случае можно выделить следующие этапы проектирования (рис. 13):
Рисунок 13 – Этапы
проектирования БД
Решение проблем
проектирования на физическом уровне во многом зависит от используемой СУБД,
зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю
предоставляется возможность настройки отдельных параметров системы, которая не
составляет большой проблемы.
Логическое
проектирование заключается в определении числа и структуры таблиц, формировании
запросов к БД, определении типов отчетных документов, разработке алгоритмов
обработки информации, создании форм для ввода и редактирования данных в базе и
решении ряда других задач.
Решение задач
логического проектирования БД в основном определяется спецификой задач
предметной области. Наиболее важной здесь является проблема структуризации данных.
Методы проектирования
реляционных баз данных
Основная проблема
проектирования реляционной базы данных состоит в обоснованном принятии решений
о том, из каких отношений должна состоять БД и какие атрибуты должны быть у
этих отношений.
Для построения
«хорошей» базы данных, которая находилась хотя бы в третьей нормальной форме,
можно использовать следующие методы:
1)
Метод нормальных форм–метод
пошаговой декомпозиции, заключающийся в последовательном разбиении
исходной и промежуточных схем отношений до тех пор, пока результирующие
отношения не будут удовлетворять заданным свойствам.
2)
Метод синтеза, состоящий в конструировании
(синтезе) набора декомпозиционных подсхем, удовлетворяющих определѐнным
свойствам, из заданного множества атрибутов выбранной предметной области на
основе заданного множества функциональных зависимостей, связывающих эти
атрибуты.
3)
Метод ER-диаграмм (семантическое
моделирование) представляет собой моделирование структуры данных,
опираясь на смысл этих данных. В качестве инструмента семантического
моделирования используются различные варианты диаграмм сущность-связь (ER –
Entity-Relationship).
1.
Метод
нормальных форм (классический метод)представляет собой вариант восходящего
подхода при проектировании БД. Нормализация предусматривает
идентификацию требуемых атрибутов с последующим созданием из них
нормализованных таблиц, основанных на функциональных зависимостях между этими
атрибутами (подраздел 2.4).
Восходящий подход
в наибольшей степени приемлем для проектирования простых (как правило,
централизованных) БД с относительно небольшим количеством атрибутов. Однако
использование этого подхода существенно усложняется при проектировании
распределенных БД, особенно при интеграции локальных баз данных, которые могут
быть выполнены с использованием различных моделей данных с большим количеством
атрибутов, установить среди которых все существующие функциональные зависимости
довольно затруднительно
2.
Более
подходящей стратегией проектирования сложных баз данных является использование
нисходящего подхода (метода синтеза). Начинается этот подход с разработки
моделей данных, которые содержат несколько высокоуровневых сущностей и связей,
затем работа продолжается в виде серии нисходящих уточнений низкоуровневых
сущностей, связей и относящихся к ним атрибутов. Например, сначала можно было
бы идентифицировать сущности ВЛАДЕЛЕЦ и ОБЪЕКТ_НЕДВИЖИМОСТИ, затем установить
между ними связь ВЛАДЕЛЕЦ владеет ОБЪЕКТОМ_НЕДВИЖИМОСТИ и лишь после этого
определить связанные с ними атрибуты — например, ВЛАДЕЛЕЦ (номер_вл, имя_вл,
адрес_вл) и ОБЪЕКТ_НЕДВИЖИМОСТИ(номер_об, адрес_об).
3.
Все
варианты диаграмм сущность-связь
исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие
диаграммы используют графическое изображение сущностей предметной области, их
свойств (атрибутов), и взаимосвязей между сущностями.
Без семантического
моделирования можно обойтись, если число таблиц не превышает десяти, но оно
совершенно необходимо, если БД включает более сотни таблиц.
В настоящее время
на рынке существует большое количество систем автоматизации проектирования баз
данных (Сomputer-Аided Software Engineering – CASE-средств), обеспечивающих
автоматизированное преобразование диаграммных концептуальных схем баз данных,
представленных в той или иной семантической модели данных, в реляционные схемы
данных конкретной СУБД (подраздел 4.1). Все CASE-системы имеют развитые
средства документирования процесса разработки, автоматические генераторы
отчетов позволяют подготовить отчет о текущем состоянии проекта с подробным
описанием объектов БД и их отношений, что существенно облегчает ведение
проекта.
Проектирование базы данных «Университет»
3.3.1
Инфологическое проектирование
Инфологическое проектирование проводится, как
правило, методом последовательных приближений к удовлетворительному набору схем
отношений. Исходной точкой является представление предметной области в виде
одного или нескольких отношений, а на каждом шаге проектирования производится
некоторый новый набор схем отношений, обладающих лучшими свойствами.
Пусть в результате
системного анализа установлена необходимость отразить в БД сведения о студентах
вуза.
При этом БД должна
содержать данные о каждом студенте: СТУДЕНТ(Номер зачетной книжки, Фамилия,
Имя, Отчество, Номер группы, Номер факультета, Наименование, Декан, Номер
специальности, Наименование специальности, Стоимость, Дата рождения, Курс,
Коммерческий).
Определим
функциональные зависимости в исходном отношении (рис. 14).
Тема 1.3 Цели и задачи
проектирования баз данных
Среди множества целей, стоящих перед
проектированием, следующие представляются наиболее важными:
1. Возможность хранения всех необходимых
данных в БД.
2. Исключение избыточности данных.
3. Сведение числа хранимых в БД
отношений к минимуму.
4. Нормализация отношений для упрощения
решения проблем, связанных с обновлением и удалением данных.
Цель 1: Возможность хранения всех
необходимых данных в БД.
Эта цель кажется очевидной, тем не менее
она очень важна. Предполагается, что БД должна содержать все данные,
представляющие интерес для пользователя, так что при проектировании следует
предусмотреть возможность размещения в БД всех необходимых данных. Первым шагом
в процессе проектирования является определение всех атрибутов, которые
впоследствии будут помещены в БД.
После определения атрибутов
проектировщик обдумывает, сколько отношений необходимо и какие атрибуты
включать в какие отношения. Кроме того, дополнительно необходимо решить,
следует ли предназначенные для хранения данные использовать для построения
одной базы или, возможно двух и более.
Цель 2: Исключение избыточности данных.
Сущность этой цели отнюдь не очевидна
для начинающего проектировщика БД. Ключ к ее пониманию заключается в уяснении
четкого различия между дублированием данных и избыточным дублированием.
Например, обратимся к отношению С - Н, приведенному на рис.3,а. Отношение имеет
два атрибута Слж# (табельный номер служащего) и Начк (начальник).
С – Н С - Н
|
Слж# |
Начк |
|
Слж# |
Начк |
|
Иванов |
Иванов |
|||
|
Петров |
Петров |
|||
|
Петров |
- |
|||
|
Иванов |
- |
а) б)
Рис.3. Дублирование данных, не
являющихся избыточными
В отношении содержатся данные,
указывающие непосредственного начальника каждого служащего предприятия. Фамилии
начальников могут неоднократно появляться в отношении. В действительности
фамилия начальника появляется один раз для каждого подчиненного ему служащего.
Хотя "Иванов" и "Петров" появляются дважды в отношении С-Н,
приведенном на рис.3,а, ни одна из дублируемых фамилий не является избыточной.
Причина отсутствия избыточности заключается в том, что при удалении одной из
фамилии из отношения будет утеряна информация. Например, на рис.3,б показано
отношение С-Н при удалении дублированных фамилий. В этом случае нет возможности
узнать фамилии начальников служащих с номерами 195 и 200.
На рис.4,а приведен пример отношения с
избыточным дублированием данных. Отношение С-Н-Т похоже на отношение С-Н, но
включает дополнительный атрибут Нтел., представляющий собой номер телефона
начальника. Предполагается, что каждый начальник имеет только один телефонный
номер. В этом экземпляре отношения номера телефонов Иванова и Петрова
появляются более чем один раз и дублированная информация о телефонных номерах
является избыточной. Причина избыточности в том, что если, скажем, удалить один
из номеров Иванова, эта информация может быть получена из других кортежей
отношения.
С-Н-Т С-Н-Т
|
Слж# |
Начк |
Нтел |
|
Слж# |
Начк |
Нтел |
|
Иванов |
Иванов |
|||||
|
Петров |
Петров |
|||||
|
Петров |
Петров |
- |
||||
|
Иванов |
Иванов |
- |
а) б)
С – Н Н - Т
|
Слж# |
Начк |
|
Начк |
Нтел |
|
Иванов |
Иванов |
|||
|
Петров |
Петров |
|||
|
Петров |
|
|||
|
Иванов |
в)
Рис.4. Исключение избыточных данных
На рис.4,б приведен пример того, как
будет выглядеть отношение С-Н-Т в случае замещения дублированных телефонных
номеров "нулями".
Данный метод устранения избыточности
неудовлетворен по двум причинам. Во-первых, пустых полей в БД следует избегать,
так как необходимы дополнительные усилия при программировании, направленные на
определение реальных значений "нулей". В рассматриваемом случае
чтение третьего кортежа <195, Петров> отношения не позволяет узнать
телефонный номер Петрова. Пользователь должен уметь находить в отношении другой
кортеж, для которого значение атрибута Начк является Петров, а значение
атрибута Нтел не является нулевым. Во-вторых, что более важно, отношение,
представленное на рис.4,б, имеет структуру, чреватую возникновением серьезных
проблем при удалении информации. Если служащий с номером Слж#=125 увольняется с
предприятия и кортеж <125, Иванов, 3051> будет удален из отношения
произойдет утеря телефонного номера Иванова, поскольку нигде более в отношении
он не представлен.
Рис.4,в показывает лучший способ
исключения избыточности телефонных номеров. Здесь отношение С-Н-Т заменяется
двумя отношениями, одно из которых содержит информацию о табельных номерах
служащих и фамилиях руководителей, а другое – информацию о начальниках и их
номерах телефонов.
Разбиение отношений представляет собой
стандартную процедуру проектирования, которая должна осуществляться при
соблюдении определенных ограничений, о чем речь далее.
Как следует из рис.4,в, служащий с
номером 125 теперь может быть удален из отношения С-Н без потери номера
телефона бывшего начальника этого служащего, хранимого в отношении Н-Т.
Цель 3: Сведение числа хранимых в БД
отношений к минимуму.
Эта цель обусловлена тем, что разбиение
одного отношения на два или более меньших отношений желательно с точки зрения
исключения определенных проблем, но это неудобно для пользователя. Таким
образом, нельзя допускать неограниченный рост числа отношений.
Цель 4: Нормализация отношений.
Для некоторых отношений очень важна
проблема удаления и обновления (например, обсуждавшаяся выше в цели 2 потеря
телефонного номера руководителя). Проектировщик должен уметь обнаруживать эти
потенциально опасные отношения и "нормализовать их" посредством
разбиения отношений предписанным образом. Нормализация представляет собой
разбиение одного отношения на два или более в соответствии со специальной
процедурой разбиения. Нормализация будет обсуждаться далее.
Цели 3 и 4 противоречат друг другу,
поэтому здесь требуется взаимный компромисс. Это будет частью завершающего
этапа проектирования.
Проектирование баз данных с использованием универсального отношения
Рассматриваемый метод проектирования
называют декомпозиционным методом.
Универсальное отношение
Предположим, что требуется разработать
небольшую БД для деканата института для учета успеваемости студентов,
проживающих в общежитии.
Первый шаг процесса проектирования
состоит в определении как всех атрибутов, наличие которых обязательно в БД, так
и связей между атрибутами.
Имена и условия, связанные с атрибутами,
хранение которых предполагается, определим следующим образом:
Сном: Номер студента. Целое значение,
уникальное для каждого студента института.
Сфам: Фамилия студента. Каждый студент
имеет только одну фамилию, но возможно, что одну фамилию носят несколько
студентов.
Кном: Номер комнаты в общежитии. В одной
комнате может проживать более одного студента.
Тном: Номер телефона студента. Каждая
комната общежития имеет один телефон и им пользуются все студенты, проживающие
в этой комнате.
Дисц: Название дисциплины. В БД будут
храниться данные о дисциплинах, по которым проведена итоговая аттестация
студента.
Семестр: Институтский семестр.
Представляет собой семестр, в котором данная дисциплина была завершена
студентом.
Возможно, что студент изучал одну и ту
же дисциплину в различных семестрах.
Оценка: Оценка за дисциплину. Оценка,
полученная студентом за определенную дисциплину в данном семестре.
На рис.5 представлена таблица с данными,
которые должны хранится в БД. Хотя на рисунке приведен пример в виде таблицы
данных, которые могут храниться в БД в некоторый момент времени, указанная
таблица отношением не является.
УСПЕВАЕМОСТЬ
|
Сном |
Сфам |
Кном |
Тном |
Дисц. |
Сем. |
Оценка |
|
Серов |
ВМ |
|||||
|
|
|
|
|
ТМ |
||
|
|
|
|
|
Физика |
||
|
Перов |
ВМ |
|||||
|
|
|
|
|
Химия |
||
|
|
|
|
|
ВТ |
||
|
Иванов |
ТМ |
|||||
|
Поляков |
ВМ |
Рис.5. Данные для размещения в БД
Для иллюстрации того, почему таблица на
рис.5 не является отношением, выделим одну "строку" из таблицы
(рис.6).
|
Серов |
ВМ |
|||||
|
|
ТМ |
|||||
|
Физика |
Рис.6. Одна "строка" таблицы,
приведенной на рис.5.
На этом рисунке значения четырех полей
Сном, Сфам, Кном и Тном - атомарные (атомарным называется неделимое значение, а
не множество, или кортеж, значений из некоторых доменов), в то время как
значения в полях Дисциплина, Семестр и Оценка - множественные.
Данная "строка" очевидным
образом отличается по форме от кортежей. Отличие в том, что не все поля строки
содержат атрибуты, значения которых атомарные. Для придания данным, приведенным
на рис.5, формы отношения необходимо реконструировать их таким образом, чтобы
каждый элемент кортежа имел атомарное значение. Обычно это удается сделать с
помощью простого процесса вставки (результат для данного случая показан на
рис.7). В результате этого процесса добавляется большой объем избыточных данных
– исключение избыточности достигается на следующих этапах проектирования.
УСПЕВАЕМОСТЬ
|
Сном |
Сфам |
Кном |
Тном |
Дисц. |
Сем. |
Оценка |
|
Серов |
ВМ |
|||||
|
Серов |
ТМ |
|||||
|
Серов |
Физика |
|||||
|
Перов |
ВМ |
|||||
|
Перов |
Химия |
|||||
|
Перов |
ВТ |
|||||
|
Иванов |
ТМ |
|||||
|
Поляков |
ВМ |
Рис.7. Данные из таблицы, приведенной на
рис.5, помещенные в корректное отношение.
Таблица на рис.7 представляет собой
экземпляр корректного отношения. Его называют универсальным отношением проектируемой
БД. В одно универсальное отношение включаются все представляющие интерес
атрибуты, и оно может содержать все данные, которые предполагается размещать в
БД в будущем. Для малых БД (включающих не более 20 атрибутов) универсальное
отношение может использоваться в качестве отправной точки при проектировании БД.
Справедливости ради следует заметить,
что большое количество атрибутов не является ограничивающим фактором при выборе
метода проектирования, так как на начальном этапе проектирования можно
воспользоваться обобщенными атрибутами, включающими в себя любое количество
атрибутов. Например, вместо атрибутов, характеризующих студента можно
использовать атрибут – характеристика студента, вместо атрибутов,
характеризующих технологический процесс можно использовать атрибут – характеристики
техпроцесса и т.д. На следующих этапах проектирования эти обобщенные
атрибуты должны быть раскрыты.
Основные этапы проектирования
Проектирование баз
данных
— это процесс создания схемы базы данных
и определения необходимых ограничений
целостности. Основными задачами проектирования баз данных являются:
•
Обеспечение
хранения в БД всей необходимой информации.
•
Обеспечение
возможности получения данных по всем необходимым запросам.
•
Сокращение
избыточности и дублирования данных.
•
Обеспечение
целостности данных (правильности их содержания): исключение противоречий в
содержании данных, исключение их потери и т.д.
Процесс
проектирования БД представляет собой последовательность переходов от
неформального словесного описания информационной структуры предметной области к
формализованному описанию объектов предметной области в терминах некоторой
модели. В общем случае можно выделить следующие этапы проектирования (рис. 13):
Рисунок 13 – Этапы
проектирования БД
Решение проблем
проектирования на физическом уровне во многом зависит от используемой СУБД,
зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю
предоставляется возможность настройки отдельных параметров системы, которая не
составляет большой проблемы.
Логическое
проектирование заключается в определении числа и структуры таблиц, формировании
запросов к БД, определении типов отчетных документов, разработке алгоритмов
обработки информации, создании форм для ввода и редактирования данных в базе и
решении ряда других задач.
Решение задач
логического проектирования БД в основном определяется спецификой задач
предметной области. Наиболее важной здесь является проблема структуризации данных.
Методы проектирования
реляционных баз данных
Основная проблема
проектирования реляционной базы данных состоит в обоснованном принятии решений
о том, из каких отношений должна состоять БД и какие атрибуты должны быть у
этих отношений.
Для построения
«хорошей» базы данных, которая находилась хотя бы в третьей нормальной форме,
можно использовать следующие методы:
1)
Метод нормальных форм–метод
пошаговой декомпозиции, заключающийся в последовательном разбиении
исходной и промежуточных схем отношений до тех пор, пока результирующие
отношения не будут удовлетворять заданным свойствам.
2)
Метод синтеза, состоящий в конструировании
(синтезе) набора декомпозиционных подсхем, удовлетворяющих определѐнным
свойствам, из заданного множества атрибутов выбранной предметной области на
основе заданного множества функциональных зависимостей, связывающих эти
атрибуты.
3)
Метод ER-диаграмм (семантическое
моделирование) представляет собой моделирование структуры данных,
опираясь на смысл этих данных. В качестве инструмента семантического
моделирования используются различные варианты диаграмм сущность-связь (ER –
Entity-Relationship).
1.
Метод
нормальных форм (классический метод)представляет собой вариант восходящего
подхода при проектировании БД. Нормализация предусматривает
идентификацию требуемых атрибутов с последующим созданием из них
нормализованных таблиц, основанных на функциональных зависимостях между этими
атрибутами (подраздел 2.4).
Восходящий подход
в наибольшей степени приемлем для проектирования простых (как правило,
централизованных) БД с относительно небольшим количеством атрибутов. Однако
использование этого подхода существенно усложняется при проектировании
распределенных БД, особенно при интеграции локальных баз данных, которые могут
быть выполнены с использованием различных моделей данных с большим количеством
атрибутов, установить среди которых все существующие функциональные зависимости
довольно затруднительно
2.
Более
подходящей стратегией проектирования сложных баз данных является использование
нисходящего подхода (метода синтеза). Начинается этот подход с разработки
моделей данных, которые содержат несколько высокоуровневых сущностей и связей,
затем работа продолжается в виде серии нисходящих уточнений низкоуровневых
сущностей, связей и относящихся к ним атрибутов. Например, сначала можно было
бы идентифицировать сущности ВЛАДЕЛЕЦ и ОБЪЕКТ_НЕДВИЖИМОСТИ, затем установить
между ними связь ВЛАДЕЛЕЦ владеет ОБЪЕКТОМ_НЕДВИЖИМОСТИ и лишь после этого
определить связанные с ними атрибуты — например, ВЛАДЕЛЕЦ (номер_вл, имя_вл,
адрес_вл) и ОБЪЕКТ_НЕДВИЖИМОСТИ(номер_об, адрес_об).
3.
Все
варианты диаграмм сущность-связь
исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие
диаграммы используют графическое изображение сущностей предметной области, их
свойств (атрибутов), и взаимосвязей между сущностями.
Без семантического
моделирования можно обойтись, если число таблиц не превышает десяти, но оно
совершенно необходимо, если БД включает более сотни таблиц.
В настоящее время
на рынке существует большое количество систем автоматизации проектирования баз
данных (Сomputer-Аided Software Engineering – CASE-средств), обеспечивающих
автоматизированное преобразование диаграммных концептуальных схем баз данных,
представленных в той или иной семантической модели данных, в реляционные схемы
данных конкретной СУБД (подраздел 4.1). Все CASE-системы имеют развитые
средства документирования процесса разработки, автоматические генераторы
отчетов позволяют подготовить отчет о текущем состоянии проекта с подробным
описанием объектов БД и их отношений, что существенно облегчает ведение
проекта.
Проектирование базы данных «Университет»
3.3.1
Инфологическое проектирование
Инфологическое проектирование проводится, как
правило, методом последовательных приближений к удовлетворительному набору схем
отношений. Исходной точкой является представление предметной области в виде
одного или нескольких отношений, а на каждом шаге проектирования производится
некоторый новый набор схем отношений, обладающих лучшими свойствами.
Пусть в результате
системного анализа установлена необходимость отразить в БД сведения о студентах
вуза.
При этом БД должна
содержать данные о каждом студенте: СТУДЕНТ(Номер зачетной книжки, Фамилия,
Имя, Отчество, Номер группы, Номер факультета, Наименование, Декан, Номер
специальности, Наименование специальности, Стоимость, Дата рождения, Курс,
Коммерческий).
Определим
функциональные зависимости в исходном отношении (рис. 14).
Рисунок 14 –
Функциональные зависимости в исходном отношении СТУДЕНТ
Следовательно,
инфологическая модель предметной области будет иметь вид, показанный на рис.
15.
Рисунок 15 –
Инфологическая модель предметной области
Модель содержит не
только информационные объекты, но и взаимосвязи между ними. Так, связь типа
«один ко многим» устанавливается:
•
между
объектами ГРУППА и СТУДЕНТ по их общему атрибуту Номер группы;
•
между
объектами ГРУППА и ФАКУЛЬТЕТ по их общему атрибуту
Номер
факультета;
•
между
объектами ГРУППА и СПЕЦИАЛЬНОСТЬ по их общему атрибуту Номер
специальности.
Стоит, однако,
обратить внимание на то, что полученная инфологическая модель, в целом
удовлетворяющая требованиям нормализации, с точки зрения логики может
некорректно описывать предметную область. Модель допускает существование
некоторой специальности, которая не преподается ни на одном факультете.
Естественным желанием при этом является добавление связи между объектами
ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ. Альтернативой этому может быть определение домена
для атрибута Номер специальности, который будет содержать только «существующие»
номера специальностей.
Даталогическое
проектирование
Выполняется
описание логических структур сформированных информационных объектов,
предполагаемых к реализации в базе данных. Описания приведены в табл. 2 – 5.
Таблица 2 –
Логическая структура информационного объекта СТУДЕНТ
Таблица 3 – Логическая
структура информационного объекта ГРУППА
Таблица 4 –
Логическая структура информационного объекта ФАКУЛЬТЕТ
Таблица 5 –
Логическая структура информационного объекта
СПАЦИАЛЬНОСТЬ
После описания
информационных объектов необходимо установить правила ссылочной целостности для каждой связи инфологической
модели.
Правила ссылочной
целостности
– это логические конструкции, которые выражают правила использования
взаимосвязанных данных при их добавлении, обновлении и удалении.
В ходе физической
реализации БД каждой связи будут приписаны триггеры
ссылочной целостности (RI-триггеры), которые и обеспечат установленное
правило целостности.
Триггеры – это подпрограммы,
которые запускаются всякий раз при выполнении команд вставки (INSERT), обновления(UPDATE) и удаления (DELETE).
Допустим, что
необходимо удалить один из экземпляров информационного объекта ГРУППА.
Экземпляр информационного объекта СТУДЕНТ не может существовать без
соответствующего экземпляра объекта ГРУППА. Следовательно, необходимо либо
запретить удаление группы, в которой числится хотя бы один студент, либо сразу
удалять всех студентов вместе с группой. Такие правила ссылочной целостности
называются RESTRICT и CASCADE соответственно.
В другой ситуации,
когда, например, экземпляр информационного объекта СТУДЕНТ может существовать
без ссылки на номер группы в объекте ГРУППА, при удалении какой -либо группы
информация о ней должна остаться в объекте СТУДЕНТ. Такое правило называется SET NULL. При этом значение атрибута
Номер группы объекта СТУДЕНТ принимает значение NULL.
Правило SET DEFAULT устанавливает атрибуту
значение по умолчанию. Например, при «удалении» группы все студенты, которые в
ней учились, зачисляются в другую группу (значению атрибута Номер группы
объекта СТУДЕНТ присваивается значение по умолчанию).
Наконец, правило NONE не меняет значение атрибута. При
«удалении» группы запись о ней «повисает в воздухе», т. е. экземпляр объекта
СТУДЕНТ ссылается на несуществующую уже запись о группе.
3.3.3
Физическое проектирование
Основной целью
физического проектирования базы данных является описание способа физической
реализации логического проекта базы данных, т.е. реализации базы данных на
вторичных запоминающих устройствах. На этом этапе рассматриваются основные
отношения, организация файлов и индексов, предназначенных для обеспечения
эффективного доступа к данным, а также все связанные с этим ограничения
целостности и средства защиты.
Физическое
проектирование неразрывно связано с конкретной СУБД. Между логическим и
физическим проектированием существует постоянная обратная связь, так как
решения, принимаемые на этапе физического проектирования с целью повышения
производительности системы, способны повлиять на структуру логической модели
данных.
Рисунок 14 –
Функциональные зависимости в исходном отношении СТУДЕНТ
Следовательно,
инфологическая модель предметной области будет иметь вид, показанный на рис.
15.
Рисунок 15 –
Инфологическая модель предметной области
Модель содержит не
только информационные объекты, но и взаимосвязи между ними. Так, связь типа
«один ко многим» устанавливается:
•
между
объектами ГРУППА и СТУДЕНТ по их общему атрибуту Номер группы;
•
между
объектами ГРУППА и ФАКУЛЬТЕТ по их общему атрибуту
Номер
факультета;
•
между
объектами ГРУППА и СПЕЦИАЛЬНОСТЬ по их общему атрибуту Номер
специальности.
Стоит, однако,
обратить внимание на то, что полученная инфологическая модель, в целом
удовлетворяющая требованиям нормализации, с точки зрения логики может
некорректно описывать предметную область. Модель допускает существование
некоторой специальности, которая не преподается ни на одном факультете.
Естественным желанием при этом является добавление связи между объектами
ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ. Альтернативой этому может быть определение домена
для атрибута Номер специальности, который будет содержать только «существующие»
номера специальностей.
Даталогическое
проектирование
Выполняется
описание логических структур сформированных информационных объектов,
предполагаемых к реализации в базе данных. Описания приведены в табл. 2 – 5.
Таблица 2 –
Логическая структура информационного объекта СТУДЕНТ
Таблица 3 – Логическая
структура информационного объекта ГРУППА
Таблица 4 –
Логическая структура информационного объекта ФАКУЛЬТЕТ
Таблица 5 –
Логическая структура информационного объекта
СПАЦИАЛЬНОСТЬ
После описания
информационных объектов необходимо установить правила ссылочной целостности для каждой связи инфологической
модели.
Правила ссылочной
целостности
– это логические конструкции, которые выражают правила использования
взаимосвязанных данных при их добавлении, обновлении и удалении.
В ходе физической
реализации БД каждой связи будут приписаны триггеры
ссылочной целостности (RI-триггеры), которые и обеспечат установленное
правило целостности.
Триггеры – это подпрограммы,
которые запускаются всякий раз при выполнении команд вставки (INSERT), обновления(UPDATE) и удаления (DELETE).
Допустим, что
необходимо удалить один из экземпляров информационного объекта ГРУППА.
Экземпляр информационного объекта СТУДЕНТ не может существовать без
соответствующего экземпляра объекта ГРУППА. Следовательно, необходимо либо
запретить удаление группы, в которой числится хотя бы один студент, либо сразу
удалять всех студентов вместе с группой. Такие правила ссылочной целостности
называются RESTRICT и CASCADE соответственно.
В другой ситуации,
когда, например, экземпляр информационного объекта СТУДЕНТ может существовать
без ссылки на номер группы в объекте ГРУППА, при удалении какой -либо группы
информация о ней должна остаться в объекте СТУДЕНТ. Такое правило называется SET NULL. При этом значение атрибута
Номер группы объекта СТУДЕНТ принимает значение NULL.
Правило SET DEFAULT устанавливает атрибуту
значение по умолчанию. Например, при «удалении» группы все студенты, которые в
ней учились, зачисляются в другую группу (значению атрибута Номер группы
объекта СТУДЕНТ присваивается значение по умолчанию).
Наконец, правило NONE не меняет значение атрибута. При
«удалении» группы запись о ней «повисает в воздухе», т. е. экземпляр объекта
СТУДЕНТ ссылается на несуществующую уже запись о группе.
3.3.3
Физическое проектирование
Основной целью
физического проектирования базы данных является описание способа физической
реализации логического проекта базы данных, т.е. реализации базы данных на
вторичных запоминающих устройствах. На этом этапе рассматриваются основные
отношения, организация файлов и индексов, предназначенных для обеспечения
эффективного доступа к данным, а также все связанные с этим ограничения
целостности и средства защиты.
Физическое
проектирование неразрывно связано с конкретной СУБД. Между логическим и
физическим проектированием существует постоянная обратная связь, так как
решения, принимаемые на этапе физического проектирования с целью повышения
производительности системы, способны повлиять на структуру логической модели
данных.
Рисунок 13 – Этапы
проектирования БД
Решение проблем
проектирования на физическом уровне во многом зависит от используемой СУБД,
зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю
предоставляется возможность настройки отдельных параметров системы, которая не
составляет большой проблемы.
Логическое
проектирование заключается в определении числа и структуры таблиц, формировании
запросов к БД, определении типов отчетных документов, разработке алгоритмов
обработки информации, создании форм для ввода и редактирования данных в базе и
решении ряда других задач.
Решение задач
логического проектирования БД в основном определяется спецификой задач
предметной области. Наиболее важной здесь является проблема структуризации данных.
Методы проектирования
реляционных баз данных
Основная проблема
проектирования реляционной базы данных состоит в обоснованном принятии решений
о том, из каких отношений должна состоять БД и какие атрибуты должны быть у
этих отношений.
Для построения
«хорошей» базы данных, которая находилась хотя бы в третьей нормальной форме,
можно использовать следующие методы:
1)
Метод нормальных форм–метод
пошаговой декомпозиции, заключающийся в последовательном разбиении
исходной и промежуточных схем отношений до тех пор, пока результирующие
отношения не будут удовлетворять заданным свойствам.
2)
Метод синтеза, состоящий в конструировании
(синтезе) набора декомпозиционных подсхем, удовлетворяющих определѐнным
свойствам, из заданного множества атрибутов выбранной предметной области на
основе заданного множества функциональных зависимостей, связывающих эти
атрибуты.
3)
Метод ER-диаграмм (семантическое
моделирование) представляет собой моделирование структуры данных,
опираясь на смысл этих данных. В качестве инструмента семантического
моделирования используются различные варианты диаграмм сущность-связь (ER –
Entity-Relationship).
1.
Метод
нормальных форм (классический метод)представляет собой вариант восходящего
подхода при проектировании БД. Нормализация предусматривает
идентификацию требуемых атрибутов с последующим созданием из них
нормализованных таблиц, основанных на функциональных зависимостях между этими
атрибутами (подраздел 2.4).
Восходящий подход
в наибольшей степени приемлем для проектирования простых (как правило,
централизованных) БД с относительно небольшим количеством атрибутов. Однако
использование этого подхода существенно усложняется при проектировании
распределенных БД, особенно при интеграции локальных баз данных, которые могут
быть выполнены с использованием различных моделей данных с большим количеством
атрибутов, установить среди которых все существующие функциональные зависимости
довольно затруднительно
2.
Более
подходящей стратегией проектирования сложных баз данных является использование
нисходящего подхода (метода синтеза). Начинается этот подход с разработки
моделей данных, которые содержат несколько высокоуровневых сущностей и связей,
затем работа продолжается в виде серии нисходящих уточнений низкоуровневых
сущностей, связей и относящихся к ним атрибутов. Например, сначала можно было
бы идентифицировать сущности ВЛАДЕЛЕЦ и ОБЪЕКТ_НЕДВИЖИМОСТИ, затем установить
между ними связь ВЛАДЕЛЕЦ владеет ОБЪЕКТОМ_НЕДВИЖИМОСТИ и лишь после этого
определить связанные с ними атрибуты — например, ВЛАДЕЛЕЦ (номер_вл, имя_вл,
адрес_вл) и ОБЪЕКТ_НЕДВИЖИМОСТИ(номер_об, адрес_об).
3.
Все
варианты диаграмм сущность-связь
исходят из одной идеи – рисунок всегда нагляднее текстового описания. Все такие
диаграммы используют графическое изображение сущностей предметной области, их
свойств (атрибутов), и взаимосвязей между сущностями.
Без семантического
моделирования можно обойтись, если число таблиц не превышает десяти, но оно
совершенно необходимо, если БД включает более сотни таблиц.
В настоящее время
на рынке существует большое количество систем автоматизации проектирования баз
данных (Сomputer-Аided Software Engineering – CASE-средств), обеспечивающих
автоматизированное преобразование диаграммных концептуальных схем баз данных,
представленных в той или иной семантической модели данных, в реляционные схемы
данных конкретной СУБД (подраздел 4.1). Все CASE-системы имеют развитые
средства документирования процесса разработки, автоматические генераторы
отчетов позволяют подготовить отчет о текущем состоянии проекта с подробным
описанием объектов БД и их отношений, что существенно облегчает ведение
проекта.
Проектирование базы данных «Университет»
3.3.1
Инфологическое проектирование
Инфологическое проектирование проводится, как
правило, методом последовательных приближений к удовлетворительному набору схем
отношений. Исходной точкой является представление предметной области в виде
одного или нескольких отношений, а на каждом шаге проектирования производится
некоторый новый набор схем отношений, обладающих лучшими свойствами.
Пусть в результате
системного анализа установлена необходимость отразить в БД сведения о студентах
вуза.
При этом БД должна
содержать данные о каждом студенте: СТУДЕНТ(Номер зачетной книжки, Фамилия,
Имя, Отчество, Номер группы, Номер факультета, Наименование, Декан, Номер
специальности, Наименование специальности, Стоимость, Дата рождения, Курс,
Коммерческий).
Определим
функциональные зависимости в исходном отношении (рис. 14).
Рисунок 14 –
Функциональные зависимости в исходном отношении СТУДЕНТ
Следовательно,
инфологическая модель предметной области будет иметь вид, показанный на рис.
15.
Рисунок 15 –
Инфологическая модель предметной области
Модель содержит не
только информационные объекты, но и взаимосвязи между ними. Так, связь типа
«один ко многим» устанавливается:
•
между
объектами ГРУППА и СТУДЕНТ по их общему атрибуту Номер группы;
•
между
объектами ГРУППА и ФАКУЛЬТЕТ по их общему атрибуту
Номер
факультета;
•
между
объектами ГРУППА и СПЕЦИАЛЬНОСТЬ по их общему атрибуту Номер
специальности.
Стоит, однако,
обратить внимание на то, что полученная инфологическая модель, в целом
удовлетворяющая требованиям нормализации, с точки зрения логики может
некорректно описывать предметную область. Модель допускает существование
некоторой специальности, которая не преподается ни на одном факультете.
Естественным желанием при этом является добавление связи между объектами
ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ. Альтернативой этому может быть определение домена
для атрибута Номер специальности, который будет содержать только «существующие»
номера специальностей.
Даталогическое
проектирование
Выполняется
описание логических структур сформированных информационных объектов,
предполагаемых к реализации в базе данных. Описания приведены в табл. 2 – 5.
Таблица 2 –
Логическая структура информационного объекта СТУДЕНТ
Таблица 3 – Логическая
структура информационного объекта ГРУППА
Таблица 4 –
Логическая структура информационного объекта ФАКУЛЬТЕТ
Таблица 5 –
Логическая структура информационного объекта
СПАЦИАЛЬНОСТЬ
После описания
информационных объектов необходимо установить правила ссылочной целостности для каждой связи инфологической
модели.
Правила ссылочной
целостности
– это логические конструкции, которые выражают правила использования
взаимосвязанных данных при их добавлении, обновлении и удалении.
В ходе физической
реализации БД каждой связи будут приписаны триггеры
ссылочной целостности (RI-триггеры), которые и обеспечат установленное
правило целостности.
Триггеры – это подпрограммы,
которые запускаются всякий раз при выполнении команд вставки (INSERT), обновления(UPDATE) и удаления (DELETE).
Допустим, что
необходимо удалить один из экземпляров информационного объекта ГРУППА.
Экземпляр информационного объекта СТУДЕНТ не может существовать без
соответствующего экземпляра объекта ГРУППА. Следовательно, необходимо либо
запретить удаление группы, в которой числится хотя бы один студент, либо сразу
удалять всех студентов вместе с группой. Такие правила ссылочной целостности
называются RESTRICT и CASCADE соответственно.
В другой ситуации,
когда, например, экземпляр информационного объекта СТУДЕНТ может существовать
без ссылки на номер группы в объекте ГРУППА, при удалении какой -либо группы
информация о ней должна остаться в объекте СТУДЕНТ. Такое правило называется SET NULL. При этом значение атрибута
Номер группы объекта СТУДЕНТ принимает значение NULL.
Правило SET DEFAULT устанавливает атрибуту
значение по умолчанию. Например, при «удалении» группы все студенты, которые в
ней учились, зачисляются в другую группу (значению атрибута Номер группы
объекта СТУДЕНТ присваивается значение по умолчанию).
Наконец, правило NONE не меняет значение атрибута. При
«удалении» группы запись о ней «повисает в воздухе», т. е. экземпляр объекта
СТУДЕНТ ссылается на несуществующую уже запись о группе.
3.3.3
Физическое проектирование
Основной целью
физического проектирования базы данных является описание способа физической
реализации логического проекта базы данных, т.е. реализации базы данных на
вторичных запоминающих устройствах. На этом этапе рассматриваются основные
отношения, организация файлов и индексов, предназначенных для обеспечения
эффективного доступа к данным, а также все связанные с этим ограничения
целостности и средства защиты.
Физическое
проектирование неразрывно связано с конкретной СУБД. Между логическим и
физическим проектированием существует постоянная обратная связь, так как
решения, принимаемые на этапе физического проектирования с целью повышения
производительности системы, способны повлиять на структуру логической модели
данных.
Комментарии
Отправить комментарий