Банки і бази даних

Аспекти проектування інформаційних систем. Адміністрація бази даних, захист, цілісність, моделювання, три рівні подання даних. Модель "об'єкт-атрибут-зв'язок". Проектування на зовнішньому рівні та даталогічне проектування. Предметна область "Бібліотека".

Рубрика Банковское, биржевое дело и страхование
Вид курсовая работа
Язык украинский
Дата добавления 13.02.2016
Размер файла 47,4 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.

Размещено на http://www.allbest.ru/

[Введите текст]

ЗМІСТ

Вступ

1. Мета і завдання практики

2. Теоретичні аспекти проектування інформаційних систем

2.1 Основні поняття

2.2 Словник даних

2.3 Адміністрація бази даних

2.4 Захист даних

2.5 Цілісність даних

2.6 Три рівні подання даних

2.7 Моделювання даних

2.8 Проектування бази даних

2.9 Модель «об'єкт-атрибут-зв'язок»

3. Поняття про багаторівневе подання даних

3.1 Етапи проектування баз даних

3.2 Суть процесу проектування

3.3 Проектування на зовнішньому рівні

3.4 Даталогічне проектування

4. Предметна область «Бібліотека»

4.1 Основні положення

4.2 Завдання бібліотеки

4.3 Зміст роботи бібліотеки

4.4 Матеріально-технічне забезпечення

4.5 Документація

Висновок

Література

ВСТУП

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

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

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

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

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

Після закінчення терміну практики студенти звітують про виконання індивідуального завдання.

1. МЕТА І ЗАВДАННЯ ПРАКТИКИ

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

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

Основними задачами роботи є:

- моніторинг за надходженням, рухом, та наявністю книжок по філіях;

- формування звітності;

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

2. ТЕОРЕТИЧНІ АСПЕКТИ ПРОЕКТУВАННЯ ІНФОРМАЦІЙНИХ СИСТЕМ

2.1 Основні поняття

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

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

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

У первинному розумінні інформація -- це будь-які відомості про певну подію, сутність, процес і т. Ін., які е об'єктом деяких операцій: сприйняття, передавання, перетворення, зберігання, використання.

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

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

В процесі розробки автоматизованих інформаційних систем відповідно до двох понять -- «інформація» і «дані» -- в автоматизованих інформаційних системах розрізняють два аспекти:інфологічний і датологічний.

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

На етапі інфологічного проектування системи вирішують такі завдання:

- визначають об'єкти і явища реального світу, інформація про які має

бути накопичувана й опрацьовувана в системі;

- визначають суттєві характеристики і взаємозв'язки цих об'єктів та явищ;

- уточнюють вищевказану інформацію для введення в інформаційну систему.

На етапі інфологічного проектування виділяють предметну область (ПО) - частину реального світу, що визначає інформаційні потреби системи.

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

На етапі датологічного проектування системи вирішують такі завдання:

- розробляють форми подання інформації, що відповідають наявним засобам сприйняття й обробки;

- наводять моделі і методи подання та перетворення даних;

- формулюють правила смислової інтерпретації даних (семантичні правила).

Банк даних -- сукупність спеціальних методів і засобів (математичних,

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

Банки даних є однією з найважливіших складових різних автоматизованих систем: управління, довідкових систем різного профілю, систем автоматизованого проектування та ін.

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

Банк даних містить два основних компоненти: базу даних (БД) і систему управління базами даних (СУБД).

Базою даних називають сукупність взаємопов'язаних даних деякої предметної галузі, що зберігаються в пам'яті ЕОМ та організовані так, що їх можна використовувати для розв'язування багатьох задач різними користувачами.

БД -- датологічне подання інформаційної моделі предметної галузі.

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

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

У кожній СУБД, перш за все, є транслятори або інтерпретатори з мови опису даних (МОД) і мови маніпулювання даними (ММД).

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

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

- вибрати з БД конкретне дане за його найменуванням;

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

умови;

- написати нові дані до бази;

- вилучити певні дані з бази;

- знайти певні дані у БД і змінити їх (оновити дані) і т.ін.

У сучасних системах обробки даних властивості МОД і ММД можуть поєднуватись в одній мові (наприклад, мова SQL Structured Query Language -- структурована мова запитів).

2.2 Словник даних

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

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

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

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

Словник даних кінцеві користувачі використовують при роботі із системою, прикладні програмісти -- при написанні програм, а системні програмісти -- у процесі розвитку системи.

Словник даних переважно описує базу даних у вигляді кількох фізичних таблиць з логічними зв'язками між ними.

2.3 Адміністрація бази даних

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

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

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

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

2.4 Захист даних

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

Захист даних може виконувати дві функції: забезпечення безпеки даних і забезпечення їхньої секретності.

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

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

2.5 Цілісність даних

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

а)структурні обмеження, які у багатьох випадках задаються

