Зв’язки між записами однієї таблиці

Вступ до баз даних.

1. Шумаков П.В., Фаронов В.В. Delphi 5. Руководство разработчика баз данных. – М.: Нолидж, 2000. – 640 с., ил.

2. Кенту М. Delphi 7 для профессионалов. – СПб.: Питер, 2004. – 1101 с.

3. Тейксейра С., Пачеко К. Borland Delphi 6. Руководство разработчика. – М.: Изд. дом Вильямс, 2002. – 1120 с.

Поняття баз даних.

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

Системи управління базами даних (СУБД) – (DBMS – DataBase Management System) – це програмні засоби, призначені для створення, наповнення, оновлення та знищення баз даних.

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

Одиницею інформації в БД є таблиця (Table). Кожну таблицю можна зобразити як сукупність рядків і стовпців, де рядки відповідають екземпляру об’єкта, певному явищу або події, а рядки - атрибутам (ознакам, характеристикам, параметрам) объекта, події, явища.

На рис. 1.1. наведено приклад таблиці, яка зберігає відомості про відпуск товару зі складу. Стовпці відповідають таким параметрам, як дата відпуску товару, назва товару, назва покупця, кількість одиниць відпущеного товару. Кожен рядок містить відомості про конкретну подію - відпуск товару покупцю.

 В термінах БД стовпці називаються полями (Field), а рядки – записами (Record).

Рис 1.1. Приклад таблиці "Відпуск товарів"

Між окремими таблицями в БД можуть існувати зв’язки. Наприклад, інформація про покупця може доповнюватись в іншій таблиці:

Рис 1.2. Приклад таблиці "Покупці"

БД, між окремими таблицями яких існують зв’язки називають реляційними (relation – зв’язок відношення).

Таблиці, які мають зв’язки діють за принципом головна (master) – підпорядкована (detail). Наприклад "Покупці" – головна (батьківська), а "Відпуск товарів" – підпорядкована (дочірня). Одна і та ж таблиця може бути головною по відношенню до однієї таблиці БД, і дочірньою – до іншої.

Первинні ключі та індекси

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

Первинні ключі спрощують встановлення зв’язків між таблицями. У таблиці “Покупці” таким ключем є поле “Покупець”. Тому встановивши зв’язок за первинним ключем, ми можемо дізнатись, що ....

Оскільки первинний ключ повинен бути унікальним, для нього можна використовувати не кожне поле у таблиці. Наприклад, назва покупця не може бути унікальною, тому поле “Покупець” не може бути первинним ключем. Поле “Телефон” краще підходить на цю роль. Якщо в таблиці немає полів з унікальними значеннями для створення первинного ключа до неї вводять додаткове числове поле. Якщо в таблицю “Покупці” додати поле “№№”, зв’язан таблиці будуть мати такий вигляд:

та

Тепер у таблиці “Відпуск товарів” у полі “Покупець” вказується значення первинного ключа, побудованого по полю “№№” таблиці “Покупці”, що дозволяє встановити однозначний зв’язок між таблицями.

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

Реляційні відношення (зв’язки) між таблицям

1.4.1. Відношення "один-до-багатьох"

Таблиця “Товари”

Таблиця “Відпуск товарів”

Рис. 1.3 Зв’язок “один-до-багатьох”

Як видн из рис. 1.3, одному запису з батьківської таблиці "Товари" може відповідати декілька записів у дочірній таблиці "Відпуск товарів". Зверність увагу на дієслово може: воно означає, що така можливість - потенційна і що у батьківській таблиці можуь бути записи, для яких у цей момент немає записів у дочірній таблиці (наприклад, товар "Сіль").

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

Зв’язок "один-до-багатьох" є найпоширенішим для реляційних баз даних. Він дозволяє моделювати ієрархії даних.

1.4.2. Відношення "один-до-одного"

Відношення "один-до-одного" має місце, коли одному запису в батьківській таблиці відповідає один запис у дочірній таблиці (рис. 1.4.).

Таблиця “Співробітники”

Таблиця “Інформація про співробітників”

Рис. 1.4 Зв’язок “один-до-одного”

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

Так як і зв’язок “один-до-багатьох” зв’язок "один-до-одного" може бути жорстким і нежорстким.

1.4.3. Відношення "багато-до-багатьох"

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

Таблиця "Навчальні групи і дисципліни” і Таблиця "Викладачі"

Рис 1.5 Зв’язок "багато-до-багатьох"

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

Зв’язки між записами однієї таблиці

Між записами однієї таблиці також можуть існувати зв’язки, тобто одні записи можуть посилатися на інші.

Приклад. Нехай в реляційній БД необхідно зберігати деревоподібну структуру довільного рівня, наприклад, структуру організації (рис. 1.6.)

Департамент автоматизації

       Технічне управління

                   Відділ мереж

                   Ремонтний відділ

                   АТС

       Управління програмними засобами

                   Відділ експлуатації

                               Інформаційна група

                               Адміністративна група

                                           Диспетчерське бюро

                   Відділ розробки

Рис. 1.6. Структура організації

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

№ підрозділу Назва підрозділу  № підрозділу вищого рівня

1     Департамент автоматизації

2     Технічне управління                                1

3     Управління програмними засобами      1

4     Відділ мереж                                             2

5     Ремонтний відділ                                     2

6     АТС                                                           2

7     Відділ експлуатації                                  3

8     Відділ розробки                                        3

9     Інформаційна група                                7

10   Адміністративна група                           7

11   Диспетчерське бюро                                10

Рис. 1.7. Табличне зображення структури організації