- •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. Репозитарій метаданих та його призначення в сховищах даних.
Поняття та основні вимоги до даталогічного проектування.
На етапi даталогiчного проектування здiйснюється перехiд вiд iнфологiчної моделi ПО до логiчної (даталогiчної) моделi, яка підтримується засобами конкретної СУБД. Процес переходу вiд iнфологiчної до даталогiчної моделi називається вiдображенням.
Даталогiчна модель являє собою базу даних, структуровану на логiчному рiвнi й орiєнтовану на конкретну СУБД. Перш нiж виконати даталогiчне проектування, необхiдно вибрати СУБД. Основні вимоги до датологічного проектування: правильний й обґрунтований вибір СКБД, висока кваліфікація спеціаліста і доскональне знання ним всіх тонкощів проектування в обраній СКБД, бо все ще не знайдено формалiзованих методiв, якi б давали змогу однозначно виконати даталогiчне проектування. Тому його результат багато в чому залежить вiд умiння та рiвня квалiфiкацiї спецiалiстiв, якi здійснюють проектнi розробки. В результатi даталогiчного проектування можна отримати кiлька варiантiв побудови логiчної моделi даних. Тому важливим моментом є оцiнка отриманих моделей і вибiр найбiльш оптимального варiанта.
Отриманий результат передусім потрібно оцiнити з точки зору вiдповiдностi наявним машинним ресурсам. У разі невiдповiдностi цим обмеженням потрiбно здійснити перепроектування БД. Крiм того, на отриманiй моделi необхiдно перевiрити умови виконання всіх запитiв користувачiв i вимог прикладних програм, тобто умову адекватностi логiчної моделi iнформацiйнiй моделi предметної областi.
Критерії вибору субд.
Вибiр СУБД — це складна задача, яка передує даталогiчному проектуванню i при розв’язаннi якої потрiбно оцiнити дуже багато факторiв . СУБД можна вибирати на пiдставi їх аналiзу за такими параметрами.
1. Загальні характеристики. До цих характеристик належать тип ЕОМ, операцiйне середовище, тип логiчної моделi бази даних, кiлькiснi обмеження СУБД (максимальне число записiв у файлi та його максимальний обсяг, максимальне число iндексiв на один файл БД тощо), наявнiсть русифiкованої версiї, фiрма-виробник, обсяг оперативної пам’ятi для системи, необхiднiсть використання постiйної пам’ятi, тип системи (вiдкрита, закрита), мова системи (власна, СІ, Паскаль та iн.), кiлькiсть версiй, що свiдчить про попит на систему i спроби виробника вдосконалити систему, наявнiсть версiї, що пiдтримує розподiлену базу даних.
2. Управління даними. До цих факторів належать:
можливість підтримувати записи змінної довжини, багатозначні атрибути і двонапрямлені зв’язки;
наявність засобів автоматизації проектування;
підтримка та автоматизоване ведення словника даних;
автоматизоване протоколювання роботи системи (фіксація часу, паролів користувачів і стану системи при вході в БД і виході з неї, статистика роботи системи тощо);
наявність засобів контролю з боку системи за внесенням змін з точки зору збереження посилкової цілісності;
наявність засобів автоматизованого відновлення й захисту інформації (криптографування, шифрування даних тощо).
Засоби підтримки прикладного програмного забезпечення. До цих параметрiв належать:
наявнiсть мови запитiв на базi SQL чи iншої мови;
наявнiсть генератора програм і генератора звiтiв;
можливiсть захисту програмного продукту;
наявнiсть власного редактора;
можливiсть пiдтримувати вiконний iнтерфейс.
4. Засоби підтримки роботи в мережі. Параметрами, які визначають можливість роботи в мережі, є такі:
можливiсть роботи в глобальнiй мережi;
можливiсть роботи в локальнiй мережi;
наявнiсть автоматизованих засобiв стеження за узгодженiстю та цiлiснiстю даних мережi при колективному використаннi даних (фото-графування стану даних чи iншi засоби). Дiю цього механiзму можна пояснити так. На початку виконання запиту роблять копiї «фотографiї» всіх файлiв, якi беруть участь у його реалiзацiї. Таким чином можна виконувати запити будь-якої складностi, тому що всi коректури, внесенi iншими користувачами в файли БД протягом виконання запиту, не впливають на його результат;
наявнiсть механiзму встановлення замкiв чи виконання захватiв при паралельному внесеннi змiн у файли БД. Замок чи захват встановлюється на файл БД на перiод внесення змiн одним користувачем. Замок захищає лише вiд паралельного внесення змiн; файл доступний для проведення всіх iнших операцiй;
механiзм стеження за часом виконання транзакцiй. Цей механiзм необхiдний для попередження зависання системи при колективному використаннi даних. Якщо лiмiт допустимого часу для виконання тразакцiї вичерпано, то її вiдмiнюють, i БД повертається в початковий стан.