- •1. Поняття автоматизованого банку даних (абд).
- •2. Склад автоматизованого банку даних характеристика та функції основних його блоків
- •3. Мовні засоби автоматизованого банку даних.
- •4. Функції скбд та їх характеристика .
- •1. Управлiння даними. Задачами управлiння даних є пiдготовка даних I їх контроль, занесення даних до бази, структуризацiя даних, забезпечення цiлісностi, секретності даних.
- •2. Доступ до даних. Пошук I селекцiя даних, перетворення даних у форму, зручну для подальшого використання.
- •3. Органiзацiя I ведення зв’язку з користувачем. Ведення дiалогу, видача дiагностичних повiдомлень про помилки в роботi з бд I т. Д.
- •5. Покоління скбд.
- •Характеристика етапів проектування бази даних.
- •Адміністратор бази даних та його функції.
- •8. Поняття словника-довідника даних його характеристика та призначення.
- •Характеристика проектування баз даних на зовнішньому рівні.
- •10. Характеристика підходів до інфологічного проектування баз даних.
- •Складові інфологічної моделі та їх характеристика.
- •Правила агрегації інформаційних об’єктів при інфологічному проектуванні бд.
- •13. Характеристика основних етапів розробки інфологічної моделі.
- •14. Інформаційні запити та правила їх побудови при інфологічному проектуванні бд.
- •15. Запитувальні зв’язки їх характеристика та правила побудови при інфологічному проектуванні.
- •16. Поняття структурних зв’язків та правила їх побудови при інфологічному проектуванні бази даних.
- •17. Правила побудови реляційної моделі даних.
- •18. Поняття об’єктних та зв’язкових відношень в реляційних бд та суть умови посилкової цілістності даних.
- •19. Суть реляційного підходу до проектування баз даних
- •20. Теорії нормалізації реляційних відношень та її використання при проектуванні бд.
- •21. Порядок приведення реляційних відношень до 3нф(4нф).
- •22. Порядок приведення реляційних відношень до нормальної форми Бойса-Кодда.
- •23. Порядок приведення реляційних відношень до 5нф.
- •Поняття та основні вимоги до даталогічного проектування.
- •Критерії вибору субд.
- •26. Відображення на ієрархічну модель бд.
- •Відображення на мережеву модель бд.
- •Відображення на реляційну модель бд
- •Особливості та характеристика субд Access.
- •Характеристика об’єктів бази даних Access.
- •32. Характеристика основних типів запитів та способи їх створення в субд Access.
- •34.Характеристика засобів захисту бази даних в субд Access.
- •35. Характеристика засобів Access, які забезпечують безпомилкове введення даних.
- •36. Стратегії розподілення даних в розподіленій базі даних.
- •37. Характеристика та призначення case-засобу AllFusion eRwin Data Modeler.
- •38. Характеристика типів зв’язків в AllFusion eRwin Data Modeler.
- •39. Технологія та особливості логічного проектування бд в середовищі AllFusion eRwin Data Modeler.
- •40. Поняття розподіленої бази даних (рбд) та особливості технології роботи з рбд.
- •41. Характеристика стратегій розподілу даних в розподіленій бд.
- •42. Особливості технології функціонування розподілених баз даних.
- •43. Особливості проектування розподілених баз даних.
- •Передумови розробки концепції сховищ даних.
- •Архітектура сховищ даних.
- •Відмінності проектування сховищ даних від баз даних.
- •47. Характеристика багатовимірної моделі представлення сховищ даних.
- •52. Визначення сховищ та вітрин (кіосків) даних їх призначення та застосування.
- •53. Репозитарій метаданих та його призначення в сховищах даних.
43. Особливості проектування розподілених баз даних.
Особливості проектування розподілених БД полягають у тому, що вони проектуються в розподілених СКБД. На ринку програмних засобів вже давно з’явились розподілені СКБД, які дають змогу підтримувати та обробляти базу даних у багатокориcтувацьких системах. Основною задачею розподіленої СУБД є забезпечення управління доступом до даних багатьох споживачів і цілісності й узгодженості даних в умовах використання мережі ЕОМ. Тобто основна функція таких СУБД –– це координування спільної роботи багатьох користувачів з розподіленою інформацією. Розв’язання проблеми автономності роботи користувачів розподіленої системи створює багато специфічних проблем в організації баз даних, оскільки різні користувачі можуть працювати паралельно з одними й тими самими даними, виконуючи з ними різні перетворення.
Передумови розробки концепції сховищ даних.
Однією з основних передумов розробки концепції сховищ даних стала потреба у вирішенні аналітичних задач, внаслідок чого постало питання оперативного аналізу (OLAP). Вирішувати задачі класу OLAP на основі традиційної БД недоречно, бо це може призвести до конфліктів повязаних з одночасним доступом до БД задач класу OLAP і OLТP. Крім того, в БД зберігається деталізована інформація, а для OLAP-задач потрібна агрегована інформація. В БД зберігаються дані, що характеризують стан обєктівуправління, а для аналізу цього недостатньо. Потрібно використовувати архівні дані із зовнішніх джерел, а також результатів вирішення задач OLТP. Саме ці чинники і призвели до появи сховищ даних.
Архітектура сховищ даних.
Сховище даних складається із чотирьох компонентів: джерела даних (як правило це оперативні системи), області перетворення, області презентації й засобу доступу до даних. Оперативні системи служать для щоденної підтримки бізнесу. До таких систем відносяться, наприклад, системи класу ERPM. Дані із джерел витягають в область перетворення, де вони приводяться до загального формату й потім потрапляють в область презентації, де вони стають доступними для бізнес користувачів за допомогою засобів доступу. Усі компоненти сховища можуть бути розділені логічно, адміністративно й фізично. Кожний компонент відповідає за виконання своїх завдань.
Відмінності проектування сховищ даних від баз даних.
Враховуючи специфіку, cховище даних має такі особливості проектування та побудови:
-отримання інформації з різних джерел даних (у тому числі і з реляційних баз даних) у деталізованому та аґреґованому вигляді (зберігаються результати застосування функцій агрегації – суми, середнього значння, максимуму, мінімуму тощо); при проектуванні БД інформацію ми черпаємо як правило з єдиного джерела.
-багатовимірне подання інформації – ігноруються деякі вимоги нормалізації (дотримують максимум 3-ої нормальної форми), що значно підвищує швидкість опрацювання інформації, оскільки зменшує кількість операцій з’єднання; при проектуванні БД ми маємо одновимірне подання інформації
-наявність метаданих для опису джерел метаданих та структури самого сховища даних – у базах даних також використовують словники для опису структур даних, а у сховищах даних мета дані (словники, дані про дані) повинні будуватися за класифікаційною схемою Захмана. За цією схемою описую об'єкти ( що?), суб'єкти (хто?), місцезнаходження (де?), час (коли?), фактори впливу, чинники (чому?), способи (як?);
- наявність пакетного завантаження даних в сховище даних та вивантаження даних; при проектуванні БД пакетне завантаження відсутнє;
- наявність процедур аналізу даних та отримання нових даних; при проектуванні БД такі процедури відсутні.
- орієнтованість даних на аналітичне, а не на статичне опрацювання. При проектуванні БД дані орієнтовані на статичне опрацювання.