41. Реляційні бази даних

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

Реляційна модель бази даних має такі властивості:

• кожний елемент таблиці — один елемент даних;

• усі стовпці в таблиці є однорідними, тобто мають однаковий тип;

• кожний стовпець (поле) має унікальне ім’я;

• однакові рядки в таблиці відсутні;

• порядок слідування рядків у таблиці може бути довільним і може характеризуватися кількістю полів, кількістю записів, типом даних.

Над цією моделлю бази даних зручно виконувати такі дії:

• сортування даних (наприклад за алфавітом);

• вибірка даних за групами (наприклад класами);

• пошук записів (наприклад за прізвищами) і т. д.

42. Основні етапи роботи із базою даних

І. Перший крок полягає у визначенні інформаційних потреб бази даних. Він включає в себе опитування майбутніх користувачів для того, щоб зрозуміти і задокументувати їх вимоги. Слід з'ясувати наступні питання:

II. Наступний крок включає в себе аналіз об'єктів реального світу, які необхідно змоделювати в базі даних.

III. Третій крок полягає у встановленні відповідності між сутностями і характеристиками предметної області і відносинами і атрибутами в нотації вибраної СУБД. Оскільки кожна сутність реального світу володіє деякими характеристиками, в сукупності утворюють повну картину її прояви, можна поставити їм у відповідність набір відносин (таблиць) та їх атрибутів (полів).

IV. На четвертому кроці визначаються атрибути, які унікальним чином ідентифікують кожен об'єкт. Це необхідно для того, щоб система могла отримати будь-яку одиничну рядок таблиці. Ви повинні визначити первинний ключ для кожного з відносин. Якщо немає можливості ідентифікувати кортеж за допомогою одного атрибута, то первинний ключ потрібно зробити складовим - з кількох атрибутів. Хорошим прикладом може бути первинний ключ у таблиці працівників, що складається з прізвища, імені та по батькові. Первинний ключ гарантує, що в таблиці не буде міститися двох однакових рядків. У багатьох СУБД є можливість крім первинного визначати ще ряд унікальних ключів. Відмінність унікального ключа від первинного полягає в тому, що унікальний ключ не є головним фактором ідентифікує записи і на нього не може посилатися зовнішній ключ іншої таблиці. Його головне завдання - гарантувати унікальність значення поля.

V. П'ятий крок передбачає вироблення правил, які будуть встановлювати і підтримувати цілісність даних. Будучи певними, такі правила в клієнт-серверних СУБД підтримуються автоматично - сервером баз даних; в локальних же СУБД їх підтримку доводиться покладати на користувальницький додаток.

VI. На шостому кроці встановлюються зв'язки між об'єктами (таблицями і стовпчиками) і проводиться дуже важлива операція для виключення надмірності даних - нормалізація таблиць.