Дайте визначення автоматизованого робочого місця бухгалтера та охарактеризуйте його призначення 7 страница

Крім стандарту SQL-86, існує комерційний стандарт мови SQL, який розроблений консорціумом виробників баз даних - SQLAccessGroup. Варіант мови, створений цією групою, використовується більшістю систем і дозволяє їм «розуміти» одна одну. Для всіх основних варіантів мови SQL було розроблено стандартний інтерфейс мови CLI (Common Language Interface). Фірмою Microsoft цей інтерфейс було формалізовано і він отримав назву ODBC (Open Data Basse Connectiviti - відкритий доступ до даних). ODBC - це драйвер, що забезпечує інтерфейс доступу до даних, які зберігаються, під управлінням різних систем керування базами даних. За допомогою ODBC вирішується проблема розуміння систем керування базами даних одна одною. Крім SQL, поширеною є також мова запитів QBE (Query By Example) - це реалізація запитів за зразком у вигляді таблиць. Для визначення запиту до бази даних користувач повинен заповнити таблицю QBE, яка надається системою, і визначити в ній критерії пошуку, вибору та перетворення даних [4].

Приклад 1 [4].

SELECT ім’я, прізвище

FROM КАДРИ

Результат:

Розглянемо деякі конструкції мови SQL.

SELECT <перелік атрибутів>

FROM <ім'я залежності>

WHERE <умова> [і\ а6о<умова> ]*.

Приймемо деякі обмеження: припустимо наявність лише однієї таблиці / залежності в БД; припустимо, що атрибути SELECT (вибрати) є підсукупністю атрибутів у схемі «залежність – ім’я» у реченні FROM (з); згідно з домовленістю, астерікс {*) є неофіційним загаль­ним знаком оператора, що означає нуль або більше.

Приклад 1

SELECT*

FROM КАДРИ

Одержимо (маючи БД КАДРИ):

КАДРИ

Приклад 2 [4].

SELECT імя, прізвище

FROM КАДРИ

Результат:

Оператор перейменування

SELECT <атрибут> АS <назва колонки>

FROM <таблиця>

Приклад 3 [4].

SELECT ТАБНОМ АS Табельний номер, прізвище, ім'я, по батькові

FROM КАДРИ

Одержимо у результаті виконання запиту таблицю ТАБНОМ:

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

SELECT <перелік атрибутів> (АS) *>

FROM <таблиця>

WHERE <текст порівняння: <, <=, <>, =...>

Приклад 4 [4].

SELECT*

FROM КАДРИ

WHERE табельний номер <2015>

Результатом виконання запиту буде таблиця:

Тепер розглянемо математичні вирази.

SELECT табельний номер, прізвище, ім'я, оклад/25

FROM КАДРИ

Одержимо:

КАДРИ

Ми розрахували середньоденні заробітки, враховуючи, що місяць має 25 робочих днів. Зауважимо, що стовпець із розрахованими значеннями середньоденних заробітків не матиме назви. Щоб назвати новостворений стовпець, необхідно використати таку конструкцію запиту:

SELECT табельний номер, прізвище, імя, оклад/25 AS середньоденний заробіток

FROM КАДРИ

WHERE оклад/25<30,00

Результатом виконання запиту буде таблиця:

Треба зауважити, що не можна використовувати ім'я змінної в окремому реченні.

Запит входу (in) можна сконструювати так:

SELECT прізвище

FROM КАДРИ

WHERE Рік народження IN ('1941', '1942')

Одержимо такий результат:

Мовою SQL можна сконструювати запит з операціями агрегування, до яких відносять COUNT (підрахунок), Мах, Мin, SUM (сума)... для таблиць або для деяких підгруп таблиці.

Конструкція запиту з операціями агрегування така:

SELECT [операція агрегування] (<атрибут>)

FROM <таблиці>

WHERE ** немає груп

Зауважимо, що

COUNT (атрибут) - обчислює кількість рядків, що містять (атрибут)

COUNT (*) - обчислює всі рядки (включаючи нулі)

Приклад 5 [4].

SELECT SUM (Оклад)

FROM КАДРИ

Одержимо:

Але не можна одночасно вибрати агрегати та одиничні значення. Наступна конструкція запиту є неприпустимою:

SELECT табельний номер, прізвище, SUM (Оклад)

FROM КАДРИ

Важливою мовою структурованих запитів SQL є конструк­ція GROUP BY (групувати за):

