Міністерство освіти Російської Федерації
Пермського державного ІНСТИТУТ МИСТЕЦТВА І КУЛЬТУРИ
Факультет документально-інформаційних комунікацій
Кафедра інформатики та інформаційних технологій
УДК 004.42:35.073.515.3
Створення автоматизованої інформаційної системи «Звід звітів» для УВО при ГУВС Пермського краю
Дипломна робота, подана до захисту за спеціальністю 351400
«Прикладна інформатика в соціально-культурній сфері»
Виконавець:
студент групи ІР-53
Стельмах Н.В.
Науковий керівник:
Серьогіна Т.А.
_____________________
Допущений до захисту
«__»_________________ 2006
Зав. кафедрой_________________ М.М. Масленников
Перм, 2006
Реферат
Анотація:
У дипломній роботі на базі платформи 1С буде розроблена конфігурація 1С: «Звід звітів» під особливості автоматизації складання звітів в Управлінні позавідомчої охорони.
Об'єкт дослідження:
Управління позавідомчої охорони.
Предмет дослідження:
Організація і технологія складання звітів УВО в конфігурації 1С: «Звід звітів».
Мета дипломної роботи:
Автоматизація складання звітів для УВО за допомогою конфігурації 1С: «Звід звітів».
Завдання дослідження:
· Розгляд предметної області: збір та аналіз наявних даних, виявлення складу і структури об'єктів, побудова концептуальної моделі;
· Аналіз нормативно-правових документів, що регламентують правила складання звітів;
· Вивчення конфігурування на платформі 1С: і особливостей рішення розрахункових завдань у ній;
· Вивчення роботи з регістрами оперативного обліку в 1С: Підприємстві;
· Впровадження системи 1С: «Звід звітів» в УВО.
Методи дослідження:
· Аналіз нормативно-правової документації;
· Моделювання;
· Проектування;
· Програмування;
· Тестування працездатності інформаційної системи.

Введення. 8
1. Сучасний стан створення звітів на підприємствах. Обгрунтування створення системи .. 10
1.1 Звітна документація як основа ефективності функціонування. 10
підприємства. 10
1.1.1 Поняття управлінської звітності. 10
1.1.2 Характеристики системи управлінської звітності. 12
1.2 Аналіз існуючих АІС з підготовки звітних документів. 16
1.1.2 Система «Облік ІТСО». 16
1.1.3 Система «Картотека». 17
1.1.4 Конфігурація 1С «АНВИК: Облік відділу позавідомчої охорони» 18
1.1.5 Порівняння систем «Облік ІТСО», «Картотека» і «АНВИК: Облік ОВО» 19
1.1.6 Висновки .. 24
1.2 Техніко-економічне обгрунтування ефективності впровадження АІС "Звід звітів" для УВО .. 24
2. Аналіз предметної області, системний і структурний аналіз. 27
2.1 Аналіз предметної області створення і використання звітних документів. 27
2.2 Існуючі форми звітності в УВО. 27
2.2.1 Форма «ВО-2». 27
2.2.2 Звіт про наявність ПЦН, ЗЗА та ріпів. 29
2.2.3 Звіт про роботу підрозділу охорони .. 30
2.2.4 Звіт про результати роботи по боротьбі зі злочинністю і адміністративними правопорушеннями на охоронюваних ринках та антитерористичної захищеності об'єктів даної категорії. 31
2.2.5 Звіт охорони об'єктів і квартир. 32
2.2.6 Звіт про супроводі перевезеного майна власника, в т.ч. грошових коштів. 32
2.2.7 Звіт за станом квартир. 32
2.2.8 Звіт за станом об'єктів. 33
2.2.9 Звіт з охорони автостоянок УВО при ГУВС Пермської області. 33
2.2.10 Звіт про результати роботи УВО форма "ВО-1". 33
2.2.11 Підсумки роботи підрозділу ОВО. 34
2.2.12 Структурний аналіз звітних форм УВО. 34
2.3 Системний аналіз та структурне проектування системи .. 35
2.3.1 Визначення вимог до нової системи. 35
2.3.1 Логічне проектування системи. 35
2.3.1.1 Операція з обліковими записами про об'єкти. 36
2.3.1.2 Операції з обліковими записами про ТСО 37
2.3.1.3 Операції з обліковими записами про ПЦО або АТС 40
2.3.1.4 Операції з записами про історію ТСО 42
2.3.1.5 Операції з записами про історію об'єктів 44
2.3.1.6 Операція з обліковими записами про заявки та супроводження майна. 46
2.3.1.7 Операція з обліковими записами про співробітників УВО. 47
2.3.1.8 Складання на основі записів звітних форм. 48
2.4 Розробка инфологической та концептуальної схеми БД. 57
2.4.1 Побудова инфологической схеми БД. 57
2.4.2 Побудова об'єктно-орієнтованої моделі БД .. 59
2.5 Вибір моделі даних і СКБД .. 61
2.5.1 Реляційна модель даних. 61
2.5.2 Об'єктно-орієнтована модель даних. 63
2.5.3 СУБД 1с: V8.0. 64
2.5.4 СУБД Oracle 10g. 65
2.5.5 СУБД SQL Server 2000. 68
2.5.6 СУБД InterBase 6. 70
2.5.7 Порівняння СУБД Oracle 10g, SQL Server 2000, InterBase 7.1 і 1С: v8.0 71
3. Проектування додатка. 74
3.1 Опис створених об'єктів у конфігурації. 74
3.2 Вимоги до обладнання, прикладного і системного ПЗ для забезпечення роботи системи .. 75
Висновок. 76
Список використаної літератури .. 77

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

Введення

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

1. Сучасний стан створення звітів на підприємствах. Обгрунтування створення системи

1.1 Звітна документація як основа ефективності функціонування

підприємства.

1.1.1 Поняття управлінської звітності.

Ефективність роботи підприємства значною мірою визначається якістю і оперативністю їх інформаційного забезпечення.
Вищий рівень управління завжди характеризується підвищеною складністю, варіативністю і динамічністю управлінських ситуацій. У багатьох структурах відомості, отримані керівництвом для контролю і прийняття рішень, базуються на двох видах звітності.
Перший з них - податкова і фінансова звітність, наявність якої вимагається від усіх за законом. Ці форми звітності детально розроблені і мають однаковий вигляд. Проблема полягає в тому, що подаються в податковій і фінансовій звітності інформація слугує специфічним цілям і не відповідають потребам вищого рівня управління.
Другий вид звітності - внутрішня звітність (аналітичні звіти). Цей вид не визначається законодавчо, і організації мають повну свободу в тому, як вести внутрішню звітність. Якщо система внутрішньої звітності складається сама собою, то виникає ситуація, при якій керівники отримують звіти про роботу своїх відділів, але представлені в цих звітах відомості зазвичай мають ряд недоліків:
- Вони розлогий;
- Не структуровані і не представлені в зручному для сприйняття вигляді;
- Неповні і суперечливі;
- Не дозволяють простежувати походження представлених у них даних до першоджерела;
- Надані різними підрозділами дані по одних і тих самих питань можуть вступати в протиріччя і істотно відрізнятися один від одного;
- Достовірність наведених у звітах даних складно або неможливо перевірити;
- Терміни подання звітності часто не дотримуються (запізнювання представляється звітної інформації).
Всі ці недоліки разом утворюють той інформаційний фон, на якому керівники здійснюють свою діяльність. Очевидно, що володіє такими недоліками інформаційна система являє собою хитку основу для прийняття оперативних і стратегічних рішень.
Управлінська звітність може розумітися у вузькому сенсі як звіти про виконані за завданням керівника діях. У більш широкому сенсі - діюча в організації інформаційна система подання керівництву у вигляді документів структурованої інформації (довідок, звітів, записок і т.д.) про всі аспекти діяльності. Система управлінської звітності розглядається саме як всеосяжна інформаційна середовище, забезпечує керівництво всією необхідною йому інформацією. Повна звітність про діяльність організації формується на основі звітності за трьома видами планів, таких як: бюджет (фінансова та бухгалтерська звітність); виробничий план; план заходів (подій) - квартальний (місячний) план дій кожного підрозділу і всієї організації.
При наявності коректно розробленої системи звітності, що відповідає цим трьом видам планів, керівництво буде мати всю повною інформацією про те, що відбувається в організації.
Найчастіше використовують трирівневу систему управлінської звітності. Основними рівнями є:
1. журнали (книги) для запису всіх операцій організації або конкретного підрозділу. Використовуються в основному на оперативному рівні для реєстрації і контролю поточної операції;
2. звіти - короткі відомості про діяльність організації або підрозділу на конкретну дату чи за звітний період. Використовуються керівниками для поточних оперативних і тактичних рішень та застосування заходів контролю та вимірювання ефективності роботи підрозділів і окремих співробітників;
3. зведені звіти - звіти, підводять підсумки діяльності організації в декількох сферах за певний період. Використовуються керівництвом для прийняття рішень і розширеного (стратегічного) планування.

