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

Можливими (найперспективнішими) напрямами аналізу банківської діяльності, для яких побудовано сховище даних, можуть бути:–

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

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

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

Побудова сховища даних потребує вирішення таких основ--них задач, як вибір та освоєння роботи із засобами доступу до даних, до яких можна віднести географічні інформаційні системи (ГІС), засоби добування даних (data mining), системи опера-тив--ного аналізу (OLAP-системи), засоби візуалізації даних, інфор-ма--ційні системи керівників, засоби оброблення статистики, броузери Internet, броузери метаданих, мови програмування 4-го поко-ління (4GL), засоби розробки графічного інтерфейсу користувача, елек--т-ронні таблиці, генератори звітів та ін.

3. Для чого використовуються рядки Умова відбору в QBE?

Для обмеження списку записів, одержуваних в результаті роботи запиту, тільки задовольняючим певним умовам - в бланку запиту передбачені поля для умов відбору. Для кожного поля запиту можна створити свою умову відбору. Якщо це числове поле, то можна указати діапазон значень, що цікавить. Наприклад, в полі Ціна можна задати умову >20, що дозволить вибрати всі книги, ціни яких перевищують цифру 20.

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

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

Для цієї цілі служить спеціальна команда мови SQL, яка виглядає так:

Like [ Текст повідомлення користувачу ]

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

За умовчанням Access визначає тип даних, що вводяться, як Текстовий. Якщо ж параметр задає умову відбору із стовпця з даними типу Числовій або Дата/Время, то необхідно уручну призначити тип даних. Це робиться таким чином:

В режимі конструктора, скопіюйте текст підказки (без квадратних дужок) з поля Умова волок в буфер обміну. Для цього виділіть рядок підказки і натисніть комбінацію клавіш Ctr+С на клавіатурі або скористайтеся пунктом Копіювати, контекстного меню правої кнопки миші.

Виберіть з меню у верхній частині вікна програми, команду Запит - Параметри, для відкриття вікна Параметри запиту.

Вставте текст підказки в полі Параметр. Для цього помістіть курсор в полі і натисніть комбінацію Ctrl+V на клавіатурі. Переконайтеся у відсутності квадратних дужок в тексті. Якщо необхідно, то видалите