База даних менеджера по роботі з клієнтами ПАТ КБ ІФФ "ПриватБанк"

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

Зміст

Вступ

1. Характеристика предметної області

1.1 Вимоги до даних

1.2 Вимоги до транзакцій

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

2.1 Концептуальне проектування бази даних

2.2 Логічне проектування бази даних

2.3 Фізичне проектування бази даних

3. Побудова форм і запитів

3.1 Побудова форма

3.2 Побудова запитів

4. Створення звітів

5. Автоматизація робочого місця за допомогою макросів

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

7. Вибір технічних засобів для автоматизованого робочого місця

8. Розрахунок споживаної потужності технічних засобів для

автоматизованого робочого місця

Висновок

Перелік використаних джерел

Додатки

Графічна частина

Вступ

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

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

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

1. Характеристика предметної області

1.1 Вимоги до даних

В якості предметної області ми розглянемо базу даних менеджера по роботі з клієнтами ПАТ КБ ІФФ "ПриватБанк"

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

Робоче місце менеджера по роботи з клієнтами в ПАТ КБ ІФФ "ПриватБанк" складається робочої площі та технічних засобів. Робоча площе це те все що оточує менеджера, тобто стіл, крісло і т. д. До технічних засобів відносять принтер, комп'ютер, планшет IPad. В основному зараз менеджері користуються планшетом.

До даних в базі даних в даному курсовому проекті були поставлені такі вимоги :

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

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

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

4. Регулярне поновлення. Базу даних необхідно час від часу поновлювати. Люди змінюють місце проживання і номери телефонів. Оновлення баз даних рекоменовано провадити у півтора-два місяця.

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

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

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

Тоді в базу даних доцільно включити інформацію про: клієнтів;про депозити;кредити; про видані карточки; про проведені операції грошових переказів. При цьому, розроблювана база даних повинна забезпечити такі функції:

1. Моніторинг клієнтів і редагування інформації про них.

В інформацію про клієнтів доцільно включити такі дані:

- прізвище;

- ім'я;

- по батькові;

- місто;

- вулиця;

- дім\квартира;

-номер телефону.

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

В інформацію про депозити доцільно включити такі дані:

- код депозиту;

- розмір депозиту;

- річні відсоткиові;

- дата депозиту;

- прізвище;

- ім'я;

-по батькові.

3. Моніторинг видачі карточок і редагування інформації про них.

В інформацію про карточки доцільно включити такі дані:

- код карточки;

- тип карточки;

- дата видачі;

- прізвище;

-код переказу.

4. Моніторинг кредитів і редагування інформації про них.

В інформацію про кредити доцільно включити такі дані:

- код кредиту;

- сума кредиту;

- відсоток кредиту;

- дата видачі;

- прізвище;

- ім'я;

-по батькові.

5. Моніторинг грошових переказів і редагування інформації про них.

В інформацію про перекази доцільно включити такі дані:

- код переказу;

- сума переказу;

- система переказу;

- прізвище.

1.2 Вимоги до транзакцій

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

В моїй базі даних менеджера по роботі з клієнтами менеджер повинен виконувати такі транзакції:

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

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

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

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

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

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

2.1 Концептуальне проектування бази даних

Етап 1.1 Визначення типів сутностей.

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

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

Для бази даних було розроблено 5 сутностей: Клієнти, Депозити, Карточки, Кредити, Перекази.

Таблиця 2.1

Сутності бази даних

Назва сутності	Опис
Клієнти	Інформація про клієнтів
Депозити	Облік даних про депозити
Карточки	Інформація про видані карточки
Кредити	Інформація про видані кредити
Перекази	Довідка про проведені перекази

Етап 1.2 Визначення типів зв'язків.

Між сутностями встановлюються зв'язки, які вказують яким чином сутності співвідносяться або взаємодіють між собою. Розрізняють такі зв'язки:

