Концептуальне проектування БД

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

Інфологічний рівень – це інформаційно-логічну модель (ІЛМ) предметної області (ПО), в якій виключена надмірність даних і відображені інформаційні особливості об'єкта управління, без урахування особливостей і специфіки конкретної СУБД.

Мета інфологічного проектування – створити структуровану інформаційну модель ПО, для якої розроблятиметься БД. Інфологічну модель зручно подавати у вигляді так званої ER-діаграми (Entity – Relationship або Сутність – Зв'язок).

Само собою зрозуміло, що кількість виробів того самого виду на різних складах може бути різною. Різною може бути і відпускна ціна однакових виробів. Тому такі характеристики, як Кількість і Ціна, уже належать не тільки об'єкту “Виріб”, але й об'єкту “Склад”. Точніше, ці характеристики належать перетину атрибутів об'єктів “Виріб” і “Склад”.

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

6. Логічне проектування БД

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

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

7. Фізичне проектування БД

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

· середовище функціонування (клас комп'ютерів і використовувана операційна система);

· тип підтримуваних моделей даних (ієрархічна, мережна або реляційна модель);

· можливості і швидкість опрацювання складних запитів;

· рівень використання (локальна СУБД, мережна СУБД, підтримка архітектури “клієнт - сервер”);

· можливості вбудованої мови СУБД (SQL, Visual Basic і т.п.);

· сумісність з іншими додатками, у т.ч. з іншими СУБД;

· наявність розвинених діалогових засобів проектування й експлуатації (використання) БД;

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

На ринку програмного забезпечення ПК відомі СУБД самого різного рівня. Для платформи MS-DOS найбільш популярними були XBase-сумісні СУБД (dBase-III Plus, dBase-IV, FoxBase, FoxPro, Бісер, Ребус і т.п.), а також СУБД сімейства Paradox. З 1996 р. фактичним стандартом для ПК стала операційна система Windows. Найбільш відомими СУБД для цієї ОС стали СУБД Access (Microsoft), а також Visual FoxPro (Microsoft) і Paradox for Windows (Borland). Особливо слід відзначити об'єктно-реляційну СУБД Oracle, що підтримує поряд із класичними даними і нетрадиційні дані. Характерним прикладом сучасних СУБД є система управління реляційними базами даних Microsoft Access (відомі версії Access 97, Access 2000, Access 2003 і ін.). Ці системи призначені для роботи в середовищі Windows і входять до складу відповідних версій популярного пакета програм Microsoft Office.

БД у СУБД Access може містити кілька таблиць, причому дані в них можуть бути взаємозалежними. Основний смисл використання кількох таблиць полягає в можливості виключення дублювання даних. Таким чином забезпечується така властивість баз даних як мінімальна надмірність. Управління роботою Access виконується звичайним для Windows способом, тобто за допомогою системи меню, панелей інструментів, контекстного меню і комбінацій клавіш. Широко застосовуються різноманітні спеціалізовані програми, називані Майстрами (Майстер таблиць, Майстер форм, Майстер звітів і т.д.). Технологія створення БД за допомогою Access досить проста [10, С. 49]. Спочатку створюється сукупність таблиць, що описують предметну область (описується структура кожної із таблиць, установлюються зв'язки між ними і вводяться конкретні дані). Далі створюються інші об'єкти БД (запити, форми, звіти) відповідно до майбутньої технології використання бази даних. Зауважимо, що спеціальна процедура установки зв'язку між таблицями дозволяє при проектуванні форм, запитів або звітів використовувати дані з кількох таблиць. У необхідних випадках проектуються також макроси і модулі для автоматизації нетривіальних для звичайного користувача операцій.

ТЕМА 5. ОРГАНІЗАЦІЙНО-МЕТОДИЧНІ ОСНОВИ СТВОРЕННЯ І ФУНКЦІОНУВАННЯ СИСТЕМ УПРАВЛІННЯ ФІНАНСАМИ

1. Основні принципи створення та функціонування ІС.

2. Організація робіт, спрямованих на створення та впровадження ІС.

3. Стадії та етапи розробки інформаційних систем.

4. Автоматизація проектування інформаційних систем.

5. Організація АІС фінансових установ.

1. Основні принципи створення та функціонування ІС

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

Створення ІС передбачає виконання таких завдань.

1. Виявлення суттєвих характеристик економічного об’єкта.

2. Створення математичних і фізичних моделей досліджуваної системи та її елементів.

3. Встановлення умов взаємодії людини та комплексу технічних засобів.

4. Детальна розробка окремих проектних рішень.

5. Аналіз проектних рішень, практична апробація та впровадження.

Загальні принципи створення ІС:

а) принципом системності: у разі декомпозиції мають бути встановлені такі зв’язки між структурними елементами системи, які забезпечують цілісність ІС та її взаємодію з іншими системами;

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

в) принципом сумісності полягає в необхідності застосування типових уніфікованих і стандартизованих елементів функціонування АІС (дає змогу скоротити часові, трудові та вартісні витрати на створення АІС);

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

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

Як правило, для ефективного здійснення управління, крім головних (загальних) принципів, вирізняють також низку часткових принципів, які деталізують загальні. Деякі з них:

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

Ø Принцип першого керівника – передбачає закріплення відповідальності при створенні АІС за замовником – керівником підприємства, установи, галузі, тобто майбутнім користувачем, який відповідає за введення в дію та функціонування АІС з ФКУ.

Окрім розглядуваних можна додатково визначити ще деякі принципи створення й функціонування АІС ФКУ, такі як принцип нових задач, надійності, єдиної інформаційної бази, безпеки даних, надійності системи, продуктивності системи, адаптації.

2. Організація робіт, спрямованих на створення та впровадження ІС

Процес створення ІС – це сукупність робіт від формування вихідних вимог щодо системи до введення її в дію (ГОСТ 34.601–90 «Автоматизированные системы. Стадии создания»).

Життєвий цикл ІС – весь період існування системи від початку розробки до закінчення її використання та утилізації комплексу засобів автоматизації інформаційної системи.

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

Існують такі стадії життєвого циклу ІС:

1) формування вимог до ІС;

