Заняття 2 Реляційна модель даних Деякі аспекти проектування

Заняття 2. Реляційна модель даних. Деякі аспекти проектування реляційних баз даних

Теоретична основа реляційних баз даних теорія множин реляційна алгебра (алгебра відношень)

Реляційна структура даних (за К. Дейтом) Структурна частина описує, які об’єкти розглядаються реляційною моделлю. За Дейтом, реляційна база даних – це база даних, яка складається з відношень. Схемою реляційної бази даних називається набір заголовків відношень, які входять у базу даних. Цілісна частина описує обмеження спеціального виду, які повинні виконуватися для будь-яких відношень у будь-яких базах даних. Це цілісність сутностей і цілісність посилань. Маніпулятивна частина описує два еквівалентних способи маніпулювання реляційними даними – реляційна алгебра і реляційне числення. Реляційна алгебра – замкнута система операцій над відношеннями в реляційній моделі даних. Реляційне числення – спеціальний метод застосування обчислення предикатів в реляційних базах даних.

Структурна частина реляційної бази даних

Термінологія в реляційній моделі

Структурна частина реляційної бази даних. Відношення, таблиця Реляційна модель базується на математичному понятті відношення, а фізичне представлення його – це таблиця. Таблиця має жорстко обумовлену кількість поіменованих та впорядкованих стовпців (структуру), і може необмежено рости за кількістю рядків. В таблиці рядки відповідають певним записам, а стовпці – атрибутам.

Відношення – це проста таблиця, в якій усі рядки містять однакову кількість комірок і у відповідних комірках містяться однакові типи даних. Відношення – це таблиця з критерієм, який дозволяє визначити, які рядки входять у таблицю, а які – ні. Цей критерій визначає сенс або семантику відношення. Оскільки відношення не має однакових кортежів, і кортежі є невпорядковані зверху донизу, то одне і те ж відношення можна представити різними таблицями, в яких рядки мають різний порядок.

Структурна частина реляційної бази даних. Атрибут – це поіменований стовпець відношення. Атрибути можуть бути розміщеними в будь-якому порядку. Незалежно від їх розміщення відношення буде залишатись одним і тим же, а тому мати той же зміст.

Структурна частина реляційної бази даних. Домен Кожен атрибут реляційної бази даних визначається на деякому домені. Домен – це набір допустимих значень для одного або декількох атрибутів. Кожен домен утворює значення одного типу даних, наприклад, числового чи символьного. Через домени користувач може визначати зміст та джерело значень, які можуть отримувати атрибути. У багатьох реляційних СУБД домени підтримуються лише частково.

Структурна частина реляційної бази даних. Кортеж Елементами відношення є кортежі, тобто рядки таблиці. Кортежі можуть бути розміщеними в будь-якому порядку, при цьому відношення залишається одним і тим же.

Структурна частина реляційної бази даних. Заголовок відношення Опис структури відношення разом зі специфікацією доменів та інших обмежень щодо можливих значень атрибутів називають його заголовком (або змістом). Заголовок відношення містить фіксовану кількість назв атрибутів. Імена атрибутів повинні бути унікальними у межах відношення. Заголовок є фіксованим до тих пір, поки зміст відношення не зміниться за рахунок додавання в нього додаткових атрибутів.

Структурна частина реляційної бази даних. Тіло відношення Кортежі називаються розширенням, станом, а набір кортежів – тілом відношення, яке постійно змінюється. Тіло відношення є підмножиною декартового добутку доменів, що і є відношенням з математичної точки зору.

Числові характеристики відношення. Ступінь відношення визначається кількістю атрибутів, які воно має: § § відношення з двома атрибутами називається бінарним (binary); § відношення з трьома атрибутами – тернарним (ternary); § відношення тільки з одним атрибутом називається унарним (unary); для відношень з великою кількістю атрибутів використовується термін n -арний (n-ary). Визначення ступеню відношення є частиною заголовка відношення.

Числові характеристики відношення. Кардинальність Кількість кортежів, які містяться у відношенні, називається кардинальним числом, або кардинальністю відношення, або потужністю відношення. Кардинальність змінюється при кожному додаванні або видаленні кортежів. Кардинальність являється властивістю тіла відношення і визначається поточним станом відношення в певний момент часу.

