воскресенье, 29 мая 2016 г.

Бази даних: #1 Загальна теорія

Усім привіт! Хотів би розкрити таку важливу тему, що часто випадає з виду, але все ж необхідну кожному розробнику в тій чи іншій мірі, як бази даних.
Не важливо пишете ви для веб чи для бекенуду, чи для iOS чи для Android ви все одно будете користуватись базами даних. І щоб розуміти як працювати з базами даних важливо розумі, що ж це таке.

База даних - це сукупність даних, що зберігаються в деякому впорядкуванні.

Абстрактне доволі поняття, чи не так? В загальному випадку базою даних можна вважати будь-який впорядкований набір даних. Наприклад, паперову картотеку з формулярами про працівників підприємства у відділі кадрів.

Система керування базами даних (СКБД) — комплекс програмного забезпечення, що надає можливості створення, збереження, оновлення та пошуку інформації в базах даних з контролем доступу до даних.


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

Бази даних бувають декількох типів:
1. Ієрархічні бази даних;
2. Мережеві бази даних;
3. Реляційні бази даних;
4. Об’єктно орієнтовані бази даних.

Ієрархічні бази даних



Ієрархічні бази даних підтримують деревоподібну організацію інформації. Зв'язки між записами виражаються у вигляді відносин предок/нащадок, а в кожного запису є рівно один батьківський запис. Це допомагає підтримувати цілісність посилань. Коли запис видаляється з дерева, всі його нащадки також повинні бути вилучені. Ієрархічні бази даних мають централізовану структуру, тобто безпеку даних легко контролювати. На жаль, певні знання про фізичний порядок зберігання записів все-таки необхідні, тому що відносини предок/нащадок реалізуються у вигляді фізичних покажчиків з одного запису на інші.
Це означає, що пошук запису здійснюється методом прямого обходу дерева. Записи, розташовані в одній половині дерева, шукаються швидше, ніж в іншій. Звідси виникає необхідність правильно впорядковувати записи, щоб час їхнього пошуку був мінімальним. Це важко, тому що не всі відносини, що існують у реальному світі, можна виразити в ієрархічній базі даних. Відносини "один до багатьох" є природними, але практично неможливо описати відносини "багато хто до багатьох" або ситуації, коли запис має кілька предків. Доти поки в додатках будуть кодуватися відомості про фізичну структуру даних, будь-які зміни цієї структури будуть грозити перекомпіляцією.

Мережеві бази даних



Мережна модель розширює ієрархічну модель, дозволяючи групувати зв'язки між записами в множини. З логічної точки зору зв'язок - це не сам запис. Зв'язки лише виражають відносини між записами. Як й в ієрархічній моделі, зв'язки ведуть від батьківського запису до дочірнього, але цього разу підтримується множинне спадкування. 
Відповідно специфікації CODASYL, мережна модель підтримує DDL (Data Definition Language - мову визначення даних) і DML (Data Manipulation Language - мова обробки даних). Це спеціальні мови, призначені для визначення структури бази даних і складання запитів. Незважаючи на їхню наявність, програміст як і раніше повинен знати структуру бази даних. 
У мережній моделі допускаються відносини "багато хто до багатьох", а записи не залежать друг від друга. При видаленні запису віддаляються й всі її зв'язки, але не самі зв'язані записи. У мережній моделі потрібно, щоб зв'язки встановлювалися між існуючими записами щоб уникнути дублювання й перекручування цілісності. Дані можна ізолювати у відповідних таблицях і зв'язати із записами в інших таблицях. Програмістові не потрібно піклуватися про те, як організується фізичне зберігання даних на диску. Це послабляє залежність додатків і даних. Але в мережній моделі потрібно, щоб програміст пам'ятав структуру даних при формуванні запитів. 
Оптимальну структуру бази даних складно сформувати, а готову структуру важко міняти. Якщо вид таблиці перетерплює зміни, всі відносини з іншими таблицями повинні бути встановлені заново, щоб не порушилася цілісність даних. Складність подібного завдання приводить до того, що програмісти найчастіше скасовують деякі обмеження цілісності заради спрощення додатків.

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


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

Об’єктно орієнтовані бази даних


