Реляційні субд: огляд бази даних, приклади

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

Історія розробки

Реляційна база даних СУБД була винайдена на початку 1970-х років. Ф. Коддом, молодим вченим-програмістом IBM. У спеціальній статті по РБД він запропонував перейти від зберігання даних в ієрархічних структурах до організації їх в таблицях, що мають рядки і стовпці.

До 1960-х років зібралася величезна кількість даних, що зберігаються на нових мейнфрейм-комп`ютерах світу, багато з яких були комп`ютерами IBM System 360. Це стало проблемою для подальшого розвитку цифрових технологій. Розрахунки на мейнфреймах були дорогими, часто коштували сотні доларів на хвилину. Важливою частиною цих витрат була складність, пов`язана з управлінням базою даних (БД).

У 1973 році лабораторія Сан-Хосе, нині Альмаден, почала розробляти програму під назвою System R (реляційний) з метою застосування теорії відносин за допомогою так званої промислової реалізації. Ця якість стала визначальною, щоб визначити, які СУБД називаються реляційними. В результаті реалізації цього проекту було винайдено нову революційну систему зберігання, що стала основою успіху IBM.

Дон Чемберлін і Рей Бойс винайшли SQL для структурованих даних, який сьогодні найбільш широко застосовуються. Патрісія Селінгер розробила оптимізатор на основі витрат, що робить роботу з реляційними БД більш рентабельною та ефективною. А Реймонд Лорі винайшов компілятор, який зберігає процедури запитів до БД для подальшого використання.

У 1983 році IBM представила друге сімейство реляційних СУБД DB2 з метою управління даними. Сьогодні DB2 все ще виробляє мільярди транзакцій щодня, будучи найуспішнішим програмним продуктом IBM. За словами Арвінда Крішни, генерального менеджера IBM Information Management, DB2 продовжує залишатися лідером в області інноваційного ПЗ для реляційних баз даних (РБД).

Доктор Кодд, відомий своїм колегам як Тед, був удостоєний звання стипендіата IBM в 1976 році, а в 1981 році Асоціація обчислювальної техніки вручила йому премію Тьюрінга за внесок, внесений в розробку РБД.

Принципи створення

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

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

Терміни та типи

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

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

Альтернативні структури

База даних NoSQL-це альтернатива RBD, яка особливо корисна для роботи з великими наборами розподілених даних.

База даних графіків виходить за рамки традиційних моделей реляційних даних на основі стовпців та рядків. NoSQL має вузли та ребра, які представляють зв`язки між відносинами даних та виявляють нові між ними. Графічні БД є більш складними, ніж RBD, і, отже, їх використання включає механізми виявлення шахрайства або веб-рекомендацій.

Приклади реляційних СУБД

SQLite-популярна БД SQL з відкритим кодом. ПЗ може зберігати всю БД в одному файлі. Найважливішою перевагою, яку вона забезпечує, є те, що всі дані можуть зберігатися локально без підключення до сервера. SQLite стала популярною для БД в мобільних телефонах, КПК, MP3-плеєрах, телевізійних приставках та інших електронних гаджетах.

MySQL-ще одна популярна реляційна модель СУБД SQL з відкритим кодом. Зазвичай вона застосовується у веб-додатках і часто доступна за допомогою PHP. Головні переваги її-простота використання, цінова доступність, надійність. Деякі з недоліків проявляються в тому, що при масштабуванні вона страждає від низької продуктивності, розробка із застосуванням відкритого вихідного коду відстає з тих пір, як Oracle встановив контроль над MySQL і не включає в себе деякі розширені функції.

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

Система управління RDBMS

RDBMS-система управління реляційними базами даних, розроблена EF Codd від IBM і здатна створювати, змінювати і адмініструвати РБД. Багато існуючих на сьогодні БД є продовженням цієї вікової моделі. Збережені дані обробляються із застосуванням реляційних операторів в СУРБД.

SQL використовують як мову запитів баз даних-це логічна група даних. Вона містить набір пов`язаних табличних і індексних просторів. Як правило, БД містить всі дані, пов`язані з одним додатком або з пов`язаною групою. Наприклад, може бути БД заробітної плати або або інвентаризації.

Відмінності RDBMS від звичайної СУБД

СУБД зберігає дані як файли, тоді як RDBMS зберігає дані як таблицю. СУБД дозволяє нормалізувати дані, а RDBMS підтримує зв`язок між даними, що зберігаються в її таблицях. Звичайна СУБД не надає посилання. Вона просто зберігає дані своїх файлів. Структурований підхід RDBMS підтримує розподілену РБД на відміну від звичайної системи управління базами даних. СУБД орієнтована на широкий спектр застосувань, її особливості дозволяють використовувати її в усьому світі.

Особливості RDBMS:

