Дослідження предметної області

ЗМІСТ

 

Вступ.

Розділ 1. Дослідження предметної області.

1.1 Загальна характеристика казначейства

1.2 Структурні підрозділи та їх основне призначення

1.3 Основні функціональні задачі

1.4 Методика вирішення функціональних задач.

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

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

2.2 засоби формалізованого описання економічної інформації

2.3 побудова оптимальної економіко-математичної моделі

2.4 опис процедури нормалізації

2.5 Визначення функціональних залежностей та складу реквізитів інформаційної бази щодо вирішення функціональної задачі

2.6 Побудова та опис діаграми „Сутність зв”язок”

Висновки...

Список використаних джерел...

Додатки...

Вступ

 

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

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

Інформаційні системи в економіці використовуються для автоматизованого (людино-машинного) розв'язування економічних задач.

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

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

Створення інформаційних систем першого покоління для розв'язування деяких задач організаційно-економічного управління в нашій країні відносять до початку 60-х років XX століття.

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

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

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

РОЗДІЛ 1

Установка

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

Установка серверної частини

- Установити Microsoft SQL Server 7.0. При установці вибрати варіант інсталяції "CASTOM" і виконати нижченаведені вказівки:

- Збільшити пропоновану ємність системної таблиці (у залежності від ємності доступного дискового простору).

- Ім'я адміністратора, пароль – по розсуду (при установці можна не визначати).

- Визначити кодову сторінку - 1251 Cyrillic.

- Порядок сортування - Ukrainian Dictionary Order Case Insensitive.

- Підтримка - Named Pipes, Multi Protocol, TCP/IP.

- Запуск служб сервера і програм, що виконуються, під час завантаження комп'ютера позначити пункти Auto Start Server at a Boot Time, Auto Start Executive at a Boot Time.

- Визначити запуск виконавської служби на системній обліковій картці (позначити пункт "Service Start Up Account – System Account").

· По закінченні установки запустити сервер баз даних: Пуск – Програми - Microsoft SQL Server 70 – Service Manager – Start

· Запустити додаток адміністрування сервера баз даних - Пуск – Програми - Microsoft SQL Server 7.0 – Microsoft SQL Enterprise Manager. (При першому запуску пропонується зареєструвати сервер).

Зареєструвати сервер баз даних - Для реєстрації сервера бази даних необхідно вибрати в Enterprise Manager'е меню "ACTION" - "NEW SQL SERVER REGISTRATION" Помічник реєстрації допоможе зареєструвати Вам потрібний сервер.

Створити базу даних. При цьому немає необхідності ставити ємність з великим запасом – SQL SERVER сам розширює базу даних при необхідності. Вводитися ім'я бази, автоматично привласнюється ім'я логічній базі даних (закладка Transaction Log). При натисканні кнопки "SQL SERVER" створить базу.

РОЗДІЛ 2

Опис процедури нормалізації

 

Нормалізація - це процес приведення реляційних БД до норманом форми для забезпечення між локальної інформації і її цілісність.

В теперішній час відомо декілька нормальних форм: 1НФ, 2НФ, 3НФ, НФ Бойса-Кодда, 4 НФ, 5НФ. Існують і більш високі нормальні форми. Вони використовуються рідко, кожна більш висока НФ покладає додаткові обмеження на структуру БД.

Умови для 1 НФ – умова для таблиці відносин, щоб привести початкову таблицю до 1 НФ необхідно здублювати загальні значення даних.

Умова для 2НФ: таблиця знаходиться у 2НФ якщо вона відповідає 1НФ і всі не ключові атрибути повністю залежать від первинного ключа.

Умова для 3НФ: вона знаходиться в 2НФ, якщо вона відповідає 2НФ і в ній не повинно бути залежностей між не ключовими атрибутами.

Нормалізація відношень виконується за кілька кроків.

1-й крок— зведення відношень до першої нормальної форми (1НФ).

Відношення в 1НФ мають відповідати таким вимогам:

- усі атрибути відношення мають бути атомарними, тобто не­подільними;

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

- імена стовпців мають бути різними, а значення однорідними (мати однаковий формат);

- порядок рядків у таблиці неістотний.

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

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

Означення 1. Атрибут Б функціонально залежить від А у від­ношенні R тоді, коли в кожний момент часу одному й тому самому значенню А відповідає не більш як одне значення Б. Функціональній залежності відповідає відношення 1:1 між атрибутами.

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

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

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

 

R1 (А*, В*, C) і R2(B*, D).

 

3-й крок (3-тя ітерація) нормалізації --це вилучення транзи­тивних залежностей. Відношення в 2НФ має аналізуватися на присутність транзитивних залежностей.

Транзитивна залежність — це залежність між неключовими атрибутами.