SELECT <перелік [атрибут | операція агрегування (<атрибут>)]>

FROM <перелік таблиці (ь)>

[WHERE<умови>]

GROUP BY <перелік атрибутів>

Приклад 6 [4].

Нехай є база даних ПОСТАЧАЛЬНИКИ:

Задано запит для агрегування за групами «Назва постачальника, назва товару» з підрахунком суми поставки за кожною назвою товару.

SELECT назва постачальника, назва товару, SUM (Сума поставки)

FROM ПОСТАЧАЛЬНИКИ

GROUP BY назва постачальника, назва товару

Результат запиту буде таким:

І, нарешті, розглянемо конструкцію запиту HAVING (має­мо). Загалом такий запит мовою SQL можна записати так:

SELECT<перелік [атрибут | операція агрегування (<атрибут>)]>

FROM <перелік таблиці (ь)>

[WHERE <умови>]

GROUP BY <перелік атрибутів>

HAVING <умову за групами>

Приклад 7 [4].

Необхідно одержати інформацію про поставки товарів однієї назви на суму більшу ніж 3000,00 грн у розрізі постачальників (крім постачальника ЗАТ «Карпати»).

Запит до бази даних ПОСТАЧАЛЬНИКИ буде таким:

SELECT назва постачальника, назва товару, SUM (Сума поставки)

FROM ПОСТАЧАЛЬНИКИ

GROUP BY назва постачальника, назва товару

HAVING назва постачальника <> «ЗАТ Карпати».

AND SUM (сума поставки) > 3000,00

Результат запиту буде таким:

Абсолютно неправильною буде конструкція запиту типу:

SELECT назва постачальника, назва товару, SUM (Сума поставки)

FROM ПОСТАЧАЛЬНИКИ

GROUP BY назва постачальника, назва товару

HAVING дата поставки <> '8.11.ХХ',

оскільки, як уже зазначалося раніше, не можна використовувати ім’я змінної в окремому реченні.

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

Глава 5.7. Огляд концепцій зберігання інформації

План

5.7.1. Поняття сховища даних

5.7.2. Характеристики сховища даних

5.7.3. Характеристики даних в сховищі даних

5.7.4. Етапи проектування сховища даних

5.7.5. Переваги сховищ даних

Різновидом баз даних є сховище даних (Data Warehouse - DW), появу якого обумовили такі фактори:

1. Поява систем підтримки прийняття рішень, основаних на OLAP- технології (реалізації аналітичних запитів).

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

3. Формування аналітичних звітів на основі традиційних баз даних займає багато часу, що призвело до того, що менеджери не встигали готувати відповідні рішення на основі отриманих аналітичних звітів.

4. В організаціях часто функціонувало декілька ОLTP-систем з окремими базами даних, що унеможливлювало побудову зведеного аналітичного запиту на основі декількох баз даних без попередньої узгодженості даних у рівних базах [4].

Вирішення перерахованих проблем було знайдено в розробці концепції сховища даних (DW) - особливої форми організації бази даних, призначеної для зберігання у погодженому вигляді агрегованої інформації, що отримується на основі баз даних різних ОLТР-систем та зовнішніх джерел [4].

DW характеризуються предметною орієнтацією, інтегрованістю» підтримкою хронології, незмінністю і мінімальною надлишковістю [4].

Предметна орієнтація

1. Дані в DW організовані відповідно до основних напрямів діяльності підприємства чи фірми (дебіторська заборгованість, замовники, склад тощо), а не до процесів (відвантаження това­ру, виписку рахунків тощо), як у базі даних.

2. Застосування DW спрямовуються даними й організують­ся навколо тем (клієнт, постачальник тощо), тобто сховища орієнтовані на бізнес-поняття, а не на бізнес-процеси [4].

Інтегрованість. Первинні дані оперативних баз даних перевіряють, певним чином добирають, зводять до одного вигляду, необхідною мірою агрегують і завантажують у DW. Наприклад, оцінка змінних величин може бути лише в метрах, формат подання дат - PMMDD, структура розшифрування для статі людини - ч/ж тощо [4].

Підтримка хронології (варіантність у часі). В операційному середовищі: інформація є точною на момент її введення; часовий горизонт або не існує, або є коротким, наприклад, 60-90 днів; ключ може і не містити елемент часу. DW нагромаджує дані у вигляді «історичних пластів»: історичні дані, наприклад, 5-10 років; ключ містить елемент часу [4].