1.1.2 Характеристики системи управлінської звітності

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

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

1.2 Аналіз існуючих АІС з підготовки звітних документів.

1.1.2 Система «Облік ІТСО»

Огляд системи складений на основі її опису у статті «Ціна зайвих папірців». Дана система експлуатується вже більше 6 років і використовує СУБД Access. Основними рисами системи є:
· Представлення приладів на об'єкті у вигляді ієрархічної 4-х рівневої моделі (об'єкт-система - група приладів - прилад);
· Можливість потокового введення однотипних приладів (повторення при введенні всієї інформації, крім бухгалтерського, інвентарного та заводського номерів);
· Можливість простежити історію приладу (ремонт, час знаходження в ЗІП, час роботи);
· Зберігання інформації про користувачів і паролі користувачів безпосередньо в базі;
· Надання коштів для ведення електронного журналу регламентних робіт;
· Видача звітів по вибраних ділянках об'єктів, по шлейфах приладів, за приладами в обмінному фонді, відповідальною особою за об'єкти.
З позитивних сторін системи можна відзначити наявність потокового введення, що полегшує введення великого масиву однотипної інформації.
Також досить зручна система ведення регламентного журналу, що здійснюється шляхом введення ідентифікатора користувача та пароль, з можливістю роздруку журналу.
У системі не вистачає основних звітних форм, наприклад журналу помилкових спрацьовувань.

1.1.3 Система «Картотека»

Оцінити саму систему «Картотека» (далі «Картотека») у роботі мені не вдалося, через те, що вона містить конфіденційну інформацію і сама система є об'єктом інтелектуальної власності одного з відділів ОВО Ленінського району. Тому нижченаведений аналіз представлений на основі відомостей наданих старшим інспектором договірно-правового відділу Д.М. Ілларіонова, що працює з цією системою.
«Картотека» є системою веде облік рентабельних об'єктів, договорів по цих об'єктах і ТСО встановлених на цих об'єктах. Також можливий пошук по окремих реквізитів. Проводиться видача звітів в текстовий файл і безпосередньо на друк, наступних видів, стосовно до теми дослідження: списки пультових номерів, списки помилкових спрацьовувань, графік регламентних робіт, наряд з усунення помилкових спрацьовувань.
· «Картотека» має низку недоліків:
· DOS-інтерфейс тобто морально застарілий;
· Система пошуку не дозволяє реалізувати складні запити, наприклад, з декількома пошуковими критеріями;
· Звіти виводяться у файли з розширенням txt і, крім того, дуже обмежені в налаштуванні;
· Неможливо відсортувати виведені дані за обраною ознакою.
Основою для бази даних служить СУБД FoxPro версії 2.6, тобто СУБД файл - серверного типу. Це призводить до таких мінусів, як:
· Неможливість одночасного доступу
· Високе завантаження мережі
Програма була написана більше 5 років тому і не відповідає вимогам Держстандартів і «Повчання».

1.1.4 Конфігурація 1С «АНВИК: Облік відділу позавідомчої охорони»

