Бази даних та знань
лекція 2
Введення у проектування БД
Проектування БД
Процесс создания схемы базы данных и определения
необходимых ограничений целостности.
Особливості концептуального
проектування
Життєвий цикл БД
Як і будь-який програмний продукт, база даних має власний
життєвий цикл (ЖЦБД).
Головною складовою частиною в життєвому циклі БД є створення
єдиної бази даних і програм, необхідних для її роботи.
ЖЦБД включає наступні основні етапи:
Планування
розробки БД
Визначння вимог
до системи
Збір та аналіз вимог
користувачів
Реалізація
Розробка
додатків
Проектування БД
Конвертування
та завантаження
даних
Тестування
Експлуатація та
супровід
Життєвий цикл БД
1.
2.
3.
4.
5.
6.
7.
8.
9.
Планування розробки бази даних;
Визначення вимог до системи;
Збір та аналіз вимог користувачів;
Проектування бази даних:
• концептуальне проектування бази даних;
• логічне проектування бази даних;
• фізичне проектування бази даних;
Розробка додатків:
• проектування транзакцій;
• проектування інтерфейсу користувача;
Реалізація;
Завантаження даних;
Тестування;
Експлуатація та супровід:
• аналіз функціонування та підтримка вихідного варіанти БД;
• адаптація, модернізація та підтримка дороблених варіантів.
Проектирования БД
Процесс проектирования БД представляет собой
последовательность переходов от неформального словесного
описания информационной структуры предметной области к
формализованному описанию объектов предметной области в
терминах некоторой модели.
Можно выделить следующие этапы проектирования базы
данных.
 системный анализ предметной области;
 инфологическое (концептуальное) проектирование;
 выбор СУБД;
 даталогическое проектирование (логическое
проектирование).
Етапи проектування БД
Інфологічне проектування
Концептуальное проектирование
базы данных
Первая фаза процесса проектирования базы данных заключается в
создании для анализируемой части предприятия концептуальной
модели данных.
Проектирование сложных баз данных с большим количеством
атрибутов осуществляется с использованием, так называемого,
нисходящего подхода.
Этот подход начинается с разработки моделей данных, которые
содержат несколько высокоуровневых сущностей и связей, затем
работа продолжается в виде серии нисходящих уточнений
низкоуровневых сущностей, связей и относящихся к ним атрибутов.
Нисходящий подход демонстрируется в концепции модели
"сущность — связь" (Entity-Relationship model — ER-модель) — самой
популярной технологии высокоуровневого моделирования данных,
предложенной П. Ченом.
В построении общей концептуальной модели данных выделяют ряд
этапов.
• Выделение локальных представлений, соответствующих обычно
относительно независимым данным. Каждое такое представление
проектируется как подзадача.
• Формулирование сущностей, описывающих локальную
предметную область проектируемой БД, и описание атрибутов,
составляющих структуру каждой сущности.
• Выделение ключевых атрибутов.
• Спецификация связей между сущностями. Удаление избыточных
связей.
• Анализ и добавление неключевых атрибутов.
• Объединение локальных представлений.
Созданная концептуальная модель данных предприятия является
источником информации для фазы логического проектирования базы
данных.
Концептуальное проектирование
базы данных
Главными элементами семантической модели данных
являются сущности, их атрибуты и типы связей.
Сущности часто представляют в виде существительных,
а типы связей — в виде глаголов.
Семантическая модель предметной области
изображается в виде диаграммы с учетом принятых
обозначений для ее элементов.
Сутності (objects)
У БД повинні зберігатися дані, логічно пов'язані між собою.
Для того, щоб дані можна було зв'язати між собою, і зв'язати так, щоб ці
зв'язки відповідали реально існуючим у даній предметній галузі,
останню піддають детальному аналізу, виділяючи сутності або об'єкти.
Сутність або об'єкт - це те, про що необхідно зберігати інформацію.
Сутність
Ім’я сутності
ВИКЛАДАЧ
викладач
Екземпляр сутності
Каждая сущность имеет имя и изображается на диаграммах в виде
прямоугольника, а экземпляр сущности — в виде точки в прямоугольнике
данной сущности.
Атрибути
Сутності мають деякі характеристики, вони називаються атрибутами,
які теж необхідно зберігати у БД.
Атрибути за своєю внутрішньою структурою можуть бути простими,
а можуть бути складними.
Прості атрибути можуть бути представлені простими типами даних.
Різного роду графічні зображення, які є атрибутами сутностей - це
приклад складного атрибуту.
кількість
код_товару
ТОВАР
найменування_товару
вартість_товару
Зв'язки
Визначивши сутності та їх атрибути, необхідно перейти до
виявлення зв'язків, які можуть бути між деякими сутностями.
Зв'язок- це те, що поєднує дві чи більше сутностей.
Зв'язки між сутностями також є частиною даних і вони також
повинні зберігатися у базі даних.
ВИКЛАДАЧ
M
ЧИТАЄ
N
КУРС
В связи могут участвовать не две, а большее количество сущностей,
которые в данном случае являются участниками этой связи.
Количество участников некоторой связи называется степенью связи.
В подавляющем числе случаев проектирования БД можно
ограничиться рассмотрением бинарных связей.
Потужність Зв'язку
Мощность обозначает максимальное количество экземпляров одной
сущности, связанных с одним экземпляром другой сущности.
Например, если допустить, что у человека может быть только один
супруг, то мощность связи ЖЕНАТЫ будет равна одному в каждом
направлении.
Иногда помимо максимальной мощности полезно определять и
минимальную мощность. В рассматриваемом примере не исключаются
одинокие мужчины и женщины, поэтому минимальная мощность
равнанулю в каждом направлении.
Такая ситуация может быть обозначена следующим образом:
ЧОЛОВІК
0..1
ШЛЮБ
0..1
ЖІНКА
Показатель кардинальности
Для того чтобы указать количество возможных связей для
каждого экземпляра участвующего в связи сущности, используют
показатель кардинальности.
Для бинарных связей показатель кардинальности может иметь
следующие значения:
"один к одному"
( 1:1 )
"один ко многим“
( 1:N )
"многие ко многим“ ( М : N )
Если максимальная мощность связи в обоих направлениях равна
одному, мы называем ее связью "один к одному" (1 : 1).
Например, на факультете может быть один декан, и обратно, один
и тот же декан может руководить только одним факультетом, что
может быть обозначено следующим образом:
ФАКУЛЬТЕТ <-----> ДЕКАН
Показатель кардинальности
Если максимальная мощность в
одном направлении равна одному,
а в другом — многим, то связь
называется:
"один ко многим" (1 : N).
Например, в группе учится много
студентов, но каждый студент
учится только в одной группе:
ГРУППА <----->> СТУДЕНТ
Зв’язки
 один-до-одного (1:1)
 багато-до-одного (M:1)
 багато-до-багатьох (M:N)