Незмінність: після вводу інформації до DW вона не підлягає оновленню (на відміну від оперативних даних бази даних, які можуть часто змінюватись); історична інформація в DW є незмінною. Її можна лише первинно завантажити, шукати та читати [4].

Мінімальна надлишковість: зведення до мінімуму надлишковості даних забезпечується тим, що перш ніж завантажувати дані до сховищ, їх фільтрують і певним чином очищають від таких даних, які не потрібні й не можуть бути використані в OLAP-системах [4].

Наведемо деякі характеристики даних у DW:

1. Таблиці дуже великі (деякі в терабайтах).

2. Розмірні дані є незалежними в об’єктах (розмірностях).

3. Основний тип доступу - це незапланований (порівняно з обумовленим наперед у базі даних) - запити, звіти, оператори OLAP.

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

5. Доступ до даних здійснюється здебільшого у режимі «лише для читання».

6. Дані потрібно періодично поновлювати з численних дже­рел.

7. Більшість зібраних даних є архівними (тобто залежать від часу) [4].

У табл. 15 наведено відмінності між операційними базами даних та сховищами даних [4].

Таблиця 15

Відмінності між базами даних і сховищами даних

Оскільки існують суттєві відмінності між базою даних і DW, то природно, що і проектування DW здійснюється за своїми алгоритмами. Загалом, процес проектування сховищ даних складається з таких етапів:

Етап 1. Аналіз бізнес-процесів, які генерують дані, та інформаційні потреби організації. Наприклад, бізнес-процесами можуть бути замовлення, відвантаження, продажі тощо. Інформаційні потреби - це наявність відповідної інформації, наприклад, щоб визначити тенденції (тренди) бізнесу, сформувати стратегію маркетингу, проаналізувати конкурентоспроможність цін тощо.

Етап 2. Застосувати цю інформацію для визначення структури таблиці (таблиць) фактичних даних, тобто структури окре­мих записів низького рівня, які потрібно ввести до таблиць фактичних даних. Наприклад, записати обсяги про­дажу продукції в різних магазинах.

Етап 3. Визначити структуру кожної таблиці фактичних даних. Наприклад, записати щоденні обсяги реалізації марок товарів в окремих магазинах.

Етап 4. Визначити для кожної таблиці фактичних даних: якими є розмірності (об’єкти) та точно з’ясувати поля для кожної розмірності; які фактори потрібно записувати у таблиці фактичних даних (наприклад, які одиниці товарів продані, суми реалізації тощо).

Етап 5. Прийняти рішення, чи нормалізувати схему типу «зірка», чи ні?

Етап 6. Прийняти рішення, як часто потрібно відбирати та завантажувати дані в DW? Наприклад, щогодини, щодня, щотижня тощо [4].

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

1. Відбір даних з джерел операційних даних (баз даних).

2. Транспортування їх до цільового середовища (DW).

3. Очищення даних (фільтрація).

4. Перетворення (трансформація) даних.

5. Завантаження очищених та трансформованих даних до DW [4].

Потрібно зауважити, що деякі інструменти ETL об’єднують кілька етапів цього процесу, інші - здійснюють їх окремо. Сам процес ETL може вимагати дуже багато часу та управління мета-даними. На цьому етапі заповнення DW потрібно визначити, до яких полів і в яких джерелах здійснити доступ та які записи відбирати. Може бути повний відбір, коли DW є пустим, або відбір з прирощенням (додаються дані до вже заповненого DW) [4].

Під час транспортування даних потрібно визначити:

1. Цільове середовище, тобто чи потрібно направляти відібрані дані просто до DW, чи їх зберігати в деякій базі даних для «повідомлення».

2. Як транспортувати дані. Деякі з джерел даних є віддаленими і їх потрібно перенести у мережу. Крім цього, необхідно визначити, чи завантажувати дані до DW із застосуванням звичайних методів або спеціальних інструментів завантаження [4].

При очищенні (фільтрації) даних, відібраних з джерел (баз даних), необхідно знайти і виправити дублювання даних, зрізаний текст (наприклад, назва вулиці не вміщується в поле), орфографічні помилки, скорочення (наприклад, M.S. або MS). На цьому етапі заповнення DW виникає проблема злиття-видалення (merge-purge). Наприклад, Алекс Тужілін і Александр Тужліу [4].