Даний програмний продукт створений фірмою "АНВИК" на основі типової конфігурації "Бухгалтерія для бюджетних організацій" системи програм "1С: Підприємство" (далі «АНВИК: Облік ОВО»).
Система працює по 3 основними напрямками:
· Облік робіт і послуг за договорами охорони власності приватних осіб та розрахунків за ними;
· Облік робіт і послуг за договорами охорони власності організацій і розрахунків за ними;
· Облік технічних характеристик об'єктів, що охороняються та показників їх обслуговування, тобто ТСО.
Реалізовані в системі можливості дозволяють автоматизувати такі завдання - ведення списку ключів на охоронюваних об'єктах з урахуванням усієї необхідної інформації, ведення переліку приладів із зазначенням їх типів, облік встановлених приладів із зазначенням зон охорони приладів та облік спрацьовувань приладів із зазначенням зон і причин спрацьовувань. Передбачено формування карток "Оперативна картка на ключ" і "Картка обліку засобів охоронно-пожежної сигналізації (ОПС)".
На підставі введених даних можна сформувати необхідні звіти. Це "Звіт з установки приладів", "Встановлені прилади", "Відомість приладів ОПС" (кількість встановлених приладів на об'єктах із зазначенням типів приладів та розрахунком обмінного фонду), "Загальна кількість охоронюваних об'єктів і приміщень" та "План-графік техобслуговування за електромонтерам "(об'єкти, закріплені за електромонтерами, з кількістю умовних установок).
Переглянути систему в дії не вдалося, так як вона є інтелектуальною власністю фірми «АНВИК».

1.1.5 Порівняння систем «Облік ІТСО», «Картотека» і «АНВИК: Облік ОВО»

Системи порівнювалися за наступними критеріями:
· Використовувані СУБД (таблиця 1);
· Відповідність сучасним нормативним документам, у частині з обліку ТСО (таблиця 2);
· Інтерфейс (таблиця 3);
· Розмежування доступу до БД (таблиця 4);
· Можливості пошуку (таблиця 5);
· Можливості по виведенню звітів (таблиця 6).
Використовувані СУБД
Таблиця - SEQ Табліца_-\ * ARABIC 1

Найменування системи	Використовувана СУБД
Облік ІТСО	Access
Картотека	FoxPro 2.6
АНВИК: Облік ОВО	1C

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

Відповідність сучасним нормативним документам, у частині з обліку ТСО
Таблиця - SEQ Табліца_-\ * ARABIC 2

Найменування системи	Відповідність «Повчання ...»
Облік ІТСО	частково
Картотека	-
АНВИК: Облік ОВО	частково

Тут, можна помітити, що система «Картотека», внаслідок того, що вона є найстарішою з представлених систем, вже не відповідає вимогам сучасного «Повчання». Інші системи лише частково відповідають вимогам нормативу.
Інтерфейс
Таблиця - SEQ Табліца_-\ * ARABIC 3

Найменування системи	Тип інтерфейсу	Багатовіконний інтерфейс	Система допомоги
Облік ІТСО	Графічний (Windows)	+	-
Картотека	Псевдографічний (DOS)	-	-
АНВИК: Облік ОВО	Графічний (Windows)	+	-

Треба відзначити, що у всіх систем, відсутня система довідок, що сильно ускладнює роботу непідготовленому користувачеві. Незручним виглядає інтерфейс системи «Картотека». Так як інтерфейс працює в текстовому режимі DOS, то обсяг інформації, що відображається обмежений параметрами текстового екрана 80 * 25 символів, що не дозволяє показувати достатній обсяг інформації на одному екрані.

Розмежування доступу до БД
Таблиця - SEQ Табліца_-\ * ARABIC 4

Найменування системи	Захист доступу паролем
Облік ІТСО	+
Картотека	+
АНВИК: Облік ОВО	+

Безпека в даних системах, звичайно є невід'ємним елементом. Однак, як вже зазначалося вище система «Облік ІТСО» зберігає користувача паролі прямо в БД. Це, на мою думку, не дуже хороший підхід, але як варіант теж має право на існування. Його негативними рисами є те, що будь-який має прямий доступ до БД зможе прочитати паролі користувачів. Дана проблема може бути вирішена на рівні безпеки СУБД, або на рівні додатку. У випадку з СУБД, у неї повинен бути механізм формування груп і ролей користувачів з розмежуванням доступу. На рівні додатку проблема вирішується шифруванням паролів. У системах 1С проблема розділення доступу, вирішена на рівні створення окремої папки в спеціальному каталозі, що зберігає права і імена користувачів. Доступ здійснюється на основі пароля.
Можливості пошуку
Таблиця - SEQ Табліца_-\ * ARABIC 5

Найменування системи	Пошук по безлічі реквізитів	Пошук по одному реквізиту
Облік ІТСО	невідомо	невідомо
Картотека	-	+
АНВИК: Облік ОВО	-	+

Потрібно відзначити, що пошук ведеться по одному-двом атрибутам, при цьому нерідко буває потрібно провести пошук відразу по декількох атрибутів. Це було з'ясовано під час опитування користувачів системи «Картотека». Наприклад, часті запити по знаходженню приладів одного типу стоять на певному об'єкті.
Можливості щодо виведення звітів
Таблиця - SEQ Табліца_-\ * ARABIC 6

Найменування системи	Журнал ремонтів	Журнал помилкових спрацьовувань	Журнал регламентів обладнання	Форма виведення звітів
Облік ІТСО	+	-	+	друк на принтері
Картотека	+	+	+	збереження в текстовий файл, друк на принтері
АНВИК: Облік ОВО	-	-	+	файли Excel, текстовий, друк на принтері

Лідером в частині щодо виведення звітів є конфігурація від АНВИК. Вона виводить звіти в більшу кількість форматів, при цьому в самій системі 1С розроблений інструментарій по швидкому створенню звітних форм, тому список звітних форм легко доповнити, при наявності програміста зі знанням 1С.

1.1.6 Висновки

Таким чином, сучасні системи з обліку, крім системи «Облік ІТСО» є підсистемами в системах з обліку об'єктів, що охороняються, що обумовлено специфікою ведення облікової роботи у позавідомчій охороні. Можна відзначити, що система «Картотека» вже морально застаріла. Найбільш застосовною, на мою думку, «АНВИК: Облік ОВО», досить повні висновки зробити складно через нестачу інформації про неї.

1.2 Техніко-економічне обгрунтування ефективності впровадження АІС "Звід звітів" для УВО

Орієнтовні річні витрати на ведення документації вручну наведені таблиці 7:
Таблиця - SEQ Табліца_-\ * ARABIC 7

Вид робіт	Кількість чол. / Год
Складання звітності про подлеченних об'єктах	16
Складання звітності про підключені ТСО	16
Складання річної звітності з охорони об'єктів	8
Складання річного звіту за ТСО	32
Складання звітності про співробітників УВО	48
Аналіз помилкових спрацьовувань для оптимізації роботи ТСО	72
Складання звітності з соправожденію майна	30
Пошук ТСО при звірках з бухгалтерією, аудиті	62
Складання різних звітів при самоконтролі, аналізі:	72
Разом	356

Примітка - таблиця наведена за матеріалами статті Сергія Журина «Ціна зайвих папірців: як забезпечити якісний автоматизований облік».
При цьому в рік на складання формулярів звітності витрачається приблизно 200 чол. / Год при надходженні в середньому 1500 об'єктів під охорону. Разом виходить 556 чол / год. За приблизними оцінками автоматизація обліку дозволяє скоротити час на операції внесення нових даних приблизно в 2-3 рази (при цьому ще можна врахувати і економію витратних матеріалів). Операції пошуку і створення звітів, особливо при великих кількостях об'єктах, прискоряться в 10-20 разів.
У результаті, операції на внесення нових об'єктах складуть приблизно 66-100 чол. / Год на рік, операції з пошуку і створення звітів приблизно 18-36 чол / год. що знизить загальну робоче навантаження з 556 до 84-136 чол / год. тобто в 4-6 разів.
Також буде вирішена проблема складання звітної документації. Так на сьогоднішній день в підрозділах позавідомчої охорони різні звіти мають загальні розділи, які складають різні люди. А так як складання звітів ведеться вручну, то тут можливі такі помилки, як:
· Розбіжність реального і позначеного у звіті кількості об'єктах
· Розбіжність підсумкового показника по УВО і суми показників по окремих підрозділах
Тому спостерігається відмінність показників в однакових розділах за різними звітами з одного підрозділу. Впровадження сучасної системи з обліку вирішило б усі перераховані вище проблеми.
На сьогоднішній день, середня зарплата інспектора або співробітника позавідомчої охорони становить 8 тис. рублів. У рік, таким чином, співробітник одержує 96 тис. рублів. У рік співробітник працює 22 * 12 = 264 дня. При 8 годинному робочому дні, виходить 264 * 8 = 2112 годин. Значить одну годину роботи коштує 96000/2112 = 45,5 рублів.
При ручному веденні документації витрати на її ведення складуть 556 * 45,5 = 25298 рублів на людину. При автоматизованому веденні документації максимум 136 * 45,5 = 6188, мінімум 86 * 45,5 = 3913. Таким чином, мінімальний річний ефект від одного співробітника складе 25298-6188 = 19110 рублів, максимальний річний ефект складе 25298-3913 = +21385. У середньому у відділах позавідомчої охорони в місті Пермі працює 20-30 співробітників активно використовують документацію з обліку та пошуку. Таким чином, мінімальний річний економічний ефект від впровадження у середньостатистичний відділ позавідомчої охорони складе 20 * 19 110 = 382 200, максимальний річний ефект складе 30 * двадцять одна тисяча триста вісімдесят п'ять = 641550.

2. Аналіз предметної області, системний і структурний аналіз.

2.1 Аналіз предметної області створення і використання звітних документів.

2.2 Існуючі форми звітності в УВО.

В даний час в УВО при ГУВС Пермського краю, існують такі звітні форми:
1. Форма "ВО-2";
2. Звіт про наявність ПЦН, ЗЗА та ріпів;
3. Звіт про роботу підрозділів охорони;
4. Звіт про результати роботи по боротьбі зі злочинністю і адміністративними правопорушеннями на охоронюваних ринках та антитерористичної захищеності об'єктів даної категорії;
5. Звіт охорони об'єктів та квартир;
6. Звіт про супровід перевезеного майна власників, у т.ч. грошових коштів;
7. Звіт за станом квартир;
8. Звіт за станом об'єктів;
9. Звіт з охорони автостоянок УВО при ГУВС Пермської області;
10. Звіт про результати роботи УВО форма "ВО-1";
11. Підсумки роботи ОВО;

2.2.1 Форма «ВО-2»

Форма ВО-2 складається раз на рік і включає в себе узагальнені відомості по всіх аспектах роботи відділів та управлінь позавідомчої охорони по Пермі та Пермської області. Включає в себе 4 розділи:
1. відомості про кількість та стан захищеності об'єктів, що охороняються;
2. відомості про наявність сил підрозділів позавідомчої охорони;
3. відомості про охорону об'єктів та квартир з використанням технічних засобів, у тому числі пультів централізованого спостереження;
4. відомості про наявність технічних засобів підрозділів охорони.
Вони включає в себе упорядкований за назвами відділів та управлінь список кількісних показників за звітний період:
· Обладнані ТСО приміщення;
· Капітально відремонтовані ОПВ;
· Встановлені прилади ТСО;
· Функціонуючі ПЦО;
· Функціонуючі ПЦС, в т.ч. окремо, у яких вийшов термін експлуатації;
· Загальна ємність функціонуючих ПЦН;
· Задіяна ємність функціонуючих ПЦН;
· Придбані ПЦН;
· АРМи чергового пульта управління;
· Загальна кількість сигналів тривоги, в т.ч. окремо, що відбулися з вини засобів ОПС і телефонних мереж;
· Процентне співвідношення загальної кількості помилкових спрацьовувань, до подією з вини ОПВ;
· Види охоронюваних об'єктів;
· Штатна чисельність співробітників;
· Некомплект співробітників;
· Кількість автотранспорту;
· Кількість радіостанцій;
· Кількість зброї;
· Кількість бронежилетів;
Обчислюються загальні підсумки, підсумки по області (крім міста Пермі) і по місту.

2.2.2 Звіт про наявність ПЦН, ЗЗА та ріпів

Звіт складається раз на півроку і включає відомості про ПЦН, ЗЗА та РВП встановлених на ПЦО, розбитих по відділам і управлінням, за наступними параметрами:
· Кількість ПЦО, в т.ч. окремо мікрорайонні і заводські;
· Кількість КСА, окремо по кожному типу приладу;
· Кількість АРМів ДПУ й ДПЦО;
· Кількість ПЦС, в т.ч. окремо за видами приладу;
· Кількість ПЦН підлягають заміні;
· Загальна ємність ПЦС і задіяна;
· Кількість СПИ, окремо по кожному типу приладів;
· Кількість РВП;
· Кількість ЗЗА;
· Загальна кількість радіосистем, в т.ч. окремо по кожному виду приладу;
· Кількість автоматичних об'єктів, що здаються по дроту і по радіоканалу (на даний момент, до таких об'єктів відносять об'єкти на яких стоять, або УО 1-1А, або УО 1-3А, або «Сигнал ВК 4-5», або «Юпітер» будь-який модифікації, а також всі об'єкти на радіоохране);
· Кількість автоматичних квартир, що здаються по дроту і по радіоканалу (пояснення див. вище);
· Загальна кількість придбаних ПЦН;
· Кількість списаних ПЦН;
· Кількість ПЦН на складі.