Цілісна частина реляційної бази даних. Обмеження домену Домен розглядається як підмножина значень деякого типу даних, які мають певний зміст. Домен має унікальне ім’я у межах бази даних, він визначений на простому типі даних або на іншому домені. Наявна логічна умова, яка дозволяє описати підмножину даних, допустимих для цього домену. Наприклад, домен D, який має зміст «вік співробітника» , можна описати як наступну підмножину множини натуральних чисел: (D=nєN: n>=18 and n<=60). Основне призначення доменів: вони обмежують порівняння. Некоректно, з логічної точки зору, порівнювати значення з різних доменів, навіть якщо вони мають однаковий тип.

Ключове слово NULL в реляційній моделі NULL вказує, що значення атрибута в даний момент невідоме, або неприйнятне для цього кортежу. NULL є способом опрацювання невизначених, неповних або незвичних даних. NULL не слід розуміти як нульове значення або заповнений пробілами текстовий рядок.

Цілісна частина реляційної бази даних. Реляційний ключ Ключ відношення – це атрибут чи множина атрибутів, який однозначно ідентифікує кортеж даного відношення. Простий ключ складається з одного атрибута, а складений – з декількох атрибутів. Поля, за якими побудовано ключ, називаються ключовими.

Значення реляційного ключа однозначна ідентифікація рядків таблиці; попередження повторень значень атрибута; прискорення виконання запитів до БД; встановлення зв’язків між окремими таблицями БД; використання обмежень цілісності посилань.

Типи реляційних ключів Потенційні (Candidate Key) – CK: § § Первинні (Primary Key) – PK;

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

Типи реляційних ключів. Первинний і альтернативні ключі Первинний ключ (PK, Primary Key) – це потенційний ключ, який вибраний для унікальної ідентифікації кортежів всередині відношення. Відношення не обов’язково повинне мати первинний ключ, але бажано завжди визначати потенційний ключ. Потенційні ключі, які не вибрані в якості первинного ключа, називаються альтернативними ключами.

Типи реляційних ключів. Зовнішній ключ (FK, Foreign Key) – це один або декілька атрибутів відношення (дочірнє відношення), які одночасно є потенційними ключами іншого відношення (батьківське відношення). Зовнішній ключ, як і потенційний, може бути простим і складеним. Зовнішній ключ повинен бути визначений на тих же доменах, що і відповідний первинний ключ батьківського відношення.

Реляційна цілісність Задаються два правила цілісності, які є обмеженнями для всіх допустимих станів бази даних. Ці два основних правила реляційної моделі називаються: § § цілісністю сутностей; цілісністю посилань. СУБД вважається реляційною у повному сенсі, якщо у неї є стандартні засоби автоматичної реалізації обмежень цілісності сутностей і цілісності посилань.

Правило цілісності сутностей Сутність в реляційній моделі – це синонім відношення або таблиці. Обмеження цілісності сутностей стосується первинних ключів базових відношень (відношень, які реально існують в базі даних). Правило: в базовому відношенні ні один атрибут первинного ключа не може містити невизначених значень, що позначаються словом NULL.

Правило цілісності посилань Обмеження цілісності посилань стосується зовнішніх ключів. Правило: якщо у відношенні існує зовнішній ключ, то значення зовнішнього ключа повинно відповідати значенню потенційного (первинного) ключа деякого кортежу в його батьківському відношенні або задаватись словом NULL. Обернене твердження є невірним, оскільки у полі зв’язку батьківської таблиці можуть бути значення, на які не посилається ні одне значення зовнішнього ключа.

Зовнішні ключі і типи зв’язку між відношеннями Зовнішній ключ не володіє властивістю унікальності. В дочірньому відношенні може бути декілька кортежів, які посилаються на один і той самий кортеж батьківського відношення. Це тип зв’язку між відношеннями «один-до-багатьох» (стандартний тип зв’язків зі збереженням цілісності посилань). Зовнішній ключ володіє властивістю унікальності – зв’язок між відношеннями має тип «один-до-одного» . Зв’язок «багато-до-багатьох» означає, що для запису деякої одної таблиці ставляться у відповідність записи іншої таблиці, і навпаки, запису іншої таблиці ставляться у відповідність записи першої.

