- •Історія розвитку баз даних
- •2.Перспективи розвитку систем управління базами даних.
- •Перспективи розвитку систем управління базами даних
- •Основні поняття та визначення бд
- •Архітектура бази даних. Фізична та логічна незалежність
- •5. Поняття інформаційно-логічної моделі
- •Етапи життєвого циклу бази даних
- •Основні функції субд
- •Класифікація моделей даних
- •Типова організація сучасної субд
- •11.Ієрархічна модель даних.
- •12.Моделі засновані на інвертованих списках.
- •13.Реляційні бази даних.
- •14.Основні оператори реляційної алгебри.
- •15. Основні елементи er-моделі
- •16. Основні етапи побудови логічної моделі
- •17. Таблиці, унікальність і ключі
- •18. Зовнішні ключі і домени
- •1. Цілісність сутностей
- •2. Цілісність значень
- •21. Перша нормальна форма
- •22. Друга нормальна форма
- •23. Третя нормальна форма
- •Четверта нормальна форма
- •Нормальна форма Бойса-Кодда (нфбк)
- •П’ята нормальна форма
- •Кодування та набори сортування в sql
- •Тема 3. Створення таблиць
- •1. Команда створення таблиці.
- •2. Заборона значення null за допомогою обмеження not null
- •Властивість identity оператора create table
- •Обмеження primary key оператора create table
- •Обмеження foreign key оператора create table
- •Обмеження unique оператора create table
- •Обмеження check оператора create table
- •Обмеження default оператора create table
- •Вказівка стовпців в операторі select
- •42.Використання арифметичних операторів в запиті на вибірку даних
- •43.Використання директиви group by
- •44.Об'єднання результатів запиту за допомогою директиви union
- •45.Використання строкових функцій
- •46.Використання числових функцій
- •47.Додавання даних до таблиці за допомогою оператора insert
- •48.Використання та синтаксис оператора replace
- •49.Використання оператора update
- •50.Видалення даних в sql
Типова організація сучасної субд
Природно, організація типової СУБД і склад її компонентів відповідає розглянутому нами набору функцій. Виділяють такі основні функції СУБД: управління даними у зовнішній пам'яті; управління буферами оперативної пам'яті; управління транзакціями; журналізація і відновлення БД після збоїв; підтримка мов БД.
Логічно в сучасній реляційної СУБД можна виділити найбільш внутрішню частину - ядро СУБД (часто його називають Data Base Engine), компілятор мови БД (звичайне SQL), підсистему підтримки часу виконання, набір утиліт. У деяких системах ці частини виділяються явно, в інших - немає, але логічно таке розділення можна провести у всій СУБД. Ядро СУБД відповідає за управління даними у зовнішній пам'яті, управління буферами оперативної пам'яті, управління транзакціями і журналізацію. Відповідно, можна виділити такі компоненти ядра (принаймні, логічно, хоч в деяких системах ці компоненти виділяються явно), як менеджер даних, менеджер буферів, менеджер транзакцій і менеджер журналу. Як можна було зрозуміти з першої частини цієї лекції, функції цих компонентів взаємопов'язані, і для забезпечення коректної роботи СУБД всі ці компоненти повинні взаємодіяти по ретельно продуманим і перевіреним протоколам. Ядро СУБД володіє власним інтерфейсом, не доступним користувачам напряму і що використовується в програмах, що проводяться компілятором SQL (або в підсистемі підтримки виконання таких програм) і утилітах БД. Ядро СУБД є основною резидентною частиною СУБД. При використанні архітектури "клієнт-сервер" ядро є основною складовою серверної частини системи.
Основною функцією компілятора мови БД є компіляція операторів мови БД в деяку програму, що виконується. Основною проблемою реляційних СУБД є те, що мови цих систем (а це, як правило, SQL) є не процедурними, тобто в операторі такої мови специфікується деяка дія над БД, але ця специфікація не є процедурою, а лише описує в деякій формі умови здійснення бажаної дії (пригадайте приклади з першої лекції). Тому компілятор повинен вирішити, яким чином виконувати оператор мови раніше, ніж зробити програму. Застосовуються досить складні методи оптимізації операторів, які ми детально розглянемо в наступних лекціях. Результатом компіляції є програма, що виконується, що представляється в деяких системах в машинних кодах, але більш часто у внутрішньому машинно-незалежному коді, що виконується. У останньому випадку реальне виконання оператора проводиться із залученням підсистеми підтримки часу виконання, що являє собою, по суті справи, інтерпретатор цієї внутрішньої мови.
Нарешті, в окремі утиліти БД звичайно виділяють такі процедури, які дуже накладно виконувати з використанням мови БД, наприклад, завантаження і вивантаження БД, збір статистики, глобальна перевірка цілісності БД і т.д. Утиліти програмуються з використанням інтерфейсу ядра СУБД, а іноді навіть з проникненням всередину ядра.
Класифікація моделей даних
Ієрархічні бази даних можуть бути представлені як дерево, що складається з об'єктів різних рівнів. Верхній рівень займає один об'єкт, другий - об'єкти другого рівня і т.д. Між об'єктами існують зв'язки, кожен об'єкт може включати в себе декілька об'єктів більш низького рівня. Такі об'єкти перебувають у відношенні предка (об'єкт більш близький до кореня) до нащадка (об'єкт більш низького рівня), при цьому можлива ситуація, коли об'єкт-предок не має нащадків або має їх декілька, тоді як у об'єкта-нащадка обов'язково тільки один предок. Об'єкти, що мають загального предка, називаються близнюками.
Мережеві бази даних подібні до ієрархічних, за винятком того, що в них є покажчики в обох напрямках, які з'єднують споріднену інформацію. До основних понять мережевої моделі бази даних відносяться: рівень, елемент (вузол), зв'язок. Вузол - це сукупність атрибутів даних, що описують деякий об'єкт. На схемі ієрархічного дерева вузли представляються вершинами графа. У мережній структурі кожен елемент може бути пов'язаний з будь-яким іншим елементом. Незважаючи на те, що ця модель вирішує деякі проблеми, пов'язані з ієрархічною моделлю, виконання простих запитів залишається досить складним процесом. Також, оскільки логіка процедури вибірки даних залежить від фізичної організації цих даних, то ця модель не є повністю незалежною від програми. Іншими словами, якщо необхідно змінити структуру даних, то потрібно змінити і додаток.
Реляційна модель орієнтована на організацію даних у вигляді двовимірних таблиць. Кожна реляційна таблиця являє собою двовимірний масив і має наступні властивості: кожен елемент таблиці - один елемент даних; всі осередки в стовпчику таблиці однорідні, тобто всі елементи в стовпчику мають однаковий тип (числовий, символьний тощо); кожен стовпчик має унікальне ім'я; однакові рядки в таблиці відсутні; порядок проходження рядків і стовпчиків може бути довільним.
Об'єктна СУБД ідеально підходить для інтерпретації складних даних, на відміну від реляційних СУБД, де додавання нового типу даних досягається ціною втрати продуктивності або за рахунок різкого збільшення термінів і вартості розробки додатків. Об'єктна база, на відміну від реляційної, не вимагає модифікації ядра при додаванні нового типу даних. Новий клас і його екземпляри просто надходять у зовнішні структури бази даних. Система управління ними залишається без змін.
Об'єктно-орієнтована база даних (ООБД) - база даних, в якій дані оформлені у вигляді моделей об'єктів, що включають прикладні програми, які управляються зовнішніми подіями. Результатом поєднання можливостей (особливостей) баз даних і можливостей об'єктно-орієнтованих мов програмування є об'єктно-орієнтовані системи управління базами даних (ООСУБД). ООСУБД дозволяють працювати з об'єктами баз даних також, як з об'єктами у програмуванні в об'єктно-орієнтованих мовах програмування. ООСУБД розширює мови програмування, прозоро вводячи довготривалі дані, управління паралелізмом, відновлення даних, асоційовані запити й інші можливості. Об'єктно-орієнтовані бази даних звичайно рекомендовані для тих випадків, коли потрібна високопродуктивна обробка даних, які мають складну структуру.
Система, яка забезпечує об'єктну інфраструктуру і набір реляційних розширювачів, називається "об'єктно-реляційною". Об'єктно-реляційні системи поєднують переваги сучасних об'єктно-орієнтованих мов програмування з такими властивостями реляційних систем як множинні представлення даних і високорівневі непроцедурні мови запитів.
Мережева модель даних
Мережева модель даних - логічна модель даних, яка є розширенням ієрархічного підходу, строга математична теорія, що описує структурний аспект, аспект цілісності й аспект обробки даних у мережевих базах даних. Різниця між ієрархічної моделлю даних і мережевої полягає в тому, що в ієрархічних структурах запис-нащадок повинна мати в точності одного предка, а в мережевій структурі даних у нащадка може матися будь-яке число предків. Мережева БД складається з набору примірників певного типу запису і набору примірників певного типу зв'язків між цими записами. Тип зв'язку визначається для двох типів запису: предка і нащадка. Примірник типу зв'язку складається з одного примірника типу запису предка і впорядкованого набору примірників типу запису нащадка. Для даного типу зв'язку L з типом запису предка P і типом запису нащадка C повинні виконуватися наступні дві умови: кожен екземпляр типу запису P є предком тільки в одному екземплярі типу зв'язку L; кожен екземпляр типу запису C є нащадком не більше ніж в одному примірнику типу зв'язку L.
Аспект маніпуляції. Зразковий набір операцій маніпулювання даними: знайти певний запис в наборі однотипних записів; перейти від предка до першого нащадку за деякою зв'язку; перейти до наступного нащадку у деякому зв'язку; перейти від нащадка до предка по деякому зв'язку; створити новий запис; знищити запис; модифіковані запис; включити у зв'язок; виключити із зв'язку; переставити в інший зв'язок і т. д.
Аспект цілісності. Є (необов'язкова) можливість вимагати для конкретного типу зв'язку відсутність нащадків, не беруть участь ні в одному примірнику цього типу зв'язку (як в ієрархічній моделі).
Перевагою мережевої моделі даних є можливість ефективної реалізації за показниками витрат пам'яті й оперативності. Недоліком мережевої моделі даних є висока складність і жорсткість схеми БД, побудованої на її основі.