Для перетворення (трансформації) даних потрібні різноманітні та гнучкі засоби трансформації, що повинні давати змо­гу консолідації, інтеграції, узагальнення і підсумовування. Наведемо приклади випадків, коли потрібна трансформація: різне кодування одних і тих же даних, різні умовні назви. Зазначимо, що часто трансформацію виконують за допомо­гою SQL-запитів [4].

На останньому етапі потрібно завантажити очищені та трансформовані дані до DW. Етапи очищення і/або трансфор­мації можна об’єднати з етапом завантаження. Під час заванта­ження даних до DW потрібні спеціальні утиліти завантажен­ня, оскільки існують величезні обсяги даних [4].

Засоби ETL розроблені для спрощення та упорядкування процесу ETL шляхом забезпечення «user-friendly» (дружнього до користувача) програмного забезпечення, що допомагає розробникам DW виконувати етапи завантаження. Деякі компанії DW мають свої власні засоби ETL [4].

Фізична організація DW. Чітко розрізняють два підходи:

1. Дані можна зберігати винятково у реляційних таблицях (ROLAP).

2. Таблиці факторів можна організувати як багатомірний куб (MOLAP) і цей куб може бути пов’язаний з таблицями вимірів через індекси [4].

В основу OLAP-систем покладено поняття гіперкуба, тобто багатовимірного куба, у комірках якого зберігаються необхідні для аналізу дані [4].

У ROLAP-системах гіперкуб є віртуальним - це лише користувацький інтерфейс, який моделюється на традиційній реляційній базі даних. Дані в сховищі подаються у вигляді моделі, що отримала назву «зірка» («star scheme»). Ця модель складається з таблиць двох типів: однієї таблиці даних, що і аналізуються, тобто фактів («fact table») - центр зірки і декіль­кох таблиць, які характеризують певні виміри цих фактів («dimension table»). Таблиця фактів вміщує числові характери­стики якогось напряму діяльності компанії чи фірми, напри­клад, обсяги продажу, а також ключі таблиць вимірів (напри­клад, назва товару і його виробника, тип товару тощо). Дані таблиць вимірів денормалізовані. Якщо ж таблиці вимірів нор­малізовані, то така модель називається «сніжинкою» («snow flake scheme»). У ROLAP-системах зберігаються агреговані дані. Переваги ROLAP-систем: підтримує відкриті стандарти SQL, мінімізує вимоги до навчання і підтримки, підходить для простого аналізу великих обсягів даних [4].

У MOLAP-системі гіперкуб будується фізично і реалізується як спеціальна модель нереляційної структури, що швидше забезпечує доступ до даних, ніж реляційні моделі, але вимагає додаткових витрат пам’яті. Переваги MOLAP-систем: оптимізовані для використання переваг кубічної організації розріджені елементи компресуються (тобто ущільнюється інформація у результаті виникнення порожніх комірок при завантаженні DW), запити й огляди в MOLAP в середньому виконуються краще, ніж у ROLAP. До недоліків MOLAP-систем належить насамперед те, що куби даних можуть бути величезними навіть після ущільнення інформації [4].

Постійна полеміка між прибічниками ROLAP і MOLAP призвели до появи підходу HOLAP-комбінованого варіанта зберігання даних, який використовує обидва типи систем керування базою даних. У багато­вимірній системі керування базою даних зберігаються агрегати даних, а докладні дані з невеликим обсягом зберігаються в реляційній системи керування базою даних. HOLAP-системи є компромісом між таборами MOLAP та ROLAP [4].

Реалізація проекту DW для бізнесу збільшує конкурентоспроможність шляхом:

1. Зменшення витрат: раціональні витрати на прийняття рішень, покращується управління активами (зобов’язаннями).

2. Збільшення прибутків і лояльності клієнтів за рахунок кращого знання клієнтів.

3. Визначення нових можливостей бізнесу і проблем через краще знання бізнесу [4].

Переваги сховищ даних (DW):

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

2. Забезпечують платформу для знання менеджменту і забезпечують мінімальне переривання діючих систем, тобто витрати часу на запити у виробничих системах зведені до мінімуму.

3. Покращує або створює нові процеси бізнесу [4].

Контрольні питання

1. Дайте визначення поняття інформаційного забезпечення інформаційної системи бухгалтерського обліку

2. Охарактеризуйте процес розробки інформаційного забезпечення

3. Охарактеризуйте структуру інформаційного забезпечення

4. Дайте визначення поняття позамашинної інформаційної бази

5. Охарактеризуйте склад позамашинної інформаційної бази