2.2.3 Звіт про роботу підрозділу охорони

Кумулятивний звіт. Містить щомісячно оновлювані відомості про поточні результати роботи відділу чи управління, за такими показниками:
· По охоронюваним об'єктах, окремо за фактичними показниками, за плановими показниками і динаміці виконання плану:
o по ОПС;
o по КТС;
o по мають 2 і більше рубежів;
o по підключеним до ПЦС.
· По відособлених приміщень, окремо за фактичними показниками, за плановими показниками і динаміці виконання плану:
o по ОПС;
o по мають 2 і більше рубежів;
o по підключеним до ПЦС.
· Капітальні ремонти, окремо за фактичними показниками, за плановими показниками і динаміці виконання плану:
o по об'єктах;
o по відособлених приміщень.
· По охоронюваним квартирах (МХЛІГ) окремо за фактичними показниками, за плановими показниками і динаміці виконання плану:
o по ОПС;
o по підключеним до ПЦС.
· Встановлені КТС, в т.ч. окремо за встановленими на КПП і сторожових постах, за встановленими в квартирах і за встановленими в офісах;
· Кількість встановленої нової техніки;
· Загальна кількість помилкових спрацьовувань, в тому числі окремо, з вини ОПВ, з вини АТС, з вини хозоргана і інших причин;
· Задіяна ємність ПЦН;
· Відсоток помилкових спрацьовувань на 1000 номерів;
· Кількість об'єктів обладнаних об'ємними сповіщувачами, в т.ч. окремо по об'єктах торгівлі;
· Кількість об'єктів обладнаних радіоохраной окремо по плановому показнику, фактичного і динаміці виконання плану;
· Загальна кількість об'єктів перебувають на даний момент під радіоохраной окремо по об'єктах, по квартирах, по кіосках і по об'єктах з КТС.

2.2.4 Звіт про результати роботи по боротьбі зі злочинністю і адміністративними правопорушеннями на охоронюваних ринках та антитерористичної захищеності об'єктів даної категорії

Кумулятивний звіт. Містить щомісячно оновлювані відомості про поточні результати роботи відділу чи управління, за такими показниками:
· Загальна кількість ринків в зоні дії підрозділу УВО;
· Кількість ринків знаходяться під охороною ОВО і спосіб охорони;
· Кількість листів спрямованих до адміністрації району по покращення охорони;
· Кількість злочинів та їх припинення;
· Кількість прийнятих під охорону ринків;

2.2.5 Звіт охорони об'єктів та квартир

Кумулятивний звіт. Містить щотижневі оновлювані відомості про поточні результати роботи відділу чи управління, за такими показниками:
· Квартир та об'єктів обладнаних ОПВ;
· Квартир та об'єктів підключених до ПЦС;
· Абсолютний приріст квартир та об'єктів;
· Порівняння з минулим тижнем;
· Кількість охоронюваних квартир та об'єктів на дане число;
· Приріст з початку року;

2.2.6 Звіт про супроводі перевезеного майна власника, в т.ч. грошових коштів

Кумулятивний звіт. Містить щотижневі оновлювані відомості про поточні результати роботи відділу чи управління, за такими показниками:
· Кількість укладених договорів на охорону майна, що перевозиться;
· Кількість виконаних заявок (супроводів);
· Отримано грошових коштів;

2.2.7 Звіт за станом квартир.

Кумулятивний звіт. Містить щотижневі оновлювані відомості про поточні результати роботи відділу чи управління, за такими показниками:
· Охороняється квартир на дане число;
· Охороняється за договорами;
· Підключено до ПЦС;
· Абсолютний приріст;
· Порівняння з минулим тижнем;

2.2.8 Звіт за станом об'єктів.

Кумулятивний звіт. Містить щотижневі оновлювані відомості про поточні результати роботи відділу чи управління, за такими показниками:
· Охороняється за договорами на початок тижня число;
· Обладнано ОПВ;
· Охороняється за договорами всього;
· Абсолютний приріст;
· Порівняння з минулим тижнем;

2.2.9 Звіт з охорони автостоянок УВО при ГУВС Пермської області.

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

2.2.10 Звіт про результати роботи УВО форма "ВО-1".

Форма ВО-2 складається раз на рік і включає в себе узагальнені відомості по всіх аспектах роботи відділів та управлінь позавідомчої охорони по Пермі та Пермської області. Включає в себе:
· Охороняється на кінець звітного періоду квартир та об'єктів;
· Кількість сигналів тривоги надійшли на ПЦС та їх причини;
· Кількість виявлених крадіжок і злочинів;
· Кількість виявлених інших злочинів;
· Кількість осіб, затриманих за злочини;
· Кількість осіб, затриманих за вчинення адміністративних правопорушень;
· Кількість надійшли доходів;
· Кількість витрат;
· Дебіторська заборгованість;

2.2.11 Підсумки роботи підрозділу ОВО.

Кумулятивний звіт. Містить щомісячні оновлювані відомості про поточні результати роботи відділу чи управління, за такими показниками:
· Штат міліцейських груп затримання;
· Розкриття злочинів МОБ;
· Розкрито злочинів СКМ;
· Всього розкрито злочинів;
· Частка на 1 співробітника;
· Розкрито злочинів за рік;
· Участь у розкритті злочинів;

2.2.12 Структурний аналіз звітних форм УВО.

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

