Тема 5
Тема 5. Створення комп’ютерних технологій
Мета заняття - вивчення складу та змісту інформаційного забезпечення АІС автоматизованого обліку, набуття практичних навичок підготовки проектних рішень за обсягами, розміщенням і методами організації інформації в системах управління фінансового обліку, виконання практичної роботи № 1 з проектуванням та створенням бази даних, формуванням вихідних інформаційних повідомлень по конкретних задачах, виконання яких починається в темі 2.
Методичні вказівки до теми
Однією з умов автоматизованого розв’язування економічних задач у будь-якій предметній галузі, в тому числі і у фінансовому обліку, є розробка їх інформаційного забезпечення (ІЗ).
Проектні рішення з організації 13 подаються в таких документах:
· опис інформаційного забезпечення;
· опис організації інформаційної бази (ІБ);
· опис системи класифікації та кодування;
· креслення форми документа (відеограми);
· опис масиву інформації;
· перелік вхідних і вихідних повідомлень і т. ін.
Опис організації ІБ проводиться окремо для позамашинної та машинної інформаційних баз. При цьому подаються склад, структура та організація ведення ІБ.
3 погляду логіки управління та розміщення даних на носіях розрізняють логічну та фізичну структуру даних.
Під логічною розуміють структуру, яка враховує погляд користувача (управлінця) на дані, тобто таку, що будується на логіці управління, а не на його техніці. Як правило, вона багаторівнева, і виділяти інформаційні одиниці можна як з нижчого, так і з вищого рівня. Наприклад, для логічних структур даних у порядку агрегування (укрупнення) характерне таке відокремлення елементів даних: символ –> реквізит –> показник –>
–> масив –> інформаційний потік –> інформаційна база. З характеристиками структурних одиниць інформації при логічному підході до структуризації економічної інформації ми вже познайомилися в темі 2.
За фізичного підходу до структури економічної інформації (тобто з позицій її подання на машинних носіях) відповідні структурні одиниці виділяються залежно від носія інформації та способу її фіксації.
Внутрішньою структуризацією масивів даних, як правило, виділяють такі одиниці інформації від нижчого до найвищого: символ –> поле –> агрегат даних –> запис –> файл –> база даних.
Визначення кожної зі структурних одиниць наведено у термінологічному словнику до теми.
Для створення бази даних з визначеної предметної галузі (теми) необхідно ретельно ознайомитися з теорією нормалізації відношень.
Проектування БД — це визначення її складу й структури, проектування зовнішнього (позамашинного) відносно бази даних інформаційного забезпечення і технологічного процесу створення та ведення БД, а також розробка організаційно-методичних та інструктивних матеріалів. Проектування БД є досить трудомістким процесом, який виконується в кілька етапів.
Етапи проектування відповідають рівням подання даних у БД, тобто виконуються певні роботи з проектування на зовнішньому, інфологічному, даталогічному (логічному) і внутрішньому рівнях.
Метою проектування на зовнішньому рівні є розробка позамашинного інформаційного забезпечення, яке вміщує систему вхідної (первинної) документації, що характеризує певну ПО, систему класифікації та кодування техніко-економічної інформації, а також перелік відповідних вихідних повідомлень, які потрібно формувати за допомогою АБД.
Існує два підходи до проектування баз даних на зовнішньому рівні:
· від предметної галузі;
· від запиту.
Підхід «від предметної галузі» полягає в тому, що формується зовнішнє інформаційне забезпечення всієї предметної сфери без урахування потреб користувачів і прикладних програм. Іноді цей підхід називають ще об’єктним, чи непроцесним.
При підході «від запиту» основним джерелом інформації про предметну галузь є вивчення запитів користувачів і потреб прикладних програм. Цей підхід також називається процесним чи функціональним. При такому підході БД проектується для виконання поточних задач управління без урахування можливості розширення системи і виникнення нових задач управління.
Перевагами підходу «від предметної галузі» є його об’єктивність, системність при відображенні ПО і стійкість інформаційної моделі, можливість реалізації великої кількості прикладних програм і запитів, у тому числі незапланованих при створенні БД. Недолік цього підходу — значний обсяг робіт, що його потрібно виконати при визначенні інформації, яка підлягає фіксації в БД, що відповідно ускладнює і збільшує термін розробки проекту.
Функціональний підхід орієнтований на реалізацію поточних вимог користувачів і прикладних програм без урахування перспектив розвитку системи. При його використанні можуть виникнути складності в агрегації вимог різних користувачів і прикладних програм, проте за такого підходу значно зменшується трудомісткість проектування, а отже, є можливість створити систему з високими експлуатаційними характеристиками.
Однак узятий окремо кожний з цих методів не може дати достатньо інформації для проектування раціональної структури БД. Тому при проектуванні БД доцільно спільно використовувати обидва підходи.
Практично процес проектування БД на зовнішньому рівні нами виконаний під час визначення вхідних і вихідних документів, довідників під час виконання завдань теми 2, тобто визначені функціональні задачі ПО, що підлягають автоматизованому розв’язанню (кожен із студентів має свою задачу),; вивчені та проаналізовані оперативні первинні документи та нормативно-довідкова інформація (по них розроблений словник атрибутів); визначені процеси перетворення вхідних повідомлень у вихідні (складено формалізований опис показників).
Вивчаються також усі вихідні повідомлення, які видаються на друк чи на екран і зберігаються у вигляді вихідних масивів на МД. Це необхідно для того, щоб визначити, які з атрибутів вхідних повідомлень потрібно зберігати в БД для одержання вихідних повідомлень. За кожним розрахунковим показником слід визначити алгоритм його формування та переконатися в тому, що цей показник можна одержати на основі атрибутів оперативної та нормативно-довідкової інформації. Якщо певних даних не вистачає для повного виконання розрахунків, необхідно повернутися назад, провести дообстеження і визначитися, де чи в який спосіб можна отримати атрибути, яких невистачає.
Крім того, потрібно визначитися, які з розрахункових показників доцільно зберігати в БД. Показники, одержані розрахунковим шляхом, як правило, в БД не зберігаються. Винятком є випадки, коли розрахунковий показник потрібно використовувати для розв’язання інших задач чи даної задачі, але в наступні календарні періоди.
Після цього здійснюється перехід до етапу інфологічного проектування, метою якого є створення структурованої інформаційної моделі ПО, для якої розроблятиметься БД. При проектуванні на інфологічному рівні створюється інформаційно-логічна модель, яка повинна відповідати таким вимогам:
– коректність схеми БД, тобто адекватне відображення модельованої ПО;
– простота і зручність використання на наступних етапах проектування, тобто інфологічна модель (ІЛМ) має легко відображатися на моделі БД, які підтримуються відомими системами керування базою даних СКБД (сіткові, ієрархічні, реляційні);
– ІЛМ повинна бути описана мовою, зрозумілою проектувальникам БД, програмістам, адміністратору і майбутнім користувачам АБД.
Основною складовою інфологічної моделі є атрибути, які потрібно проаналізувати і певним чином згрупувати для подальшого зберігання в БД.
Суть інфологічного моделювання полягає у виділенні інформаційних об’єктів ПО, які підлягають зберіганню в БД (в нашому випадку таблиць БД), а також у визначенні характеристик об’єктів і взаємозв’язків між ними (побудові схеми даних).
Існує два підходи до інфологічного проектування: аналіз об’єк-
тів і синтез атрибутів. Підхід, що базується на аналізі об’єктів, називається нисхідним, а на синтезі атрибутів — висхідним. Економіко-організаційні системи найчастіше створюються з використанням висхідного підходу, який полягає в аналізі атрибутів і синтезі на їх основі інформаційних об’єктів.
Основними складовими елементами інфологічної моделі є інформаційний об’єкт, атрибут, запит, запитальний зв’язок, структурний зв’язок.
Інформаційний об’єкт — деяка сутність ПО, яку необхідно відображувати в БД з точки зору прикладної програми чи користувача БД. Це може бути предмет, факт, дія, явище чи поняття. Кожен об’єкт описується його властивостями, тобто його атрибутами. Крім атрибутів та інформаційних об’єктів, складовими частинами інфологічної моделі є інформаційний запит, запитувальний зв’язок і структурний зв’язок.
Інформаційний запит — словесний опис інформаційної потреби користувача чи прикладної програми.
Запитувальний зв’язок будується на основі запиту. Він являє собою структурований опис інформаційного запиту, в якому відображено необхідні для його реалізації об’єкти з урахуванням навігації (шляхів інформаційного пошуку) між ними.
Структурний зв’язок — асоціації, що описують ієрархічні зв’язки між парами інформаційних об’єктів, один з яких виступає як власник, а інший як підпорядкований об’єкт. Екземпляр структурного зв’язку — це екземпляр об’єкта власника та певна сукупність зв’язаних з ним екземплярів підпорядкованого об’єкта.
Ключовим моментом при визначенні структури інформаційних об’єктів є вивчення типів співвідношень між атрибутами. Між атрибутами можуть бути такі типи співвідношень: 1:1, 1:Б, Б:1 і Б:Б.
Тип співвідношення «один до одного» Т (А1:А2) = (1:1) існує тоді, коли одному і тому самому значенню атрибута А1 відповідає не більш як одне значення атрибута А2. Наприклад, атрибути «табельний номер і прізвище», «ім’я та по батькові» знаходяться у співвідношенні 1:1.
Тип співвідношення «один до багатьох» Т (А1:А2) = (1:Б) означає, що одному значенню атрибута А1 може відповідати нуль або багато значень атрибута А2. Водночас будь-якому екземпляру атрибута А2 може відповідати не більш як один екземпляр атрибута А1. Наприклад, між атрибутами Т (код банку: код клієнта) існує співвідношення 1:Б.
Тип співвідношення «багато до одного» Т (АІ:А2) = (Б:1) існує, коли одному значенню атрибута А1 відповідає щонайбільше одне значення атрибута А2, а будь-якому атрибуту А2 може відповідати нуль чи багато значень атрибута А1. Якщо Т (А1:А2) = Б:1, тоді Т (А2:А1) = 1:Б.
Тип співвідношення «багато до багатьох» Т (А1:А2) = Б:Б означає, що будь-якому значенню А1 може відповідати нуль чи кілька значень А2 і водночас, навпаки, будь-якому значенню А2 може відповідати нуль чи кілька значень АІ. Наприклад, Т (ПРОДУКЦІЯ: ПОКУПЕЦЬ) = Б:Б, одну й ту саму продукцію можуть купувати різні покупці і, навпаки, один покупець може купувати різні види продукції.
Інфологічні моделі мають велике значення при відображенні семантики модельованої предметної галузі. Послідовність робіт при інфологічному проектуванні наступна:
1) вилучення синонімії, омонімії та узагальнення атрибутів;
2) аналіз атрибутів і виділення інформаційних об’єктів;
3) перевірка об’єктів на відповідність умовам нормалізації;
4) зовнішнє кодування;
5) виявлення та опис інформаційних запитів до бази даних;
6) формалізований опис інформаційних запитів у вигляді запиту вальних зв’язків;
7) аналіз і виведення запитувальних зв’язків до канонічного вигляду;
8) побудова структурних зв’язків і графічне зображення інфологічної моделі;
9) перевірка інфологічної моделі на коректність.
1. Першим кроком, який виконується при інфологічному проектуванні, є аналіз атрибутів на предмет вилучення синонімії та омонімії. Серед атрибутів можуть зустрітися такі, що мають однакові імена, але різні за змістом, тобто омоніми. У цьому разі атрибутам-омонімам потрібно присвоїти різні унікальні імена. Прикладом атрибута-омоніма може бути атрибут з іменем «залишок», який в одному випадку може характеризувати залишок матеріалів, а в інших — залишок коштів, готової продукції. Тому для однозначної ідентифікації кожному залишку необхідно присвоїти унікальне ім’я.
Крім того, існують випадки синонімії, коли один і той самий атрибут у різних документах має різну назву. У цьому разі всім таким атрибутам присвоюється одне ім’я. Вибираючи назву для синонімічної групи атрибутів, серед атрибутів-синонімів необхідно вибрати ім’я, яке є семантичною домінантою для поданої групи, і залишити його в переліку атрибутів, а всі інші синонімічні назви його вилучити зі списку. Наприклад, атрибути «номенклатурний номер продукції», «код продукції» є синонімічними. Тому в переліку атрибутів, замість групи, потрібно залишати лише один атрибут «код продукції».
Складаючи список атрибутів, можливо, необхідно буде виконати ще одну операцію, яка називається узагальненням. При цьому деяку сукупність атрибутів замінюють одним атрибутом, який узагальнює сутність поданої групи. Наприклад, у переліку атрибутів є такі: токар, фрезерувальник, слюсар і т.д. Цю групу можна замінити одним атрибутом «професія». Отже, узагальненню підлягають атрибути, що мають однаковий формат і семантику.
2. Другий крок — агрегація атрибутів і компонування їх у інформаційні об’єкти. Процес агрегації атрибутів і визначення об’єктів є ітеративним, тобто послідовним.
Порядок виконання процедури агрегації такий:
2.1. Спочатку серед атрибутів виділяються ті, між якими існує однозначний зв’язок в обох напрямах (1:1). Такі атрибути агрегуються в один об’єкт, якому присвоюється унікальне ім’я (ім’я таблиці бази даних в СКБД Access). Наприклад, атрибути «код продукції», «назва продукції», «одиниця вимірювання», «ціна без ПДВ» об’єднуються в один об’єкт під назвою «ПРОДУКЦІЯ». Важливим моментом є вибір імені об’єкта. Ідентифікація об’єкта якимось ім’ям залежить від того, якій сутності предметної галузі відповідає даний об’єкт. Виконуючи такий аналіз, іноді необхідно додатково уточнювати ім’я атрибута для його однозначного семантичного трактування. При цьому слід пам’ятати, що в результаті виконання 2.1 один і той самий атрибут може потрапити до кількох об’єктів. Наприклад, «код продукції» може бути включений до об’єкта «ПРОДУКЦІЯ», який уміщує всю довідкову інформацію про продукцію на підприємстві, а також до об’єкта «ПРОДАЖІ», що вміщує дані про щоденну реалізацію продукції.
2.2. Після багаторазового виконання 2.1 перевіряють атрибути, що залишилися, на тип співвідношення з виділеними об’єктами. Якщо серед них є такі, що знаходяться у співвідношенні 1:1 з виділеними об’єктами, то їх приєднують до відповідних об’єктів.
2.3. Якщо серед решти атрибутів немає таких, які знаходилися б з виділеними об’єктами у співвідношенні 1:1, то необхідно виконати перевірку на співвідношення 1:Б між рештою атрибутів і виділеними об’єктами. При такому типі співвідношення може існувати функціональна залежність. Але слід пам’ятати, що співвідношення 1:Б у цьому разі означатиме те, що в екземплярах об’єкта можуть дублюватися значення даного атрибута. Такі атрибути приєднуються до виділених об’єктів.
2.4. Якщо після виконання описаного аналізу ще залишаться атрибути і серед них немає таких, які знаходилися б з виділеними об’єктами у співвідношенні 1:1 чи І:Б, то вирішують питання про створення з решти атрибутів нових окремих об’єктів. Не виключена можливість, що при цьому може з’явитися об’єкт, який містить лише один атрибут. Це свідчить про те, що існують недоліки в проектуванні на зовнішньому рівні. Тому потрібно виконати дообстеження ПО з точки зору поповнення таких об’єктів атрибутами, яких бракує.
Отримані об’єкти необхідно ідентифікувати унікальними іменами. Іменувати об’єкт краще одним словом і бажано, щоб це був іменник, наприклад, «ПРОДУКЦІЯ», «ПОКУПЦІ», «ПРОДАЖІ». Але не завжди можна ідентифікувати об’єкт одним словом, тому іменами об’єктів можуть бути також словосполучення.
3. Третім кроком інфологічного проектування є перевірка відповідності отриманих об’єктів умовам нормалізації. Але спочатку для кожного інформаційного об’єкта потрібно визначити первинні ключі. Первинний ключ — це атрибут або їх сукупність, що дають змогу однозначно ідентифікувати запис під час його пошуку. Первинним ключем може бути атрибут, який не дублюється й обов’язково присутній у кожному запису. Якщо серед атрибутів немає такого, який міг би бути первинним ключем, необхідно домовитися із замовником щодо визначення первинного ключа.
Коли процедуру агрегації об’єктів виконано бездоганно, то вони автоматично розміщуватимуться в 3НФ чи 4НФ. Але якщо предметна галузь досить складна і велика, налічує багато атрибутів та інформаційних об’єктів, то краще, аби переконатися, що не допущено помилок на попередньому етапі, ще раз перевірити об’єкти на відповідність умовам нормалізації.
4. Зовнішнє кодування. На цьому кроці необхідно вивчити атрибути з неунікальними значеннями. Якщо ці атрибути подані досить довгими текстами, то необхідно вирішити питання про доцільність заміни їх на короткі кодові позначення. У цьому разі в інфологічну модель вноситься новий інформаційний об’єкт, який доречно назвати «ДОВІДНИК». Він складатиметься з коду атрибута та його текстового значення. При цьому в усіх раніше виділених об’єктах текстові значення замінюються на код.
5. Виділення запитів до БД та їх словесний опис. Для того щоб описати запити, необхідно дослідити процеси обробки інформації по кожній функціональній задачі модельованої предметної галузі. Цей аналіз та формалізація процесу обробки інформації потрібні для визначення структурних зв’язків між інформаційними об’єктами, тобто вже на етапі інфологічного моделюванння БД проектувальник має чітко уявляти алгоритм та логічну схему розв’язання кожної задачі.
Запити виділяють опитуванням користувачів і з’ясуванням інформаційних потреб прикладних програм. Їх описують спочатку словесно, по можливості чітко виділяючи всі об’єкти, які використовуються при виконанні запиту, а також описуючи останній так, щоб можна було виявити послідовність переходу від одного об’єкта до іншого при виконанні запиту.
Слід мати на увазі те, що не завжди під час формування словесного опису запиту є можливість описати його так, щоб у тексті були наведені всі імена інформаційних об’єктів, які беруть участь в його реалізації. У таких випадках опис запиту повинен вміщувати ключові слова, що вказують на ті об’єкти, які семантично складно було відобразити в тексті інформаційного запиту.
Описуючи запит, також потрібно враховувати режим його виконання. Режими бувають одиночними і множинними. Одиночний режим — це такий, коли запит виконується для одного екземпляра початкового об’єкта: наприклад, «Для заданого ПОСТАЧАЛЬНИКА...». Множинний режим означає багаторазове виконання запиту для всіх екземплярів початкового об’єкта чи їх підмножини: наприклад, «Для всіх ПОСТАЧАЛЬНИКІВ...». Отож, коли в запиті вказано «для всіх» чи «для кожного», то передбачається виконання запиту для багатьох екземплярів початкового об’єкта. Це свідчить про те, що при реалізації алгоритму екземпляри даного об’єкта вибирають і обробляють послідовно. Якщо в запиті вказано слова «для заданого», «для певного», це значає, що запит виконується для конкретного єдиного екземпляра початкового об’єкта, пошук якого при реалізації запиту можна виконувати за ключем.
6. Кожний запит необхідно подати в структурованому вигляді відповідним запитувальним зв’язком.
Початкові й кінцеві об’єкти виділяють на основі семантичного аналізу запиту. Якщо в результаті аналізу виділено кілька кінцевих об’єктів, це означає, що один запит вміщує кілька одновимірних запитувальних зв’язків.
Запити поділяються на одновимірні й багатовимірні. Запит,
у якого на вході є один початковий об’єкт, називається одновимірним. Запит, у якого на вході існують кілька початкових об’єктів, є багатовимірним. Наприклад, запит «Видати список студентів певної ГРУПИ заданого ФАКУЛЬТЕТУ, вказаного КУРСУ» є багатовимірним
Усі одновимірні запитувальні зв’язки не підлягають подальшому аналізу і перетворенням. Їх можна одразу використовувати для побудови структурних зв’язків. Багатовимірні зв’язки необхідно додатково проаналізувати і перевірити їх на відповідність умовам канонічності.
ЛІТЕРАТУРА ДО ТЕМИ |
1. М.М. Редько, Навчально – методичний посібник «Інформаційні системи і технології в обліку» НМЦ, 2003р. с.9-11
2. Ф.Ф. Бутинець „Інформаційні системи бухгалтерського обліку”: в-во Житомир ПП. „Рута” 2002 рік. стор.103-107;
3. Закон України «Про інформацію» від 02.10.1992 року, ВР, 1992 р. № 48;
Контрольні запитання для перевірки знань
1. Поняття бази даних, банку даних, СУБД.
2. Що називається моделлю даних?
3. Суть ієрархічної та мереженої моделі.
4. Етапи розробки бази даних.
5. Елементи опису структури таблиць.
6. Призначення MS Access.
7. Об’єкти бази даних та їх суть.
8. Режими роботи MS Access., їх суть.
9. Операції, які можна проводити засобами MS Access.
10. Що таке ключове поле?
11. Види запитів у MS Access.
12. Який порядок створення таблиць Access у режимы конструктора?
13. Як створити відкоригувати форму Access?
14. Як створити і відкоригувати звіт Access?