Примітка. Приклади складних зв'язків між таблицями

Підкласи зв'язку «один-до-багатьох» Ідентифікуючий зв’язок з’єднує дві таблиці, у яких первинні ключі чи їхня частина співпадають. Тобто, потенційний ключ з базової таблиці мігрує у первинний ключ підлеглої таблиці. Неідентифікуючий зв’язок означає, що потенційний ключ з базової таблиці не мігрує у первинний ключ підлеглої таблиці. Такий тип зв’язку часто використовують при посиланні на довідкову таблицю або з метою уникнення аномалій вставки.

Маніпулятивна частина реляційної бази даних Описує засоби, за допомогою яких: з даних, що зберігаються в базі даних, можна отримати вибірки або звідні результати; § § змінювати самі дані або їх структуру. В сучасних промислових СУБД це мова запитів, зокрема SQL. Усі реляційні СУБД реалізують той чи інший діалект SQL. Мова SQL є реляційно повною. Це означає, що будь-який оператор реляційної алгебри може бути виражений певною сукупністю операторів мови SQL.

Приклад 1. Створення діаграми бази даних

Приклад 1. (продовження)

Основні аспекти проектування реляційних баз даних Надлишковість даних та аномалії Функціональні залежності Процес нормалізації

Надлишковість даних та аномалії Надлишковість – це дублювання даних в базі, яке може викликати додаткове використання ресурсів для зберігання даних і синхронізації дублікатів. Наявність надлишковості даних при виконанні операцій над ними призводить до різних аномалій – порушення цілісності БД.

Аномалії модифікації даних Аномалія введення даних означає, що при спробі додати у відношення новий кортеж, необхідно додати й інший кортеж, який містить дублікат, і зв’язані з ним значення інших атрибутів. Аномалія видалення означає, що при спробі видалення кортежу, необхідно видалити й інший кортеж, який містить дублікат, який необхідно видалити, і зв’язані з ним значення інших атрибутів (по аналогії зі вставкою). Однак, при видаленні обох кортежів можуть втратитись дані, пов’язані з дублікатами. Аномалія оновлення означає, що при спробі змінити певне значення атрибута, необхідно його змінювати для всіх дублікатів.

Вирішення проблеми аномалії модифікації даних Для усунення аномалії модифікації даних використовується метод нормалізації відношень, який базується на поняттях: § функціональної залежності (ФЗ); § нормальних форм (НФ).

Функціональна залежність (ФЗ) – концепція, що лежить в основі багатьох питань, пов'язаних з реляційними базами даних, включаючи, зокрема, їхнє проектування. Математично являє собою бінарне відношення між множинами атрибутів даного відношення і є, по суті, зв'язком типу «одиндо-багатьох» . Функціональна залежність – це поняття, що визначає певний семантичний зв’язок між стовпцями таблиці. Нехай у таблиці існує множина стовпців X. Деякий стовпець чи множина стовпців A є функціонально залежним від X тоді і тільки тоді, коли для кожної комбінації значень X ставиться у відповідність одне і тільки одне значення A (X→A). Наприклад, № студентського квитка → Прізвище, Ім’я, Група, Кафедра, №моб. тел. читається: «номером студентського квитка визначаються прізвище, ім’я, група, кафедра та номер мобільного телефону» . У цьому взаємовідношенню № студентського квитка називають визначником чи детермінантом – стовпцем, що визначає значення інших стовпців.

Повна і часткова функціональні залежності Функціональна залежність X→A вважається повною, якщо стовпець чи множина стовпців A є функціонально залежним від X, але не залежить ні від жодного окремо взятого стовпця з множини X. Тобто, якщо видалення будь-якого стовпця з X приводить до втрати цієї залежності. Приклад повної функціональної залежності: Прізвище, Ім’я → Рейтинг. Функціональна залежність X→A вважається частковою, якщо в X є деякий стовпець, при видаленні якого ця залежність зберігається. Приклад часткової функціональної залежності: X = {ID, Child’s. Birthdate}; A = {Surname, Name}, але ID → Surname, Name. Child’s. Name,