Наприклад, дано відношення R (А *, В, Q, в якому атрибут В незалежить безпосередньо від ключа, а С залежить від неключового атрибута В, який залежить від А, то тоді С транзитивне залежить від А.

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

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

Функціональна частина являє собою ту область, в якій використовується СОЕІ тобто функціональна частина з точки зору кібернетичної моделі управління є об”єктом управління, Наприклад – підприємство, банк, податкова служба і т,д. Функціональна частина в якості складності вивчення ділиться на декілька компонентів, в кожній підсистемі виділено комплекси вирішення задач, кожна задача забезпечує обробіток інформаційних об”єктів

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

 

2.7 Побудова та опис діаграми „Сутність зв΄язок”

 

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

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

2. Неможливо відразу визначити повний список атрибутів. Користувачі мають звичку називати різними іменами одні і ті ж речі або навпаки, називати одними іменами різні речі.

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

У реальному проектуванні структури бази даних застосовуються інший метод - так зване, семантичне моделювання. Семантичне моделювання є моделювання структури даних, спираючись на сенс цих даних. Як інструмент семантичного моделювання використовуються різні варіанти діаграм суть-зв'язок (ER - Entity-Relationship).

Перший варіант моделі суть-зв'язок був запропонований в 1976 р. Пітером Пін-шен Ченом [37]. Надалі багатьма авторами були розроблені свої варіанти подібних моделей (нотація Мартіна, нотація IDEF1X, нотація Баркера і ін.). Крім того, різні програмні засоби, що реалізовують одну і ту ж нотацію, можуть відрізнятися своїми можливостями. По суті, всі варіанти діаграм суть-зв'язок виходитимуть з однієї ідеї - малюнок завжди наочніший за текстовий опис. Всі такі діаграми використовують графічне зображення суті наочної області, їх властивостей (атрибутів), і взаємозв'язків між суттю.

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

Основні поняття ER-діаграм

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

Кожна суть повинна мати найменування, виражене іменником в однині.

Прикладами суті можуть бути такі класи об'єктів як "Постачальник", "Співробітник", "Накладна".

Кожна суть в моделі зображається у вигляді прямокутника з найменуванням:

 

Мал. 1

 

Визначення 2. Екземпляр суті - це конкретний представник даної суті.

Наприклад, представником суті "Співробітник" може бути "Співробітник Іванов".

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

Визначення 3. Атрибут суті - це іменована характеристика, що є деякою властивістю суті.

Найменування атрибуту повинне бути виражене іменникам в однині (можливо, з характеризуючими прикметниками).

Прикладами атрибутів суті "Співробітник" можуть бути такі атрибути як "Табельний номер", "Прізвище", "Ім'я", "По батькові",

"Посада", "Зарплата" і т.п.

Атрибути зображаються в межах прямокутника, що визначає суть:

 

Мал. 2

 

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

Суть може мати декілька різних ключів.

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

 

Мал. 3

 

Визначення 5. Зв'язок - це деяка асоціація між двома суттю. Одна суть може бути пов'язана з іншою суттю або сама з собою.

Зв'язки дозволяють по одній суті знаходити іншу суть, пов'язану з нею.

Наприклад, зв'язки між суттю можуть виражатися наступними фразами - "СПІВРОБІТНИК може мати декілька ДІТЕЙ", "кожного СПІВРОБІТНИКА зобов'язаний числитися рівно в одному ВІДДІЛІ".

Графічно зв'язок зображається лінією, що сполучає дві суть:

 

Мал. 4

 

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

Кожен зв'язок може мати один з наступних типів зв'язку:

Мал. 5

 

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

Зв'язок типу одін-ко-многим означає, що один екземпляр першої суті (лівою) пов'язаний з декількома екземплярами другої суті (правою). Це найбільш часто використовуваний тип зв'язку. Ліва суть (з боку "один") називається батьківською, права (з боку "багато") - дочерней. Характерний приклад такого зв'язку приведений на Мал. 4.

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

Кожен зв'язок може мати одну з двох модальностей зв'язки:

 

Мал. 6

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

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

Зв'язок може мати різну модальність з різних кінців (як на Мал. 4).

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

побудови фраз: <Кожен екземпляр СУТІ 1> <МОДАЛЬНІСТЬ ЗВ'ЯЗКУ> <НАЙМЕНУВАННЯ ЗВ'ЯЗКУ> <ТИП ЗВ'ЯЗКУ>

<екземпляр СУТІ 2>.

Кожен зв'язок може бути прочитаний як зліва направо, так і справа наліво. Зв'язок на Мал. 4 читається так:

Зліва направо: "кожен співробітник може мати декілька дітей".

Справа наліво: "Кожна дитина зобов'язана належати рівно одному співробітникові".

Приклад розробки простій ER-моделі

При розробці ER-моделей ми повинні отримати наступну інформацію про наочну область:

1. Список суті наочної області.

2. Список атрибутів суті.

3. Опис взаємозв'язків між суттю.

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

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

Наприклад, в ході бесіди з менеджером з продажу, з'ясувалося, що він (менеджер) вважає, що проектована система повинна виконувати наступні дії:

•   Зберігати інформацію про покупців.

•   Друкувати накладні на відпущені товари.

•   Стежити за наявністю товарів на складі.

Виділимо всі іменники в цих пропозиціях - це будуть потенційні кандидати на суть і атрибути, і проаналізуємо їх (незрозумілі терміни виділятимемо знаком питання):

•   Покупець - явний кандидат на суть.

•   Накладна - явний кандидат на суть.

•   Товар - явний кандидат на суть

•   (?)Склад - а взагалі, скільки складів має фірма? Якщо декілька, то це буде кандидатом на нову суть.

•   (?)Наявність товару – це, швидше за все, атрибут, але атрибут якої суті?

Відразу виникає очевидний зв'язок між суттю - "покупці можуть купувати багато товарів" і "товари можуть продаватися багатьом покупцям". Перший варіант діаграми виглядає так:

 

Мал. 7

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

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

 

Мал. 8

 

Пора подумати про атрибути суті. Розмовляючи із співробітниками фірми, ми з'ясували наступне:

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

•   Кожен товар має найменування, ціну, а також характеризується одиницями вимірювання.

•   Кожна накладна має унікальний номер, дату виписки, список товарів з кількостями і цінами, а також загальну суму накладної. Накладна виписується з певного складу і на певного покупця.

•   Кожен склад має своє найменування.

•   Знову випишемо всі іменники, які будуть потенційними атрибутами, і проаналізуємо їх:

•   Юридична особа - термін риторичний, ми не працюємо з фізичними особами. Не звертаємо уваги.

•   Найменування покупця - явна характеристика покупця.

•   Адреса - явна характеристика покупця.

•   Банківські реквізити - явна характеристика покупця.

•   Найменування товару - явна характеристика товару.

•   (?)Ціна товару - схоже, що це характеристика товару. Чи відрізняється ця характеристика від ціни в накладній?

•   Одиниця вимірювання - явна характеристика товару.

•   Номер накладної - явна унікальна характеристика накладної.

•   Дата накладної - явна характеристика накладної.

•   (?)Список товарів в накладній - список не може бути атрибутом. Ймовірно, потрібно виділити цей список в окрему суть.

•   (?)Кількість товару в накладній - це явна характеристика, але характеристика чого? Це характеристика не просто "товару", а "товару в накладній".

•   (?)Ціна товару в накладній - знову ж таки це повинна бути не просто характеристика товару, а характеристика товару в накладній.

•   Сума накладної - явна характеристика накладної. Ця характеристика не є незалежною. Сума накладної рівна сумі вартостей всіх товарів, що входять в накладну.

•   Найменування складу - явна характеристика складу.

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

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

Точно також поступимо із зв'язком, що сполучає суть "Склад" і "Товар". Введемо додаткову суть "Товар на складі". Атрибутом цієї суті буде "Кількість товару на складі". Таким чином, товар числитиметься на будь-якому складі і кількість його на кожному складі буде своє.

Тепер можна внести все це до діаграми:

Мал. 9

 

Концептуальні і фізичні ER-моделі

Розроблений вище приклад ER-діаграми є прикладом концептуальної діаграми. Це означає, що діаграма не враховує особливості конкретної СУБД. По даній концептуальній діаграмі можна побудувати фізичну діаграму, яка вже враховуватимуться такі особливості СУБД, як допустимі типи і найменування полий і таблиць, обмеження цілісності і т.п. Фізичний варіант діаграми, приведеної на Мал. 9 може виглядати, наприклад, таким чином:

 

Мал. 10

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

Легко відмітити, що отримані таблиці відразу знаходяться в 3НФ.

 

Висновки

 

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

Як інструмент семантичного моделювання використовуються різні варіанти діаграм суть-зв'язок (ER - Entity-Relationship).

Діаграми суть-зв'язок дозволяють використовувати наочні графічні позначення для моделювання суті і їх взаємозв'язків.

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

При правильному визначенні суті, отримані таблиці відразу знаходитимуться в 3НФ.

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

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

ЗМІСТ

 

Вступ.

Розділ 1. Дослідження предметної області.

1.1 Загальна характеристика казначейства

1.2 Структурні підрозділи та їх основне призначення

1.3 Основні функціональні задачі

1.4 Методика вирішення функціональних задач.

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

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

2.2 засоби формалізованого описання економічної інформації

2.3 побудова оптимальної економіко-математичної моделі

2.4 опис процедури нормалізації

2.5 Визначення функціональних залежностей та складу реквізитів інформаційної бази щодо вирішення функціональної задачі

2.6 Побудова та опис діаграми „Сутність зв”язок”

Висновки...

Список використаних джерел...

Додатки...

Вступ

 

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

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

Інформаційні системи в економіці використовуються для автоматизованого (людино-машинного) розв'язування економічних задач.

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

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

Створення інформаційних систем першого покоління для розв'язування деяких задач організаційно-економічного управління в нашій країні відносять до початку 60-х років XX століття.

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

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

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

РОЗДІЛ 1

Дослідження предметної області