- •1.Передумови створення концепції бд .
- •2. Переваги концепції бд.
- •3. Характеристика структури абд .
- •4. Класифікація абд.
- •5. Системи управління базою даних (субд) та її функції.
- •6. Характеристика першого та другого покоління субд.
- •7. Характеристика третього покоління субд та його переваги.
- •8. Зовнішній етап проектування бд та його характеристика.
- •9. Інфологічний етап проектування бд та його характеристика.
- •10. Даталогічний етап проектування бд та його характеристика.
- •11. Внутрішній (фізичний) етап проектування бд та його характеристика.
- •12. Мовні засоби абд.
- •13. Визначення відкритих та закритих систем та їх характеристика.
- •14. Драйвер odbc та його призначення.
- •16. Категорії користувачів адб та їх характеристика.
- •17. Адміністратор бд його призначення та функції.
- •18. База даних, фонд та архів даних визначення та призначення.
- •19. Підходи до проектування на зовнішньому рівні.
- •20. Сутність проектування на зовнішньому рівні.
- •21. Вимоги до iнфологiчної моделі.
- •22. Підходи до інфологічного проектування бд
- •23. Інструментальні засоби iнфологiчного проектування.
- •24. Схема взаємозв’язку робіт при інфологічному проектуванні.
- •25. Правила агрегації атрибутів в інформаційні об’єкти.
- •26. Зовнішнє кодування його сутність та використання при інфологічному проектуванні.
- •28. Виявлення та опис інформаційних запитів до бд.
- •29. Поняття запитувального зв’язку їх формальний опис та різновиди.
- •30. Аналіз і зведення запитувальних зв’язків до канонічного вигляду (перетворення № 1).
- •31. Аналіз і зведення запитувальних зв’язків до канонічного вигляду (перетворення № 2).
- •32. Аналіз і зведення запитувальних зв’язків до канонічного вигляду (перетворення № 3).
- •33. Правила побудови структурних зв’язків.
- •34. Поняття об’єкта - зв’язки та його використання при інфологічному проектуванні.
- •35. Обмеження цілісності (бізнес-правила), які накладаються на атрибути бд.
- •36. Характеристика процедури перевірки інфологічної моделі на коректність.
- •37. Мета й завдання даталогiчного проектування.
- •38. Критерії вибору субд загального характеру.
- •39. Критерії вибору субд з точки зору підтримки роботи прикладного програмного забезпечення.
- •40. Відображення iнфологiчної моделі на ієрархічну.
- •41.Відображення інфологічної моделі на сіткову.
- •55.Переваги нормалізації відношень.
- •56.Особливості організації бази даних та характеристика об’єктів в Access.
- •57.Типи даних, поняття первинного та вторинного ключів в Access.
- •58.Типи зв"язків між таблицями та їх підтримка в Access.
- •59.Створення зовнішнього само і тета-об"єднання таблиць в в Access.
- •Само об’єднання - зв’язування полів однієї таблиці на умові їх спів падання. (приклад, відображення всіх внутрішньобанківських платежів).
- •60.Правила побудови схеми даних в Access.
- •Загальна характеристика мови sql та її застосування в субд Access.
- •63. Характеристика основних типів запитів для яких викоритсовується sql в Access
- •64. Форми в access , їх призначення та характеристика як інтерфейсного засобу
- •65. Характеристика елементів управління формою в access
- •66. Запити в access та їх класифікація
- •67.Оптимізація запитів (оз)та засоби підвищення продуктивності бд в Access.
- •68. Операції адміністрування бд в Access.
- •Загальна характеристика case-засобів для автоматизації проектування баз даних та інформаційних систем.
- •Характеристика пакета s-Designor як case-засобу для проектування баз даних. Основні можливості s-Designor.
- •Інструментарій s-Designor та режими роботи s-Designor.
- •Концептуальне моделювання – створення cdm-моделі.
- •Фізичне моделювання – створення pdm-моделі.
- •Поняття трігерів і зберігаємих процедур та їх використання в бд.
- •77. Визначення та характеристика розподіленої бд.
- •78.Характеристика централізованої стратегії розподілення даних в бд.
- •81. Особливості технології функціонування розподілених бд.
- •82. Сутність механізму підтримки транзакцій в розподілених бд.
- •83. Сутність механізму підтримки реплікацій в розподілених бд.
- •84. Вимоги до технологiї створення I ведення бд.
- •85. Характеристика технологiчної операцiї завантаження бд.
- •86. Характеристика технологiчної операцiй дублювання I вiдновлення бд.
- •87. Характеристика основних можливих випадків руйнування бд та операції по її відновленню.
- •88. Характеристика технологiчної операцiй реорганiзацiя I реструктуризацiя бд.
- •89. Характеристика технологiчної операцiї актуалізації бд.
- •90. Поняття сховища даних та передумови його створення.
- •91. Основні характеристики сховищ даних.
- •92. Переваги сховища даних та клас задач для яких вони використовуються.
- •93. Архітектура сховищ даних.
- •95. Характеристика molap моделі сховища даних .
- •96. Характеристика rolap моделі сховища даних.
- •98. Поняття кіоска (вітрини) даних та його застосування в системах обробки даних.
- •99. Особливості проектування сховищ даних.
- •Передумови створення концепції бд .
- •Переваги концепції бд.
23. Інструментальні засоби iнфологiчного проектування.
Основні інструментальні засоби інфологічної моделі:
атрибут – поіменована мінімальна логічно неподільна одиниця інформації. Інколи це поняття ототожнюють з поняттям реквізит (поняття зовнішнього рівня), поле (поняття внутрішнього рівня).
інформаційний обєкт (ІО) – це деяка сутність ПО, яка характеризує певний процес, подію чи явище. Характеристиками ІО виступають атрибути. Інколи поняття ІО ототожнюють з файлом БД , реляційною таблицею.
інформаційний запит – це словесний опис інформаційної потреби користувача чи прикладної програми, який вміщує перелік ІО, що приймають участь його реалізації.
запитувальний звязок – будується на основі запиту. Представляє собою структурований опис інформаційного запиту, в якому відображені обєкти, необхідні для його реалізації з врахуванням навігації між ними. Навігація – це послідовність пошуку та переходу від одного обєкту до іншого при реалізації запиту.
структурний звязок – це графічне відображення ієрархічного звязку між парами ІО, один з яких виступає головним (власником звязку), а другий – підпорядкованим (підлеглим) обєктом.
24. Схема взаємозв’язку робіт при інфологічному проектуванні.
Схему взаємозв’язку роб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 синонiмiчнi його назви вилучити зі списку. Складаючи список атрибутiв, можливо, необхiдно буде виконати узагальнення - деяку сукупнiсть атрибутiв замiнюють одним атрибутом, який узагальнює сутнiсть представленої групи.
2. Агрегац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ж атрибутами.
3. Перевiрка вiдповiдностi отриманих об’єкт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нюються на код.
5. Вид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 запиту.
6. Кожний запит необхiдно подати в структурованому виглядi вiдповiдним запитувальним зв’язком. Узагальнена форма запитувального зв’язку така:
,
де Х1, Х2, ..., Хn –– початковi об’єкти, якi потрiбно розмістити в порядку iнформацiйного пошуку чи в порядку зменшення групувальної ознаки об’єктiв;
У –– кiнцевий об’єкт, який уособлює мету реалiзацiї запиту (вiн має бути завжди один).
7. Перевірка запитувальних зв’язків на вiдповiднiсть умовам канонiчностi. Канонiчний запитувальний зв’язок –– це такий багатовимiрний зв’язок, у якому: тип спiввiдношення мiж будь-якими двома початковими об’єктами може бути лише Б:Б; тип спiввiдношення мiж будь-яким початковим i кiнцевим об’єктaми не може бути Б:1.
8. Побудова структурних зв’язкiв мiж iнформацiйними об’єктами i графiчну побудову iнфологiчної моделi.
9. Перев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 допускається вилучати структурні зв’язки, якщо решта зв’язків забезпечують повне та коректне виконання всіх інформаційних запитів. Виконуючи ці перетворення, можна навіть вилучати об’єкти-зв’язки, а також узагальнювати деякі об’єкти.