? між двома сутностями (бінарний зв'язок);

? між трьома сутностями (тернарний зв'язок);

? між N сутностями (N-арний зв'язок);

? між однією сутністю (рекурсивний зв'язок).

Найбільш поширеними є бінарні зв'язки. Зв'язок показує яким чином екземпляри сутностей зв'язані між собою. Бінарні зв'язки бувають:

? 1:1 (один до одного);

? 1:M (один до багатьох);

? N:M (багато до багатьох).

Таблиця 2.2

Основні типи зв'язків

Тип сутності	Тип зв'язку	Тип сутності
Клієнти	1:М	Депозити
Клієнти	1:М	Карточки
Клієнти	1:М	Кредити
Клієнти	1:М	Перекази
Перекази	1:М	Карточки
Клієнти	N:М	Перекази

Етап 1.3 Визначення атрибутів і зв'язування їх з типами сутностей та зв'язків.

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

Етап 1.4 Визначення атрибутів, що є потенційними і первинними ключами.

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

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

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

2. Ніякої з атрибутів первинного ключа не повинен мати нульове значення;

3. Значення атрибутів первинного ключа не повинні змінюватися.

Як випливає з назви, не ключовий атрибут - це атрибут, який не був обраний ключовим. Потенційний ключ, який не став первинним називається альтернативним ключем ( Alternate key ). У розробленій базі даних альтернативних ключів немає.

база автоматизація макрос запит

Таблиця 2.3

Сутності та їхніпервинні і альтернативні ключі

Сутність	Первинний ключ	Альтернативний ключ
Клієнти	Прізвище	-
Депозити	Код депозити	-
Карточки	Код карточки	-
Кредити	Код кредиту	-
Перекази	Код переказу	-

Етап 1.5 Створення діаграми "сутність-зв'язок".

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

Ця ER-діаграма(див. креслення схеми даних) і підготовлена на етапі 1 документація (в сукупності) представляють собою локальну концептуальну модель даних для користувача АРМу.

2.2 Логічне проектування бази даних

Етап 2.1 Перетворення локальної концептуальної моделі даних в локальну логічну модель.

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

Даний етап включає:

- видалення зв'язків з кардинальністю "багато до багатьох";

- видалення складених зв'язків (котрі з'єднують більше двох типів сутностей;

- видалення рекурсивних зв'язків;

- видалення зв'язків з атрибутами;

- видалення множинних атрибутів;

- повторний огляд зв'язків типу 1:1.

Видалення зв'язків типу багато до багатьох.

У локальній концептуальній моделі даних зв'язки типу N:M відсутні,

тому ми переходимо до наступного етапу.

Видалення складних зв'язків.

На цьому етапі проводиться видалення будь-яких складених (не бінарних) зв'язків, що є присутніми у концептуальній моделі. У локальній концептуальній моделі даних складні зв'язки відсутні, тому ми переходимо до наступного етапу.

Видалення рекурсивних зв'язків.

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

Видалення зв'язків, що мають атрибути.

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

Видалення множинних атрибутів.

У локальній концептуальній моделі даних множинні атрибути відсутні, тому ми переходимо до наступного етапу.

Повторний огляд зв'язків типу 1:1.

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

Етап 2.2 Визначення набору відношень, виходячи із структури локальної логічної моделі даних.

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

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

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

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

Для кожного бінарного зв'язку типу 1:1, встановленого між сутностями El i Е2, ми повинні переслати атрибути первинного ключа сутності Е1 у відношення, яке представляє сутність Е2. Ці атрибути будуть використовуватись в ньому в якості зовнішнього ключа.

Визначення батьківської і дочірньої сутностей залежить від обмежень участі, накладених на члени відношення Е1 і Е2. Сутність, яка частково бере участь в зв'язку, визначається як батьківська, а та сутність, яка бере участь в зв'язку повністю (тотально), визначається як дочірня.

Для кожного бінарного зв'язку типу І :М, встановленого в логічній моделі даних між сутностями Е1 і Е2, необхідно переслати копію атрибутів первинного ключа сутності Е1 у відношення, яке представляє сутність Е2, де вони відіграватимуть роль зовнішнього ключа. Сутність, яка представляє "одинарну" сторону зв'язку, визначається як батьківська, а сутність, що представляє "множинну" сторону, -- як дочірня.

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

-клієнти	1:М	депозити
-клієнти	1:М	карточки
-клієнти	1:М	кредити
-клієнти	1:М	перекази
-перекази	1:М	карточки
-клієнти	N:М	перекази

Етап 2.3 Перевірка моделі за допомогою правил нормалізації.

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

* приведення до першої нормальної форми (1НФ), що дозволяє видалити з відношень групи атрибутів, які повторюються;

* приведення до другої нормальної форми (2НФ), що дозволяє видалити часткову залежність атрибутів від первинного ключа;

* приведення до третьої нормальної форми (ЗНФ), що дозволяє видалити транзитивну залежність атрибутів від первинного ключа;

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

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

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

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

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

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

Етап 2.4 Створення остаточного варіанту діаграми "сутність-зв'язок"

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

У проектованій базі даних не потрібно вносити змін або доповнень у вихідний варіант ER-діаграми.

Етап 3 Створення та перевірка глобальної логічної моделі даних.

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

2.3 Фізичне проектування бази даних

Етап 4 Перенесення глобальної логічної моделі даних в середовище цільової СУБД.

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

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

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

· Етап 5.1. Аналіз транзакцій;

· Етап 5.2. Визначення вимог до дискової пам'яті.

Етап 5.1 Аналіз транзакцій.

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

· Очікувана частота транзакцій.

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

· Атрибути, які при виконанні запитів будуть використовуватись для з'єднання двох або більше відношень.

· Обмеження, що встановлюються на час виконання транзакцій.

Етап 5.2 Визначення вимог до дискової пам'яті.

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

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

Етап 7 Організація моніторингу і налаштування функціонування системи.

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

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

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

3. Побудова форм та запитів

3.1 Побудова форм

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

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

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

Створення форми з наявної таблиці або запиту в програмі Access

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

У програмі Access буде створено форму, яка відобразиться в поданні макета. За потреби можна змінити структуру, наприклад настроїти розмір текстових полів відповідно до обсягу даних. Докладніше про це див. у статті про використання знаряддя «Форма».

Створення пустої форми в програмі Access

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

2. В області Список полів натисніть знак "плюс" (+) поруч з однією або кількома таблицями, що містять поля, які мають відображатися у формі.

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

ПРИМІТКА : Порядок таблиць в області Список полів може змінюватися, залежно від того, яку частину форми наразі вибрано. Якщо не вдається додати поле до форми, спробуйте вибрати іншу частину форми, а потім додати поле знову.

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

2. Якщо потрібно додати до форми ширший спектр елементів керування, виберіть вкладку Конструктор і скористайтеся знаряддями в групі Елементи керування.

Створення розділеної форми в програмі Access

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

Щоб створити нову розділену форму за допомогою знаряддя «Розділена форма», в області переходів клацніть таблицю або запит, що містить дані для форми, а потім на вкладці Створити натисніть кнопку Додаткові форми та виберіть пункт Розділена форма.

Програма Access створює форму, структуру якої можна змінити. Наприклад, за потреби можна настроїти розмір текстових полів відповідно до обсягу даних. Для отримання додаткових відомостей про роботу з розділеною формою див. статтю про створення розділеної форми.

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

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

1. В області переходів клацніть таблицю або запит із даними, які мають відображатися у формі.

2. На вкладці Створити клацніть елементи Додаткові форми > Кілька елементів.

3. У програмі Access буде створено форму, яка відобразиться в поданні макета. У поданні макета можна змінювати макет форми під час відображення в ній даних. Наприклад, розмір текстових полів можна настроїти відповідно до обсягу даних. Додаткові відомості див. у розділі Створення форми за допомогою засобу «Кілька елементів».

3.2 Побудова запитів

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

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

Відповідно до функцій виділяють такі типи запитів:

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

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

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

2. Запити на зміну -- вносять в таблиці значні зміни, відмінити які не можна. В LibreOffice Base такі запити часто заблоковані, тобто на виконання таких запитів необхідно мати специфічні права доступу. Запити такого типу поділяють підтипи:

o запит на видалення записів;

o запит на долучення записів;

o запит на створення таблиці;

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

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

Оновлюваний запит -- це динамічний набір даних. В оновлюваних запитах можна редагувати дані й долучати нові, всі зміни можна буде зберегти у базових таблицях, віртуальні поля буде перераховано. Ознака оновлюваного запиту -- символ * (новий запис) в кінці таблиці. Зазвичай це запити на вибірку.
Неоновлюваний запит -- це статичний набір даних, призначений лише для перегляду. Якщо змінити властивості запиту на вибірку, можна перетворити його на статичний набір даних.

Записати умови запиту можна по-різному. LibreOffice Base підтримує типи запитів QBE і SQL.

Запити на створення таблиці

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

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

Процес створення запиту на створення таблиці складається з таких основних кроків:

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

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

Додаткові відомості про нормалізацію даних див. в статті Основи розробки баз даних.

· Перетворення запиту на вибірку на запит на створення таблиці, вибір розташування нової таблиці та виконання запиту для створення таблиці.

Не слід плутати запит на створення таблиці із запитом на оновлення або додавання. Запит на оновлення використовується для додавання або змінення даних в окремих полях. Запит на додавання використовується для додавання записів (рядків) до наявного набору записів у наявній таблиці.

Для отримання додаткових відомостей про запити на оновлення див. статтю Створення запиту на оновлення. Для отримання додаткових відомостей про запити на додавання див. статтю Створення запиту на додавання.

4. Створення звітів

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

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

За допомогою Microsoft Office Access 2007 можна створювати різноманітні звіти, від простих до складних. Перш за все слід визначити джерело записів, на якому базуватиметься звіт. Незалежно від того, чи є звіт простим списком записів, чи згрупованим зведенням щодо продажу за регіонами, спочатку необхідно визначити, в яких полях містяться потрібні для звіту дані та в яких таблицях або запитах розташовані ці поля.

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

Вибір джерела записів

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

Створення звіту за допомогою засобу "Звіт"

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

1. В області переходів клацніть таблицю або запит, на основі яких потрібно створити звіт.

2. На вкладці Створення в групі Звіти натисніть кнопку Звіт.

Access сформує звіт і відобразить його в режимі розмітки.

3. Додаткові відомості про перегляд і друк звіту див. в розділі Перегляд, друк або надсилання звіту електронною поштою.

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

Створення звіту за допомогою майстра звітів

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

· На вкладці Create, у групі Reports клацніть елемент Report Wizard.

· Виконайте вказівки на сторінках майстра звітів. На останній сторінці натисніть кнопку Готово.

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

ПРИМІТКА : Якщо до звіту потрібно додати поля з кількох таблиць і запитів, не натискайте кнопку Далі абоГотово після вибору полів із першої таблиці або запиту на першій сторінці майстра звітів. Повторіть кроки для вибору таблиці або запиту та виберіть додаткові поля, які потрібно включити до звіту. Після цього натисніть кнопку Далі або Готово, щоб продовжити.

Створення етикеток за допомогою майстра етикеток

Майстер етикеток дає змогу легко створювати різноманітні етикетки стандартних розмірів.

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

2. На вкладці Створення в групі Звіти натисніть кнопку Етикетки.

3. Виконайте вказівки на сторінках майстра етикеток. На останній сторінці натисніть кнопку Готово.

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

ПРИМІТКА : Одночасно переглянути кілька стовпців можна лише в режимі попереднього перегляду - в інших поданнях відображаються дані тільки одного стовпця.

5. Автоматизація робочого місця за допомогою макросів

Макрос - це засіб, який дає змогу автоматизувати завдання і додавання функцій до форм, звітів і елементів керування. Наприклад, якщо додати кнопки до форми, пов'язати подія OnClick кнопки для макросу, і макрос із командами, яку потрібно кнопку щоразу при натисканні.

У програмі Access варто вважати макроси спрощений мова програмування, що ви пишете шляхом створення список дій для виконання. Якщо створити макрос, який розкривного списку виберіть кожної дії а потім заповніть необхідні відомості для кожної операції. Макроси дають змогу додавання функцій до форм, звітів і елементи керування без написання коду в у модулі Visual Basic for Applications (VBA). Макросів є підмножиною команд, доступних у VBA, і більшість користувачів зручніше створити макрос, ніж написати код VBA.

Припустімо, що потрібно почати звіту безпосередньо з до форми введення даних. Можна додати кнопки до форми та виберіть створити макрос, який починається у звіті. Макрос може бути автономного макросу (окремих об'єктів у базі даних), які потім прив'язано до події OnClick кнопки, або можна вбудувати макрос безпосередньо до події OnClick кнопки - це нова функція Office Access 2007. Будь-якому випадку, якщо натиснути кнопку, макрос запускається і буде запущено звіт.

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

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

Імена макросів

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

Аргументи

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

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

Умови

Умова визначає певні критерії, які повинні виконуватися для виконання певної дії. Можна скористатися будь-яким вираз, що має значення «Істина/Хибність» або «Так/Ні». Дія не виконуватиметься, якщо вираз має значення «Хибність», «Ні» або 0 (нуль). Якщо вираз має будь-яке інше значення, дію буде запущено.

Можна зробити так, щоб одна умова керувала кількома діями --для цього потрібно ввести трикрапку (...) у стовпці Умова для кожної подальшої дії, до якої має застосовуватися умова. Якщо вираз має значення «Хибність», «Ні» або 0 (нуль), жодна дія не виконуватиметься. Якщо умова має будь-яке інше значення, виконуватимуться всі дії.

Створення макросу

В Office Access 2007 макрос або група макросів можуть міститися в об'єкті макросу (який іноді називається ізольованим макросом), або макрос може вбудовуватись у будь-яку властивість події форми, звіту або елемента керування. Вбудовані макроси стають частиною об'єкта або елемента керування, до яких вони вбудовані. Ізольовані макроси відображаються в області переходів, у розділі Макроси, а вбудовані макроси -- ні.

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

Є два шляхи запуску макросів:

Безпосередній запуск макросів.

Можна вручну запустити макрос з вікна бази даних, з конструктора, або з меню «Сервіс | Макрос».

Непрямий запуск макросів.

Можна вказати макрос як дію пункту меню, кнопки, оброблювача події. Також макрос можна запустити з іншого макросу або з VBA програми.

Для рішення про виконання певної макрокоманди, може застосовуватися умовний вираз.

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

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

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

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

Всі аргументи для кожної макрокоманди відображаються в нижній половині вікна макросу.

Для деяких макрокоманд (Відкрити...) їхній можна автоматично заповнити за допомогою перетаскування миші.

Виконання макросу в покроковому режимі дозволяє простежити передачу керування і результати виконання кожної макрокоманди.

Це полегшує пошук макрокоманди, що приводить до виникнення помилки або дає невірні результати.

За допомогою відповідної кнопки на панелі задач, можна включити / виключити покроковий режим.

Для того щоб тимчасово пропустити макрокоманду, уведіть як умову «False». Такий прийом часто використовують при налагодженні макросів.

У ранніх версіях Access макроси відігравали значну роль. Починаючи з 97 версії, на перший план вийшло програмування на Visual Basic.

Спеціальний макрос AutoExec дозволяє автоматично виконати макрокоманду або набір макрокоманд при відкритті бази даних. У процесі відкриття бази даних Microsoft Access виконує пошук макросу з цим ім'ям і, якщо такий макрос існує, автоматично запускає його.

Допускається зв'язування макрокоманди або набору макрокоманд із конкретною клавішею або сполученням клавіш за допомогою спеціальної групи макросів AutoKeys. Після цього при натисканні клавіші або сполучення клавіш Microsoft Access буде виконувати дану макрокоманду.

Усього існує близько 60 макрокоманд.

Деякі з них:

ЗапускМакроса - виконання іншого макросу.

ОстановитьМакрос - Припиняє виконання макросу.

ОтменитьСобытие - Скасувати подію, яка призвела до запуску макросу.

ЗапускПриложения - виконання зовнішньої програми.

Закрыть, - закрити зазначений об'єкт бази даних.

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

ПрименитьФильтр - застосовує до набору даних зазначений фільтр.

Обновление - обновляє дані в активному об'єкті.

КэлементуУправления - перемішає фокус на зазначене поле або елемент керування.

НаСтраницу - змінює активну сторінку у формі.

Печать - роздрукує активний об'єкт.

ВыводНаЭкран - вкл / викл відображення результатів роботи майстри.

Сообщение - видає на екран текст зазначеного повідомлення.

Выход - закрити Access.

6. Експлуатація бази даних

Реалізація інформаційної системи

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

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

Конвертування та завантаження даних

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

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

Тестування інформаційної системи

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

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

Супровід інформаційної системи

В нашому випадку супровід готової інформаційної системи включає такі види робіт:

1) навчання працівників ;

2) профілактичне обслуговування ПК;

3) внесення змін в системі в результаті змін у законодавстві України.

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

7. Вибір технічних засобів для автоматизованого робочого місця

Провівши детальний аналіз завдань АРМ відділу , дамо попередню оцінку апаратного і програмного забезпечення для подальшого проектування і успішного функціонування БД. Результати запишемо у вигляді таблиць 2.9 і 2.10

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

Таблиця 7.1

Характеристика апаратного забезпечення

Перелік	К-сть	Вартість одиниці (грн)	Вартість всього (грн.)
наявного апаратного забезпечення	необхідного апаратного забезпечення
1	2	3	4	5
	1. Комп'ютер	5	4068,91	20344,57
	1.1. Системний блок	5	2868,94	14344,72
	1.1.1. Материнська плата MB Asus M4N68T Socket AM3/ Geforce 7025/2 x DDR3 DIMM/8-канальный кодек VT1708S/1 x Parallel port, 1 x VGA, 3 x Audio I/O, 2 x PS/2, 1 x LAN(RJ45), 4 x USB 2.0/1.1, 1 x COM/1 x PCIe x16, 1 x PCIe x1, 2 x PCI/uATX	5	437,8	2189
	1.1.2. Процесор CPU AMD Athlon 64 II X3 445 sAM3 (3,1GHz, L1: 3x128 Кб, L2: 3x512 Кб, 95W) BOX	5	616,9	3084,5
	1.1.3. Оперативна пам'ять 2 x DDR3 2GB/1333 Goodram	5	334	1670
	1.1.4. Відеокарта ATI Radeon PCI-E HD5550 1Gb D2 XFX (HD-555X-ZNF2)	5	449,74	2248,7
	1.1.5 Вінчестер HDD SATA 320Gb Seagate 16Mb (STM3320418AS)	5	383,67	1918,35
	1.1.6. Дисковод ASUS DRW-24B3ST SATA Black Bulk (DVD+/-RW)	5	230,84	1154,2
	1.1.7. Охолоджувач Deepcool CK-AM209 s754/939/AM2/AM3	5	59,70	298,5
	1.1.8. Блок живлення PrologiX 300W, 1 SATA	5	99,50	497,5
	1.1.9. Корпус GRESSO C-3010/Black	5	256,47	1282,35
	1.2. Монітор Acer X203HBb (ET.DX3HE.B02) 20"	5	1074,6	5372
	1.3. Клавіатура A4 Tech KM-720 Black/ USB	5	50,47	252,35
	1.4. Миша Ewel Mouse pad/ USB	5	74,90	374,5
	2. Принтер МФУ Canon i-SENSYS MF4410 А4	5	1862,64	9313,2
	3. Колонки Gembird WCS-605 silver/black	5	103,32	516,6
	4. Веб-камера GembirdCAM81U 2M з мікрофоном	5	119,4	597
	5. Кабель IPnet Cat. 5e UTP cable 4x2x1 - 0.5mm, мідь 100% 305м	5	382,08	1910,4
Всього	6536,35	32681,8

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

Таблиця 7.2

Характеристика апаратного забезпечення

Тип програмного забезпечення	Перелік	К-сть	Вартісь одиниці (грн)	Вартість всього (грн.)
	Наявного програмного забезпечення	Необхідного програмного забезпечення
1. Системне		1.1. Операційна система MS Windows XP Pro Rus (OEM)	5	1255,25	6276,46
2.Прикладне		2.1. Пакет офісних програм MS Office 2007 Pro Rus (OEM)	5	313	1564,14
		2.2. Антивірусна програма Kaspersky Anti-Virus 2011	5	188	939,28
		2.3 Програма для розпізнавання документів ABBYY FineReader 9.0 Professional Edition	5	699	3494,44
		2.4 Програма для відеодзвінків та чату Skype 5.3.0.111	5	238,8	1194
Всього	2693,66	13468,32

8. Розрахунок споживаної потужності технічних засобів для створення бази даних

Розрахунок споживаною блоком живлення потужності слід виконувати на стадії аналізу початкової моделі ПК або компонентів для самосбора.

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

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

...