6. Назвіть дії, які виконуються під час створення позамашинної інформаційної бази

7. Наведіть класифікацію носіїв даних

8. Назвіть основні характеристики носіїв даних, які використовуються в сучасних інформаційних системах

9. Дайте визначення поняття уніфікованої системи документації

10. Охарактеризуйте вимоги до уніфікованої документації

11. Охарактеризуйте анкетні, лінійні, табличні (табельні) та комбіновані документи

12. Наведіть класифікацію первинних документів

13. Охарактеризуйте послідовність проектування первинних документів

14. Охарактеризуйте послідовність проектування візуальних форм виводу результативної інформації

15. Охарактеризуйте розробку ескізу візуальної форми виводу результативної інформації

16. Дайте визначення поняття машинної інформаційної бази бухгалтерського обліку

17. Охарактеризуйте склад машинної інформаційної бази бухгалтерського обліку

18. Дайте визначення понять файлу, масивів даних і програмних масивів

19. Наведіть класифікацію масивів даних

20. Дайте визначення поняття та назвіть складові компоненти автоматизованого банку даних

21. Охарактеризуйте ресурси баз даних

22. Охарактеризуйте моделі баз даних

23. Охарактеризуйте особливості ієрархічної моделі даних

24. Охарактеризуйте особливості сіткової моделі даних

25. Охарактеризуйте особливості реляційних моделей даних

26. Визначте мету нормалізації

27. Наведіть перелік етапів нормалізації відношень

28. Охарактеризуйте призначення та особливості мови структурованих запитів SQL

29. Наведіть приклади використання мови структурованих запитів SQL

30. Охарактеризуйте поняття сховища даних

31. Назвіть характеристики сховища даних

32. Назвіть характеристики даних в сховищі даних

33. Охарактеризуйте етапи проектування сховища даних

34. Визначте переваги сховищ даних

Розділ 6. Інформаційні технології обробки економічної інформації

Глава 6.1. Поняття інформаційних технологій

План

6.1.1. Поняття інформаційних технологій

6.1.2. Компоненти, від яких залежать інформаційні технології

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

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

Інформаційні технології залежить від різних компонентів, зокрема: технічних засобів; персоналу, здатного використовувати їх; організації, яка об’єднує засоби і персонал у єдиному процесі; інформаційних засобів, що здійснюють формування та видачу інформації [4].

Основу технології обробки даних становлять процеси перетворення вхідної інформації на результатну. Кожна інформаційна технологія закінчується створенням інформаційного продукту [4].

Глава 6.2. Етапи розвитку інформаційних технологій

План

6.2.1. Етап машинних ресурсів

6.2.2. Етап програмування

6.2.3. Етап нової інформаційної технології

6.2.4. Етап високих інформаційних технологій

З появою електронних обчислювальних машин настала ера комп’ютерної інформаційної технології, яка в своєму розвиткові пройшла кілька етапів [4].

Основне завдання інформаційної технології етапу машинних ресурсів (50-60-ті роки XX ст.) полягало в підвищенні ефективності обробки даних за формалізованими алгоритмами або такими, що легко формалізуються. Концепція інформаційних технологій полягала в тому, що все, що можуть робити люди, вони повинні робити; ЕОМ виконувала лише роботи з опрацювання інформації, які люди принципово виконувати не могли, наприклад, масові розрахунки [4].

Для етапу програмування (середина 60-х - початок 80-х років XX ст.) визначальним став масовий випуск міні-ЕОМ. Вартість машинних ресурсів істотно знизилась, тому метою інформаційної технології стала економія праці програмістів. Докорінно змінилась кон­цептуальна орієнтація: все, що можна запрограмувати, повинні робити ЕОМ, люди повинні виконувати лише те, що не можна запрограмувати [4].

Основу концепції третього етапу - нової інформаційної технології (1970 - 1990 рр.) - становлять розподілена комп’ютерна техніка, «дружнє» програмне забезпечення, роз­винуті комунікації. Користувачеві надавалась можливість ав­томатизувати все, що люди можуть описати, програмувати без програмістів. Основним завданням нової інформаційної технології було створення типової технології автоматизації персональних обчислень, а метою - економія праці користувачів. Елементом нової інформаційної технології стало автомати­зоване робоче місце фахівця певного профілю [4].

В основу концепції четвертого етапу - високих інформаційних технологій - покла­дено ідею вдосконалення засобів спілкування між людьми а гло­балізацією інформаційного простору до масштабів планети [4].