2) розробка концепції ІС;

3) технічне завдання;

4) ескізний проект;

5) технічний проект;

6) робоча документація;

7) введення в дію;

8) супроводження.

Усі результати робіт, які виконуються на різних стадіях,

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

Існує дві групи методів створення ІС: орієнтовані на дані та

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

3. Стадії та етапи розробки інформаційних систем

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

Також можна виділити такі стадії та етапи розробки ІС

1. Стадія формування вимог до IС.

Етапи: обстеження об’єкта i обґрунтування необхідності побудови системи; формування вимог користувача до неї; оформлення звіту i заявки на її розробку.

2.Стадiя розробки концепції IС.

Етапи: вивчення об’єкта; виконання необхідних науково-дослідних робіт; розробка варіантів концепції IС i вибір того з них, який задовольняє вимоги користувача; оформлення звіту про виконану роботу.

3. Стадія розробки технічного завдання.

Етапи: розробка технічного завдання та його затвердження.

4. Стадія ескізного проектування.

Етапи: розробка попередніх проектних вирішень стосовно системи та окремих її частин.

5. Стадія технічного проектування.

Етапи: розробка проектних вирішень стосовно системи та її частин; розробка документації IС та її частин; розробка й оформлення документації на поставляння або розробку виробів для комплектування системи; розробка завдань на проектування в суміжних частинах проекту автоматизації.

6. Стадія робочого проектування.

Етапи: розробка робочої документації на систему та її частини; створення або адаптація програм.

7. Стадія впровадження системи в дію.

Етапи: підготовка об’єкта автоматизації до впровадження IС; підготовка персоналу; комплектування IС (програмними i технічними засобами, інформаційними виробами); будiвельно-монтажнi роботи; попередні випробування; дослідна експлуатація; приймальні випробування.

8. Стадія супроводження.

Етапи: виконання робіт згідно з гарантійними зобов’язаннями та пiслягарантiйне обслуговування.

Залежно від складності автоматизовуваних процесів i завдань не всі стадії є однаково обов’язковими.

4. Автоматизація проектування інформаційних систем

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