Поняття нормалізації Нормалізація – це формальний метод аналізу таблиць на основі їх первинних чи потенційних ключів та існуючих функціональних залежностей. Він включає ряд правил, які можуть використовуватися для перевірки окремих таблиць таким чином, щоб уся БД могла бути нормалізованою до необхідного степеню. Якщо деяка вимога не виконується, тоді таблиця, що суперечить цій вимозі, повинна бути розбита на таблиці, кожна з яких окремо задовольняє усім вимогам нормалізації.

Процес нормалізації Нормалізація виконується в декілька послідовних етапів, кожен з яких відповідає деякій нормальній формі. Під час нормалізації формат відношень стає більш строгим і менш вразливим до аномалій модифікації даних. Процес нормалізації починається з перетворення даних з формату введення даних у формат таблиці. На вихідному етапі таблиця перебуває у ненормалізованій формі (ННФ).

Перша нормальна форма Правило 1 NF: усі дані, що зберігаються у таблиці, повинні бути атомарними *, а таблиця має мати первинний ключ. * Комірки таблиці не можуть містити у собі повторювані групи, тобто масиви даних. Зауваження: 1 NF передбачає таблиці повинні бути різними. строге забезпечення цілісності сутностей, тобто усі стрічки

Друга нормальна форма Правило 2 NF: таблиця повинна бути у 1 NF, та кожен її неключовий стовпець (що не входить у склад первинного ключа) повинен бути зв’язаний повною функціональною залежністю з первинним ключем. Зауваження: якщо таблиця має первинний ключ у вигляді одного стовпця, то вона автоматично знаходиться у 2 NF. У цьому випадку кожен неключовий стовпець залежить від усього ключа, і часткових залежностей буди не може.

Третя нормальна форма Правило 3 NF: таблиця повинна бути у 2 NF та не мати транзитивних залежностей. Транзитивна залежність існує тоді, коли функціональні залежності носять такий характер: X→A та A→B, тому X→B. Тобто у таблиці існує транзитивна залежність тоді, коли існує функціональна залежність між неключовими стовпцями. Зауваження: якщо таблиця у 2 NF не містить транзитивних залежностей, то вона автоматично переводиться у розряд таблиць 3 NF.

Нормальна форма Бойса-Кодда Правило BCNF: таблиця повинна відповідати 3 NF, а усі визначники (детермінанти) є кандидатами на використання у якості ключа. Зауваження: усі відношення, що знаходяться у BCNF, автоматично знаходяться у 3 NF. Основна відмінність між ними полягає у тому, що 3 NF допускає існування функціональних залежностей виду X→A, де A є частиною первинного ключа, а X при цьому сам по собі не є потенційним ключем, у той час як у BCNF детермінант X повинен бути потенційним ключем. І тому BCNF є, фактично, більш сильною формою 3 NF.

Четверта нормальна форма Правило 4 NF: таблиця повинна відповідати BCNF та не мати багатозначних залежностей. Між атрибутами A, B і C деякого відношення існує багатозначна залежність (БЗЗ) (позначається A−>>B|C), якщо для кожного значення атрибуту A існує набір значень атрибуту B і набір значень атрибуту C. Однак значення атрибутів B та C не залежать один від одного.

П’ята нормальна форма При будь-якій декомпозиції відношення на два інших отримані відношення володіють властивістю з’єднання без втрат. Однак бувають випадки, коли потрібно зробити декомпозицію на більш ніж два відношення. У таких (досить рідких випадках) виникає необхідність враховувати залежність з’єднання (project-join), яка усувається за допомогою 5 НФ. Залежність з’єднання – це властивість декомпозиції, яка генерує хибні рядки при оберненому з’єднанні декомпозованих відношень. Наявність PJ-залежності у відношенні робить його надлишковим та затруднює операції модифікації.

Денормалізація Строго нормалізована БД усуває аномалії обновлення та надлишковість даних. Однак надмірна нормалізація іноді погано впливає на продуктивність. Також вона може ускладнити і дизайн БД. Взагалі, будь-яка вибірка даних з декількох таблиць зі встановленим зв’язком є значно повільнішою за вибірку з однієї таблиці. І тому, іноді, для підвищення продуктивності роботи з великими об’ємами даних проводять денормалізацію структури БД.

Завдання 1. Створити діаграму сутність -зв’язок для бази даних