Экзаменационный билет № 9

Семантическая модель. Логическое проектирование реляционной БД.

• Формализованное описание концептуальной схемы банка данных осуществляется средствами одной их семантических моделей данных

• В большинстве случаев семантические модели применяются на стадии концептуального проектирования с последующим преобразованием концептуальной схемы в структуру соответствующей БД

• Наиболее известные семантические модели:

  • ER-модели – диаграммы Бахмана

  • UML- диаграммы классов

• Модель «сущность - связь» или «Entity Relationship»

• Предложена Пин-Шен-Ченом в 1976

• Фактически стандарт при инфологическом моделировании

• Существует множество CASE-средств (в том числе позволяющих осуществить автоматическое преобразование ER-модели в реляционную)

• Используются различные графические нотации

• Базовые понятия: сущность, атрибуты, ключевые атрибуты, связи

• При проектировании схемы реляционной БД можно выделить такую последовательность процедур:

  • определение перечня таблиц и их связей

  • определение перечня полей, типов полей, ключевых полей таблиц, установление связей между таблицами через внешние ключи

  • разработка списков (словарей) для полей с перечислимым характером значений данных

  • определение и установление индексов для полей таблиц

  • установление ограничений целостности по полям таблиц и связям

  • нормализация таблиц, доработка перечня таблиц и их связей

• Первые три процедуры называют процессом предварительного проектирования таблиц и связей между ними

• Для каждого объекта-сущности в реляционных СУБД проектируют соответствующую таблицу

• Поля таблиц соответствуют атрибутам информационных объектов концептуальной схемы

• Для каждого поля необходимо определить:

  • Тип поля

  • Словарь (для перечислимых полей)

  • Ключ

  • Внешний ключ

  • Ограничения целостности

  • Наличие индекса

• Понятие типа поля в СУБД = тип в Языке Программирования

• Традиционно поддерживаемые СУБД простые типы:

  • числовой

  • символьный

  • темпоральный (дата/время)

  • булевский (логический)

• Современные СУБД поддерживают специализированные типы полей

  • Денежный, OLE, MEMO и др.

• Домен ≠ тип!

• Домен – подмножество базисного типа данных с определенной смысловой нагрузкой

• Пример: множество всех имен из множества всевозможных значений символьного типа

• Важное значение имеет выделение полей с перечислимым (перечислительным, словарным, списковым) характером значений

• Значения таких полей определяются из некоторого унифицированного списка-словаря

• Словари (списки):

  • фиксированные

    • «привязываются» к соответствующим полям БД и размещаются в каталоге БД

  • динамические

    • реализуются через создание дополнительных таблиц

• Требование уникальности кортежей Þ определение и установление ключевых полей таблиц реляционных СУБД

• Определение ключевого поля выполняется на основе смыслового эвристического анализа тематики таблицы + принцип минимальной достаточности Þ количество полей, образующих ключ таблицы, должно быть минимальным

• Часто как ключевые поля используются поля типа «AUTOINCREMENT» (Счетчик)

• Ограничения по значениям полей

  • уникальность значений ключевых полей

  • UNIQUE

  • NOT NULL

  • допустимые диапазоны значений полей

  • относительные соотношения значений по полям таблицы

  • внешние ключи – межтабличные ссылки

• Ограничения целостности данных отражают правила и особенности предметной области (бизнес-правила)

• Три подхода реализации требования целостности по ссылкам:

  • запрет удаления записи, если на нее существуют ссылки из других таблиц

  • при удалении записи значения внешних ключей всех связанных записей становятся неопределенными

  • каскадное удаление всех записей, связанных с удаляемой

• Важный момент проектирования таблиц – определение необходимости индексирования тех или иных полей таблиц

• Индексируются те поля, по которым чаще всего производится поиск

• Ключевые поля индексируются автоматически

• Если в одной таблице установлено более 10 индексов, то недостаточно продумана структура БД (таблицы)

• внутреннее устройство индексных массивов обычно остается скрытым и для пользователей и для разработчиков

ЭКЗАМЕНАЦИОННЫЙ БИЛЕТ № 10

Корректная схема БД. Нормализация таблиц. Первая и вторая нормальные формы.

• Задача логического проектирования – разработать корректную схему БД

• Корректной назовем схему БД, в которой отсутствуют нежелательные зависимости между атрибутами отношений (требования атомарности значений полей, требования рациональности группировки полей-атрибутов по различным таблицам)

• Классическая технология проектирования реляционных БД связана с теорией нормализации

• Нормализация таблиц – последовательная доработка концептуальной схемы данных, на каждом шаге доработки схема соответствует нормальной форме более высокого уровня

• В теории реляционных БД выделяется следующая последовательность:

  • Первая нормальная форма (1NF)

  • Вторая нормальная форма (2NF)

  • Третья нормальная форма (3NF)

  • Нормальная форма Бойса-Кодда (BCNF)

  • Четвертая нормальная форма (4NF)

  • Пятая нормальная форма (5NF)

• Наиболее простая – первая нормальная форма = требование атомарности полей и единственности значений по полям в реляционной модели

• Отношение находится в первой нормальной форме тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов

• Отношения (таблицы), находящиеся в первой нормальной форме, часто называют просто нормализованными отношениями

• Таблицы в первой нормальной форме могут содержать:

  • ситуации дублирования данных

  • аномалии схемы таблиц-отношений

• Е. Кодд разработал механизм разбиения таблиц для приведения к более совершенным нормальным формам – функциональная зависимость полей-атрибутов

• Поле-атрибут Y функционально зависит от поля атрибута X, если любому значению X всегда соответствует одно и только одно значение Y

В первой нормальной форме все неключевые атрибуты функционально зависят от ключа таблицы

• Вторая нормальная форма основана на понятии полной функциональной зависимости

• Функциональная зависимость неключевого атрибута от составного ключа называется полной, если он зависит от составного ключа в целом, но не зависит от любой его части

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

• В таблицах, находящихся во второй нормальной форме большинство аномалий, присущих первой нормальной форме, устранено

• Вместе с тем, могут сохраниться ситуации дублирования данных - транзитивная зависимость атрибутов

• Отношение находится в третьей нормальной форме тогда и только тогда, когда оно находится во второй нормальной форме и не содержит транзитивных зависимостей

• Третья нормальная форма = взаимная независимость неключевых атрибутов и их полная функциональная зависимость от первичного ключа

• Третья нормальная форма устраняет:

  • большинство аномалий схем таблиц-отношений

  • ситуации дублирования данных

• Существуют также четвертая и пятая нормальные формы, которые связаны с многозначной зависимостью атрибутов

• Обычно ограничиваются третьей нормальной формой и BCNF

• Нормализация исходных таблиц при проектировании БД проводится для рационализации группировки полей-атрибутов в схемах таблиц с целью устранения аномалий и дублирования данных

• Нормализация = декомпозиция исходных таблиц на множество связанных и не связанных более простых таблиц Þ при обработке данных выполняется множество операций соединения таблиц