2.3 Системний аналіз та структурне проектування системи

2.3.1 Визначення вимог до нової системи.

Нова система повинна вирішувати такі завдання:
· Автоматизоване складання звітної форми УВО при ГУВС Пермського краю;
· Можливість ведення єдиного обліку об'єктів взятих під охорону;
· Можливість ведення обліку ТСО;
· Можливість ведення обліку заявок і супроводу майна;
· Можливість ведення обліку працівників підрозділів УВО;
· Можливість ведення обліку засобів охорони УВО; зброю, боєприпаси, бронежилети і т.д.

2.3.1 Логічне проектування системи.

Виходячи з вимог пред'являються до системи, виділимо 8 глобальних процесів:
· Операція з обліковими записами про об'єкти;
· Операція з обліковими записами про ТСО;
· Операції з обліковими записами про ПЦО або АТС;
· Операція із записами про історію ТСО;
· Операція з обліковими записами про історію об'єкта;
· Операція з обліковими записами про заявки і супроводі майна;
· Операція з обліковими записами про співробітників УВО;
· Складання на основі записів звітних форм;
Далі розглянемо детально кожний глобальний процес.

2.3.1.1 Операція з обліковими записами про об'єкти.

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

2.3.1.2 Операції з обліковими записами про ТСО

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

2.3.1.3 Операції з обліковими записами про ПЦО або АТС

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

2.3.1.4 Операції з записами про історію ТСО

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

2.3.1.5 Операції з записами про історію об'єктів

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

2.3.1.6 Операція з обліковими записами про заявки та супроводження майна.

Виділимо основні операції:
· Прийняття заявки на супровід;
· Виконання заявки;
· Видалення заявки;
· Зміна даних про заявки;
Далі розглянемо детально кожну операцію.
Прийняття заявки на супровід
Відбувається при подачі заявки на супроводження та охорону майна.
Обов'язкові дані:
· Унікальний ключ заявки;
· Дата подання заявки;
· Дата супроводу;
Виконання заявки
Відбувається після виконання заявки та супроводження майна. Унікальний ключ заявки повинен бути присутнім в даних про принятий заявки.
Обов'язкові дані:
· Унікальний ключ заявки;
· Дата виконання;
Видалення заявки
Відбувається при видаленні даних про заявки або її виконань.
Обов'язкові дані:
· Унікальний ключ заявки;
Зміна даних про заявки
Відбувається при зміні дати супроводу.
Обов'язкові дані:
· Унікальний ключ заявки;
· Дата супроводу;

2.3.1.7 Операція з обліковими записами про співробітників УВО.

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

2.3.1.8 Складання на основі записів звітних форм.

Виділимо основні операції:
· Генерування облікової форми «План-графік виконання регламентів обслуговування технічних засобів охорони, встановлених на об'єктах»;
· Генерування облікової форми «План-графік виконання регламентів обслуговування технічних засобів охорони, встановлених на ПЦО та АТС»;
· Генерування облікової форми «Картка обліку технічних засобів охорони встановлених на об'єкті»;
· Генерування облікової форми "Журнал обліку технічних засобів охорони»;
· Генерування облікової форми "Журнал обліку заявок на ремонт ТСО, помилкових спрацьовувань і невзятій об'єктів під охорону»;
· Генерування облікової форми "Журнал обліку технічних засобів охорони, що направляються в ремонтну групу, майстерню»;
· Генерування облікової форми "Журнал обліку ремонту ТСО»;
· Генерування звіту «Форма« ВО-2 »»;
· Генерування звіту «Звіт про наявність ПЦН, ЗЗА та ріпів»;
· Генерування звіту «Звіт про роботу підрозділів охорони».
· Генерування звіту «Звіт про об'єкти охорони УВО»
· Генерування звіту «Звіт про супроводі перевезеного майна»
Далі детально розглянемо кожну операцію.
Генерування облікової форми «План-графік виконання регламентів обслуговування технічних засобів охорони, встановлених на об'єктах»
Визначення місяця, за який вибирається регламент.
Генерування «шапки» таблиці такого вигляду:

№ п / п	Найменування об'єкта	Число і проводяться роботи					Примітка
№ п / п	Найменування об'єкта	1	2	... ... ... ... ... ... ... ... ... ....	30	31

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

№ п / п	Найменування ТСО	Інвентарний номер	Число і проводяться роботи					Примітка
№ п / п	Найменування ТСО	Інвентарний номер	1	2	... ... ... ... ... ... ... ... ... ... ... ...	30	31	Примітка

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

№ п / п

Тип ТСО

Заводські № ТСО і дати введення в експлуатацію

Кількість ТСО

Кількість умовних установок

