
- •1. Поняття автоматизованого банку даних (абд).
- •2. Склад автоматизованого банку даних характеристика та функції основних його блоків.
- •4.Функції скбд та їх характеристика .
- •3.Мовні засоби автоматизованого банку даних.
- •5. Покоління скбд.
- •6. Характеристика етапів проектування бази даних.
- •7.Адміністратор бази даних та його функції.
- •8. Поняття словника-довідника даних його характеристика та призначення.
- •9. Характеристика проектування баз даних на зовнішньому рівні.
- •10. Характериистика підходів до інфологічного проектування баз даних.
- •11.Інструментальні засоби інфологічного проектування.
- •12. Правила агрегації інформаційних об’єктів при інфологічному проектуванні бд.
- •13. Характеристика основних етапів розробки їнфологічної моделі
- •14. Запитувальні зв’язки їх характеристика та правила побудови при інфологічному проектуванні.
- •15. Поняття структурних зв’язків та правила їх побудови при інфологічному проектуванні бази даних.
- •16. Правила побудови реляційної моделі даних.
- •17. Поняття об’єктних та зв’язкових відношень в реляційних бд та суть умови посилкової цілістності даних.
- •18. Суть реляційного підходу до проектування баз даних
- •19. Теорії нормалізації реляційних відношень та її використання при проектуванні бд.
- •20. Порядок приведення реляційних відношень до 3нф(4нф).
- •21. Порядок приведення реляційних відношень до нормальної форми Бойса-Кодда.
- •22. Порядок приведення реляційних відношень до 5нф.
- •23. Поняття та основні вимоги до даталогічного проектування.
- •24. Критерії вибору субд.
- •25. Відображення на ієрархічну модель бд.
- •26. Відображення на мережеву модель бд.
- •27. Відображення на реляційну модель бд
- •28. Особливості та характеристика субд Access.
- •29. Характеристика об’єктів бази даних Access.
- •30. Таблиці в Access та правила їх побудови.
- •Створення нової таблиці в новій базі даних
- •Створення нової таблиці в наявній базі даних
- •31. Характеристика основних типів запитів та способи їх створення в субд Access.
- •33.Характеристика засобів захисту бази даних в субд Access.
- •34. Характеристика засобів Access, які забезпечують безпомилкове введення даних.
- •35.Стратегії розподілення даних в розподіленій базі даних.
- •36.Характеристика та призначення case-засобу Erwin.
- •38.Технологія логічного проектування бд в середовищі Erwin.
- •39. Поняття розподіленої бази даних (рбд) та особливості технології роботи з рбд.
- •40. Характеристика стратегій розподілу даних в розподіленій бд.
- •41. Особливості технології функціонування розподілених баз даних.
- •42.Особливості проектування розподілених баз даних.
- •Передумови розробки концепції сховищ даних.
- •Архітектура сховищ даних.
- •Відмінності проектування сховищ даних від баз даних.
- •Характеристика багатовимірної моделі представлення сховищ даних.
- •Характеристика реляційної моделі представлення сховищ даних.
- •48. Характеристика гібридної моделі представлення сховищ даних.
- •49. Складові сховищ даних та їх характеристика.
- •50. Сутність медодики вимірного моделювання сховищ даних.
- •51. Визначення сховищ та вітрин (кіосків) даних їх призначення та застосування.
- •52. Репозитарій метаданих та його призначення в сховищах даних.
- •1.Поняття автоматизованого банку даних (абд).
- •2.Склад автоматизованого банку даних характеристика та функції основних його блоків.
6. Характеристика етапів проектування бази даних.
1. Визначення мети створення бази даних. На першому етапі проектування бази даних необхідно визначити мету створення бази даних, основні її функції та інформацію, яку вона повинна містити. Тобто потрібно визначити основні теми таблиць бази даних та інформацію, що міститимуть поля таблиць.
2.Визначення таблиць, які повинні містити база даних.
Одним із найскладніших етапів у процесі проектування бази даних є розробка таблиць, тому що результати, які повинна видавати база даних (звіти, вихідні форми тощо), не завжди дають повне уявлення про структуру таблиці. Отже, у разі проектування таблиць слід керуватися такими основними принципами:
— інформація в таблиці не повинна дублюватися. Не повинно бути повторень і між таблицями.;
кожна таблиця повинна містити інформацію лише на одну тему. Дані на кожну тему опрацьовуються набагато легше, якщо вони утримуються в незалежних одна від іншої таблицях.
3. Визначення необхідних у таблиці полів. Кожна таблиця містить інформацію на окрему тему, а кожне поле в таблиці містить окремі дані по темі таблиці. Під час розробки полів для кожної таблиці необхідно пам'ятати:
— кожне поле має бути пов'язане з темою таблиці;
— не рекомендується включати до таблиці дані, що є результатом виразу;
— у таблиці має бути вся необхідна інформація;
— інформацію варто розбивати на найменші логічні одиниці.
4. Задання індивідуального значення кожному полю. Кожна таблиця повинна містити поле чи набір полів, що задаватимуть індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають основним ключем.
5. Визначення зв'язків між таблицями. Після розподілу даних по таблицях і визначення ключових полів необхідно вибрати схему для зв'язку даних у різних таблицях. Для цього потрібно визначити зв'язки між таблицями.
6. Відновлення структури бази даних.
Після проектування таблиць, полів і зв'язків необхідно ще раз переглянути структуру бази даних і виявити можливі недоліки.
7. Додавання даних і створення інших об'єктів бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запити, форми, звіти, макроси та модулі.
8. Використання засобів аналізу в СУБД. Наприклад, у СУБД Microsoft Access є два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таблицю, в разі потреби пропонує нову її структуру та зв'язки, а також переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації з її поліпшення, а також реалізує їх.
7.Адміністратор бази даних та його функції.
До складу організаційних засобів АБД входять персо нал, який працював над створенням і веденням БД, а також система нормативно-технологічної та інструктивно-методичної документації з організації та експлуатації БД.
АБД не може функціонувати без участі в цьому процесі персоналу. З банком даних взаємодіють дві категорії персоналу. Перша— це користувачі систем, для потреб яких створюються АБД; їх ще називають кінцевими користувачами.
Друга група персоналу, що взаємодіє з АБД, — це адміністрація бази даних. Залежно від обсягу бази даних, специфіки та особливостей СКБД служба адміністрації може відрізнятись як за чисельністю складу, так і за рівнем фахової підготовки.
До складу групи адміністрування можуть входити системні аналітики, проектувальники структур даних і зовнішнього щодо банку інформаційного забезпечення, проектувальники технологічних процесів обробки даних, системні та прикладні програмісти, оператори, спеціалісти з технічного обслуговування. У комерційних базах даних до адміністративної групи обов'язково мають входити спеціалісти з маркетингу.
Адміністратор — це спеціаліст, який має цілковите уявлень про інформаційні потреби користувачів, співпрацює з ними в тісному контакті й відповідає за завантаження, ведення та підтримування БД в актуальному стані, а також за захист та ефективність функціонування системи.
Основні функції адміністратора: спільна робота з проектувальниками задач для визначення умов використання БД, розробка опису БД і початкове її завантажування, підтримування цілісності БД, організація захисту зберігання даних, відновлення БД у разі виникнення помилок програмного забезпечення чи збої пристроїв, які призводять до руйнування БД, нагромадження статистики по роботі з БД, реорганізація та реструктуризація БД відповідно до зміни потреб.
Різноманітні задачі, які повинен розв'язувати адміністратор, можна поділити відповідно до етапів розробки АБД на чотири групи: планування, проектування, експлуатація і використання [49]. При плануванні адміністратор бере участь у виборі програмного забезпечення та обладнання. Він співпрацює з кінцевими користувачами, аби встановити реальні потреби, мету та вимоги прикладних програм до бази даних. Адміністратор бере участь у довгостроковому плануванні, в якому визначаються перспективи розвитку системи та розширення бази даних.
Під час проектування адміністратор надає спеціалістам необхідні дані для розробки логічної та фізичної моделей даних. Якщо виникають нові вимоги до даних, адміністратор визначає, як можна включити ці дані до баз даних і управляє процесом внесення змін.
На етапі експлуатації до обов'язків адміністратора входять розробка і контроль дій, які гарантують збереження цілісності бази даних, включаючи процедури її копіювання та відтворення, а також визначення засобів захисту інформації за допомогою механізму управління доступом до ресурсів БД.
Окрім того, адміністратор увесь час спілкується з користувачами бази даних, тому він визначає стандарти на зміст і використання даних, супроводжує спеціальне програмне забезпечення роботи з базою даних (словники даних, статистику роботи з БД тощо), проводить консультації та здійснює ведення БД.
Адміністратор взаємодіє також із системними програмістами, вирішуючи питання технології й доведення її до відповідних експлуатаційних характеристик, спілкується і співпрацює із системними програмістами в разі зміни версій системи чи операційного середовища.
При супроводженні баз даних, особливо розподілених, адміністраторові часто доводиться співпрацювати із співробітниками, котрі відповідають за експлуатацію технічних засобів АБД. Така співпраця пов'язана з необхідністю виявлення причин збоїв обладнання, які призводять до руйнування баз даних, і розробки заходів запобігання цього в ході подальшої експлуатації системи.
У звітах ANSI/X3/SPARC виділяється також адміністратор предметної області, який відповідає за синтез опису предметної області, відображеної в базі даних.