- •1. Поняття автоматизованого банку даних (абд).
- •2. Склад автоматизованого банку даних характеристика та функції основних його блоків.
- •4.Функції скбд та їх характеристика .
- •3.Мовні засоби автоматизованого банку даних.
- •5. Покоління скбд.
- •6. Характеристика етапів проектування бази даних.
- •7.Адміністратор бази даних та його функції.
- •8. Поняття словника-довідника даних його характеристика та призначення.
- •9. Характеристика проектування баз даних на зовнішньому рівні.
- •10. Характериистика підходів до інфологічного проектування баз даних.
- •11.Інструментальні засоби інфологічного проектування.
- •12. Правила агрегації інформаційних об’єктів при інфологічному проектуванні бд.
- •13. Характеристика основних етапів розробки їнфологічної моделі
- •14. Запитувальні зв’язки їх характеристика та правила побудови при інфологічному проектуванні.
- •15. Поняття структурних зв’язків та правила їх побудови при інфологічному проектуванні бази даних.
- •16. Правила побудови реляційної моделі даних.
- •17. Поняття об’єктних та зв’язкових відношень в реляційних бд та суть умови посилкової цілістності даних.
- •18. Суть реляційного підходу до проектування баз даних
- •19. Теорії нормалізації реляційних відношень та її використання при проектуванні бд.
- •20. Порядок приведення реляційних відношень до 3нф(4нф).
- •21. Порядок приведення реляційних відношень до нормальної форми Бойса-Кодда.
- •22. Порядок приведення реляційних відношень до 5нф.
- •23. Поняття та основні вимоги до даталогічного проектування.
- •24. Критерії вибору субд.
- •25. Відображення на ієрархічну модель бд.
- •26. Відображення на мережеву модель бд.
- •27. Відображення на реляційну модель бд
- •28. Особливості та характеристика субд Access.
- •29. Характеристика об’єктів бази даних Access.
- •30. Таблиці в Access та правила їх побудови.
- •Створення нової таблиці в новій базі даних
- •Створення нової таблиці в наявній базі даних
- •31. Характеристика основних типів запитів та способи їх створення в субд Access.
- •33.Характеристика засобів захисту бази даних в субд Access.
- •34. Характеристика засобів Access, які забезпечують безпомилкове введення даних.
- •35.Стратегії розподілення даних в розподіленій базі даних.
- •36.Характеристика та призначення case-засобу Erwin.
- •38.Технологія логічного проектування бд в середовищі Erwin.
- •39. Поняття розподіленої бази даних (рбд) та особливості технології роботи з рбд.
- •40. Характеристика стратегій розподілу даних в розподіленій бд.
- •41. Особливості технології функціонування розподілених баз даних.
- •42.Особливості проектування розподілених баз даних.
- •Передумови розробки концепції сховищ даних.
- •Архітектура сховищ даних.
- •Відмінності проектування сховищ даних від баз даних.
- •Характеристика багатовимірної моделі представлення сховищ даних.
- •Характеристика реляційної моделі представлення сховищ даних.
- •48. Характеристика гібридної моделі представлення сховищ даних.
- •49. Складові сховищ даних та їх характеристика.
- •50. Сутність медодики вимірного моделювання сховищ даних.
- •51. Визначення сховищ та вітрин (кіосків) даних їх призначення та застосування.
- •52. Репозитарій метаданих та його призначення в сховищах даних.
- •1.Поняття автоматизованого банку даних (абд).
- •2.Склад автоматизованого банку даних характеристика та функції основних його блоків.
41. Особливості технології функціонування розподілених баз даних.
Розподілені системи, які підтримують архітектуру клієнт –– сервер, можна ще визначити як системи типу: багато-клієнтів/один-сервер чи багато-клієнтів/багато-серверів. У системах першого типу управління базою даних централізоване і виконується досить просто, оскільки вся база зберігається на одному сервері. У таких системах управління доступом до даних клієнтів зводиться до управління процесами блокування та управління буферами клієнтів.
У системах типу багато-клієнтів/багато-серверів база даних може розміщуватися на кількох серверах і для виконання запитів користувачів потрібна взаємодія серверів одного з одним. Кожна клієнтська машина має свій сервер і на нього направляє запити користувача — нібито працює з централізованою базою. Взаємодії серверів при виконанні запиту прозорі для користувача. У більшості існуючих СУБД реалізовано один із двох типів архітектури клієнт — сервер.
Справді, розподілені СУБД не повинні розрізняти клієнтські та серверні машини. В ідеальному варіанті кожний вузол мережі може виступати залежно від ситуації як клієнт чи як сервер. Така архітектура визначається як рівний-до-рівного. Але поки що немає СУБД, які б підтримували цю архітертуру, бо досить складно на програмному рівні реалізувати розподіл даних по багатьох вузлах, а це призводить до ускладнення протоколів управління даними.
Блокування первинної копії — це управління одночасним доступом, що використовується для баз даних з реплікаціями, в яких копії одних і тих самих даних можуть зберігатися на багатьох вузлах. Одна з таких копій виділяється як первинна, і для доступу до будь-якого елемента даних необхідно встановити блокування на його первинну копію. Множина первинних копій відома всім вузлам розподіленої системи, і запити на блокування надходять на ті вузли, де зберігаються ці копії. Якщо в розподіленій базі даних не використовуються реплікації, то механізм блокування первинної копії зводиться до розподіленого блокування. Механізм блокування первинної копії запропонований в розподіленій версії СУБД Ingres.
Розподілене (деценралізоване) блокування пропонує розподілити обов’язки з управління блокуванням між усіма вузлами системи. Під час блокування згідно з цим механізмом необхідна координація взаємодій менеджерів блокувань кількох вузлів. Цей підхід до блокування усуває недоліки централізованого блокування, пов’язані з перевантаженням централізованого вузла, проте він складніший і характеризується більш високими комунікаційними витратами. Цей алгоритм використовується в системах System R* і NonStop SQL.
Блокувати можна весь файл, окремий його запис чи групу записів. При блокуванні система повинна інформувати інших користувачів по мережі про те, що в даний момент виконано блокування. Проте наявність замка не повинна заважати виконанню операцій пошуку у файлах, їх перегляду чи доступу до отриманих результатів. Замок має захищати лише від паралельного внесення змін різними користувачами.
Загальний побічний ефект усіх розглянутих алгоритмів управління паралельним доступом за допомогою блокувань –– це можливість виникнення тупикових ситуацій. Тупик –– це така ситуація, коло багато запитів створюють цикл, очікуючи зняття захватів іншими запитами з цієї самої множини. Виявлення та усунення тупиків –– це одна з найскладніших задач у розподілених системах.