1. Загальна реалізація стовпця, а також багатокористувацький доступ включені у функції RDBMS.
2. Потенціал цієї моделі реляційних СУБД був більш ніж виправданий сучасними можливостями застосування.
3. Краща безпека забезпечується створенням таблиць.
4. Деякі таблиці можуть бути захищені системою.
5. Користувачі можуть встановлювати бар`єри доступу до контенту. Це дуже корисно в компаніях, де менеджер може вирішити, які дані надаються працівникам та клієнтам. Таким чином, можна налаштувати індивідуальний рівень захисту даних.
6. Забезпечення майбутніх вимог, оскільки нові дані можуть бути легко додані до існуючих таблиць і узгоджені з раніше доступним вмістом. Це функція, якої немає в жодній БД плоских файлів.

Структурна таблиця

Таблиця-це логічна структура, що складається з рядків і стовпців. Рядки не мають фіксованого порядку, тому, якщо витягуються дані, може знадобитися відсортувати їх. Порядок стовпців вказується при створенні таблиці адміністратором БД. На перетині кожного стовпця і рядка знаходиться певний елемент даних, званий значенням, або, точніше, атомарним значенням. Таблиця називається класифікатором ідентифікатора користувача власника високого рівня, за яким слідує назва таблиці, наприклад TEST.DEPT або PROD.DEPT.

Існує декількох типів таблиць:

1. Базова, яка створюється і містить постійні дані.
2. Тимчасова, в якій зберігаються проміжні результати запиту.

Елементи таблиць:

1. Стовпці мають упорядкований набір: DEPTNO, DEPTNAME, MGR та ADMK DEPT. Всі вони повинні бути однотипними даними.
2. Рядки-кожна містить дані для одного відділу.
3. Значення на перетині стовпця та рядка. Наприклад, PLANNING-це значення стовпця Dept NAME у рядку для відділу B01.

Індекс-це впорядкований набір покажчиків на рядки таблиці. На відміну від рядків таблиці, які не знаходяться в певному порядку, Індекс DB2 повинен завжди підтримувати порядок.

Індекс використовується для двох цілей:

1. Для підвищення швидкодії отримання значень даних.
2. Для унікальності.

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

Основні ключі

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

1. Він повинен мати значення, тобто не бути нульовим.
2. Він повинен мати унікальний індекс.
3. Можна мати більше одного унікального ключа в таблиці.
4. Іноземний ключ-зовнішній ключ, зазначений в обмеженні посилальної цілісності, щоб його існування залежало від первинного або батьківського ключа.

Модель мережевої бази даних

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

Переваги мережевої БД:

1. Концептуально проста і легка в розробці.
2. Доступ до даних простіший і гнучкіший щодо ієрархічної моделі і не дозволяє члену існувати без батьків.
3. Може обробляти складні дані через його ставлення " багато до багатьох». Це дозволяє більш природне моделювання відносин між записами або об`єктами реляційної СУБД на відміну від ієрархічної.
4. Завдяки своїй гнучкості легше переміщається і знаходить інформацію в мережевій БД.
5. Така структура ізолює керуючі програми від складних фізичних даних.

Об`єктно-орієнтована система

В об`єктно-орієнтованих БД всі дані є об`єктами. Вони можуть бути пов`язані один з одним відношенням "є частиною" для представлення більших складових елементів.

Наприклад, дані, що описують автомобіль, можуть зберігатися як складова частина конкретного двигуна, шасі, коробки передач, системи рульового управління та ін. Класи об`єктів можуть утворювати ієрархію, в якій окремі об`єкти успадковують властивості від об`єктів вище. Наприклад, всі об`єкти класу "моторний транспорт" матимуть двигун (вантажівка, автомобіль або літак). Аналогічно двигуни також є об`єктами даних, і атрибут двигуна конкретного транспортний засіб буде посиланням на конкретний об`єкт двигуна.

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

Процес проектування

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

Алгоритм проектування:

1. Визначають мету БД для аналізу вимог.
2. Збирають вимоги. Виконують збір даних, організацію таблиць і вказують первинні ключі.
3. Вибирають один або кілька стовпців в якості так званого первинного ключа з метою ідентифікації рядків.
4. Створюють відносини між таблицями. Сила реляційної БД полягає у відносинах між таблицями. Найбільш важливим аспектом при розробці РБД є виявлення взаємозв`язків між ними.
5. Необхідно вибрати необхідний тип даних для конкретного стовпця. Зазвичай типи даних містять: цілі числа, рядок (або текст), дату, час, двійковий код, колекцію, наприклад перерахування та набір.
6. Уточнюють дизайн, додавши більше стовпців.
7. Створюють нову таблицю для необов`язкових даних, використовуючи відношення один до одного.
8. Розбивають великий стіл на два менших столу.
9. Застосовують правила нормалізації, щоб перевірити, чи є база даних структурно правильною та оптимальною.
10. Індекс можна визначити для одного стовпця, набору стовпців, який називається складеним індексом, або частини стовпця, яка називається частковим індексом. Можна створити більше одного індексу в таблиці. Наприклад, якщо часто шукають клієнта, використовуючи або customer Name або phone Number, можна прискорити пошук, побудувавши Індекс по стовпцю customer Name, а також phone Number.
11. Більшість СУБД автоматично будує Індекс по первинному ключу.

Створення БД Access

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

Алгоритм створення БД:

1. Попередньо визначають дані і складають список необхідних полів (фрагментів інформації) з використанням різних типів даних.
2. Усувають зайві поля. Не допускається зберігати однакову інформацію більш ніж в одному місці. У випадку коли можна обчислити одне поле, використовуючи інше, зберігають одне.
3. Організовують поля. Формують їх відповідно опису, в зв`язку з чим кожна група перетворюється в таблицю.
4. Додають таблиці кодів зі скороченнями.
5. Включають в БД таблицю назв і коди з двох букв.
6. Вибирають первинний ключ.
7. Пов`язують таблиці.

Таким чином, можна підвести підсумок, що основні переваги РБД полягають в тому, що вони дозволяють користувачам просто класифікувати і зберігати дані, легко розширюються і не залежать від фізичної організації. Після створення вихідної БД можна додати нову категорію даних без зміни всіх існуючих додатків.