Вибір з таблиці «Регламентне обслуговування ПЦО та АТС» всіх записів, з обмеженнями по вибраному місяцю, при цьому підставляємо в результат замість ключа приладу його інвентарний номер, за словом, визначаємо вид приладу і впорядковуємо результат по ньому.
Заповнення звітної форми отриманими результатами. При цьому в полі «Примітка» записуємо значення через крапку з комою (якщо в місяць по об'єкту більше одного регламенту з примітками).
Генерування облікової форми "Журнал обліку технічних засобів охорони»
Генерування «шапки» таблиці такого вигляду:

№ п / п

Найменування ТСО

Кількість на об'єктах

Кількість на ПЦО та АТС

Кількість в обмінному фонді

Вибір з таблиці «Облік ТСО» всіх записів, при цьому по ключу визначаємо вид приладу і впорядковуємо результат за місцем обліку приладу (об'єкт, ПЦО, АТС, обмінний фонд) і з вигляду приладу.
Заповнення звітної форми отриманими результатами.
Генерування облікової форми "Журнал обліку заявок на ремонт ТСО, помилкових спрацьовувань і невзятій об'єктів під охорону»
Визначення періоду, за який видається журнал.
Генерування «шапки» таблиці такого вигляду:

№ п / п

Дата і час повідомлення

Пультової номер

Вид повідомлення

Причина несправності

Примітка

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

№ п / п

Тип і заводський № приладу

Найменування об'єкта

Дата відправлення в ремонт

Дата отримання з ремонту

Примітка

№ п / п

Дата надходження в ремонт

Найменування ТСО

Заводський № і рік випуску

Найменування підрозділу, що здала в ремонт

Зовнішній прояв несправності

Причина несправності

Ремонт справив (дата, ПІБ)

З ремонту отримав (дата, ПІБ)

Вибір з таблиці «ТСО ремонту» по зовнішніх ключів записів з таблиці «Ремонт ТСО» з збігаються первинними ключами. При цьому замість ключа ремонту підставляємо запис з таблиці «Ремонт ТСО» з відповідним первинним ключем.
Вибір з отриманого результату всіх записів, з обмеженнями по обраному періоду.
Заміна в результаті всіх зовнішніх ключів обліку ТСО на відповідні записи таблиці «Облік ТСО». При цьому замість ключа виду приладу підставляємо найменування його виду.
Заміна в утворилися записах ключів ТСО об'єкта через номер договору найменуванням підрозділу.
Заповнення звітної форми отриманими результатами.
Генерування звіту «Форма« ВО-2 »»
Генерування «шапки» таблиці
Підрахунок на підставі таблиці «Об'єкти» кількості об'єктів у яких дата постановки на облік входить у звітний період, з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Об'єкти» кількості об'єктів у яких дата постановки на облік входить у звітний період і встановлений прапор власної установки, з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Ремонт» кількості капітальних ремонтів, з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «ПЦО та АТС» кількості ПЦО, з угрупуванням по підрозділах.
Підрахунок загальної ємності ПЦС на підставі таблиць «Облік ТСО» і «ТСО», з угрупуванням по підрозділах.
Підрахунок задіяної ємності ПЦС на підставі таблиці «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок кількості ПЦН на підставі таблиць «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок кількості ПЦН, у яких термін з дати виготовлення перевищує термін експлуатації, на підставі таблиці «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок кількості ПЦН, у яких дата надходження входить у звітний період, на підставі таблиці «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок кількості АРМ ДПУ й ДПЦО, на підставі таблиці «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок кількості помилкових спрацьовувань з розбивкою за типами несправності, на підставі таблиці «Повідомлення про об'єкт», з угрупуванням по підрозділах
Заповнення звітної форми отриманими результатами.
Генерування звіту «Звіт про наявність ПЦН, ЗЗА та ріпів»
Генерування «шапки» таблиці
Підрахунок на підставі таблиці «ПЦО та АТС» кількості ПЦО, з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Облік ТСО» кількості АРМів, з групуванням за видами і підрозділам.
Підрахунок на підставі таблиці «Облік ТСО» кількості АРМів, з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Облік ТСО» кількості ПЦН, з угрупуванням по підрозділах.
Підрахунок загальної ємності ПЦС на підставі таблиць «Облік ТСО» і «ТСО», з угрупуванням по підрозділах.
Підрахунок задіяної ємності ПЦС на підставі таблиці «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок процентного співвідношення задіяної ємності ПЦС до загальної на підставі таблиці «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Облік ТСО» кількості ПЦН, з групуванням за видами і підрозділам.
Підрахунок кількості ПЦН, у яких термін з дати виготовлення перевищує термін експлуатації, на підставі таблиці «Облік ТСО», з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Облік ТСО» кількості РВП, з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Облік ТСО» кількості ЗЗА, з угрупуванням по підрозділах.
Підрахунок на підставі таблиці «Облік ТСО» кількості радіосистем, з угрупуванням по підрозділах.

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

2.4 Розробка инфологической та концептуальної схеми БД.

2.4.1 Побудова инфологической схеми БД.

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

SHAPE \ * MERGEFORMAT

Облік роботи УВО

Облік роботи підрозділу УВО

Облік складських приміщень

Облік об'єктів, що охороняються

Облік робота груп затримання

Облік із супроводу майна

Облік майна

Охорона засобами ТЗН

Заявки

Виконання заявки

Спрацювання ТСО

Затримання

На цій схемі видно основні напрямки інформаційних потоків при обліку роботи УВО при ГУВС Пермського краю.

2.4.2 Побудова об'єктно-орієнтованої моделі БД

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

SHAPE \ * MERGEFORMAT

Об'єкт охорони
Унікальний ключ об'єкта
Вид об'єкту

Обладнання об'єкта
Унікальний ключ об'єкта
Вид обладнання

Охорона об'єкта
Унікальний ключ об'єкта
Вид охорони

Види охорони об'єктів
Унікальний ключ
Вид охорони

Вид ТСО
Унікальний ключ
Вид ТСО

Вид об'єкту
Унікальний ключ
Група
Вид

Група об'єкта
Унікальний ключ
Група

Заявки на ремонт ТСО
Унікальний ключ
дата прийняття на ремонт
Дата повернення

Заявки на супровід
Унікальний ключ
Дата заявки
Дата супроводу

Супровід майна

Виконання заявки
Дата виконання

Штат співробітників УВО

2.5 Вибір моделі даних і СКБД

Враховуючи специфіку створення звітних документів, мною були розглянуті наступні моделі даних:
· Реляційна модель даних;
· Об'єктно-орієнтована модель даних;

2.5.1 Реляційна модель даних

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

2.5.2 Об'єктно-орієнтована модель даних

Моделлю даних, що привертає дедалі більше уваги з кінця 80-х рр.., Є об'єктна, або "об'єктно-орієнтована" модель. Основними поняттями, з якими оперує ця модель, є наступні:
· Об'єкти, що володіють внутрішньою структурою і однозначно ідентифікуються унікальним внутрішньосистемних ключем;
· Класи, є, по суті, типами об'єктів;
· Операції над об'єктами одного чи різних типів, звані "методами";
· Інкапсуляція структурного і функціонального опису об'єктів, поз8воляющая розділяти внутрішнє і зовнішнє опису (у термінології передував об'єктному модульного програмування - "модульність" об'єктів);
· Успадкованого зовнішніх властивостей об'єктів на основі співвідношення "клас-підклас".
До переваг об'єктно-орієнтованої моделі можна віднести:
· Можливість для користувача системи визначати свої наскільки угодно8 складні типи даних (використовуючи наявний синтаксис і властивості успадкованого та інкапсуляції);
· Наявність успадкованого властивостей об'єктів;
· Повторне використання програмного опису типів об'єктів при зверненні до інших типів, на них посилаються,.
До недоліків об'єктно-орієнтованої моделі можна віднести:
· Відсутність строгих визначень; різне розуміння термінів і відмінності в термінології;
· Як наслідок - ця модель не досліджена настільки ретельно математично, як реляційна;
відсутність загальновживаним стандартів, що дозволяють пов'язувати конкретні об'єктно-орієнтовані системи з іншими системами роботи з даними.
Основним і головною відмінністю об'єктно-орієнтованої моделі вважається наявність унікального системного ідентифікатора.

2.5.3 СУБД 1с: V8.0

Система програм 1С-Підприємство розроблена фірмою 1С.
Система програм «1С: Підприємство 8.0» включає в себе платформу і прикладні рішення, розроблені на її основі, для автоматизації діяльності організацій і приватних осіб. Сама платформа не є програмним продуктом для використання кінцевими користувачами, які зазвичай працюють з одним з багатьох прикладних рішень (конфігурацій), розроблених на даній платформі. Такий підхід дозволяє автоматизувати різні види діяльності, використовуючи єдину технологічну платформу.
Гнучкість платформи дозволяє застосовувати 1С: Підприємство 8.0 в найрізноманітніших галузях:
· Автоматизація виробничих і торгових підприємств, бюджетних і фінансових організацій, підприємств сфери обслуговування і т.д.
· Підтримка оперативного управління підприємством;
· Автоматизація організаційної і господарської діяльності;
· Ведення бухгалтерського обліку з декількома планами рахунків і довільними вимірами обліку, регламентована звітність;
· Широкі можливості для управлінського обліку і побудови аналітичної звітності, підтримка багатовалютного обліку;
· Вирішення завдань планування, бюджетування і фінансового аналізу;
· Розрахунок зарплати і управління персоналом;
· Інші області застосування.
Платформа 1С: Підприємство 8.0 була створена з урахуванням 6-річного досвіду застосування системи програм 1С: Підприємство 7.7, яку використовують десятки тисяч розробників. Незважаючи на значні зміни, нова версія 8.0 зберегти ідеологічне спадкоємність з попередніми версіями.
Механізми 1С: Підприємства, призначені для формування економічної та аналітичної звітності, представляють собою комплекс засобів, що дозволяють формувати не просто друковані форми, а інтерактивні документи, тісно інтегровані в прикладне рішення. Користувач може не тільки роздрукувати звіт, але і працювати з ним практично так само, як з будь-якої екранної формою - змінювати параметри звіту, перебудовувати його, використати "розшифровки" - можливість формування додаткових звітів на основі окремих елементів вже сформованого звіту і т.д.

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

2.5.4 СУБД Oracle 10g

Ця СУБД існує в 4 версіях:
Oracle Database 10g Standard Edition One. Надає cервер бази даних для робочих груп. До складу сервера входить інтегрований набір засобів тиражування, реплікації і управління. Підтримує не більше двох процесорів на одному сервері.
Oracle Database 10g Standard Edition (SE). Відрізняється від Oracle Database 10g Standard Editio8n One тим що підтримує 4 процесора (на сервері або серверному кластері).
Oracle Database 10g Enterprise Edition (EE). Забезпечує повноцінне керування інформацією підприємства - від настільних комп'ютерів до глобальних обчислювальних мереж. Утиліти СУБД забезпечують завантаження / вивантаження даних БД, копіювання і відновлення даних, міграцію даних з однієї БД в іншу, контроль роботи бази даних Oracle і керування використанням дискового простору. Підтримує серверні кластери.
Oracle Database 10g Personal Edition. Персональна база для розробника або звичайного, мобільного і віддаленого користувача. Підтримує всі можливості й функції Oracle Enterprise Edition.
Тому що нам не потрібні розширені можливості версії Enterprise і нас не влаштовують можливості Personal версії, то зупинимо вибір на Standart версіях. Ось деякі з особливостей Oracle:
Real Application Cluster (RAC) забезпечує роботу одного примірника бази даних на декількох вузлах кластерної мережі, дозволяючи управляти навантаженням і гнучко масштабувати систему в разі необхідності
Automatic Storage Management (ASM) дозволяє автоматично розподіляти дані між наявними ресурсами систем зберігання даних, що підвищує відмовостійкість системи і знижує загальну вартість володіння
Продуктивність. Oracle Database 10g дозволяє автоматично управляти рівнями сервісу і тиражувати еталонні конфігурації в рамках всієї мережі
Самоврядування. Спеціальні механізми Oracle Database 10 g дозволяють самостійно перерозподіляти навантаження на систему, оптимізувати і коригувати SQL-запити, виявляти та прогнозувати помилки
Великі бази даних. Тепер максимальний розмір примірника бази даних Oracle може досягати 8 екзабайт

Розглянемо ціни на Standard версії (таблиця 8):
Таблиця - 8

Oracle Database 10g Standard Edition One Processor License	4995 ye
Oracle Database 10g Standard Edition One Named User	149 ye
Oracle Database 10g Standard Edition (SE) Processor License	15000 ye
Oracle Database 10g Standard Edition (SE) One Named User	300 ye

Таким чином, вартість версії Standard Edition One буде складати приблизно 5-6 тис. доларів (з 1-5 користувачами), а Standard Edition (SE) - 15-17 тис. доларів (з 1-5 користувачами). Потрібно зауважити, що документація і підтримка не є безкоштовними і становлять 22% від вартості конфігурації. [Www.oracle.com]

2.5.5 СУБД SQL Server 2000

SQL Server 2000 постачається в наступних виданнях:
· SQL Server 2000 Enterprise Edition для великих підприємств (включає постачання всього супутнього інструментарію);
· 88SQL Server 2000 Standard Edition для малих і середніх підприємств;
· SQL Server 2000 Windows CE Edition (SQL Server CE) для мобільних пристроїв;
· SQL Server 2000 Developer Edition для розробників (можливості Enterprise версії, але для цілей тестування і розробки додатків, без права використання);
· SQL Server 2000 Personal Edition для персональних користувачів (можливості Standart, але через розподільника паралельних навантажень, неможливо масштабувати дану версію);
· SQL Server 2000 Desktop Engine (MSDE) використовується як вільно розповсюджуваний модуль СУБД, для розробки на його основі сторонніми розробниками своїх продуктів (за можливостями дорівнює Personal, але без графічної консолі управління).
З даних версій виберемо Standard версію, як влаштовує за параметрами масштабованості і наявності необхідних функцій:
· Служби перетворення даних;
· 8Средства реплікації (миттєві знімки, транзакції і злиття);
· Повнотекстовий пошук;
· Формування запитів на природній мові;
· Засоби налагодження і розробки збережених процедур;
· Інструментарій SQL-профілювання та аналізу продуктивності.
Розглянемо ціни на Standard версію (таблиця 9):
Таблиця - 9

Microsoft SQL Svr 2000 Standard Edtn English Processor License	4781 ye
Microsoft SQL Svr 2000 Standard Edtn English Server License	667 ye
Microsoft SQL Svr 2000 Standard Edtn English CAL (User or Device)	146 ye

Таким чином, ціна на мінімальну конфігурацію складе 6-7 тис. доларів (1-5 користувачів). [Www.microsoft.com]

2.5.6 СУБД InterBase 6

Випускається в настільному (Desktop Edition) і серверному (Server Edition) варіанті.
InterBase 6 підтримує симетричну мультипроцесорну обробку і многопоточную архітектуру, що забезпечує високу продуктивність комплексних програм з великим числом одночасно працюючих користувачів. Засоби контролю транзакцій надають розробникам можливість точного контролю бази даних, дозволяють відстежувати весь процес, початок, кінець і повернення транзакцій, процесів і запитів. Працює з SQL-стандартами SQL-92 і SQL-99. Інтеграція з засобами розробки додатків фірми Borland, ODBC і JDBC. Підтримка XML. Також варто відзначити налаштовуються сервера, що забезпечується механізмами розпаралелювання обробки і корекції SQL-запитів, а також т.зв. механізмом «збирання сміття» (garbage collecting).
Розглянемо ціни на Server версію (таблиця 10):
Таблиця - 10

Borland InterBase 6 for Windows - Simultaneous Users 1	150 у.о.
Borland InterBase 6 for Windows - Simultaneous Users 10	1200 ye
Borland InterBase 6 for Windows - Simultaneous Users 20	2100 ye
Borland InterBase 6 for Windows - Unlimited Users	3999 ye
Borland InterBase 6 Windows Processor License	200 ye
Borland InterBase 6 Additional Processor License	1000 $

Таким чином, ціна на мінімальну конфігурацію InterBase становитиме 1,5-2,5 тис. доларів (1-10 користувачів). [Www.borland.com]

2.5.7 Порівняння СУБД Oracle 10g, SQL Server 2000, InterBase 7.1 і 1С: v8.0

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

Таблиця - 11

Назва критерію вибору	SQL Server 2000	ORACLE 10g	InterBase	1c: v8.0
Вартість серверу (ліцензія на процесор і на сам сервер)	5448 $	4995 $	1200 $	300 $
Вартість клієнта	146 $	149 $	150 $ (Чим більше ліцензія, тим дешевше)	-
Максимальне число користувачів	Залежить від ліцензії	Залежить від ліцензії	Залежить від ліцензії	Необмежено
Технічні вимоги до сервера	166 Мгц 64 Мб ОЗУ 140-500 Мб на HDD	300 Мгц 128 Мб ОЗУ 1,5 Гб на HDD	32 МГц 32 Мб ОЗУ 20 Мб	32 МГц 32 Мб ОЗУ 20 Мб
Підтримувані серверні ОС	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition	Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 Datacenter Server, Windows NT Server 4.0, Windows NT Server 4.0 Enterprise Edition, UNIX-подібні системи, Solaris, Mac OS і ін	Windows 2000 (SP2), Windows Server 2003, Windows NT ® 4.0 (SP6a або вище), Windows XP Red Hat Enterprise Linux, SUSE Enterprise Linux Server 9 Solaris 7, 8, 9	Windows 2000 (SP2), Windows Server 2003, Windows NT ® 4.0 (SP6a або вище), Windows XP Red Hat Enterprise Linux, SUSE Enterprise Linux Server 9 Solaris 7, 8, 9
Рівень кваліфікації персоналу	Високий	Високий	Низький	Низький

Для проектування ІС «Зведені звіти УВО» було обрано СУБД 1с: v8.0, так як 1С: v8.0 задовольняє параметрам легкості адміністрування, низької ціни і достатньої функціональності, а також меншим, ніж у решти систем вимогам до ресурсів сервера.

3. Проектування програми

3.1 Опис створених об'єктів в конфігурації

Тип об'єкта	Назва об'єкта
Довідники	Об'єкти
	ТСО
	Охорона
	Майно
Документи	ОхранаОб'екта
	ІзмененіеОб'екта
	УстановкаТСОУво
	УстановкаОхрани
	УстановкаТСО
	РемонтТСО
	ВозвратТСО
	СробативаніеТСО
	РезультатВиезда
	ЗаявкаСопр
	ВиполненіеЗаявкі
Регістри	Об'єкт
	НалічіеТСО
	Штат
	РемонтТСО
	МастерскіеТСО
	НалічіеОхрани
	ЗаявкіСопр
	Супровід
	УчетІмущества

3.2 Вимоги до обладнання, прикладного і системного ПЗ для забезпечення роботи системи

Дана система має такі системні вимоги:
процесор 100 Мгц або вище
32 Мб оперативної пам'яті
Windows 98 або вище

Висновок

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

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

1. ГОСТ 18322-78 Система технічного обслуговування і ремонту техніки. Терміни та визначення .- М.: ГУВО МВС РФ, 1978
2. ГОСТ Р 50775-95. Системи тривожної сигналізації .- М.: ГУВО МВС РФ, 1995
3. РД 78.36.003-2002. Інженерно-технічного укріплення. Технічні засоби охорони. Вимоги та норми проектування щодо захисту об'єктів від злочинних посягань .- М.: ГУВО МВС України, 2002
4. РД 78.146-93 МВС Росії. Інструкція про технічний нагляд за виконанням проектних і монтажних робіт з обладнання об'єктів засобами охоронної сигналізації .- М.: ГУВО МВС РФ, 1993
5. РД 78.145-93 МВС Росії. Системи і комплекси охоронної, пожежної та охоронно-пожежної сигналізації. Правила виробництва і приймання робіт .- М.: ГУВО МВС РФ, 1993
6. РМ 78.36.002-99 ГУВО МВС Росії. Порядок обстеження об'єктів, що приймаються під охорону .- М.: ГУВО МВС РФ, 1999
7. П 78.36.001 - 2004 «Перелік технічних засобів, дозволених до застосування у позавідомчій охороні в 2004 році» .- М.: МВС РФ, 2004
8. Р78.36.011 - 2000 Організація роботи ПЦО .- М.: ГУВО МВС РФ, 2000
9. Р 78.36.013-2002 МВС Росії. Помилкові спрацьовування технічних засобів охоронної сигналізації та методи боротьби з ними .- М.: ГУВО МВС України, 2002
10. Ціна зайвих папірців: Як забезпечити якісний автоматизований облік технічних засобів охорони / Журін С., к.т.н. / / БДІ.-СПб: НП-Принт, 2003 .- № 5-6 (51) .- С.64- 66
11. "1С: Підприємство" ДЛЯ відділу позавідомчої охорони / С. Маркелова, Н. ЛОБАНОВА / / http://www.oxpaha.ru/view.asp?8362 Стаття про комплекс "АНВИК: Облік відділу позавідомчої охорони" 1С
12. Наказ № 291 Про організацію роботи з підбору під охорону об'єктів власності .- Перм: УВО при ГУВС, 2003
13. Чері, С. Логічне програмування та бази даних / С. Чері, Г. Готлоб, Л. Танка; пер. з англ. Під ред. Л.А. Калинченко .- М.: Світ, 1992 .- 352 с.: Іл.
14. Дейт, К.Д. Введення в системи баз даних: пров. з англ .- М., СПб.; Київ: Вільямс, 1999 .- 848 с.: іл.
15. Економічне обгрунтування дипломних проектів / Під ред. Ю.В. Старкова - Перм, 1997.
16. Техніко-економічне обгрунтування дипломних проектів: навч. посібник для втузів / Л. А. Астреіна, В. В. Балдесов, В. К. Беклешов та ін; Під ред. В. К. Беклешова. - М.: Вищ. шк., 1991. - 176 с.: Іл.
17. Положення про позавідомчої охорони при органах внутрішніх справ Російської Федерації від 14. 08. 1992, № 589
18. 1С: Підприємство: Версія 7.7. Конфігурування та адміністрування. - М.: 1С, 1999
19. Фаронов В.В. Delphi 5. Керівництво розроблювача баз даних / В.В. Фаронов / / .- М.: Нолидж, 2000 .- 510с.
20. Ходирєва Г. В. Реляційні бази даних: мова SQL / Г. В. Ходирєва / / Інформатика та освіта. - 2004. - № 4. - С. 36 - 45.
21. Хоменко А.Д., Циганков В.М., Мальцев М.Г. Бази даних: Підручник для вищих навчальних закладів. / Под ред. проф А.Д. Хоменко. - СПб.: Корона принт, 2000. - 416 с.

Створення автоматизованої інформаційної системи Звід звітів для УВО при ГУВС Пермського краю

Введення

1. Сучасний стан створення звітів на підприємствах. Обгрунтування створення системи

1.1 Звітна документація як основа ефективності функціонування

підприємства.

1.1.1 Поняття управлінської звітності.

1.1.2 Характеристики системи управлінської звітності

1.2 Аналіз існуючих АІС з підготовки звітних документів.

1.1.2 Система «Облік ІТСО»

1.1.3 Система «Картотека»

1.1.4 Конфігурація 1С «АНВИК: Облік відділу позавідомчої охорони»

1.1.5 Порівняння систем «Облік ІТСО», «Картотека» і «АНВИК: Облік ОВО»

1.1.6 Висновки

1.2 Техніко-економічне обгрунтування ефективності впровадження АІС "Звід звітів" для УВО

2. Аналіз предметної області, системний і структурний аналіз.

2.1 Аналіз предметної області створення і використання звітних документів.

2.2 Існуючі форми звітності в УВО.

2.2.1 Форма «ВО-2»

2.2.2 Звіт про наявність ПЦН, ЗЗА та ріпів

2.2.3 Звіт про роботу підрозділу охорони

2.2.5 Звіт охорони об'єктів та квартир

2.2.6 Звіт про супроводі перевезеного майна власника, в т.ч. грошових коштів

2.2.7 Звіт за станом квартир.

2.2.8 Звіт за станом об'єктів.

2.2.9 Звіт з охорони автостоянок УВО при ГУВС Пермської області.

2.2.10 Звіт про результати роботи УВО форма "ВО-1".

2.2.11 Підсумки роботи підрозділу ОВО.

2.2.12 Структурний аналіз звітних форм УВО.

2.3 Системний аналіз та структурне проектування системи

2.3.1 Визначення вимог до нової системи.

2.3.1 Логічне проектування системи.

2.3.1.1 Операція з обліковими записами про об'єкти.

2.3.1.2 Операції з обліковими записами про ТСО

2.3.1.3 Операції з обліковими записами про ПЦО або АТС

2.3.1.4 Операції з записами про історію ТСО

2.3.1.5 Операції з записами про історію об'єктів

2.3.1.6 Операція з обліковими записами про заявки та супроводження майна.

2.3.1.7 Операція з обліковими записами про співробітників УВО.

2.3.1.8 Складання на основі записів звітних форм.

2.4 Розробка инфологической та концептуальної схеми БД.

2.4.1 Побудова инфологической схеми БД.

2.4.2 Побудова об'єктно-орієнтованої моделі БД

2.5 Вибір моделі даних і СКБД

2.5.1 Реляційна модель даних

2.5.2 Об'єктно-орієнтована модель даних

2.5.3 СУБД 1с: V8.0

2.5.4 СУБД Oracle 10g

2.5.5 СУБД SQL Server 2000

2.5.6 СУБД InterBase 6

2.5.7 Порівняння СУБД Oracle 10g, SQL Server 2000, InterBase 7.1 і 1С: v8.0

3. Проектування програми

3.1 Опис створених об'єктів в конфігурації

3.2 Вимоги до обладнання, прикладного і системного ПЗ для забезпечення роботи системи

Висновок

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