Типові технологічні засоби пошуку, збирання і нагромадження маркетингової інформації

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

2.8.4 Об'єднання таблиць

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

Розпочнемо з досить простого об'єднання двох таблиць. Об'єднаємо список замовлень з адресами покупців, які зробили ці замовлення. Для цього, створюючи новий запит у діалоговому вікні Додати таблицю, потрібно вибрати два файли: Zakaz.dbf і Pokupec.dbf і лише після цього закрити діалог, натиснувши кнопку Закрити. Цей діалог не закривається автоматично. І якщо кілька разів натискати на кнопку Додати, то відбудеться додавання тої самої таблиці. За правильного виконання операції додавання у зоні вхідних таблиць вікна запиту з'являться два списки з переліком полів таблиці Zakaz і Pokupec.

У таблиці Pokupec кожному покупцеві відповідає певний код, який знаходиться у полі KODP і для різних покупців має різне значення. Таким чином, таблиця Pokupec -- це довідник покупців, у якому кожного покупця можна знайти за його кодом.

У таблиці Zakaz кожному замовленню також відповідає певний код покупця. Але кількість записів з однаковим кодом у цій таблиці не обмежена (вона визначається кількістю замовлень, зроблених конкретним покупцем). Для того щоб довідкові відомості з таблиці Pokupec можна було використовувати у разі виведення інформації з таблиці Zakaz, необхідно визначити зв'язки між записами цих двох таблиць. MS-Query не встановлює зв'язки автоматично. Це повинен робити користувач. Слід зауважити, що імена полів з кодом покупця у таблицях Zakaz і Pokupec можуть збігатися (Zakaz.KODР і Pokupec.KODP), а можуть бути й різними.

2.8.5 Визначення зв'язків (відношень) між таблицями

Для того щоб визначити зв'язки між двома таблицями, потрібно виконати такі дії:

бажано виключити режим Запитувати автоматично (у разі великих розмірів таблиць це значно зменшить витрати часу);

установити курсор миші на ім'я потрібного поля в таблиці, до якої слід приєднати іншу (у нашому прикладі -- поле KODP таблиці Zakaz, тобто Zakaz.KODP);

натиснути ліву кнопку миші і, не відпускаючи її, перемістити курсор миші на ім'я поля другої таблиці (у нашому прикладі -- поле KODP таблиці Pokupec, тобто Pokupec.KODP). Між іменами двох полів різних таблиць з'явиться лінія, що відбиває зв'язок таблиць за відповідними полями.

Альтернативний спосіб визначення співвідношення між двома таблицями -- виконати в меню Таблиця команду Об'єднання.

2.8.6 Визначення властивостей зв'язків

У MS-Query є можливість установлювати різні властивості зв'язків між таблицями.

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

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

Щоб дізнатися про тип встановленого зв'язку або змінити його, треба клацнути мишею на відповідній лінії між таблицями. Ця лінія зв'язку стане виділеною. Подвійне клацання на цьому зв'язку або виконання команди Таблиця/Об'єднання не тільки відкриє діалог Об'єднання, а й покаже параметри саме цього зв'язку. У діалоговому вікні можна встановити будь-який із вказаних типів зв'язку. За умовчання встановлюється перший тип з умовою «дорівнює». Саме такий тип зв'язку потрібно встановити для об'єднання списку замовлень з адресами покупців. Після встановлення зв'язку можна, наприклад, отримати список прізвищ і телефонів покупців з Києва, які замовили 486-й комп'ютер.

2.8.7 Створення нової таблиці

За допомогою MS-Query можна створювати нові таблиці для баз даних. Для цього потрібно виконати команду меню Файл/Визначення таблиці. Відкриється діалог Вибір таблиці. У цьому діалозі потрібно вибрати таблицю, яка використовуватиметься як шаблон для нової. Якщо двічі клацнути на імені таблиці (файла бази даних), то відкриється діалог Перегляд визначення таблиці. У відповідних полях цього діалогу можна визначити ім'я та тип поля (символьне, чисельне і т. ін.) таблиці, довжину цього поля. Можна також додавати нові поля (кнопка Додати) та вилучати існуючі (кнопка Вилучити). Для того щоб завершити створення таблиці і записати її на диск, у першому рядку (Ім'я таблиці) діалогу слід замінити ім'я попередньої таблиці (шаблону) на нове ім'я. За спроби створити таблицю з таким самим ім'ям MS-Query попередить, що така таблиця не може бути створена.

3. Сховища даних

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

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

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

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

Основні компоненти сховища даних наведено на рис. 1. Оперативні дані збираються з різних джерел, очищуються, узгоджуються, інтегруються й складаються в реляційне сховище. Потім вони (цілком або частково) підготовлюються для OLAP-аналізу. Вони можуть бути завантажені в спеціальну БД OLAP або залишені в реляційному сховищі.

Рис. 1. Основні компоненти сховища даних

Дані реляційного сховища доступні для аналізу за допомогою різноманітних засобів побудови звітів. Але ті традиційні звіти, які створюються програмістами і призначені для безпосереднього використання особами, що приймають рішення, хоча і є надзвичайно простими у застосуванні, проте жорстко обмежені у функціональності (позбавлені гнучкості). Вони отримуються за допомогою певної множини запитів і, будучи достатніми для повсякденного застосування, неспроможні відповісти на всі запитання до наявних даних, що можуть виникнути при прийнятті рішень. Результатом виконання цих запитів, як правило, є багатосторінкові звіти. Особа, що приймає рішення, не може їх «прокрутити», «розгорнути» або «згорнути», щоб одержати бажане уявлення даних. Тому після ретельного вивчення цих звітів у неї з'являється нова серія запитань. Проте кожний новий непередбачений запит має бути спочатку формально описаний, закодований програмістом -- тільки після цього він може бути виконаний. Час чекання в такому разі може сягати кількох годин і навіть днів, що здебільшого неприйнятне. Отже, зовнішня простота отримання інформації, чого активно домагається більшість замовників інформаційно-аналітичних систем, обертається катастрофічною втратою гнучкості. За не дуже великих обсягів даних у реляційному сховищі та не дуже складних взаємозв'язків між таблицями непоганий спосіб виходу з цієї ситуації -- відбір потрібних даних і перенесення їх для наступного аналізу в Excel за допомогою програми MS Query. Але у разі роботи з великою кількістю реляційних таблиць така задача залишається надто складною і проведення оперативного аналізу даних стає практично неможливим.

Тому попереднє збирання, очищення та інтегрування даних -- це ще не все, що потрібно кінцевому користувачеві. Йому потрібні також:

зручніша, ніж це можуть забезпечити реляційні таблиці, структура даних (з погляду спрощення доступу до даних);

гнучкі інструменти для обчислень і перегляду інформації, які дають змогу просто й зручно розгортати і згортати дані, забезпечуючи можливість як перегляду деталізованої інформації, так і комплексного погляду на зібрану інформацію, її узагальнення та агрегацію;

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

Одним із засобів вирішення перших двох проблем є OLAP (On-Line Analytical Processing -- оперативне аналітичне оброблення) -- технологія організації даних відповідно до методів їх аналізу, що зменшує витрати часу і зусилля на створення необхідних звітів. Хоча OLAP і не є необхідним атрибутом сховища даних, але саме він найчастіше застосовується для аналізу нагромаджених у сховищі відомостей.

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

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