Студопедия.Орг Главная | Случайная страница | Контакты | Мы поможем в написании вашей работы!  
 

Архітектура подання даних в АІС



Рівень / деком-пози-ція Зовнішній: предметна область – предмет дослідження Інфологіч-ний: на основі знань спеціаліста-предметника Концепту- альний: на основі моделі даних СКБД Внутрішній: засобами опису та маніпулю-вання даними СКБД Реалізації (фізичний): засобами збереження даних СКБД в пам’яті ОС
  Система об’єктів (процесів, документів) предметної області Інфологічна модель Концепту-альна модель База даних як сукупність файлів даних і програм Бібліотека на магнітних дисках
  Набір об’єктів Набір описів про інфор-маційні сутності як сукупностей реквізитів Набір структур ін-формаційних сутностей і зв’язків між ними Сукупність зв’язаних таблиць даних і запитів Том
  Об’єкт   Сутність Структура таблиці Запис   Фізичний запис
  Властивість об’єкта Реквізит Атрибут Поле Відповідна сукупність комірок пам’яті ОС
  Характерис-тика властивості Значення реквізиту Значення атрибуту Значення поля Стан комірок пам’яті ОС

На основі такого опису можна відслідкувати відображення кожного структурного елемента на певному етапі декомпозиції рівнів архітектури подання даних АІС. Наприклад, на 4-му етапі декомпозиції реквізит, як певна властивість процесу або документу, відображається в атрибут на концептуальному рівні. В свою чергу атрибут відображається в поле на внутрішньому рівні подання даних.

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

3.4. Проектування та оптимізація структури баз даних (для самостійної роботи студентів)

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

Етапи проектування відповідають рівням подання даних у АІС, тобто виконуються певні роботи з проектування на зовнішньому, інфологічному, концептуальному і внутрішньому рівнях.

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

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

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

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

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

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

Якщо схематично представити процес проектування БД на зовнішньому рівні, то він складається з таких робіт:

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

При опису вказується призначення задачі та її техніко-економічна сутність. Для обґрунтування необхідності її розв'язання необхідно:

· привести періодичність розв'язання задачі і термін видачі вихідної інформації;

· вказати умови, при яких припиняється автоматизоване розв'язання задачі;

· перерахувати зв'язки даної задачі з іншими задачами інформаційної системи та привести інформаційну модель взаємозв'язків задач/;

· оцінити необхідність автоматизованого розв'язання задачі в прикладній чи предметній постановці;

· описати розподіл дій між персоналом і технічними засобами при різних ситуаціях розв'язання задач;

· привести математичний опис задачі в умовах її автоматизованого розв'язання.

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

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

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

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

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

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

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

Для закріплення теоретичного матеріалу розробимо проект (модельний) БД в прикладній постановці на прикладі задачі автоматизованого облікуматеріалу (m) в одиницях виміру (o) на складі (s).

Математична постановка такої задачі може бути сформульована наступним чином:

ZZmos = Zmos + Nmos – Wmos, де:

Zmos, ZZmos – відповідно, залишок матеріалу на початок та кінець звітного періоду;

Nmos, Wmos – відповідно, надходження та витрати матеріалу на протязі звітного періоду.

Спочатку визначається множина документів, що задіяні в задачі та відображається їх взаємозв’язок. Такими документами для задачі, що розглядається, є «Приймальний акт» та «Накладна на відпуск матеріалів».

До документа «Приймальний акт» на отримані матеріали додаються документи:

· «ПОДАТКОВА НАКЛАДНА»;

· «НАКЛАДНА».

До документа «Накладна на відпуск матеріалів» додаються документи:

· «ПОДАТКОВА НАКЛАДНА»;

· «ТОВАРНО-ТРАНСПОРТНА НАКЛАДНА»;

· «ДОРУЧЕННЯ»;

· «УГОДА» (при відпущені матеріалів на основі угоди).

Оскільки при проектуванні БД в предметній постановці аналізуються всі документи, а в прикладній постановці лише ті, які відповідають конкретному запиту, тому в нашому модельному проекті використовуються лише «Приймальний акт» та «Накладна на відпуск матеріалів».

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

Таблиця 3.2





Дата публикования: 2015-11-01; Прочитано: 684 | Нарушение авторского права страницы | Мы поможем в написании вашей работы!



studopedia.org - Студопедия.Орг - 2014-2024 год. Студопедия не является автором материалов, которые размещены. Но предоставляет возможность бесплатного использования (0.01 с)...