Реляційна база даних - це сукупність відносин, що містять всю інформацію, яка повинна зберігатися в БД. Однак користувачі можуть сприймати таку базу даних як сукупність таблиць.
1. Кожна таблиця складається з однотипних рядків і має унікальне ім'я.
2. Рядки мають фіксоване число полів (стовпців) і значень (множинні поля і повторювані групи неприпустимі). Інакше кажучи, в кожній позиції таблиці на перетині рядка і стовпця завжди є в точності одне значення або нічого.
3. Рядки таблиці обов'язково відрізняються один від одного хоча б єдиним значенням, що дозволяє однозначно ідентифікувати будь-який рядок такої таблиці.
4. стовпців таблиці однозначно присвоюються імена, і в кожному з них розміщуються однорідні значення даних (дати, прізвища, цілі числа або грошові суми).
6. При виконанні операцій з таблицею її рядки і стовпці можна обробляти в будь-якому порядку безвідносно до їх інформаційного змісту. Цьому сприяє наявність імен таблиць і їх стовпців, а також можливість виділення будь-якої їх рядки або будь-якого набору рядків із зазначеними ознаками (наприклад, рейсів з пунктом призначення "Париж" і часом прибуття до 12 годин).
Маніпулювання реляційними даними
Запропонувавши реляційну модель даних, Е.Ф.Кодд створив і інструмент для зручної роботи з відносинами - реляційну алгебру. Кожна операція цієї алгебри використовує одну або кілька таблиць (відносин) в якості її операндів і продукує в результаті нову таблицю, тобто дозволяє "розрізати" або "склеювати" таблиці.
Мал. 3.3. Деякі операції реляційної алгебри
Створено мови маніпулювання даними, що дозволяють реалізувати всі операції реляційної алгебри і практично будь-які їх поєднання. Серед них найбільш поширені SQL (Structured Query Language -структурізованний мову запитів) і QBE (Quere-By-Example-запит за зразком). Обидва відносяться до мов дуже високого рівня, за допомогою яких користувач вказує, які дані необхідно отримати, не уточнюючи процедуру їх отримання.
За допомогою єдиного запиту на будь-якому з цих мов можна з'єднати кілька таблиць в тимчасову таблицю і вирізати з неї необхідні рядки і стовпці (селекція і проекція).
33. Моделі даних. Цілі проектування бд і універсальне відношення. Нормалізація, функціональні і багатозначні залежності.
Окремі БД можуть об'єднувати всі дані, необхідні для вирішення однієї або декількох прикладних задач, або дані, які стосуються будь-якої предметної області (наприклад, фінансів, студентам, викладачам, кулінарії і т.п.). Перші зазвичай називаютпрікладнимі БД, а другі -предметнимі БД (співвідносяться з предметами організації, а не з її інформаційними додатками). (Перші можна порівняти з базами матеріально-технічного постачання або відпочинку, а другі - з овочевими та взуттєвими базами.)
Предметні БД дозволяють забезпечити підтримку будь-яких поточних і майбутніх додатків, оскільки набір їх елементів даних включає в себе набори елементів даних прикладних БД. Внаслідок цього предметні БД створюють основу для обробки неформалізованих, змінюються і невідомих запитів та програм (додатків, для яких неможливо заздалегідь визначити вимоги до даних). Така гнучкість і пристосованість дозволяє створювати на основі предметних БД досить стабільні інформаційні системи, тобто системи, в яких більшість змін можна здійснити без вимушеного переписування старих додатків.
Засновуючи ж проектування БД на поточних і передбачуваних додатках, можна істотно прискорити створення високоефективної інформаційної системи, тобто системи, структура якої враховує найбільш часто зустрічаються шляху доступу до даних. Але, у міру зростання числа додатків таких інформаційних систем швидко збільшується число прикладних БД, різко зростає рівень дублювання даних і підвищується вартість їх ведення.
Таким чином, кожен з розглянутих підходів до проектування впливає на результати проектування в різних напрямках. Бажання досягти і гнучкості, і ефективності призвело до формування методології проектування, що використовує як предметний, так і прикладної підходи. У загальному випадку предметний підхід використовується для побудови початкової інформаційної структури, а прикладний - для її вдосконалення з метою підвищення ефективності обробки даних.
Основна мета проектування БД - це скорочення надмірності збережених даних, а отже, економія обсягу використовуваної пам'яті, зменшення витрат на багаторазові операції оновлення надлишкових копій і усунення можливості виникнення протиріч через зберігання в різних місцях відомостей про одне й те ж об'екте.Так званий, "чистий" проект БД ( "Кожен факт в одному місці") можна створити, використовуючи методологію нормалізації відносин.
Цей варіант таблиці не є відношенням, так як більшість її рядків не атомарний. Атомарними є лише значення полів Блюдо, Вид, Рецепт (хоча він і великий), Працюй і Дата. В інші ж поля табліци- множинні. Для додання таких даних форми відносини необхідно реконструювати таблицю. Найпростіше це зробити за допомогою простого процесу вставки. Однак таке перетворення призводить до виникнення великого обсягу надлишкових даних.
Таблиця являє собою екземпляр коректного ставлення. Його називають універсальним ставленням проектованої БД. В одне універсальне відношення включаються всі представляють інтерес атрибути, і воно може містити всі дані, які передбачається розміщувати в БД в майбутньому. Для малих БД (що включають не більше 15 атрибутів) універсальне відношення може використовуватися в якості відправної точки при проектуванні БД.
Нормалізація- це розбиття таблиці на дві або більше, що володіють кращими властивостями при включенні, зміні і видаленні даних. Остаточна мета нормалізації зводиться до отримання такого проекту бази даних, в которомкаждий факт з'являється лише в одному місці, тобто виключена надмірність інформації. Це робиться не стільки з метою економії пам'яті, скільки для виключення можливої суперечливості збережених данних.Т.к. кожна таблиця в реляційній БД задовольняє умові, відповідно до якого в позиції на перетині кожного рядка і стовпця таблиці завжди знаходиться єдине атомарному значення, і ніколи не може бути безлічі таких значень. Будь-яка таблиця, яка задовольняє цій умові, називаетсянормалізованной. Фактично, ненормалізованние таблиці, тобто таблиці, що містять повторювані групи навіть не допускаються в реляційної БД.Всякая нормалізована таблиця автоматично вважається таблицею вперше нормальній формі, сокращенно1НФ. Таким чином, строго кажучи, "нормалізована" і "що знаходиться в 1НФ" означають одне і те ж. Однак на практиці термін "нормалізована" часто використовується в більш вузькому сенсі - "повністю нормалізована", який означає, що в проекті не порушуються ніякі принципи нормалізаціі.Теперь на додаток до 1НФ можна визначити подальші рівні нормалізації-друге нормальну форму (2НФ), третю нормальну форму (3НФ) і т.д. По суті, таблиця знаходиться в 2НФ, якщо вона знаходиться в 1НФ і задовольняє, крім того, деякого додатковій умові, суть якого буде розглянута нижче. Таблиця знаходиться в 3НФ, якщо вона знаходиться в 2НФ і, крім цього, задовольняє ще іншому додатковому умові і т.д.
Таким чином, кожна нормальна форма є в певному сенсі більш обмеженою, але і болеежелательной, ніж попередня. Це пов'язано з тим, що "(N + 1) -я нормальна форма" не володіє деякими непривабливими особливостями, властивим "N-й нормальній формі". Загальний сенс додатковою умовою, що накладається на (N + 1) -ю нормальну форму по відношенню до N-й нормальній формі, складається у виключенні цих непривабливих особливостей.
Теорія нормалізації грунтується на наявності тієї чи іншої залежності між полями таблиці. Визначено два види таких залежностей: функціональні і багатозначні.
Функціональна залежність. Поле У таблиці функціонально залежить від поля А тієї ж таблиці в тому і тільки в тому випадку, коли в будь-який заданий момент часу для кожного з різних значень поля А обов'язково існує тільки одне з різних значень поля В. Відзначимо, що тут допускається, що поля А та В можуть бути складовими. Наприклад, в таблиці Страви поля Блюдо і Вигляд функціонально залежать від ключа БЛ, а в таблиці Постачальники рис. 4.3 поле Країна функціонально залежить від складеного ключа (Постачальник, Місто). Однак остання залежність не є функціонально повною, так як Країна функціонально залежить і від частини ключа - поля Город.Полная функціональна залежність. Поле В знаходиться в повній функціональної залежності від складеного поля А, якщо воно функціонально залежить від А і не залежить функціонально від будь-якої підмножини поля А.