Переваги використання CASE:

1. Звільнення розроблювача для виконання більш творчих проблемних задач.

2. Створення ясної документації і координація проектно-конструкторських робіт групи.

3. Організація спільної роботи групи.

4. Розробка більш надійного і потребуючого меншого ремонту систем.

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

6. Застосування структурних методологій.

7. Підтримка об’єктно-орієнтованої розробки.

8. Збільшення продуктивність і якості.

Задачі CASE:

1. Розпорядження стандартної методології розробки і проектної дисципліни:

- ефективна координація великі групи і програмні проекти;

- цілісність проекту і загальних проектно-конструкторських робіт.

2. Поліпшення зв'язку між користувачами і технічними фахівцями.

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

4. Автоматизація стомлюючих і підданих помилкам частин аналізу і проекту.

5. Автоматизація перевірки і контролю відкоту.

Застосування сучасних інструментальних засобів CASE:

1. Вхідна робота з проектування й аналізу, що зменшує кількість помилок, який необхідно пізніше виправити.

2. Створення технічно правильних діаграм, обробка описів і введення словника даних за допомогою текстових і графічних редакторів CASE.

3. Побудова діаграми за допомогою стандартного набору символів.

4. Автоматичний зв'язок елементів даних із процесами, де вони використовуються.

5. Перевірка вірогідності проекту, автоматичне балансування діаграм потоку даних і перевірки діаграм і специфікацій на закінченість і послідовність.

6. Ітеративна розробка, автоматизація переглядів і змін і забезпечення засобів макетування.

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

8. Спільне використання членами проектної групи й обмеження можливості зміни база даних CASE.

5. Організація АІС фінансових установ

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

Для фінансово-кредитних установ, і для банківських насамперед, важливою особливістю є те, що об’єкт управління – керована частина, або основне їх «виробництво» – також пов’язане з виробленням і переробкою інформації. Адже основою діяльності таких установ є, по суті, робота з інформацією, яка часто стає і предметом і продуктом праці не лише відповідних інформаційних систем, а й установи в цілому.

Справді, хоча банки й проводять операції з готівкою, але переважна більшість розрахунків у них здійснюється в безготівковій формі. Готівкові гроші (за нормальної роботи економіки) становлять 5–10% суми загального грошового обігу. Проведення безготівкових розрахунків означає, що грошей у явному вигляді, у «натурі» немає, існують лише записи про грошові кошти та операції з ними на відповідних носіях, тобто є інформація, яка за певних умов може матеріалізуватися. Те саме стосується й інших фінансово-кредитних установ – податкових, фінансових тощо.

Отже, у фінансово-кредитних установах автоматизація «основного виробництва» зводиться до автоматизації операцій обробки даних відповідних документів, тобто до обробки інформації. Цим такі установи істотно відрізняються від промислових підприємств, де автоматизація основного виробництва являє собою автоматизацію процесів обробки матеріальних потоків, а отже, створення АІС тут означає автоматизацію інформаційних процесів, пов’язаних із основним виробництвом, а не самого виробництва.

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

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

АІС у ФКУ формально можна подати як синтез автоматизованої системи обробки управлінської інформації (АСУу) та автоматизованої системи основного виробництва (АСОВ):

АІС ФКУ = АСУу + АСОВ.

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

Зауважимо, що в банках доводиться також вирішувати питання, пов’язані з управлінням грошовими ресурсами і самими банківськими установами. Відповідні задачі ще недостатньо автоматизовані, причому ступінь автоматизації АСУу і АСОВ у АІС ФКУ нині різний – вищий у АСОВ i нижчий у АСУу. Крім того, розв’язування завдань управління на промислових підприємствах автоматизоване значно вище, ніж в АІС ФКУ. Тобто широке застосування у ФКУ ЕОМ, і насамперед персональних комп’ютерів, забезпечується, здебільшого, завдяки автоматизації основного виробництва.

ТЕМА 6. АВТОМАТИЗОВАНА СИСТЕМА ФІНАНСОВИХ РОЗРАХУНКІВ

1. Призначення та особливості побудови АСФР.

Дата добавления: 2014-12-08