- •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. Репозитарій метаданих та його призначення в сховищах даних.
14. Інформаційні запити та правила їх побудови при інфологічному проектуванні бд.
Інформаційний запит (дал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йного запиту.
Oписуючи запит, також потрiбно враховувати режим його виконання. Режими бувають одиночними i множинними. Одиночний режим — це такий, коли запит виконується для одного екземпляра початкового об’єкта: наприклад, «Для заданого ПОСТАЧАЛЬНИКА ... ». Множинний режим означає багаторазове виконання запиту для всiх екземплярiв початкового об’єкта чи їх пiдмножини: наприклад, «Для всiх ПОСТАЧАЛЬНИКIВ ... ». Отож, коли в запитi вказано «для всiх» чи «для кожного», то передбачається виконання запиту для багатьоx екземплярiв початкового об’єкта. Це свiдчить про те, що при реалiзацiї алгоритму екземпляри даного об’єкта вибирають i обробляють послiдовно. Якщо в запитi вказано слова «для заданого», «для певного», це значає, що запит виконується для конкретного єдиного екземпляра початкового об’єкта, пошук якого при реалiзацiї запиту можна виконувати за ключем.
15. Запитувальні зв’язки їх характеристика та правила побудови при інфологічному проектуванні.
Інформаційний запит (дал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, Х2, ..., Хn –– початков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.