реляційна модель даних
Реляційна модель базується на теоретико-множині понятті відносини. У математичних дисциплінах існує поняття'' відношення '' (relation), фізичним представленням якого є таблиця . Звідси і пішла назва моделі - реляційна .
Стосовно до БД поняття''реляціонная БД'' і''таблічная БД'' є синонімами. Реляційні бази набули найбільшого поширення в світі. Майже вс е продукти БД, створені з кінця 70-х років, є реляційними.
У 1970 році з'явилися роботи, в яких обговорювалися можливості застосування різних табличних мо їй даних. Найбільш значною з них була стаття співробітника фірми IBM д-ра Е. Кодда (Codd E.F., A Relational Model of Data for Large Shared Data Banks (Реляційна модель даних для великих спільно використовуваних банків даних). CACM 13: 6, June 1970), де вперше був застосований термін "Реляційна модель даних" . Проект System R був розроблений в дослідницькій лабораторії корпорації IBM. Цей проект був задуманий з метою довести практичність реляційної моделі. Реляційні СУБД відносяться до СУБД другого покоління.
цілі створення реляційної моделі даних:
1. Забезпечення більш високого ступеня незалежності від даних.
2. Створення міцного фундаменту для вирішення проблем несуперечності і надмірності даних.
3. Розширення мов управління даними за рахунок включення операцій над множинами.
Комерційні системи на базі реляційної моделі даних почали з'являтися в кінці 70-х - початку 80-х років. Сьогодні існує кілька сотень типів різних реляційних СУБД.
Реляційна модель є зручною і найбільш звичною формою представлення даних у вигляді таблиці (відносини ). Кожне відношення має ім'я і складається з названих атрибутів (Стовпців) даних. Одним з базових переваг реляційної моделі є її однорідність. Всі дані зберігаються в таблицях, в яких кожен рядок має один і той же формат. Кожен рядок в таблиці представляє певний об'єкт реального світу або співвідношення між об'єктами.
Основними поняттями, за допомогою яких визначається реляційна модель, є наступні:
1. реляційна БД - набір нормалізованих відносин;
2. відношення - файл, плоска таблиця, що складається з стовпців і рядків; таблиця, в якій кожне поле є атомарним;
3. домен - сукупність допустимих значень, З якої береться значення відповідного атрибута определ енного відносини. З точки зору програмування, домен - ϶ᴛᴏ тип даних;
4. універсум - сукупність значень нд ех полів або сукупність доменів;
5. кортеж - запис, рядок таблиці;
6. кардинальність - кількість рядків у таблиці;
7. атрибути – поіменованниеполя, стовпці таблиці;
8. ступінь відносини - кількість полів (стовпців);
9. схема відносини - впорядкований список імен атрибутів;
10. схема реляційної БД - сукупність схем відносин;
11. первинний ключ - унікальний ідентифікатор з неповторяющимися записами - стовпець або неĸᴏᴛᴏᴩᴏᴇ підмножина стовпців, які єдиним чином визначають ланцюжки.
Первинний ключ, який включає більше одного стовпчика, прийнято називати множинним , або комбінованим , або складовим , або суперключ .
Правило цілісності об'єктів стверджує, що первинний ключ не повинна бути повністю або частково порожнім.
Співвідношення цих понять ілюструється на рис. 4.5.
| № | ПІБ | Рік нар. | Посада | Кафедра |
| 1. | Іванов І. І. | Зав. каф. | 22 | |
| 2. | Сидоров С. С. | Проф. | 22 | |
| 3. | Андрєєва Г. Г. | Проф. | 22 | |
| 4. | Цвєткова С. С. | доцент | ||
| 5. | Козлов К. К. | доцент | 22 | |
| 6. | Петров П. П. | Ст. преп. | 22 |
|
|||
мал. 4.5. Основні поняття реляційної моделі даних.
Іноді в якості первинного ключа в таблиці бувають обрані різні стовпці. Виділ енний ключ - ключ, явно перерахований разом з реляційною схемою. В іншому випадку говорять про неявному ключі, або можливий ключі, або ключі-кандидаті.
12. зовнішній ключ - ϶ᴛᴏ стовпець або підмножина стовпців однієї таблиці, які можуть служити в якості первинного ключа для іншої таблиці. Зовнішній ключ таблиці є посиланням на первинний ключ іншої таблиці. Оскільки метою побудови БД є зберігання нд ех даних, по можливості, в одному примірнику, то якщо якийсь атрибут присутній в декількох аспектах, то його наявність зазвичай відображає определ енную зв'язок між рядками цих відносин.
Зовнішні ключі реалізують зв'язку між таблицями БД.
Зовнішній ключ, як і первинний ключ, може являти собою комбінацію стовпців. На практиці зовнішній ключ нд егда буде складовим, в разі якщо він посилається на складовою первинний ключ іншої таблиці. Кількість стовпців і їх типи даних у первинному та зовнішньому ключах повинні збігатися.
У разі якщо таблиця пов'язана з декількома іншими таблицями, вона може мати кілька зовнішніх ключів.
кожна реляціоннаятабліца володіє наступними властивостями:
Має ім'я, ĸᴏᴛᴏᴩᴏᴇ відрізняється від імен нд ех інших таблиць;
Дані в клітинках таблиці повинні бути структурно неподільними. Неприпустимо, щоб в комірці таблиці містилося більше однієї порції інформації. Наприклад, Номер і серія паспорта повинні розташовуватися в різних стовпчиках таблиці;
Нд е стовпці в таблиці однорідні, ᴛ.ᴇ. вс е елементи в стовпці мають однаковий тип (числовий, символьний і т.д.) і довжину;
Кожен стовпець має унікальне ім'я;
Однакові рядки в таблиці відсутні;
Порядок проходження рядків і стовпців повинна бути довільним, незалежно від їх переупорядочивания ставлення буде залишатися одним і тим же, а тому мати таке ж значення.
Основні поняття реляційної моделі даних - поняття і види. Класифікація та особливості категорії "Основні поняття реляційної моделі даних" 2017, 2018.
Мережева модель даних
У СМД елементарні дані і відносини між ними представляються у вигляді орієнтованої мережі (вершини - дані, дуги - відносини).
Мережеві бази даних мали низку переваг:
· Гнучкість.Множинні відносини предок / нащадок дозволяли мережевий базі даних зберігати дані, структура яких була складніше простий ієрархії.
· Стандартизація. Поява стандарту CODASYL популярність мережевої моделі, а такі постачальники міні-комп'ютерів, як Digital Equipment Corporation і Data General, реалізували мережеві СУБД.
· Швидкодію. Всупереч своїй великої складності, мережеві бази даних досягали швидкодії, який можна порівняти з швидкодією ієрархічних баз даних. Безлічі були представлені покажчиками на фізичні запису даних, і в деяких системах адміністратор міг задати кластеризації даних на основі безлічі відносин.
Звісно, у мережевих баз даних були недоліки. Як і ієрархічні бази даних, мережеві бази даних були дуже жорсткими. Набори відносин і структуру записів доводилося ставити наперед. Зміна структури бази даних зазвичай означало перебудову всієї бази даних.
Як ієрархічна, так і мережева база даних були інструментами програмістів. Реалізація призначених для користувача запитів часто затягувалася на тижні і місяці, і до моменту появи програми інформація, яку вона надавала, часто виявлялася марною.
Над даними мережевий моделі можна виконувати такі дії:
· внести запис в БД (в залежності від типу включення запис може бути внесена в групове відношення чи ні);
· включити запис в групове відношення (зв'язати запис з будь-яким власником);
· переключити (зв'язати підпорядковану запис із записом власника в тому ж груповому відношенні);
· змінити значення елементів попередньо витягнутої записи;
· витягти запис або за значенням ключа, або послідовно в рамках групового відносини;
· видалити - при видаленні запису необхідно враховувати класи членства;
· виключити з групового відносини (розірвати зв'язок між записом власника і підпорядкованої записом).
Реляційна модель даних.
реляційною моделлюназивається база даних, в якій всі дані, доступні користувачеві, організовані у вигляді таблиць, а всі операції над даними зводяться до операцій над цими таблицями. Наочною формою подання відносини є двовимірна таблиця. Таблиця має рядки (записи) і стовпці (колонки). Кожен рядок має однакову структуру і складається з полів. Рядках таблиці відповідають кортежі, а стовпцями - атрибути відносини. Гідність реляційної моделі полягає в простоті, зрозумілості та зручності фізичної реалізації на ЕОМ. Саме простота і зрозумілість для користувача з'явилися для користувача основною причиною її використання. Проблема ж ефективності обробки даних цього типу виявилися технічно цілком можна вирішити. Основними недоліками є: відсутність стандартних засобів ідентифікації окремих записів і складність опису ієрархічних і мережевих зв'язків. Прикладами зарубіжних реляційних СУБД є: Visual FoxPro і Access (Microsoft).
Основні елементи реляційної моделі: Ставлення - найважливіше поняття і являє собою двовимірну таблицю, яка містить деякі дані. Сутність-об'єкт будь-якої природи, дані про який зберігаються в БД. Дані про сутність зберігаються в відношенні. Атрибути-властивості, що характеризують сутність. У таблиці він іменується і йому відповідає заголовок стовпця таблиці. Домен-безліч всіх можливих значень певного атрибута відносини. Схема відносини (заголовок відносини) список імен атрибутів. Первинний ключ (ключ відносини) атрибут відносини, однозначно ідентифікує кожен з його кортежів. Якщо кортежі ідентифікуються тільки зчепленням значень декількох атрибутів, то говорять, що відношення має складовою ключ. Ставлення може містити кілька ключів. Завжди один з ключів оголошується первинним, його значення не можуть оновлюватися. Всі інші ключі відносини називаються можливими ключами.
Переваги реляційної моделі:
Простота і доступність для розуміння користувачем. Єдиною використовуваної інформаційної конструкцією є "таблиця";
Суворі правила проектування, що базуються на математичному апараті;
Повна незалежність даних. Зміни в програмному забезпеченні при зміні реляційної БД мінімальні;
Для організації запитів і написання прикладного ПО немає необхідності знати конкретну організацію БД у зовнішньої пам'яті.
Недоліки реляційної моделі:
Далеко не завжди предметна область може бути представлена \u200b\u200bу вигляді "таблиць";
В результаті логічного проектування з'являється безліч "таблиць". Це призводить до труднощів розуміння структури даних;
БД займає відносно багато зовнішньої пам'яті;
Відносно низька швидкість доступу до даних.
Три складові частини реляційної моделі даних:
§ структурна
§ маніпуляційна
§ цілісна
структурна частина моделі визначає, що єдиною структурою даних є нормалізоване парне ставлення. Відносини зручно представляти у формі таблиць, де кожен рядок є кортеж, а кожен стовпець - атрибут, визначений на деякому домені. Даний неформальний підхід до поняття відносини дає більш звичну для розробників і користувачів форму подання, де реляційна база даних являє собою кінцевий набір таблиць.
маніпуляційна частина моделі визначає два фундаментальних механізму маніпулювання даними - реляційна алгебра і реляційне числення. Основною функцією маніпуляційної частини реляційної моделі є забезпечення заходів реляційної будь-якого конкретного мови реляційних БД: мова називається реляційних, якщо він має не меншу виразністю і потужністю, ніж реляційна алгебра або реляційне числення.
цілісна частина моделі визначає вимоги цілісності сутностей і цілісності посилань. Перша вимога полягає в тому, що будь-яке відношення має володіти первинним ключем. Вимога цілісності по посиланнях, або вимога зовнішнього ключа полягає в тому, що для кожного значення зовнішнього ключа, що з'являється в посилається відношенні, щодо, на яку веде посилання, повинен знайтися кортеж з таким же значенням первинного ключа, або значення зовнішнього ключа повинно бути невизначеним (тобто ні на що не вказувати).
10. Модель «сутність зв'язок» ER-модель, нормалізація даних.
ER-модель (Entity-Relationship model) являє собою високорівневу концептуальну модель даних, яка була розроблена в 1976 році з метою спрощення задачі проектування БД. Основні концепції моделі «сутність-зв'язок» включають типи сутностей, зв'язку та атрибути.
Основною концепцією ER-моделювання є тип сутності, який представляє безліч об'єктів реального світу з однаковими властивостями. Тип сутності характеризується незалежним існуванням і може бути об'єктом з фізичним (реальним) існуванням або об'єктом з концептуальним (абстрактним) існуванням.
Кожен унікально ідентифікований екземпляр типу сутності називається просто сутністю. Кожен тип сутності ідентифікується ім'ям і списком властивостей і класифікується на два типи: сильний слабкий. Існування слабкого типу залежить від іншого типу, сильного - не залежить.
на використанні різновидівER-моделі засновано більшістьсучасних підходів до проектування баз даних (головним чином, реляційних). Модель була запропонована Ченом в 1976 р. Моделювання предметної області базується на використанні графічних діаграм, що включають невелике число різнорідних компонентів. У зв'язку з наочністю подання концептуальних схем баз даних ER-моделі отримали широке поширення в CASE-засобах, призначених для автоматизованого проектування реляційних баз даних.
Для моделювання структури даних використовуються ER-діаграми (діаграми «сутність-зв'язок»), які в наочній формі представляють зв'язку між сутностями. Відповідно до цього ER-діаграми набули поширення в CASE-системах, що підтримують автоматизоване проектування реляційних баз даних. Найбільш поширеними є діаграми, виконані відповідно до стандарту 1DEF1X, який використовують найбільш популярні CASE-системи (зокрема, ERwin, Design / IDEF, Power Designer). Основними поняттями ER-діаграми є сутність, зв'язокі атрибут.
сутність
сутність -це реальний або віртуальний об'єкт, що має істотне значення для розглянутої предметної області, інформація про який підлягає зберіганню. Якщо не вдаватися в подробиці, то можна вважати, що сутності відповідають таблицями реляційної моделі. Кожна сутність повинна мати наступні властивості:
1. мати унікальний ідентифікатор;
Будь-яка сутність може мати будь-яку кількість зв'язків з іншими сутностями.
У діаграмах ER-моделі сутність представляється у вигляді прямокутника, що містить ім'я сутності.
Частина 2. Реляційна модель даних
Реляційна модель є зручною і найбільш звичною формою представлення даних у вигляді таблиці.
На відміну від ієрархічної та мережевий моделей, Такий спосіб представлення:
1. зрозумілий користувачеві-непрограмістів;
2. дозволяє легко змінювати схему - приєднувати нові елементи даних і запису без зміни відповідних подсхем;
3. забезпечує необхідну гнучкість при обробці непередбачених запитів. До того ж будь-яка мережева або ієрархічна схема може бути представлена \u200b\u200bдвовимірними відносинами.
Одним з основних переваг реляційної моделі є її однорідність. Всі дані розглядаються як збережені в таблицях, в яких кожен рядок має один і той же формат. Кожен рядок в таблиці представляє певний об'єкт реального світу або співвідношення між об'єктами.
Користувач моделі сам повинен для себе вирішити питання, чи мають відповідні сутності реального світу однорідністю. Цим самим вирішується проблема придатності моделі для передбачуваного застосування.
Основними поняттями, за допомогою яких визначається реляційна модель, є наступні:
1. домен,
2. відношення,
3. кортеж,
4. кардинальність,
5. атрибути,
6. ступінь,
7. первинний ключ.
Співвідношення цих понять ілюструється малюнок 7.
Мал. 7. Основні поняття реляційної моделі
Таблиця 7.
Ці поняття представляють спеціальну термінологію, введену авторами теоретичних основ, однак вони мають і більш звичні аналоги (але не в усьому еквіваленти), відповідність яких наведено в таблиці нижче 1.
домен - це сукупність значень, з якої беруться значення відповідних атрибутів певного ставлення. З точки зору програмування, домен - це тип даних, який визначається системою (стандартний) або користувачем і сукупність додаткових обмежень, що накладаються на ці дані.
У математичних дисциплінах поняття «таблиця» відповідає поняття «ставлення» (relation). Звідси і пішла назва моделі - реляційна. Тобто, стосовно до баз даних поняття «реляційна БД» і «табличная БД» по суті є синонімами.
Первинний ключ - це стовпець або деяку підмножину стовпців, які унікально, т. Е. Єдиним чином визначають ланцюжки. Первинний ключ, який включає більше одного стовпчика, називається множинним, або комбінованим, або складовим. Правило цілісності об'єктів стверджує, що первинний ключ не може бути повністю або частково порожнім, т. Е. Мати значення null.
Решта ключі, які можна також використовувати в якості первинних, називаються потенційними або альтернативними ключами.
зовнішній ключ - це стовпець або підмножина однієї таблиці, який може служити в якості первинного ключа для іншої таблиці. Зовнішній ключ таблиці є посиланням на первинний ключ іншої таблиці. Правило посилальної цілісності свідчить, що зовнішній ключ може бути або порожнім, або відповідати значенням первинного ключа, на який він посилається. Зовнішні ключі є невід'ємною частиною реляційної моделі, оскільки реалізують зв'язку між таблицями бази даних.
Зовнішній ключ, як і первинний ключ, теж може являти собою комбінацію стовпців. На практиці зовнішній ключ завжди буде складовим (що складається з декількох стовпців), якщо він посилається на складовою первинний ключ в іншій таблиці. Очевидно, що кількість стовпців і їх типи даних у первинному та зовнішньому ключах збігаються.
Якщо таблиця пов'язана з декількома іншими таблицями, вона може мати кілька зовнішніх ключів.
Модель пред'являє до таблиць наступні вимоги:
1. дані в осередках таблиці повинні бути структурно неподільними 1;
2. дані в одному стовпці повинні бути одного типу;
3. кожен стовпець повинен бути унікальним (неприпустимо дублювання стовпців);
4. стовпці розміщуються в довільному порядку;
5. рядки розміщуються в таблиці також в довільному порядку;
6. стовпці мають унікальні найменування.
В цілому концепція реляційної моделі визначається наступними дванадцятьма правилами Кодда (В лекції правила наводяться по).
1. Правило інформації. Вся інформація в базі даних повинна бути надана виключно на логічному рівні і лише одним способом - у вигляді значень, що містяться в таблицях.
2. Правило гарантованого доступу. Логічний доступ до всіх і кожного елементу даних (атомарному значенню) в реляційної базі даних повинен забезпечуватися шляхом використання комбінації імені таблиці, первинного ключа і імені стовпця.
3. Правило підтримки недійсних значень. У реляційній базі даних повинна бути реалізована підтримка недійсних значень, які відрізняються від рядка символів нульової довжини, рядки символів пробілів, від нуля або будь-якого іншого числа і використовуються для подання відсутніх даних незалежно від типу цих даних.
4. Правило динамічного каталогу, заснованого на реляційної моделі. Опис бази даних на логічному рівні має бути представлено в тому ж вигляді, що і основні дані, щоб користувачі, які володіють відповідними правами, могли працювати з ним за допомогою того ж реляційного мови, який вони застосовують для роботи з основними даними.
5. Правило вичерпного под'язика даних. Реляційна система може підтримувати різні мови і режими взаємодії з користувачем (наприклад, режим питань і відповідей). Однак повинен існувати, принаймні, одну мову, оператори якого можна представити у вигляді рядків символів відповідно до деяким чітко визначеним синтаксисом і який в повній мірі підтримує наступні елементи:
Визначення даних;
Визначення уявлень;
Обробку даних (інтерактивну і програмну);
Умови цілісності;
Ідентифікацію прав доступу;
Межі транзакцій (початок, завершення і скасування).
6. Правило поновлення уявлень. Всі вистави, які теоретично можна оновити, повинні бути доступні для оновлення.
7. Правило додавання, оновлення та видалення. Можливість працювати з ставленням як з одним операндом повинна існувати не тільки при читанні даних, але і при додаванні, оновленні та видаленні даних.
8. Правило незалежності фізичних даних. Прикладні програми і утиліти для роботи з даними повинні на логічному рівні залишатися недоторканими при будь-яких змінах способів зберігання даних або методів доступу до них.
9. Правило незалежності логічних даних. Прикладні програми і утиліти для роботи з даними повинні на логічному рівні залишатися недоторканими при внесенні в базові таблиці будь-яких змін, які теоретично дозволяють зберегти недоторканими що містяться в цих таблицях дані.
10. Правило незалежності умов цілісності. Повинна існувати можливість визначати умови цілісності, специфічні для конкретної реляційної бази даних, на підмові реляційної бази даних і зберігати їх в каталозі, а не в прикладній програмі.
11. Правило незалежності поширення. Реляційна СУБД не повинна залежати від потреб конкретного клієнта.
12. Правило єдиності. Якщо в реляційної системі є низькорівневий мову (що обробляє один запис за один раз), то має бути відсутня можливість використання його для того, щоб обійти правила і умови цілісності, виражені на реляционном мовою високого рівня (обробному кілька записів за один раз).
Правило 2 вказує на роль первинних ключів при пошуку інформації в базі даних. Ім'я таблиці дозволяє знайти необхідну таблицю, ім'я стовпця дозволяє знайти необхідний стовпець, а первинний ключ дозволяє знайти рядок, що містить шуканий елемент даних.
Правило 3 вимагає, щоб відсутні дані можна було уявити за допомогою недійсних значень ( NULL).
Правило 4 говорить, що реляційна база даних повинна сама себе описувати. Іншими словами, база даних повинна містити набір системних таблиць, описують структуру самої бази даних.
Правило 5 вимагає, щоб СУБД використовувала мова реляційної бази даних, наприклад SQL. Такий мова повинна підтримувати всі основні функції СУБД - створення бази даних, читання і введення даних, реалізацію захисту бази даних і т. Д.
Правило 6 стосується уявлень, які є віртуальними таблицями, що дозволяють показувати різним користувачам різні фрагменти структури бази даних. Це одне з правил, які найскладніше реалізувати на практиці.
Правило 7 акцентує увагу на тому, що бази даних за своєю природою орієнтовані на безлічі. Воно вимагає, щоб операції додавання, видалення і оновлення можна було виконувати над множинами рядків. Це правило призначене для того, щоб заборонити реалізації, в яких підтримуються тільки операції над одним рядком.
Правила 8 і 9 означають відділення користувачів та прикладної програми від низкоуровневой реалізації бази даних. Вони стверджують, що конкретні способи реалізації зберігання чи доступу, використовувані в СУБД, і навіть зміни структури таблиць бази даних не повинні впливати на можливість користувача працювати з даними.
Правило 10 говорить, що мова бази даних повинен підтримувати обмежувальні умови, що накладаються на дані, що вводяться і дії, які можуть бути виконані над даними.
Правило 11 говорить, що мова бази даних повинен забезпечувати можливість роботи з розподіленими даними, розташованими на інших комп'ютерних системах.
І, нарешті, правило 12 запобігає використання інших можливостей для роботи з базою даних, крім мови бази даних, оскільки це може порушити її цілісність.
література
1. Дейт До . Введення в системи баз даних: Пер. з англ. - М .: Наука, 1980.- 463 с.
2. Грофф Дж., Ваінберг П. SQL: повне керівництво / Пер. з англ. 2-е изд. К .: BHV, 2001..
бази даних, якщо вони ґрунтуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи один спільну мову.Хоча поняття моделі даних є загальним, і можна говорити про ієрархічної, мережевої, семантичної та інших моделях даних, потрібно відзначити, що в області баз даних це поняття було введено Едгаром Коддом стосовно до реляційних систем і найбільш ефективно використовується саме в даному контексті. Спроби прямолінійного застосування аналогічних моделей до дореляціонним організаціям показують, що реляційна модель занадто "велика", а для постреляціонних організацій вона виявляється "мала".
Загальна характеристика
хоча поняття реляційної моделі даних першим ввів основоположник реляційного підходу Едгар Кодд, найбільш поширене трактування реляційної моделі даних, Мабуть, належить відомому популяризаторові ідей Кодда Крістоферу Дейта, який відтворює її (з різними уточненнями) практично у всіх своїх книгах (див., Наприклад, К. Дейт. Введення в системи баз даних. 6-е изд., М. ; СПб .: Вільямс.- 2000). Згідно з трактуванням Дейта, реляційна модель складається з трьох частин, що описують різні аспекти реляційного підходу: Структурної частини, маніпуляційної частини і цілісної частини.
У структурної частини моделі фіксується, що єдиною родовою структурою 7 Уже вдруге в цій лекції стверджується, що нормалізоване n -арної ставлення є єдиною родовою структурою даних, що використовується в реляційних БД. Прийшов час пояснити, що ми маємо на увазі під терміном родова структура. У мовах програмування з розвиненими системами типів зазвичай є конструкції, звані родовими типами, параметрізуемих типами, конструкторами типів, генераторами типів і т.д., що дозволяють породити конкретний тип даних на основі його абстрактної (зазвичай, зумовленої) специфікації. Особливість таких типів полягає в тому, що і основні операції конкретного типу визначаються на рівні цієї абстрактної специфікації. Одним з найбільш відомих прикладів є тип безлічі, наприклад, в мові Pascal. В разі реляційної моделі даних ми не говоримо явно, що ставлення є родовим типом, але, по суті, це саме так. Операції реляційної алгебри визначаються на рівні абстрактного відносини і застосовні до будь-яких значеніям- відносинам з конкретними заголовками. даних, що використовується в реляційних БД, є нормалізоване n -арної відношення. Визначаються поняття доменів, атрибутів, кортежів, заголовка, тіла і змінної відносини. По суті справи, в двох попередніх розділах цієї лекції ми розглядали саме поняття і властивості структурної складової реляційної моделі.
У маніпуляційної частини моделі визначаються два фундаментальних механізму маніпулювання реляційними БД - реляційна алгебра і реляційне числення. Перший механізм базується в основному на класичній теорії множин (з деякими уточненнями і доповненнями), а другий - на класичному логічному апараті обчислення предикатів першого порядку. Ми розглянемо ці механізми більш детально в наступних лекціях, а поки лише зауважимо, що основною функцією маніпуляційної частини реляційної моделі є забезпечення заходів реляційної будь-якого конкретного мови реляційних БД: мова називається реляційних, якщо він має не меншу виразністю і потужністю, ніж реляційна алгебра або реляційне числення.
Цілісність суті і посилань
Нарешті, в цілісній частині реляційної моделі даних фіксуються два базових вимоги цілісності, які повинні підтримуватися в будь-який реляційної СУБД. Перша вимога називається вимогою цілісності сутності (entity integrity). Об'єкту або сутності реального світу в реляційних БД відповідають кортежі відносин. Саме вимога полягає в тому, що будь-який кортеж будь-якого значення-відносини будь-якої змінної відносини повинен бути відрізнити від будь-якого іншого кортежу цього значення відносини по складовим значенням заздалегідь певної множини атрибутів змінної відносини, Т. Е., Іншими словами, будь-яка змінна відносини повинна володіти первинним ключем. Як ми бачили в попередньому розділі, це вимога автоматично задовольняється, якщо в системі не порушуються базові властивості відносин.
Насправді, вимога цілісності сутності повністю звучить наступним чином: у будь-який змінної відносини повинен існувати первинний ключ, і ніяке значення первинного ключа в кортежі значення-відносини змінної відносини не повинно містити невизначених значень . Щоб це формулювання було повністю зрозуміла, ми повинні хоча б коротко обговорити поняття невизначеного значення (NULL).
Звичайно, теоретично будь-який кортеж, що заноситься в яке зберігається відношення, повинен містити всі характеристики модельованої їм сутності реального світу, які ми хочемо зберегти в базі даних. Однак на практиці не всі ці характеристики можуть бути відомі до того моменту, коли потрібно зафіксувати сутність в базі даних. Простим прикладом може бути процедура прийняття на роботу людину, розмір заробітної плати якого ще не визначено. В цьому випадку службовець відділу кадрів, який заносить в відношення СЛУЖБОВЦІ кортеж, що описує нового службовця, просто не може забезпечити значення атрибута СЛУ_ЗАРП (будь-яке значення домену РАЗМЕРИ_ВИПЛАТ буде невірно характеризувати зарплату нового службовця).
Едгар Кодд запропонував використовувати в таких випадках невизначені значення. невизначене значення не належить ніякому типу даних і може бути присутнім серед значень будь-якого атрибута, визначеного на будь-якому типі даних (якщо це явно не заборонено при визначенні атрибута). Якщо a - це значення деякого типу даних або NULL, op - будь-яка двомісна "арифметична" операція цього типу даних (наприклад, +), а lop - операція порівняння значень цього типу (наприклад, \u003d), то за визначенням:
a op NULL \u003d NULL NULL op a \u003d NULL a lop NULL \u003d unknown NULL lop a \u003d unknown
Тут unknown - це третє значення логічного, або булевского, типу, Що володіє наступними властивостями:
NOT unknown \u003d unknown true AND unknown \u003d unknown true OR unknown \u003d true false AND unknown \u003d false false OR unknown \u003d unknown
(Нагадаємо, що операції AND і OR є комутативними) 8 Як показує досвід автора, не завжди і не всі студенти пам'ятають базові логічні операції. Для гарантії приведемо таблиці істинності операцій AND (& - сполучення), OR (- диз'юнкція) і NOT (- заперечення): AND
true
false
OR
true
false
NOT
true
false
true
true
false
true
true
true
false
true
false
false
false
false
true
false
Так от, перше з вимог - вимога цілісності сутності - означає, що первинний ключ повинен повністю ідентифікувати кожну сутність, а тому в складі будь-якого значення первинного ключа не допускається наявність невизначених значень . (У класичній реляційної моделі ця вимога поширюється і на можливі ключі; як буде показано в наступних лекціях, в SQL-орієнтованих СУБД така вимога для можливих ключів не підтримується.)
Друга вимога, яке називається вимогою цілісності по посиланнях (referential integrity), Є більш складним. Очевидно, що при дотриманні нормалізованності відносин складні сутності реального світу представляються в реляційної БД у вигляді декількох кортежів декількох відносин. Наприклад, уявімо, що у Вас можуть запитати в реляційній базі даних сутність ВІДДІЛ з атрибутами ОТД_НОМЕР (номер відділу), ОТД_РАЗМ (кількість службовців) і ОТД_СЛУ (безліч службовців відділу). Для кожного службовця потрібно зберігати СЛУ_НОМЕР (номер службовця), СЛУ_ІМЯ (ім'я службовця) і СЛУ_ЗАРП ( заробітня плата службовця). Як ми побачимо в лекції 7, при правильному проектуванні відповідної БД в ній з'являться два відносини: ВІДДІЛИ (ОТД_НОМЕР, ОТД_РАЗМ) (Первинний ключ - (ОТД_НОМЕР)) і СЛУЖБОВЦІ (СЛУ_НОМЕР, СЛУ_ІМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМ) (Первинний ключ - (СЛУ_НОМЕР)).
Як видно, атрибут СЛУ_ОТД_НОМ вводиться в відношення СЛУЖБОВЦІ не тому, що номер відділу є власним властивістю службовця, а лише для того, щоб мати можливість при необхідності відновити повну сутність ВІДДІЛ. Значення атрибута СЛУ_ОТД_НОМ в будь-якому кортежі відносини СЛУЖБОВЦІ має відповідати значенням атрибута ОТД_НОМ в деякому кортежі відносини ВІДДІЛИ. Атрибут такого роду (можливо, складовою) називається зовнішнім ключем (foreign key), Оскільки його значення однозначно характеризують сутності, представлені кортежами деякого іншого відношення (т. Е. Описують їх первинного ключа). Звичайно, зовнішній ключ може бути складеним, т. Е. Складатися з декількох атрибутів. Кажуть, що ставлення, в якому визначено зовнішній ключ, посилається на відповідне відношення, в якому такий же атрибут є первинним ключем.
вимога цілісності по посиланнях, Або вимога цілісності зовнішнього ключа, полягає в тому, що для кожного значення зовнішнього ключа, що з'являється в кортежі значення-відносини посилається змінної відносини, Або в значенні- щодо змінної відносини, На яку вказує посилання, повинен знайтися кортеж з таким же значенням первинного ключа, Або значення зовнішнього ключа повинно бути повністю невизначеним (т. Е. Ні на що не вказувати) 9 В мові SQL допускається кілька варіантів визначення зовнішнього ключа, з яких тільки один повністю відповідає класичному підходу. Більш детально ми обговоримо це в наступних лекціях. . Для нашого прикладу це означає, що якщо для службовця вказано номер відділу, то цей відділ повинен існувати.
Зауважимо, що, як і первинний ключ,
Яка є додатком до завдань обробки даних таких розділів математики як теорії множин і логіка першого порядку.
На реляційної моделі даних будуються реляційні бази даних.
Реляційна модель даних включає наступні компоненти:
- Структурний аспект (складова) - дані в базі даних є набором відносин.
- Аспект (складова) цілісності - відносини (таблиці) відповідають певним умовам цілісності. РМД підтримує декларативні обмеження цілісності рівня домену (типу даних), рівня відносини і рівня бази даних.
- Аспект (складова) обробки (маніпулювання) - РМД підтримує оператори маніпулювання відносинами (реляційна алгебра, реляційне числення).
Основними поняттями реляційних баз даних є тип даних, відношення, сутність, атрибут, домен, кортеж, первинний ключ.
поняття тип даних в реляційної моделі даних повністю аналогічно поняттю типу даних в мовах програмування. Зазвичай в сучасних реляційних базах даних допускається зберігання символьних, числових даних, бітових рядків, спеціалізованих числових даних (таких як гроші), а також спеціальних даних (дата, час, часовий інтервал).
ставлення є найважливішим поняттям і являє собою двовимірну таблицю, яка містить деякі дані.
сутність– деякий окремий об'єкт або подія, інформацію про який необхідно зберігати в базі даних і який має певний набір властивостей - атрибутів. Сутностями можуть бути як фізичні (реально існуючі) об'єкти, наприклад СТУДЕНТ (атрибути - Номер залікової книжки, Прізвище, Ім'я, По батькові, Спеціальність, Номер групи і т.д.), так і абстрактні, наприклад ІСПИТ (атрибути - Дисципліна, Дата, викладач, Аудиторія та ін.). Для сутностей розрізняють тип і екземпляр. Тип характеризується ім'ям і списком властивостей, а екземпляр - конкретними значеннями властивостей.
атрибути являють собою властивості, що характеризують сутність. У структурі таблиці кожен атрибут іменується і йому відповідає заголовок деякого стовпця таблиці. Атрибути сутності бувають:
1) ідентифікують і описові.Ідентифікують атрибути мають унікальне значення для сутностей даного типу і є потенційними ключами. Вони дозволяють однозначно розпізнавати екземпляри сутності. З потенційних ключів вибирається один первинний ключ.В якості первинного ключа зазвичай вибирається потенційний ключ, за яким частіше відбувається звернення до екземплярів запису. Первинний ключ повинен включати в свій склад мінімально необхідне для ідентифікації кількість атрибутів. Решта атрибути називаються описовими;
2) прості і складові.Простий атрибут складається з одного компонента, його значення неподільне. Складовою атрибут є комбінацією декількох компонентів, можливо належать різним типам даних (наприклад, адреса). Рішення про те, використовувати складовою атрибут або розбивати його на компоненти, залежить від особливостей процесів його застосування і може бути пов'язано із забезпеченням високої швидкості роботи з великими базами даних;
3) однозначні і багатозначні.Атрибути можуть мати відповідно одне або багато значень для кожного екземпляра сутності;
4) основні і похідні.Значення основного атрибута не залежить від інших атрибутів. Значення похідного атрибута обчислюється на основі значень інших атрибутів (наприклад, вік людини обчислюється на основі дати його народження і поточної дати).
Специфікація атрибута складається з його назви, вказівки типу даних і опису обмежень цілісності - множини значень (або сайти), які може приймати даний атрибут.
доменявляє собою безліч всіх можливих значень певного атрибута відносини.
Схема відносини (заголовок відносини)являє собою список імен атрибутів із зазначенням імен доменів.
кортеж, що відповідає даній схемі відносини, являє собою безліч пар (ім'я атрибуту, значення), яке містить одне входження кожного імені атрибута. Аргумент "значення" є допустимим значенням домену даного атрибута.
первинним ключем(Ключем відносини, ключовим атрибутом)називається атрибут або набір атрибутів відносини, однозначно ідентифікує кожен з його кортежів. Первинний ключ за визначенням унікальний: у відношенні не може бути двох різних кортежів з однаковими значеннями первинного ключа. Атрибути, що становлять первинний ключ, не можуть мати значення NULL.поняття NULLв теорії реляційних баз даних покликане позначати відсутність будь-якого значення атрибута. Для кожного відносини первинний ключ може бути тільки один.
Кожне відношення обов'язково має комбінацію атрибутів, яка може служити ключем. Можливі випадки, коли відношення має кілька комбінацій атрибутів, кожна з яких однозначно визначає всі кортежі відносини. Всі ці комбінації атрибутів є можливими ключамивідносини. Будь-який з можливих ключів може бути обраний як первинний.
Зовнішні ключі - це основний механізм для організації зв'язків між таблицями та підтримки цілісності і несуперечності інформації в базі даних.
зовнішній ключ- це набір атрибутів одного відносини, що є можливим ключем іншого ставлення.
Завдяки наявності зв'язок між можливими і зовнішніми ключами забезпечується взаємозв'язок кортежів певних відносин, яка тим самим сприяє підтримці бази даних в такому стані, що її можна розглядати як єдине ціле. Ставлення, що містить зовнішній ключ, називається дочірнім, а відношення, що містить пов'язаний із зовнішнім ключем можливий ключ, - батьківським. Типи даних (а в деяких СУБД і розмірності) відповідних атрибутів зовнішнього і батьківського ключів повинні збігатися.
Елементи реляційної моделі даних і форма їх подання
|
Елемент реляційної моделі |
форма подання |
|
|
ставлення |
||
|
схема відносини |
Рядок заголовків стовпців таблиці (заголовок таблиці) |
|
|
рядок таблиці |
||
|
сутність |
Опис властивостей об'єкта |
|
|
Тема шпальти таблиці |
||
|
Безліч допустимих значень атрибута |
||
|
значення атрибута |
Значення поля в записі |
|
|
Первинний ключ |
Один або кілька атрибутів |
|
|
Тип даних |
Тип значень елементів таблиці |
|