1
КУРС
ЧИТАЄ
N
КУРС
ЧИТАЄ
M
КУРС
ВИКЛАДАЧ
1
ЧИТАЄ
ВИКЛАДАЧ
1
ВИКЛАДАЧ
N
Якщо все це, а саме:
сутності,
атрибути сутностей та
зв'язку між сутностями виявлені,
то концептуальна схема бази даних
може виглядати приблизно так:
шість сутностей, які зображені
прямокутниками, кожен з яких
має свої атрибути
п'ять зв'язків, які позначені
стрілками та пов'язують ті
сутності, на які вони спрямовані:
ER– Діаграма
(Entity-Relationship)
З представленої діаграми бачимо, що дані мають
певну структуру.
Для виявлення цієї структури база даних повинна
пройти процес проектування.
Супертип и подтип
Для удовлетворения новых требований, выдвигаемых все более
усложняющимися приложениями, в семантическое моделирование
были введены дополнительные концепции, расширяющие его
возможности.
Дополнительные концепции базируются на таких понятиях, как
супертип и подтип, а также используют процесс наследования
атрибутов.
Супертип — это сущность, включающая разные подтипы, которые
необходимо представить в модели данных.
Подтип — это сущность, являющаяся членом супертипа, но
выполняющая отдельную роль в нем.
Супертип и подтип
Супертип может иметь несколько разных подтипов.
Так, например, подтипы:
АССИСТЕНТ, СТАРШИЙ ПРЕПОДАВАТЕЛЬ, ДОЦЕНТ, ПРОФЕССОР
являются членами супертипа ПРЕПОДАВАТЕЛЬ.
Это означает, что каждый экземпляр подтипа является в то же
время и экземпляром супертипа. Связь между супертипом и
подтипом относится к типу "один к одному".
Использование понятий супертипа и подтипов позволяет при
моделировании выделить для подтипа свои собственные атрибуты
и атрибуты, наследуемые им от супертипа.
Супертип и подтип
На каждой линии, идущей от подтипа, располагается
U-образный символ, который обозначает направление
включения. Верхняя часть U "открывается" в сторону
супертипа.
Внутри кружка располагается буква D, если подтипы не пересекаются, и
буква О — для пересекающихся подтипов. В последнем случае экземпляр
супертипа может быть членом сразу нескольких подтипов. Изображенная
на диаграмме ситуация исключает пересечение подтипов, поэтому в
кружок помещен символ D
Логічне проектування
Проектирование реляционной БД
(перехід від концептуальної моделі до реляційної моделі даних)
Концептуальна модель даних складається з низки компонентів:
сутностей, зв'язків, атрибутів.
При переході до реляційної схеми бази даних кожен із цих компонентів
має бути проаналізований і якщо це виявиться необхідним, то навіть
перетворений. Зміни, що вносяться в процесі перетворення, повинні
бути такими, щоб їх результат повністю відповідав вимогам реляційної
моделі даних.
Таким чином, фаза логічного проектування передбачає наступні дії:
• перетворення концептуальної моделі даних на логічну модель, в
результаті якого буде визначено схему реляційної моделі даних;
• перевірка моделі за допомогою концепцій послідовної
нормалізації;
• перевірка підтримки цілісності даних.
Концептуальная
модель для примера
ВИКЛАДАЧ
1
*
ЧИТАЄ
*
1
КУРС
код_викладача
код_викладача
код_курсу
ПІБ
код_курсу
назва
вчене_звання
вчений_ступень
кількість_годин
Реляционная схема базы данных для примера
Предварительные отношения для бинарных
связей типа 1:1
1
ЧОЛОВІК
1
PK
ПІБ
passport (UNIQUE)
1
Іванов
ІВ-47637
М
ВА-68543
2
Петров
ПЕ-57895
М
ФЕ-00012
3
Фєйгіна
ФЕ-00012
Ж
ПЕ-57895
4
Сідоров
СИ-54738
М
null
5
Вакуленко
ВА-68543
Ж
ІВ-47637
ШЛЮБ
ЖІНКА
стать spouse_passport (UNIQUE)
Предварительные отношения для бинарных
связей типа 1:N
СТУДЕНТ
N
ВЧИТЬСЯ
Child Relation
1
ГРУПА
Parent Relation
Предварительные отношения для бинарных
связей типа M:N
ВИКЛАДАЧ
ВИКЛАДАЧ
ПІБ
Посада
M
N
ЧИТАЄ
ВИКЛАДАЧ_КУРС
КУРС
КУРС
таб_ном
таб_н
к_ід
ід
назва
Любченко
асс
11-22
11-22
2
1
фізіка
Сідоров
доц
33-44
33-44
3
2
хімія
Іванов
ст.вик
55-66
33-44
4
3
математика
Петров
проф
77-88
55-66
1
4
інформатика
55-66
2
Отношения реляционной базы данных в зависимости от содержания
подразделяются на два класса:
• объектные отношения
• связные отношения
Объектные отношения хранят данные о группах одно- родных
объектов, явлений или процессов, имеющих однотип- ные
характеристики. В объектном отношении ключ называют
первичным, или просто ключом отношения.
Связное отношение хранит данные о связях между объ- ектными
отношениями. Связное отношение содержит ключи связанных
объектных отношений и данные, количественно или качественно
характеризующие связь. Ключи связных отноше- ний называют
внешними ключами, поскольку они являются первичными ключами
других отношений.
Реляційна модель даних
Відношення має дві основні властивості:
1. У відношенні не повинно бути однакових кортежів, так як це множина.
2. Порядок кортежей у відношенні невизначений.
Кількість рядків у таблиці (кортежів у відношенні) називається
потужністю відношення, кількість стовпців (атрибутів) – арністю.
Визначення термінів
Следующие наборы терминов эквивалентны:
• отношение, таблица, файл
• кортеж, строка, запись
• атрибут, ячейка, поле
Поименованный список имен атрибутов отношения называют
схемой отношения.
Пример схемы:
Детали (Номер детали, Название детали, Вид обработки, Вес)
Ключевой атрибут в схеме отношения подчеркивают.
Совокупность схем отношений, используемых для представления
информации, называется схемой реляционной базы данных.
Визначення термінів
Число столбцов в отношении называют степенью або арністю.
Текущее число кортежей в отношении называют мощностью.
Степень отношения обычно не изменяется после создания
отношения, но мощность будет колебаться по мере добавления
новых и удаления старых кортежей.
Реляционная база данных – это совокупность отношений,
содержащих всю информацию, которая должна храниться в базе
данных.
Ключові атрибути відношення
Каждое отношение имеет ключ.
Ключ (первичный ключ, ключ отношения, ключевой атрибут) – это
атрибут или группа атрибутов, которые позволяют однозначно
идентифицировать кортеж в отношении.
Если ключ составной (состоит из двух и более атрибутов), то он
должен быть минимальным. Это значит, что если один
произвольный атрибут исключить из составного ключа, оставшихся
атрибутов будет недостаточно для однозначной идентификации
отдельных кортежей.
Возможны случаи, когда отношение имеет несколько комбинаций
атрибутов, каждая из которых однозначно опреде- ляет все кортежи
отношения. Все эти комбинации атрибутов
являются возможными ключами отношения.
Любой из возможных ключей может быть выбран как первичный.
Ключи обычно используют для достижения следующих целей:
• исключения дублирования значений в ключевых атрибутах;
упорядочения кортежей;
• ускорения работы с кортежами отношения;
• организации связывания таблиц.
Пусть в отношении R1 имеется не ключевой атрибут А, значения которого
являются значениями ключевого атрибута В другого отношения R2. Тогда
говорят, что атрибут А отношения R1 (атрибут В отношения R2) есть
внешний ключ.
С помощью внешних ключей устанавливаются связи между отношениями.
Реляционная модель накладывает на внешние ключи ограничение,
называемое ссылочной целостностью. Это означает, что каждому
значению внешнего ключа должен соответствовать кортеж объектного
отношения. Без этого возможна ситуация, когда внешний ключ ссылается
на объект, о котором ничего не известно.
Первинний ключ (primary key)
Логічна модель БД
ER – Діаграма
(Entity-Relationship)
Проверка модели
с помощью концепций
последовательной нормализации
Надмірність даних
Надмірність даних в базі даних відноситься до небажаних явищ, тому
що це збільшує обсяг пам'яті, необхідний для фізичного зберігання
відносин.
Надмірність є результатом, перш за все, дублюванням даних.
Ось типовий приклад відношення, що містить небажану надмірність:
СТУДЕНТ
Ном_зач_кн
ФІО_студента
Код_группи
ФІО_старости
Куратор
20-Т-201
Іванов С.И.
20-Т-11
Рябов В.С.
доц. Фок І.І.
20-Т-215
Петров Я.Р.
20-Т-12
Сізов М.М.
доц. Докин С.С.
20-Т-217
Рябов В.С
20-Т-11
Рябов В.С.
доц. Фок І.І.
20-Т-211
Сєнова А.Л.
20-Т-11
Рябов В.С.
доц. Фок І.І.
Надмірність даних
У даному відношенні первинний ключ Ном_зач_кн в кожному
кортежі про кожного учня з однієї групи повторюється інформація
про ідентифікатор групи, старости та куратора.
Під час роботи з відношеннями, які містять надлишкові дані
можуть виникнути проблеми, які називаються аномаліями
оновлення.
Розрізняють три типи аномалій:
• аномалії включення;
• аномалії видалення;
• аномалії модифікації.
Аномалії включення
У наведеному вище відношенні аномалії включення виникають
при спробі створити нову групу і ввести її у відношення при той
умові, що до неї ще не зараховано жодного студента.
Введення такої інформації у подібній ситуації вимагає надання
значення NULL всім атрибутам опису студента, в тому числі і
атрибуту Ном_зач_кн, який є первинним ключем цього
відношення.
Реалізація такої спроби призведе до порушення категоріальної
цілісності, отже, система її має відхилити.
Результатом аналізу є висновок того, що у відношенні присутні
аномалії включення, отже, це відношення має бути перетворено
таким чином, щоб їх позбутися (наступний слайд).
Аномалії включення
СТУДЕНТ
ном_зач_кн
ПІБ_студента
Код_группи
20-Т-201
Іванов С.И.
20-Т-11
20-Т-215
Петров Я.Р.
20-Т-12
20-Т-217
Рябов В.С
20-Т-11
20-Т-211
Сєнова А.Л.
20-Т-11
Декомпозиція на два окремих
відношення як вирішення
проблеми.
ГРУПА
Код_группи
ПІБ_старости
Куратор
20-Т-11
Рябов В.С.
доц. Фок І.І.
20-Т-12
Сізов М.М.
доц. Докин С.С.
Аномалії видалення
Повернемося до аналізу відношення, поданого на слайді 15.
При видалення з цього відношення кортежу:
20-Т-215 Петров Я.Р. 20-T-12 Сізов М.М. доц. Докін С.С.
з бази даних буде видалено всі відомості про групу 20-Т-12.
Така ситуація є аномалію видалення.
Для виключення з бази даних аномалії видалення це
відношення має бути перетворено.
Причому перетворення має бути проведено таке ж саме, як
було проведено для виключення аномалії включення.
Аномаліі модифікаціі
Така аномалія виникає при спробі змінити щось щодо відомостей
про групу навчання студента. Припустимо, що у групі 20-Т-11
вирішили призначити нового старосту, наприклад Сєнову А.Л.
У такій ситуації необхідно переглянути всі кортежі відношення та
у кожному кортежі значення атрибуту ПІБ_старости замінити
Рябов В.С. на Сєнова А.Л.
Поява аномалії модифікації можна заблокувати, якщо знову
ж вдатися до перетворення відношення зі слайду 15.
Ці перетворення точно такі ж, які були використані для
виключення аномалій включення та видалення.
Справді, зміна старости групи потребують зміни значення
атрибуту ПІБ_старости лише в одному кортежі відношення на
слайді 18.
Нормалізация відношень
Для усунення розглянутих вище недоліків і застосовується
процес нормалізації відношень.
Цей процес — це формальний метод аналізу відношень на основі
їх первинних чи потенційних ключів та існуючих функціональних
залежностей.
Він включає ряд формальних правил, що використовуються для
перевірки всіх відношень бази даних.
Розрізняють:
• 1НФ - першу нормальну форму;
• 2НФ - другу нормальну форму;
• ЗНФ - третю нормальну форму;
• НФБК — нормальну форму Бойса — Кодда;
• 4НФ - четверту нормальну форму;
• 5НФ - п'яту нормальну форму.
Довідник користувача
1-ша нормальна форма
1-ша нормальна форма
СТУДЕНТ
ном_зач_кн
ПІБ_студента
Код_группи
20-Т-201
Іванов С.И.
20-Т-11
20-Т-215
Петров Я.Р.
20-Т-12
20-Т-217
Рябов В.С
20-Т-11
20-Т-211
Сєнова А.Л.
20-Т-11
ГРУПА
код_группи
Отношение находится в 1НФ,
если все его атрибуты имеют
простые (атомарные) значения.
ПІБ_старости
Куратор
20-Т-11
Рябов В.С.
доц. Фок І.І.
20-Т-12
Сізов М.М.
доц. Докин С.С.
СТУДЕНТ
Ном_зач_кн
1-ша нормальна форма
ПІБ_студента
Код_группи
20-Т-201
Іванов С.И.
20-Т-11
20-Т-215
Петров Я.Р.
20-Т-12
20-Т-217
Рябов В.С
20-Т-11
20-Т-211
Сєнова А.Л.
20-Т-11
КУРАТОР
ГРУПА
Код_группи
Вирішення проблемі:
декомпозиція відношення
ПІБ_старости Куратор_id
id
ПІБ_викл
Посада
1
Фок І.І.
доц
20-Т-11
Рябов В.С.
(1)
2
Докин С.С.
доц
20-Т-12
Сізов М.М.
(2)
Функціональні залежності
Функціональна залежність визначається для атрибутів,
що знаходяться в тому самому відношенні в 1НФ. Функціональна
залежність є семантичною властивістю атрибутів відношення.
Нехай дана схема відношення: R(А1, А2, ...., Аn).
Атрибут А2 функціонально залежить від атрибуту А1 якщо кожному
значенню А1 відповідає єдине значення А2 (тобто кожен кортеж, що має
одне і те ж значення А1, повинен мати те саме значення А2)
Позначається така ситуація так: А1→А2.
Ліва частина функціональної залежності називається детермінантом, а
права частина - залежною частиною.
Відсутність функціональної залежності позначається так: А-/→ В.
Розглянута вище функціональна залежність називається F-залежністю.
Друга нормальна форма
Друга та третя нормальні форми виникли в результаті
прагнення уникнути аномалій оновлення даних під час
роботи з БД і позбутися від інформаційної надмірності у
відношеннях.
Друга нормальна форма застосовується до відношень зі
складовими ключами, тобто до таких відношень , первинний
ключ яких складається з двох або більше атрибутів.
Відношення, у якого первинний ключ включає лише один
атрибут, завжди знаходиться у 2НФ.
Друга нормальнаформа
Отже, схема відношення R знаходиться у 2НФ, якщо
воно знаходиться у 1НФ, і кожен непервинний атрибут
функціонально-повно залежить від первинного ключа.
Розглянемо відношення КОНСУЛЬТАЦІЇ_ДИПЛОМНИКІВ з наступною
схемою:
ПІБ_викл
Посада
ПІБ_студ
Тема
диплому
Час
Аудит
орія
Мі
20-Т-201 11.11.22
Лісіцин А.О.
доц
Котов А.М.
тема 1
14:00
34б
15
20-Т-217 11.11.22
Голіков Т.В.
ас
Сидоров В.А.
тема 2
15:00
33
40
но
икл
ном_зал
_кн
233
244
дата
Позначимо основні залежності цього відношення:
(Таб_Ном_викл, Ном_зал_кн, Дата) →
(ПІБ_викл, Посада, ПІБ_студ, Тема_діплому, Час, Аудиторія, Місткість)
Друга нормальна форма
Описові атрибути викладача ПІБ_викл, Посада залежать лише від
частини первинного ключа. Дану ситуацію визначає залежність:
Таб-Ном_преп → (ПІБ_викл, Посада)
Описові атрибути студента ПІБ_студ, Тема диплому також залежать
тільки від частини первинного ключа і не залежать від решти атрибутів
ключа, тобто є залежність виду:
Ном_зач_кн → (ПІБ_студ, Тема_диплому)
Відсутність повної функціональної залежності кожного непервинного
атрибуту відношення від первинного ключа є джерелом аномалій
оновлення та вносить свою частку надмірності до бази даних.
Усунення даних негативних явищ здійснюється шляхом декомпозиції
вихідного відношення на три нових з наступними схемами:
(наступний слайд)
Друга нормальна форма
СТУДЕНТ
ном_зал_кн
ПІБ_студ
Тема_диплому
20-Т-201
Котов А.М.
тема 1
20-Т-217
Сидоров В.А. тема 2
ВИКЛАДАЧ
таб_ном_викл
ПІБ_викл
Посада
112233
Лісіцин А.О.
доц
112244
Голіков Т.В.
ас
Вирішення проблемі:
декомпозиція відношення
КОНСУЛЬТАЦІЇ
таб_ном_викл
ном_зал_кн
дата
Час
Аудиторія
Місткість
112233
20-Т-201
11.11.22
14:00
34б
15
112244
20-Т-217
11.11.22
15:00
33
40
Третя нормальна форма
Розглянемо транзитивну залежність наступного типу:
якщо А → В, В -/→ А (В не є ключом),
В → С, то А → С.
У цьому випадку вважається, що С транзитивно залежить від А.
Транзитивна залежність викликана наявністю у відношенні двох
семантичних залежностей різних типів.
Схема відношення знаходиться у третій нормальній формі щодо безлічі
функціональних залежностей F, якщо вона знаходитьсяв 1НФ і жоден з
непервинних атрибутів R не є транзитивно-залежним від ключа для R.
Схема всієї БД знаходиться в 3НФ щодо F, якщо кожна схема
віднршення перебуває у 3НФ щодо F.
Розглянемо схему бази даних з попереднього прикладу:
(попередній слайд)
Третя нормальна форма
Останнє відношення містить транзитивну залежність:
(Таб_Ном_викл, Ном_зал_кн, Дата) → Аудиторія → Місткість.
Отже, це відношення не перебуває у 3НФ з усіма наслідками, що
випливають з цього, насам перед, наступними:
• якщо аудиторія виключається з розкладу консультацій, то про
неї взагалі губляться усі відомості;
• якщо аудиторію перебудовано і в результаті змінилася її
місткість, то доведеться переглянути всі кортежі та провести
модифікацію значень атрибуту.
Для усунення транзитивної залежності необхідно провести
декомпозицію останнього відношення, вилучивши з нього
транзитивно-залежний атрибут і помістивши його у нове
відношення разом з копією того атрибута, від якого є залежить.
Третя нормальна форма
ВИКОАДАЧ
таб_ном_викл ПІБ_викл
АУДИТОРІЯ
Аудиторія
Посада
Місткість
112233
Лісіцин А.О.
доц
34б
15
112244
Голіков Т.В.
ас
33
40
КОНСУЛЬТАЦІЇ
таб_ном_викл
ном_зал_кн дата
Час
Аудиторія
112233
20-Т-201
11.11.22
14:00
34б
112244
20-Т-217
11.11.22
15:00
33
СТУДЕНТ
ном_зал_кн
ПІБ_студ
Тема_диплому
20-Т-201
Котов А.М.
тема 1
20-Т-217
Сидоров В.А.
тема 2
Третя нормальна форма
Під час проектування структури реляційної бази даних
вважається коректною установка, що будь-яка БД
повинна бути як мінімум у 3НФ.
на практиці третя нормальна форма схем відношень
достатня у більшості випадків, та з приведенням до
третьої нормальної формі процес проектування
реляційної бази даних зазвичай закінчується.
Нормальна форма Бойса - Кодда
Слід зазначити, що визначення для 3НФ було надано Коддом для
ситуацій зі спрощуючим картину припущенням того, що відношення
має тільки один потенційний ключ, який, природно, і є первинним
ключем.
Природно, що не всі відношення можуть бути укладені у такі досить
жорсткі рамки. Більше узагальнюючими є випадки, коли є такі умови:
• відношення має два (або більше) потенційні ключі;
• два потенційні ключі є складовими;
• два потенційні ключі перекриваються, тобто мають, як найменьш,
один загальний атрибут.
Схема відношення R знаходиться в НФБК щодо безлічі F- залежностей
тоді і тільки тоді, коли детермінанти є потенційними ключами.
Нормальная форма Бойса — Кодда
Припустимо, що при проектуванні бази даних ПОСТАВКИ_ТОВАРІВ
розглядається таке відношення:
ПОСТАВКА
Iндекс_постач
Iм'я_постач
Iндекс_товару
Кільк_товару
1
Агромол
М23
4
Припустимо також, що значення атрибуту Ім'я_постач унікальні
та можуть бути використані поряд з атрибутом Індекс_постач
для ідентифікації постачальника. У такій ситуації можна виділити
два складових потенційних ключа:
(Індекс постачання, Індекс_товару)
(Ім'я_постач, Індекс_товару)
У такому випадку є два атрибути - Індекс_постач та Ім'я_постач,
які ідентифікують один і той же кземпляр сутності, отже, вони
визначають один одного.
Нормальная форма Бойса — Кодда
У такому випадку відношення містить два детермінанти, але ці
детермінанти не є потенційними ключами відношення. Така
картина суперечить визначенню НФБК, і, отже, дане відношення
не знаходиться в НФБК.
Схема відношення R знаходиться в НФБК щодо безлічі
F-залежностей тоді і лише тоді, коли детермінанти є
потенційними ключами.
Для прикладу розв'язання проблеми можна здійснити, розбивши
вихідне відношення на два. При чому оскільки два детермінанти
Індекс_постач та Ім'я_постач визначають один одного, то можливі
два рівноцінні варіанти декомпозиції які призводять до НФБК.
Нормальная форма Бойса — Кодда
Перший варіант реалізується, якщо враховується залежність:
Індекс_постач → Ім'я_постач
Індекс_постач
Індекс_товару
Кільк_товару
Індекс_постач
Ім'я_постач
1
М23
4
1
Агромол
Другий варіант виходить із залежності:
Ім'я_постач → Індекс_постач
Ім'я_постач
Індекс_товару
Кільк_товару
Індекс_постач
Ім'я_постач
Агромол
М23
4
1
Агромол
Четвертая нормальная форма
Отже, НФБК дозволяє усунути будь-які аномалії оновлення, викликані
функціональними залежностями. Розглянемо таку схему відношення НДР:
Номер_НДР
Співроб
Завдання_НДР
111
Ставков
завдання 1
111
Фудіна
завдання 2
222
Ставков
завдання 1
222
Тіпасков
завдання 2
222
завдання 3
Відношення НДР містить:
• номери тем науково-дослідних робіт,
• для кожної теми – список співробітників, які можуть виконувати
роботи з теми, та список завдань теми.
Співробітники можуть брати участь у кількох темах, та різні теми
можуть включати однакові завдання.
У такій ситуації єдиним можливим ключем відношення може бути
складовий атрибут: (Номер_НДР, Співроб, Завдання_НДР)
Четвертая нормальная форма
Це відношення характеризується значною надмірністю та наводить до
виникнення аномалій оновлення. Всі розглянуті до цього часу прийоми
нормалізації, що спираються на функціональні залежності, виявляються
непридатними, оскільки цих залежностей у відношенні просто немає.
У 1971 році Фейгін запропонував суворо теоретично обґрунтований
вихід з цієї ситуації за допомогою поняття багатозначною залежності
(МОЗ).
Визначимо формально умову існування багатозначної залежності:
багатозначна залежність має місце у тому відношенні, в якому
міститься два незалежні зв'язки типу 1:М.
І всі проблеми даної ситуації викликані саме цією незалежністю зв'язків.
Четвертая нормальная форма
У відношенні R(A, В, С) існує багатозначна залежність А→ В в тому і тільки в
тому випадку, якщо безліч значень В, яке відповідає парі значень А та С
залежить тільки від А і незалежитьвід С.
У відношенні НДР існують дві такі багатозначні залежності:
Номер_НДР ->> Співроб
Номер_НДР ->> Завдання_НДР
Багатозначні залежності завжди утворюють пов'язані пари та тому їх
зазвичай представляють разом у символьному вигляді як:
А ->> B | C.
Подальша нормалізація таких відношень має відбуватися шляхом поділу
двох незалежних груп що повторюються.
Цей поділ ґрунтується на наступній теоремі Фейгіна.
Четвертая нормальная форма
Відношення R (А, В, C) можна спроектувати без втрат у відношення
R1 (А, В) та R2 (А, С)
тоді і тільки тоді, коли для відношення R виконується БЗ-залежність:
А ->> В | С.
Така залежність називається нетривіальною МЗ-залежністю.
Відношення знаходиться в четвертій нормальній формі (4НФ) тоді і
тільки тоді, коли існують такі підмножини А та В атрибутів у відношенні R, що
виконується нетривіальна багатозначна залежність А ->> В.
Тоді всі атрибути відношення R також функціонально залежать від атрибуту A.
Отже, оскільки проблема багатозначних залежностей виникає в зв'язку з
багатозначними атрибутами, то вирішити проблему можна, помістивши
кожен багатозначний атрибут у свою власну таблицю разом з ключем, від якого
залежить атрибут.
Четвертая нормальная форма
У цьому прикладі можна зробити декомпозицію відношення
НДР у два наступних відношення:
НДР-СПІВПРАЦІВНИКИ
НДР-ЗАВДАННЯ
Номер_НДР
Співроб
Номер_НДР
Завдання_НДР
111
Ставків
111
завдання 1
111
Фудіна
111
завдання 2
222
Ставків
222
завдання 1
222
Типасков
222
завдання 2
222
завдання 3
П'ята нормальна форма
Іноді нормалізувати ставлення шляхом декомпозиції на два нових
відношення без втрат не вдається, але проглядається можливість
декомпозиції вихідного відношення без втрат на більшу кількість відношень,
кожне з яких володіє кращими властивостями.
Таке відношення називається терміном
"n-декомпозируєме відношення" для деякого n > 2.
Це означає, що для цього відношення можлива декомпозиція без втрат на nпроекцій, а на меньшу кількість проекцій декомпозиція без втрат неможлива.
Якщо в процесі природного з'єднання декомпозованого
відношення у порівнянні з первісним відношенням генеруються хибні
кортежі, така декомпозиція характеризується залежністю з'єднання.
П'ята нормальна форма
У відношенні R (X, У, ..., Z) відсутня залежність з'єднання *(Х, У, ..., Z),
в тому і тільки в тому випадку, коли
R відновлюється без втрат шляхом з'єднання своїх проекцій на X, У, ..., Z
Відношення знаходиться у 5НФ,
якщо воно не містить залежностей з'єднання.
Проверка поддержки целостности данных
Следует обратить внимание на следующие вопросы:
•
•
•
•
•
возможность для атрибутов иметь пустые значения;
ограничения для доменов атрибутов;
категорная целостность;
ссылочная целостность;
бизнес-правила в данной предметной области.
Необходимо выполнить работу по проверке каждой составляющей
применительно к каждой сущности, к каждому атрибуту, к каждой
связи логической модели предметной области.
В том случае, если и данная проверка даст положительный
результат, можно переходить к следующему этапу проектирования
базы данных — физическому проектированию.
Словник даних (metadata)
БД містить не лише дані, які всебічно характеризують діяльність
самої організації, фірми, процесу чи іншої предметної галузі, але і опис
цих даних.
Інформацію про дані прийнято називати "метаданими", тобто
"даними про дані".
В сукупності опис всіх даних утворюють словник даних.
information_schema
attributes
character_sets
collations
columns
domain_constraints
domains
referential_constraints
role_column_grants
role_routine_grants
role_table_grants
role_usage_grants
routines
sequences
sql_features
sql_implementation_info
table_constraints
table_privileges
tables
triggers
view_column_usage
view_routine_usage
views
view_table_usage
...
information_schema.tables
table_catalog
table_schema
table_name
table_type
self_referencing_column_name
reference_generation
user_defined_type_catalog
user_defined_type_schema
user_defined_type_name
is_insertable_into
is_typed
commit_action
SELECT * FROM information_schema.tables
information_schema.columns
table_catalog
table_schema
table_name
column_name
ordinal_position
column_default
is_nullable
data_type
character_maximum_length
character_octet_length
numeric_precision
numeric_precision_radix
numeric_scale
datetime_precision
interval_type
interval_precision
character_set_name
collation_name
domain_name
is_self_referencing
is_identity
is_generated
is_updatable
...
Фізичне проектування
Физическая модель БД
Решение проблем проектирования на физическом уровне во многом
зависит от используемой СУБД, зачастую автомати- зировано и скрыто
от пользователя. В ряде случаев пользовате- лю предоставляется
возможность настройки отдельных пара- метров системы.