9. Визначення сховищ та вітрин (кіосків) даних їх призначення та застосування.

Сховище даних — це інтегрований накопичувач даних, які збираються з різних систем та джерел і використовуються для бізнес-аналізу та прийняття обгрунтованих стратегічних рішень.

Сховище даних (Data Warehouse) — це предметно орі­єнтована, інтегрована, прив'язана до часу та незмінна сукупність даних, призначена для підтримки прийняття рішень.

Дані в сховищі даних організовані від­повідно до основних напрямів діяльності підприємства чи фірми (замовники, продажі, склад і т. п.). Це — відмінність сховищ даних від організації оперативної БД, в якій дані організуються відповід­но до процесів (відвантаження товару, виписка рахунків і т. п.). Предметна організація даних не лише спрощує проведення аналізу, але й значно прискорює виконання аналітичних розрахунків. Тоб­то сховища орієнтовані на бізнес-поняття, а не на бізнес-процеси.

Перш ніж завантажити дані до сховища вони перевіряються, певним чином відбираються, приводяться до'одні го єдиного способу кодування, виду та формату і в необхідній мі. агрегуються (тобто обраховуються сумарні показники). З цьои моменту вони представляються користувачеві у вигляді єдиної» інформаційного простору, які набагато простіше аналізувати

Кіоски, або вітрини, даних {data marts) — це певна підмножи-на корпоративних даних, які характеризують конкретний аспект діяльності корпорації, наприклад роботу конкретного підрозділу. Кіоск може вміщувати як агреговані, так і первинні дані певної предметної області. Кіоск може отримувати дані з корпоративно­го сховища даних (залежний кіоск) чи бути незалежним і тоді джерелом поповнення його даними будуть оперативні БД. Розро­бка кіоску даних потребує значно менше часу і в середньому за­ймає приблизно 3—4 місяці.

10. Характеристика етапів проектування бази даних.

1. Визначення мети створення бази даних. На першому етапі проектування бази даних необхідно визначити мету створення бази даних, основні її функції та інформацію, яку вона повинна містити. Тобто потрібно визначити основні теми таблиць бази даних та інформацію, що міститимуть поля таблиць.

2.Визначення таблиць, які повинні містити база даних.

Одним із найскладніших етапів у процесі проектування бази даних є розробка таблиць, тому що результати, які повинна видавати база даних (звіти, вихідні форми тощо), не завжди дають повне уявлення про структуру таблиці. Отже, у разі проектування таблиць слід керуватися такими основними принципами:

— інформація в таблиці не повинна дублюватися. Не повинно бути повторень і між таблицями.;

кожна таблиця повинна містити інформацію лише на одну тему. Дані на кожну тему опрацьовуються набагато легше, якщо вони утримуються в незалежних одна від іншої таблицях.

3. Визначення необхідних у таблиці полів. Кожна таблиця містить інформацію на окрему тему, а кожне поле в таблиці містить окремі дані по темі таблиці. Під час розробки полів для кожної таблиці необхідно пам'ятати:

— кожне поле має бути пов'язане з темою таблиці;

— не рекомендується включати до таблиці дані, що є результатом виразу;

— у таблиці має бути вся необхідна інформація;

— інформацію варто розбивати на найменші логічні одиниці.

4. Задання індивідуального значення кожному полю. Кожна таблиця повинна містити поле чи набір полів, що задаватимуть індивідуальне значення кожного запису в таблиці. Таке поле чи набір полів називають основним ключем.

5. Визначення зв'язків між таблицями. Після розподілу даних по таблицях і визначення ключових полів необхідно вибрати схему для зв'язку даних у різних таблицях. Для цього потрібно визначити зв'язки між таблицями.

6. Відновлення структури бази даних.

Після проектування таблиць, полів і зв'язків необхідно ще раз переглянути структуру бази даних і виявити можливі недоліки.

7. Додавання даних і створення інших об'єктів бази даних. Якщо структури таблиць відповідають поставленим вимогам, то можна вводити всі дані. Потім можна створювати будь-які запити, форми, звіти, макроси та модулі.

8. Використання засобів аналізу в СУБД. Наприклад, у СУБД Microsoft Access є два інструменти для вдосконалення структури баз даних. Майстер аналізу таблиць досліджує таблицю, в разі потреби пропонує нову її структуру та зв'язки, а також переробляє її. Аналізатор швидкодії досліджує всю базу даних, дає рекомендації з її поліпшення, а також реалізує їх.

12.Х-ка ф-цій адміністратора БД

Адміністратор БД відповідає за цілісність інформаційних ресурсів компанії. На ньому лежить відповідальність за створення, оновлення та збереження пов'язаних між собою резервних копій файлів, виходячи із завдань підприємства. Ця людина має в найдрібніших подробицях знати існуючі механізми відновлення програмного забезпечення БД.

Можливі ситуації, при яких адміністратору БД буде потрібно на основі логічних прикладних моделей створювати елементи фізичної схеми, а також підтримувати зв'язок користувачів із системою і забезпечувати відповідний рівень інформаційної безпеки, стежачи за тим, щоб доступ до даних мали тільки ті люди, які його потребують.

Адміністратор БД повинен вміти визначати вузькі місця системи, що обмежують її продуктивність, налаштовувати SQL і програмне забезпечення СУРБД і володіти знаннями, необхідними для вирішення питань оптимізації швидкодії БД.