Об’єктно-орієнтована база даних (ООБД) дозволяє програмістам, які працюють із мовами третього покоління, інтерпретувати всі свої інформаційні сутності як об'єкти, що зберігаються в оперативній пам'яті. Додатковий інтерфейсний рівень абстракції забезпечує перехоплення запитів, що звертаються до тих частин бази даних, які перебувають у постійному сховищі на диску. Зміни, внесені в об'єкти, оптимальним образом переносяться з пам'яті на диск. 
Перевагою об’єктно-орієнтованих баз даних є спрощений код. Додатки одержують можливість інтерпретувати дані в контексті тієї мови програмування, на якому вони написані. Реляційна база даних повертає значення всіх полів у текстовому виді, а потім вони приводяться до локальних типів даних. В об’єктно-орієнтованих базах даних цей етап ліквідований. Методи маніпулювання даними завжди залишаються однаковими незалежно від того, перебувають дані на диску або в пам'яті. 
Дані в об’єктно-орієнтованих базах даних здатні прийняти вид будь-якої структури, яку можна виразити використовуваною мовою програмування. Відносини між сутностями також можуть бути довільно складними. Об’єктно-орієнтована база даних управляє кеш-буфером об'єктів, переміщаючи об'єкти між буфером і дисковим сховищем у міру необхідності. 
За допомогою об’єктно-орієнтованих баз даних вирішуються дві проблеми. По-перше, складні інформаційні структури виражаються в них краще, ніж у реляційних базах даних, а по-друге, усувається необхідність транслювати дані з того формату, що підтримується в СКБД. Наприклад, у реляційній СКБД розмірність цілих чисел може становити 11 цифр, а у використовуваній мові програмування - 16. Програмістові прийде враховувати цю ситуацію. 
Об’єктно-орієнтовані СКБД виконують багато додаткових функцій. Це окупається сповна, якщо відносини між даними дуже складні. У такому випадку продуктивність об’єктно-орієнтованих баз даних виявляється вище, ніж у реляційних СКБД. Якщо ж дані менш складні, додаткові функції виявляються надлишковими. В об'єктній моделі даних підтримуються нерегламентовані запити, але мовою їхнього складання не обов'язково є SQL. Логічне подання даних може не відповідати реляційній моделі, тому застосування мови SQL стане безглуздим. Найчастіше зручніше обробляти об'єкти в пам'яті, виконуючи відповідні види пошуку. 
Великим недоліком об’єктно-орієнтованих баз даних є їхні тісні зв'язки із застосовуваною мовою програмування. До даних, що зберігаються в реляційній СКБД, можуть звертатися будь-які додатки, тоді як, приміром, Java-об'єкт, поміщений в об’єктно-орієнтовану базу даних, буде становити інтерес лише для додатків, написаних на Java.

PostgreSQL




PostgreSQL є реляційною СКБД, і найкмітливіші вже здогадалися, що саме реляційні бази ми й будемо розглядати.

Для розуміння PostgeSQL необхідно знати деякі базові поняття.

База даних складається з таблиць. Кожна таблиця складається зі стовпців (поля, атрибути) та рядків (записи, кортежі).
В таблиці не може бути двох однакових рядків.
В таблиці може не бути жодного рядка, але хочаб один стовпчик має бути.
У кожного стовпчика є своє унікальне ім’я в рамках таблиці. 
Усі значення в стовпчику є однотипними (число, текст, дата...)

Первинний ключ — атрибут, або набір атрибутів, що однозначно ідентифікує кортеж даного відношення. Первинний ключ обов'язково унікальний, він єдиний і найголовніший із унікальних ключів.

CREATE TABLE fools(
id integer primary key auto_increment, 
name char(20), 
folly char(40));

Зовнішній ключ — атрибут (набір атрибутів) в деякому відношенні R, який відповідає первинному ключу іншого відношення або того ж таки відношення R. В реляційних базах даних зовнішній ключ задається обмеженням FOREIGN KEY.

CREATE TABLE fools (
   id    INTEGER  PRIMARY KEY AUTO_INCREMENT,
   name  CHAR(20),
   folly_id  INTEGER,
   FOREIGN KEY(folly_id)
      REFERENCES follies(id) ON DELETE CASCADE);

Для знайомства з основами SQL рекомендую пройти стислий і в той же час інформативний курс від codecademy.com.


Посилання:

1. UA5.org

Комментариев нет:

Отправить комментарий