функціональними залежностями і відповідно контролюються;

б)обмеження реальних значень даних, що зберігаються у базі. Такі обмеження переважно ставлять вимогу, щоб значення полів належали певним діапазонам значень, або задають деяке арифметичне співвідношення, яке мають

задовольняти значення полів.

Існують також інші обмеження цілісності. Наприклад, обмеження на умови виконання паралельних операцій над даними у базі, обмеження типу «старий-новий», коли база переходить у новий стан, та ін.

Взагалі цілісність може бути порушена при збої обладнання, наявності програмної помилки, помилки людини-оператора, помилок у вхідних даних

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

цілісності.

2.6 Три рівні подання даних

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

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

Концептуальне подання даних пов'язане з відображенням знань про предметну галузь. Структуру даних на концептуальному рівні називають концептуальною схемою, і вона пов'язана з виявленням семантики даних. Елементарними одиницями концептуального подання даних є три поняття: елементи (об'єкти, предмети, процеси) предметної галузі; властивості елементів предметної галузі; зв'язки між цими елементами та їхніми властивостями.

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

2.7 Моделювання даних

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

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

1) інфологічна модель (її називають також концептуальною), зорієнтована

на користувача;

2) датологічна модель, зорієнтована на реалізацію в середовищі інформаційної (комп'ютерної) системи.

У банку даних при відображенні інфологічної МПГ у середовищі СУБД

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

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

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

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

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

2.8 Проектування бази даних

Проектування бази даних -- складний процес здійснення відображення: "опис предметної галузі» -- «схема внутрішньої моделі бази даних».

Цей процес подають у вигляді послідовних простіших процесів відображень між проміжними моделями данних.

Основні етапи проектування БД -- інфологічне і датологічне проектування. В останньому виділяють логічне та фізичне проектування.

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

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

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

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

2.9 Модель «об'єкт-атрибут-зв'язок»

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

Основне призначення неформальної моделі «об'єкт-атрибут-зв'язок» --моделювання і структурування інформації для подальшого використання інформаційною системою.

При побудові моделей типу «об'єкт-атрибут-зв'язок» для подання складових предметної галузі використовують три основних структурних елементи: об'єкт, атрибут і зв'язок.

Об'єкт -- збірне поняття, деяка абстракція реально існуючого предмета, або явища, про яке необхідно зберігати інформацію в системі. Обєктами в моделях предметної галузі можуть бути як матеріальні (співробітники установи, вироби підприємства та ін.), так і нематеріальні об'єкти (опис деякого явища, опис структур даних, які використовує система, та ін.). У моделі використовують поняття «тип об'єкта» (клас) і «екземпляр об'єкта» (власне об'єкт). Тип об'єкта визначає набір однорідних об'єктів, а поняття «екземпляр об'єкта» стосується конкретного об'єкта в наборі.

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

Зв'язок -- засіб, за допомогою якого подають відношення між об'єктами, наявними у предметній галузі. Тип зв'язку розглядають між типами об'єктів, її конкретний екземпляр зв'язку певного типу -- між конкретними екземплярами типів об'єктів.

Між об'єктами можуть існувати бінарні (зв'язки між двома об'єктами), тернарні (між трьома об'єктами) і в загальному випадку -- n-арні зв'язки. Найчастіше трапляються бінарні зв'язки.

3. ПОНЯТТЯ ПРО БАГАТОРІВНЕВЕ ПОДАННЯ ДАНИХ

3.1 Етапи проектування баз даних

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

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

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

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

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

Усі зовнішні подання інтегруються на інфологічному рівні, де формується інфологічна (канонічна) модель даних, яка не є простою сумою зовнішніх подавань даних.

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

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

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

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

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

3.2 Суть процесу проектування

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

Усі роботи, які виконуються на кожному етапі проектування, повинні інтегруватись зі словником даних (схему взаємозв'язку етапів зображено на

рис.1. Кожний етап проектування розглядається як певна послідовність ітеративних процедур, у результаті яких формується певна модель БД.

Рис.1.Схема взаємозв'язків етапів проектування зі словником даних

3.3 Проектування на зовнішньому рівні

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

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

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

Існує два підходи до проектування баз даних на зовнішньому рівні: «від предметної області» та «від запиту».

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

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

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

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

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

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

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

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

2.Вивчення та аналіз оперативних первинних документів.

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

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

4. Вивчення процесів перетворення вхідних повідомлень на вихідні. Передусім вивчаються всі вихідні повідомлення, які видаються на друк чи на екран і зберігаються у вигляді вихідних масивів на магнітних дисках (МД). Це необхідно для того, щоб визначити, які з атрибутів вхідних повідомлень потрібно зберігати в БД для отримання вихідних повідомлень. Крім того, на цьому етапі визначаються ті показники, що їх отримують під час розв'язання задачі в результаті виконання певних обчислень. За кожним розрахунковим показником слід визначити алгоритм його формування та переконатися в тому, що цей показник можна отримати на основі атрибутів оперативної і нормативно-довідкової інформації, які були визначені на другому та третьому кроках. Якщо не вистачає для повного виконання розрахунків певних даних, необхідно повернутися назад, провести до обстеження і визначитися, де або в який спосіб можна отримати атрибути,яких не вистачає.

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

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

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

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

3.4 Даталогічне проектування

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

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

Основними факторами, що впливають на даталогічне проектування з боку СКБД є:

1. Тип логічної моделі, що його підтримує вибрана СКБД. Зараз найпоширенішими на ринку програмних засобів і в практиці автоматизації економічних розрахунків є реляційні СКБД. Крім реляційних моделей, існують єрархічні та мережеві моделі баз даних.

2. Особливості фізичної організації даних у середовищі вибраної СКБД. Наприклад, у СКБД Раradох чи dВАSЕ-системах база даних організована у вигляді набору взаємозв'язаних файлів форматів DB і DВF. Усі інші об'єкти, такі як форми та звіти, також зберігаються в окремих файлах. У середовищі СКБД Місrosoft Ассеss усі дані та інструментальні засоби роботи з ними зберігаються в єдиному файлі бази даних. Тому при проектуванні БД потрібно знати не лише правила побудови логічної, а й особливості фізичної організації бази даних.

3. Кількісні обмеження, які накладає СКБД (наприклад, кількість рівнів єрархії в єрархічних моделях, можлива кількість полів, записів, файлів тощо).

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

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

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

4. ПРЕДМЕТНА ОБЛАСТЬ «БІБЛІОТЕКА»

4.1 Основні положення

Бібліотека є структурним підрозділом Інституту підприємництва та

перспективних технологій при Національному університеті "Львівська

політехніка", що забезпечує бібліотечно-інформаційні, навчальні та культурно-просвітницькі потреби навчально-виховного процесу.

У своїй діяльності бібліотека керується Законом України "Про освіту",

Законом України "Про бібліотеки і бібліотечну справу", нормативними

актами та документами з бібліотечної справи органів управління вищими

навчальними закладами України, Статутом ІППТ, наказами Ректора ІППТ,

а також цим Положенням.

Загальне методичне керування бібліотекою здійснює Науково-методична

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

4.2 Завдання бібліотеки

- Формування, належний облік та збереження, раціональне використання

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

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

- Сприяння вихованню гармонійної, морально досконалої особистості,

свідомої свого громадянського обов'язку, відкритої до інтелектуального,

духовного і творчого розвитку.

- Популяризація та розкриття через книгу змісту загальнолюдських цінностей, історичної, наукової та культурної спадщини, ідеї національного

державотворення.

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

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

- Виховання інформаційної культури читачів, прищеплення їм навичок користування книгою та бібліотекою.

- Координація діяльності бібліотеки з структурними підрозділами та громадськими організаціями Інституту.

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

4.3 Зміст роботи бібліотеки

- Здійснює інформаційне та бібліотечно-бібліографічне обслуговування читачів.

- Забезпечує читацький контингент IППТ основними бібліотечними послугами.

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

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

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

- Виконує всі види бібліографічних довідок.

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

- Формує бібліотечні фонди шляхом придбання навчальної, наукової

літератури і інформаційних матеріалів згідно з навчальними планами,

програмами та тематикою наукових досліджень в інституті.

- Систематично аналізує бібліотечні фонди з метою оптимізації їх складу та підвищення ефективності використання.

- Вносить до керівництва ІППТ пропозиції щодо перевидання навчальної та методичної літератури.

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

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

- Створює і веде систему бібліотечних каталогів і бібліотечних картотек, при

цьому використовує традиційні носії інформації і сучасні інформаційні

технології (електронний каталог), які забезпечують багатоаспектне

розкриття бібліотечного фонду.

- Бере участь у створенні галузевих, регіональних та загальнодержавних баз даних.

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

інституту проводить читацькі конференції, літературні вечори, диспути, інші заходи.

- Веде роботу, спрямовану на покращення умов праці читачів та працівників бібліотеки.

- Вивчає й упроваджує в практику роботи передовий бібліотечний досвід.

- Здійснює перехід на нові бібліотечні технології.

4.4 Матеріально-технічне забезпечення

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

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

4.5 Документація

Документація бібліотеки ІППТ, ведення якої є обов'язковим:

- Тематичний план комплектування бібліотеки;

- Книги сумарного обліку надходжень;

- Журнал без інвентарного обліку масової (багатоекземплярної) літератури;

- Журнал позабалансового - без інвентарного обліку рукописів та

прирівняних до них документів;

- Інвентарні книги індивідуального обліку;

- Журнал обліку втраченої читачами та отриманої взамін літератури;

- Криги сумарного обліку резервного фонду бібліотеки;

- Журнал видачі літератури в читальний зал.

5. ПРОБЛЕМИ ТА НЕДОЛІКИ НАЯВНОЇ ІНФОРМАЦІЙНОЇ СИСТЕМИ

На даний момент бібліотека використовує систему програм «1С: Підприємство».

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

Основні завдання автоматизації, вирішувані тиражними прикладними рішеннями:

- Бухгалтерський облік;

- Бухгалтерський і податковий облік в повній відповідності з національним законодавством;

- Облік основних засобів і розрахунок амортизації;

- Формування податкової, бухгалтерської і іншої регламентованої звітності в різні органи;

- Бухгалтерський облік і контроль кошторисів витрат бюджетних організацій в повній відповідності із законодавством і

відомчими інструкціями:

- Збір зведеної звітності бюджетних організацій.

Складський, торговий, облік виробництва:

- Автоматизація складського обліку, аналіз стану складів, контроль руху товарно-матеріальних цінностей;

- Управління номенклатурою товарів, продукції і послуг, включаючи автоматизацію ціноутворення, складання складних калькуляцій, виготовлення виробів;

- Управління торговою діяльністю і автоматизація торгового документообігу;

- Аналіз ефективності торгової діяльності і прогнозування продажу;

- Автоматизація розрахунків з контрагентами, аналіз стану і динаміки взаєморозрахунків;

- Управління комісійною торгівлею від імені комітента і комісіонера;

- Розрахунок собівартості продукції і аналіз економічної ефективності виробничої діяльності;

- Управління виробництвом, включаючи незавершене виробництво, багато передільне виробництво, обробку давальницької сировини;

- Облік замовлень від покупців, внутрішнє планування випуску продукції, контроль виконання замовлень;

- Планування і контроль виконання замовлень на закупівлю продукції. Розрахунок зарплати і кадровий облік:

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

Завдання планування і фінансового аналізу:

- Планування, управління і аналіз фінансових результатів діяльності підприємства (бюджетування, планування фінансових показників, порівняння планових і фактичних показників за різні періоди).

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

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

Компоненту БУХГАЛТЕРСЬКИЙ ОБЛІК може бути використана для ведення будь-яких розділів бухгалтерського обліку. Різноманітні і гнучкі можливості даної системи дозволяють використовувати її і як простій і наочний інструмент бухгалтера, і як засіб повної автоматизації обліку від введення первинних документів до формування бухгалтерської і податкової звітності. Облік в компоненті заснований на принципі подвійного запису.

Компоненту ОПЕРАТИВНИЙ ОБЛІК є універсальною системою для обліку наявності і руху засобів. Вона може бути налаштована на різні схеми обліку і планування складських запасів, взаєморозрахунків, засобів на розрахункових рахівницях і в касі, розрахунків з підзвітними лицями, кредиторами і т.д. Компоненту дозволяє вести більш деталізований аналітичний облік, проте не орієнтована на балансову схему (Актив-Пасив).

Компоненту РОЗРАХУНОК орієнтована на проведення періодичних розрахунків і призначена для вирішення широкого круга різноманітних завдань, таких як облік переміщень співробітників підприємства і розрахунок їх заробітної платні і різного роду компенсацій. Крім того, на базі цієї компоненти можуть бути вирішені завдання, не пов'язані з розрахунком заробітної платні, наприклад, розрахунок вартості і амортизації основних засобів, реєстрація клієнтів і розрахунок вартості виконуваних для них замовлень і т.д.

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

«1С: Підприємство» - є системою програм з широкими можливостями економічного спрямування і призначена для комплексної автоматизації економічної діяльності підприємств різних напрямів діяльності. Ця система не може повністю задовольнити поставленні вимоги та завдання, що передбаченні у функціонуванні бібліотеки. Вона несе в собі значну надлишковість інформації і не є зручною для використання в діяльності бібліотеки, тому ми будемо розробляти БД засобами Microsoft Access, що є більш зручною системою для нашої предметної області.


Подобные документы

  • Аналіз структури та захисту інформаційних потоків в автоматизованій банківській системі (АБС) АКБ "Промінвестбанк". Побудова моделі системної інтеграції модулів захисту інформаційних потоків в АБС та оцінка рівня вразливості банківської інформації.

    дипломная работа [3,6 M], добавлен 02.07.2010

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

    дипломная работа [1,7 M], добавлен 09.09.2010

  • Теоретичні аспекти здійснення міжнародних розрахунків, дослідження механізму проведення даних операцій. Аналіз структури експортно-імпортних операцій. Особливості міжнародної торгівлі. Пропозиції щодо удосконалення міжнародних розрахунків України.

    курсовая работа [501,8 K], добавлен 06.09.2014

  • Теоретичні засади лізингового кредиту. Механізм застосування лізингового кредиту в Україні. Напрями вдосконалення механізму лізингового кредитування в Україні. Вдосконалення нормативно-правової бази та інформаційної бази щодо лізингу в Україні.

    курсовая работа [206,1 K], добавлен 23.12.2007

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

    контрольная работа [38,0 K], добавлен 14.03.2010

  • Гроші як засіб нагромадження суспільного і особистого багатства, опис форм їх нагромадження. Суть і характер обігу векселя, нормативно-правові основи даних процесів. Характеристика банківської системи України, оцінка її позитивних та негативних сторін.

    контрольная работа [46,4 K], добавлен 18.04.2013

  • Особливості функціонування систем страхування депозитів різних країн. Визначення їх ролі у забезпеченні стабільності фінансової системи. Використання диференційованих внесків до Фонду гарантування фізичних осіб з метою підтримки ліквідності Фонду.

    статья [36,3 K], добавлен 21.09.2017

  • Розробка системи для обліку операцій у банку. Аналіз її функцій: збереження номеру рахунку, прізвища вкладника, персональної інформації; виведення даних про найбагатшого вкладника; визначення сумарних внесків на рахунки і зняття з них за минулий місяць.

    курсовая работа [237,0 K], добавлен 30.01.2010

  • Характеристика показників, які мають бути визначальними при виборі надійної компанії, що займається страхуванням життя. Аналіз структури активів та пасивів на основі даних публічної фінансової звітності. Показники фінансової стійкості страхової компанії.

    отчет по практике [71,9 K], добавлен 06.04.2014

  • Класифікація депозитів. Проблеми формування ресурсної бази банку в період кризи. Аналіз депозитних операцій банків України. Модель залежності рентабельності активів ВАТ "Ощадний банк України" від коефіцієнтів ділової активності в частині пасивів.

    курсовая работа [395,4 K], добавлен 05.03.2012

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.