- •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. Особливості проектування сховищ даних.
- •Передумови створення концепції бд .
- •Переваги концепції бд.
86. Характеристика технологiчної операцiй дублювання I вiдновлення бд.
Операції відновлення виконують у випадках часткового пошкодження чи повного знищення файлів БД. Технологія ведення файлів БД повинна бути зпроектована таким чином щоб можна було відновити їх в випадку зруйнування. Деякі СУБД мають змогу відновлювати інформацію в деяких випадках її пошкодження. Так, Microsoft Access має спеціальну команду відновлення бази даних, коли її пошкодження сталося в результаті незапланованої зупинки Access (наприклад, «зависання» системи).
З метою забезпечення відновлення БД, на випадок її зруйнування, необхідно з певною періодичністю виконувати резервне копіювання абсолютно всіх файлів БД. Адміністратором складається графік проведення таких копіювань. Деякі СУБД мають автоматичні засоби ведення журналу, в якому фіксуються всі дії, які виконувались з БД і при цьому ідентифікується користувач, який виконував ці дії, фіксується дата і час цих змін, іноді записується копія до і після внесення змін.
В звичайній системі (бухгалтерія) необхідно мати лише програму, яка б Фіксувала всі внесені зміни у відповідному файлі коректур. Цей файл повинен бути певним чином захіщений. Відновлення БД при наявності страхових копій і файла чи журнала коректур полягає у виконанні наступних дій:
Виявити причину, яка призвела до зруйнування файла БД і по можливості ввести якійсь допоміжний механізм, який би надалі запобігав би таким зруйнуванням.
Необхідно обробити разом файл коректур і файл, який вміщує резервну копію і внести відповідні зміни в цю копію, тобто повинна бути відповідна програма внесення змін в файл коректур. Якщо такої програми немає, то зміни вносяться вручну з відповідного журнала “Реєстрації внесення змін в файл БД”. Потім файл коректур знищується і робиться нове копіювання. У випадку часткового зруйнування файлів БД, коли з ним проводились якись розрахунки, то ці розрахунки необхідно повторити на відновленій БД.
87. Характеристика основних можливих випадків руйнування бд та операції по її відновленню.
Розглянемо можливі ситуації пошкодження БД.
Індивідуальний відкіт транзакції. Ця ситуація може виникнути, коли відкіт ініціюється оператором чи системою, при виникненні виняткової ситуації в прикладній програмі (наприклад, ділення на нуль) та при інших помилках програмного забезпечення. Для відновлення бази даних необхідно усунути наслідки дій операторів модифікації бази даних, які виконувалися в цій транзакції.
М’який збій. Така ситуація може виникнути після аварійного вимкнення електроенергії в мережі, при збої процесора з невстановлених причин і т.п. У цьому разі втрачається та частина бази даних, яка в момент збою розміщувалася в буферах оперативної пам’яті.
Жорсткий збій. Ця ситуація пов’язана з поломкою зовнішнього пристрою, на якому розміщена база даних. Ця ситуація за досить високої надійності пристроїв зовнішньої пам’яті може виникати дуже рідко, але все одно такий варіант пошкодження БД потрібно передбачати і мати засоби відновлення БД.
З метою забезпечення відновлення бази даних на випадок її руйнування необхідно періодично виконувати страхове копіювання файлів бази даних.
Відновлення бази даних передбачає виконання таких дій.
1. Виявляють помилку, яка призвела до руйнування бази даних, аналізують її з точки зору введення якогось допоміжного механізму, якщо це, звичайно, можливо, аби надалі запобігти виникненню таких помилок.
2. Виконують злиття страхової копії з файлом коректур, який відображує внесені зміни в базу даних з часу останнього страхового копіювання.
3. Якщо було частково зруйновано файли бази даних і на них виконували якісь розрахунки, то їх необхідно повторити на відновленій базі даних.