- •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. Особливості проектування сховищ даних.
- •Передумови створення концепції бд .
- •Переваги концепції бд.
34. Поняття об’єкта - зв’язки та його використання при інфологічному проектуванні.
Інформаційний об’єкт –– це деяка сутнiсть ПО, яку необхiдно вiдображувати в БД з точки зору прикладної програми чи користувача БД, і яку можна описати деякою логiчно взаємопов’язаною сукупнiстю атрибутiв.
Якщо в одновимірному запитувальному зв’язку співвідношення Т (Х1, У) = Б:Б, тодi Х1 i У оголошуються як власники двох структурних зв’язків. Підпорядкованим об’єктом оголошується новий об’єкт, який називається об’єктом-зв’язкою.
У структурному зв’язку, де власником є об’єкт Х, напрям руху ВП, а в структурному зв’язку, де власником є кінцевий об’єкт У, напрям руху ПВ. Для об’єкта-зв’язки клас членства в обох зв’язках обов’язковий.
О б’єкти-зв’язки мають бути семантично визначенi, їм присвоюється iм’я i задаються характеристики, тобто визначаються атрибути, якi повиннi входити до їх складу.
Досить часто об’єктом-зв’язкою виступає той об’єкт, який не визначили на бiльш раннiх стадiях проектування. До складу об’єктa-зв’язки обов’язково повиннi входити ключовi атрибути тих об’єктiв, зв’язок мiж якими встановлюється.
35. Обмеження цілісності (бізнес-правила), які накладаються на атрибути бд.
Більшість існуючих в даний час СУБД пропонує в розпорядження розробників ті чи інші засоби реалізації бізнес-правил (чи обмежень цілісності). Поняття цілісності в широкому розумінні цього слова –– це забезпечення достовірності та узгодженості даних у базі даних у будь-який момент часу її функціонування.
Розглянемо обмеження цілісності, які повинні накладатися на окремі атрибути.
Контроль поля за шаблоном - перевіряються довжина та тип поля. Цей вид контролю можна доповнити, створивши так звану маску для введення поля.
Контроль на відповідність певному діапазону (здебільшого для числових полів). Встановлення діапазону та контроль на відповідність йому атрибута дають змогу запобігти явним помилкам, які можуть виникнути при введенні чи внесенні змін у дані.
Існують відкриті й закриті діапазони. Відкритий фіксує лише значення одного з обмежень — верхню чи нижню межу можливої зміни значення атрибута. При відкритому діапазоні задають обидва обмеження.
3. Задання ознаки непорожнього поля. Певні атрибути повинні обов’язково мати якесь конкретне значення і не допускається порожнього поля.
4. Задання можливих значень полів. При цьому задають певний перелік можливих значень полів і вводячи нове значення, перевіряють, чи є відповідне йому значення в заданому переліку.
5. Обмеження переходу з одного стану в інший. Виконання цього обмеження потрібно перевіряти, вносячи зміни у файл даних.
6. Перевірка на унікальність (здебільшого для ключових атрибутів, що визначені як первинні ключі). Ці ключі не повинні мати порожніх значень. Розглянуте обмеження стосується не лише окремого атрибута, а й об’єкта в цілому, тому що первинний ключ є ідентифікатором певного об’єкта. Тому це обмеження щодо об’єкта називається обмеженням його цілісності.
7. Обмеження на значення атрибута. Обмеження цілісності може стосуватись не лише унікальності значень ключових атрибутів; воно може накладатись на будь-який атрибут запису чи певної їх сукупності.
8. Встановлення значення за замовчуванням. Часто одне і те саме значення атрибута може повторюватись кілька разів у різних записах. З метою зменшення помилок під час введення даних та економії часу на цю роботу значення таких атрибутів можна встановлювати за замовчуванням.
9. Обмеження на обов’язкове введення значень. Деякі поля бази даних при внесенні даних не можна пропускати, тобто вони не можуть бути порожніми. Тому на них повинно накладатись таке обмеження, яке б не дозволяло пропускати поля, що підлягають обов’язковому заповненню. До полів, які підлягають обов’язковому заповненню, належать, наприклад, ключові поля.