85655

Розробка комп’ютеризованої підсистеми управління матеріально-технічним забезпеченням на вугледобувного підприємстві (на прикладі СП шахти «Самсонівська-Західна» ВАТ «Краснодонвугілля»)

Дипломная

Информатика, кибернетика и программирование

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

Украинкский

2015-03-29

1.34 MB

5 чел.

Міністерство освіти і науки України

Східноукраїнський національний університет

імені Володимира Даля

Кафедра економічної кібернетики

ДИПЛОМНА РОБОТА

на тему:

«Розробка комп’ютеризованої підсистеми управління матеріально-технічним забезпеченням на вугледобувного підприємстві

(на прикладі СП шахти «Самсонівська-Західна» ВАТ «Краснодонвугілля»)

Студент групи    Кз-031  ________________ Парій Ю.В. 

Керівник дипломної роботи______________ к.т.н., доц. Істомін Л.Ф.

Завідувач кафедри

економічної кібернетики:________________ д.т.н., проф. Рамазанов С.К.

Краснодон 2008



Анотація

У роботі проаналізовано процес прийняття рішень у сфері матеріально-технічного забезпечення на вугледобувному підприємстві на прикладі шахти «Самсонівська-Західна».  Розроблена система підтримки прийняття рішень (СППР) у сфері матеріально-технічного забезпечення на основі OLAP-аналізу, яка реалізується засобами “Delphi 7.0”.


Реферат

Сторінок 105, таблиць 0, малюнків 13, джерел 33

OLAP, аналіз, система, рішення, СППР, ОПР, матеріально-технічне забезпечення, програма, шахта, склад

Об'єктом дослідження э матеріально-технічні ресурси. Ціль дослідження полягає в тому, щоб проаналізувати процес прийняття рішень у сфері матеріально-технічного забезпечення на шахті «Самсонівська-Західна» і розробити СППР на основі OLAP-аналізу  для  ефективного керування матеріалами на підприємстві.


Зміст

Вступ            6

1. Характеристика діяльності підприємства шахта «Самсонівська-Західна» 8

1.1. Загальна характеристика підприємства     8

1.2. Організаційна структура               14

1.3. Матеріально-технічне забезпечення на підприємстві           18

2. Процес прийняття рішень - основний фактор успішної виробничої діяльності підприємства                25

2.1. Управлінські рішення на підприємстві            25

2.2. Система підтримки прийняття рішень(СППР)           25

2.2.1. Поняття й сутність СППР             42

2.2.2. Бази даних - основа СППР             59

2.3. OLAP - оперативний аналіз              65

2.4. Прийняття рішень у сфері матеріально-технічного

забезпечення шахти                82

3. Програмне забезпечення інформаційної системи матеріально-технічного забезпечення                  87

3.1. Моделювання даних               87

3.1.1. Концептуальне моделювання             87

3.1.2. Фізичне моделювання              89

3.2. Побудова розмірностної моделі даних            90

3.3. Обґрунтування вибору алгоритму й інструментальних засобів аналізу даних                  95

3.4. Опис і порядок роботи із програмою             96

Висновок                 101

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

Додатки                 105


Вступ

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

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

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

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

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

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

  1.  Дати   загальну   характеристику   діяльності   шахти «Самсонівська-Західна».
  2.  Проаналізувати   організаційну   структуру   управління   шахти,   охарактеризувати       відділи   підприємства.
  3.  Розглянути   процес прийняття рішень у сфері матеріально-технічного забезпечення.
  4.  Обґрунтувати вибір програмного засобу для аналізу даних.
  5.  Розробити систему підтримки прийняття рішень (СППР) у сфері матеріально-технічного забезпечення на основі OLAP-аналізу.


1. Характеристика діяльності підприємства шахта

«Самсонівська-Західна»

1.1. Загальна характеристика підприємства

Шахта «Самсонівська-Західна» розташована в Краснодонському районі Луганської області. Поле шахти з розмірами по простяганню 13 км і по падінню 3 - 6 км перебуває на північно-заході Краснодонського вугільного району поруч із селищем Самсонівка.

Центральний майданчик шахти розташован  в безпосередній близькості від автомагістралі «Кишинів - Волгоград». Шахта має безпосередній вихід на залізничну станцію  «Сімейкіно - Нова».

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

Основними напрямками діяльності підприємства є:

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

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

Будувати її почали в 1965 році. Генпідрядником був трест «Краснодоншахтобуд», а замовником - Дирекція споруджуваних підприємств, створена в 1964 році. Розташовувалася вона тоді в Луганську.

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

В 1975 році на шахті «Самсонівської-Західної» залишилася мінімальна кількість працюючих, що забезпечують вентиляцію, водовідлив і підтримку раніше пройдених вироблень. У результаті цього була зроблена «мокра» консервація шахти (консервація гірських вироблень шару І-3-1, повітряподаючого й вентиляційного №2 стовбурів).

З 1980 року відновилися роботи із проведення основних об'єктів шахтної поверхні. Був побудований й уведений у роботу баштовий копер допоміжного стовбура із клітьовими підйомами. Закінчено будівництво вентиляторної установки ВЦЦ-31,5 у головного стовбура. В 1984 році зводиться баштовий копер головного стовбура, добудовується ємнісна частина навантажувальних бункерів, будується блок будівель допоміжного стовбура й адміністративно-побутовий комбінат , побудована будівля котельні й запущені в роботу два парових казани. На ачику вентиляційного стовбура №1 велося будівництво вентилятора головного провітрювання ВЦД- 47,5 в.

У зв'язку з тим, що державне фінансування велося слабко, був переглянутий проект шахти. Переглянутим проектом, затвердженим в 1998р., із проектною потужністю 1500тис. т. вугілля в рік (6 лав) і кошторисною вартістю 1179 млн. грн. передбачалося поетапне відпрацьовування поля. Проектна потужність досягалася 3-ма пусковими комплексами:

I пусковий комплекс - 750 тис. т. (3 лави в бремсбергової панелі №1 пл. ДО2Н)

II пусковий комплекс - 550 тис. т. (2 лави в уклонному полі пл. ДО2Н)

III пусковий комплекс - 200 тис. т. (1 лава в бремсбергової частини пл. З1)

У серпні 1999 року шахта була уведена в експлуатацію в складі об'єктів поверхні й однієї лави по пл. ДО2Н с потужністю 250 тис. т.

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

Центральний проммайданчик розташован на північному схилі балки Самсонівська. Розміщення будівель і споруджень виконано з максимально доцільним блокуванням, з обліком строгого зонування території. З огляду на те, що рельєф місцевості має значний ухил (5%), будівлі й спорудження розміщаються відповідно зонам на трьох терасах. Територія озеленена, усюди влаштовані газони й квітники, висаджені дерева й чагарники. Все це додало зовнішньому вигляду шахти архітектурну виразність.

Будучи потужним високоефективним вуглевидобувним підприємством, вона після освоєння проектної потужності зможе добувати 1,5 млн. тонн конкурентноздатного вугілля, що коксує. Шахтне поле, розкинувшись на      13км по простяганню  від 3 до 6 по падінню, уміщає в себе 164,3 млн. тонн вугілля. У тектонічному відношенні воно перебуває в східній частині Лутугінської улоговини. Основне простягання порід у західній і центральній частинах в обох крилах близьке до широтного, азимут простягання 70-75° на північний схід. Поле шахти ускладнене великими й дрібними диз'юнктивними порушеннями типу насувань. Переважні кути падіння шарів у межах шахтного поля - 5-20 градусів.

Промислова вугленосність шахтного поля характеризується наявністю трьох робочих шарів К2, И31, ЛзВ, що дають основні промислові запаси вугілля.

Найбільше вугленасиченою є західна частина шахтного поля. На східній частині поля робочу потужність зберігають тільки два шари: К2 і  И31.

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

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

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

У східній частині поля потужність шару витримана і стійка, коливається в межах 1,0- 1,5м і більше. У західній частині потужність шару знижується до 0,7...0,9м. При цьому будова шару, в основному, простої, однопачкове.

Шар ЛзВ у границях шахти є єдиним робочим шаром зі звиті З26. Його потужність коливається в широких межах - від неробочого прошаку  0,24м до робочої - 1,39м. Спостерігається поступове потоаттня шару в східному напрямку до неробочого значення.

Будова шару однопачкове, дуже рідко двухпачкове.

Геологічним звітом шар характеризується як нестійкий.

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

Вугілля, що добувають, ставляться до марок "ГЖ" й "Ж", придатні для коксування.

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

Безпосередньо ґрунт шару К2 складається з алевролитів, рідше аргиллитів, характеризується як слабкстійка (для аргиллитів) і відносно стійка (для алевролітів).

Безпосередній ґрунт шару Из  на більшій площі представлений алевролітом, у  меншій  частині піщаником і на обмежених площах   - аргиллитом. Алевроліти при обводненому  стані здатні до спучування.

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

По зольності й змісту сірки це високоякісне вугілля марки «ж». Промислові запаси вугілля по шахті - 133,1 млн. тонн. Так що шахта, вийшовши на проектну потужність, при сприятливих умовах могла б працювати 90 років.

Шахта є зверхкатегорною по газовому фактору, небезпечною по раптових викидах, небезпечною по пилу.

При будівництві шахти була застосована прогресивна блокова схема розкриття й підготовки шахтного поля двома самостійними стовбурами зі збільшеними блоками по простяганню до 4-5 км і по падінню до 2 км, що забезпечує стабільність роботи шахти протягом 15-20 років без істотних обсягів капітальних горнопрохідних робіт.

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


1.2. Організаційна структура

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

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

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

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

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

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

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

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

  1.  Головний інженер - керує всією інженерною діяльністю на шахті, очолює технічну службу. Основними завданнями головного інженера є:

- розвиток шахти, своєчасна підготовка обріїв, створення необхідної діючої й резервної очисної лінії вибоїв;

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

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

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

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

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

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

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

  1.    Заступник директора по охороні праці (ОП): здійснює відомчий контроль за виконанням на шахті Закону України «Про охорону праці», Гірського Закону України, Кодексу України про надра, Правил безпеки у вугільних шахтах, інших нормативно-правових актів і технічної документації по охороні праці й безпеки виконання робіт; керує діяльністю служби охорони праці й працівників шахти в питаннях охорони праці; забезпечує функціонування системи керування охороною праці. Заступникові директора по ОП підкоряється служба ОП.

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

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

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

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

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

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

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

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

Геологічний відділ здійснює розвідку й контроль гірничо-геологічних умов підземних вироблень.

На підставі аналізу організаційної структури підприємства можна зробити висновки:

1.  Організаційна структура є негнучкою.

2.  Поділ відділів по їхніх функціональних обов'язках приводить до відсутності взаємозв'язку між відділами.

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

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

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

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

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

Виробнича структура шахти «Самсонівська-Західна» представлена наступними виробничими ділянками й службами:

  1.  Ділянка № 1 по видобутку вугілля.
  2.  Ділянка ПР-1 і ГКР - проходження підготовчих вироблень.
  3.  РВУ - ремонт і перекріплення гірських вироблень.
  4.  ВКТ - забезпечення конвеєрним транспортом для переміщення вугілля й породи.
  5.  МДРЗВ - монтаж, демонтаж, ремонт забійного встаткування.
  6.  ВТБ - забезпечення вентиляційного контролю й дотримання техніки безпеки.
  7.  ПРТБ - виконання профілактичних робіт з техніки безпеки.
  8.  ШТ-1, ШТ-2 - ділянки шахтного транспорту, підйом, спуск і транспортування людей і вантажів.
  9.  Стаціонарні установки № 1 водовідлив, вентилятор ВДЦ - 31,5, компресорна станція.
  10.  Стаціонарні установки № 2 - вентиляційний стовбур № 1, вентилятор головного провітрювання.
  11.   ППС - повітряподаючий стовбур.
  12.  БПР - проведення підривних робіт у прохідницьких вибоях.
  13.   Поверхневий технологічний комплекс - транспорт вугілля по поверхні, контроль якості вугілля й відвантаження в залізничні вагони.
  14.  Механічний цех - токарські й зварювальні роботи.
  15.  Енерго-механична служба - енергопостачання шахти, телефонний зв'язок.
  16.  РБУ - будівництво й ремонт приміщень поверхні, виготовлення залізобетонного кріплення.
  17.  Котельня - теплопостачання шахти.
  18.  Автотранспорт.
  19.  Склад устаткування.

1.3. Матеріально-технічне забезпечення на підприємстві 

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

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

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

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

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

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

Завданнями аналізу використання матеріальних ресурсів є:

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

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

  •  бізнес-плану;
  •  оперативно-технічного й бухгалтерського обліку;
  •  відомості аналітичного бухгалтерського обліку про надходження, витрату й залишки матеріальних ресурсів;
  •  відомості про витрати на виробництво й реалізацію продукції (робіт, послуг) [30, с. 187].

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

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

Загальна потреба в матеріальних ресурсах визначається виходячи з норм їхньої витрати на одиницю продукції (робіт, послуг) або на операцію, процес. Розрізняють використання матеріальних ресурсів в основному, допоміжному й обслуговуючому виробництві (виробничо-експлуатаційні витрати), у капітальному будівництві, для створення виробничих запасів і резервів. Характеристика використання матеріальних ресурсів у виробництві заснована на аналізі їхньої фактичної витрати в порівнянні з нормативним, плановим. Такий аналіз виконується постійно, відхилення в тій або інший бік ретельно аналізується [5, c. 141].

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

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

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

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

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

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

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

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

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

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

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

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

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

Існує два основних види видаткових документів: вимога, лімітно-заборна картка.

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

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

При відпустці комірник у двох екземплярах вимоги відображає фактично відпущену кількість товару. Один екземпляр вимоги залишається в комірника, а іншої - у представника цеху [1, c 18].

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

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

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

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

Картка складського обліку є регістром аналітичного обліку матеріалів, вона може вестися комірником тільки в кількісному або кількісно-сумовому вираженні.

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

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

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

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

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

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


2. Процес прийняття рішень - основний фактор успішної

виробничої діяльності підприємства

2.1. Управлінські рішення на підприємстві

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

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

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

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

Рішення є одним з видів розумової діяльності й проявом волі людини.

Його характеризують наступні ознаки:

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

Відповідно під управлінським рішенням розуміється:

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

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

До управлінського рішення пред'являється ряд вимог, до числа яких можна віднести:

  1.  всебічну обґрунтованість рішення;
  2.  своєчасність;
  3.  необхідну повноту#змісту;
  4.  повноважність;
  5.  погодженість#із прийня葂йми раніше рішеннями.

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

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

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

а) мета (сукупність цілей) функціонування й розвитку системи;

б) кошти й ресурси, використовувані для досягнення цих цілей;

в) основні шляхи й способи досягнення цілей;

г) строки досягнення цілей;

д) порядок взаємодії між підрозділами й виконавцями;

е) організацію виконання робіт на всіх етапах реалізації рішення.

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

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

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

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

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

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

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

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

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

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

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

  1.  по функціональному змісту;
  2.  по характеру розв'язуваних завдань (сфері дії);
  3.  по ієрархії керування;
  4.  по характеру організації розробки;
  5.  по характеру цілей;
  6.  із причин виникнення;
  7.  по вихідних методах розробки;
  8.  по організаційному оформленню.

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

а) рішення планові;

б) організаційні;

в) контролюючі;

г) прогнозуючі.

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

Інший принцип класифікації пов'язаний з характером розв'язуваних завдань:

а) економічних;

б) організаційних;

в) технологічних;

г) технічних;

д) екологічних та інших.

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

Залежно від організації розробки рішень виділяються наступні управлінські рішення:

а) одноособові;

б) колегіальні;

в) колективні.

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

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

а) поточні (оперативні);

б) тактичні;

в) стратегічні.

Із причин виникнення управлінські рішення діляться на:

а) ситуаційні, пов'язані з характером виникаючих обставин;

б) по приписанню (розпорядженню) вищих органів;

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

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

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

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

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

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

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

По організаційному оформленню управлінські рішення діляться на:

а) тверді, що однозначно задають подальший шлях їхнього втілення;

б) що орієнтують, визначальний напрямок розвитку системи;

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

г) нормативні, що задають параметри протікання процесів у системі.

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

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

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

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

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

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

Перераховані види рішень приймаються, в основному, у процесі оперативного керування персоналом. Для стратегічного й тактичного керування будь-якої підсистеми системи менеджменту приймаються раціональні рішення, засновані на методах економічного аналізу, обґрунтування й оптимізації [28, c. 108].

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

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

Прийняття рішень в організації характеризується як:

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

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

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

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

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

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

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

Ефективним вважається рішення, що задовольняє ряд вимог. Воно повинне:

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

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

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

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

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

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

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

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

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

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

  •  своєчасність подання проекту рішення;
  •  ступінь наукової обґрунтованості рішень (використання наукових методів розробки, сучасних підходів) і ін [22, с. 157].

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

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

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

  1.  Класифікація проблеми. Типова це проблема або унікальна. Або ж це досконало новий тип проблеми, для рішення якої ще тільки має бути виробити правила.
    1.  Визначення проблеми. Із чим ми маємо справу.
      1.  Визначення способу рішення проблеми. Які «граничні умови», тобто умови які повинні бути дотримані.
        1.  Визначення того, що «правильно», а не «прийнятно» З метою дотримання граничних умов. Перш ніж шукати компроміси, займатися адаптацією й робити допущення, варто з'ясувати, що повністю задовольняє граничним умовам.
          1.  Визначаємо рішення таким чином, щоб воно несло в собі дію, необхідну для його виконання. Яку дію варто почати для виконання рішення. Хто повинен про це знати.
            1.  Перевірка обґрунтованості й ефективності рішень на відповідність реальному положенню речей. Яким чином виконується рішення. Наскільки сприйнятливі припущення, на яких воно засновано [33, с. 10].

Хороший керівник, що приймає рішення, запитає: це симптом загального безладдя або випадковість! Типові проблеми варто вирішувати з використанням правил або принципів. Але  випадковість можна розглядати лише в сугубо індивідуальному порядку, з огляду на унікальність ситуації.

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

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

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

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

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

Наступний крок в ухваленні рішення  визначити чіткі умови, якою воно повинне відповідати. Які мети ми переслідуємо! Які найважливіші завдання! Які умови повинні бути дотримані! У науці такі умови відомі як «граничні умови». Ефективне рішення повинне відповідати граничним умовам.

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

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

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

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

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

Перетворення рішення в дію  п'ятий найважливіший елемент процесу ухвалення рішення.

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

Недолік великого числа програмних заяв, особливо в бізнесі, полягає в тому, що в них нічого не говориться про дії, необхідні для виконання рішення, - про те, як перетворити його у чиєсь конкретне завдання й відповідальність. Тому не дивно, що люди в багатьох організаціях ставляться до таких заяв скептично, а іноді навіть сприймають їх як декларацію того, що вище керівництво в дійсності не має наміру робити. Перетворюючи рішення в дію, необхідно дати відповідь на кілька питань: Хто повинен знати про це рішення? Які дії варто почати? Хто повинен це зробити? Якими повинні бути дії, щоб люди, яким доручено їхнє виконання, могли впоратися зі своїм завданням? Про першому й останньому із цих питань часто забувають, що приводить до досить сумних результатів.

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

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

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

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

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

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

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

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

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

Хороший керівник знає, що ухвалення рішення - це систематичний процес із чітко вираженими елементами й певною послідовністю кроків [33, с. 15].

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

2.2. Система підтримки прийняття рішень(СППР)

2.2.1. Поняття й сутність СППР

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

Малюнок 2.1. Рівень використання людиною різних об'єктів матеріального миру

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

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

  •  уведення даних;
  •  зберігання даних;
  •  аналіз даних.

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

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

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

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

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

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

Таким чином, узагальнена архітектура СППР може бути представлена в такий спосіб (малюнок 2.2).Розглянемо окремі підсистеми більш докладно.

ПІДСИСТЕМИ АНАЛІЗУ

ПІДСИСТЕМА ВВЕДЕННЯ ДАНИХ (СУБД - OLTP

ПІДСИСТЕМА ЗБЕРІГАННЯ ІНФОРМАЦІЇ (СУБД Й/АБО СХОВИЩЄ ДАНИХ)

ПІДСИСТЕМИ ІНФОРМАЦІЙНО-ПОШУКОВОГО АНАЛІЗУ (СБД SQL)

ОПЕРАТОР

ПІДСИСТЕМИ ОПЕРАТИВНОГО АНАЛІЗУ (OLAP)

АНАЛІТИК

ПІДСИСТЕМИ ІНТЕЛЕКТУАЛЬНОГО АНАЛІЗУ (DATA MINING)

Малюнок 2.2. Узагальнена архітектура СППР

Підсистема уведення даних. У таких підсистемах, які називають OLTP (Online transaction processing), реалізується операційна (транзакціона) обробка даних. Для їхньої реалізації використають звичайні системи керування базами даних (СУБД).

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

Підсистема аналізу. Дана підсистема може бути побудована на основі:

  •  підсистеми інформаційно-пошукового аналізу на базі реляційних СУБД і статичних запитів з використанням мови SQL (Structured Query Language);
  •  підсистеми оперативного аналізу. Для реалізації таких підсистем застосовується технологія оперативної аналітичної обробки даних OLAP (On-line analytical processing), що використає концепцію багатомірного подання даних;
  •  підсистеми інтелектуального аналізу. Дана підсистема реалізує методи й алгоритми Data Mining ("видобуток даних") [4, c. 226].

СППР виникли на початку 70-х років як подальший розвиток управлінських інформаційних систем й являють собою системи розроблені для підтримки прийняття рішень менеджерами в складних й слабоструктурованих ситуаціях. На розвиток СППР істотний вплив зробили досягнення в області інформаційних технологій. Як приклад, телекомунікаційні мережі, персональні комп'ютери, динамічні електронні таблиці, експертні системи. Цей термін належить Гарри й Мортону. До цього часу існує безліч певних СППР і розмаїтість визначень відображає широким діапазон різних форм, розмірів, типів СППР, однак всі віди комп'ютерних систем характеризуються чіткою структурою, основними компонентами: підсистемою інтерфейсу користувачі підсистемою керування базою даних; підсистемою керування базою моделей.

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

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

Потужність СППР позначає можливість системи відповідати на більше істотні питання.

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

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

Надійність СППР - у здатності системи заповнювати потрібні функції системи протягом заданого періоду.

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

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

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

СППР другого покоління вже мають принципово нові ознаки:

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

Мета й призначення СППР другого покоління в загальному виді можна визначити в такий спосіб:

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

Дружній користувальницький СППР дозволяє йому на рівні звістки діалог з ПЭОМ, використовуючи звичайну мову спілкування.

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

Для сучасних комп'ютерних СППР характерна наявність ряду характеристик:

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

2. СППР підтримує й підсилює (однак не замінює й не скасовує) мислення й оцінки керівника. Контроль залишається за людиною. Користувач почуває себе комфортно і як удома у системі, а не почуває залякування з боку системи;

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

4. СППР здійснює інтеграцію моделей й аналітично методів зі стандартним доступом і вибіркою даних. Для допомоги при прийнятті рішень активізується одна або кілька моделей  (математичних, статистичних, імітаційних, кількісних, якісних і комбінованих). Зміст БД охоплює історію поточних операцій (сильна сторона типовий АИС), а так само інформацію зовнішнього характеру й інформацію про середовище;

5. СППР проста в роботі для осіб, які не мають достатнього досвіду роботи з ЕОМ. Системи є дружніми з користувачем, не вимагають ніяких знань ОТ і забезпечують просте пересування по системі, діалогову документацію, убудовані способи навчання й інші атрибути програмних інтерфейсних систем;

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

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

8. СППР не повинна нав'язувати певного процесу прийняття рішень користувачем. Він повинен мати набір можливостей, використовуючи їх у формі й послідовності, що відповідають його пізнавальному стилю «подання моделей» [25, c. 48 ].

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

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

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

Узагальнені СППР можуть інтегрувати дві й більше перераховані функції. В 1984 році в США був зроблений аналіз 131 типу СППР, у результаті були визначені пріоритетні області  використання систем.

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

Комп'ютерна підтримка різних функцій за допомогою СППР має такий розподіл у відсотках: оперативне керівництво - 30; довгострокове планування - 40; розподіл ресурсів - 15; розрахунки річного бюджету -12%. Перерахування найбільш відомих комерційних СППР включає сотні назв.

Найбільш типові СППР, які ставляться до проблем макро- і мікроекономіки:

  •  «Сімплан» призначена для корпоративного планування;
  •  «Прожектор» фінансове планування;
  •  «Джи-план» загальне планування;
  •  «Експрес» - маркетиногово-финансовое планування;
  •  PMS - керівництво цінними паперами;
  •  CIM- планування виробів;
  •  PI.MS - маркетингу;
  •  B1S - керівництво бюджетом;
  •  1FPS - інтерактивне фінансове планування;
  •  FOKUS - фінансове планування;
  •  ISDS - формування «портфеля замовлень»;
  •  MAUD - індивідуальний вибір;

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

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

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

Система «Сімплан» містить такі підсистеми:

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

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

Режим даних поєднує засоби системи по керуванню ними. Режим аналізу містить у собі набір релевантних економічних і статистичних методів аналізу, прогнозування й мова моделювання системи «Сімплан». Режим звіту є основою генерації звітів, режим редагування призначений для цілей подальшого спрощення створення й використання моделей і звітів. Графічний режим дає можливість ідентифікувати закономірності даних, використаних як базис для прогнозування, розглядати розбіжність між практичними даними і їхніми прогнозами або бюджетами, а також для візуального порівняння результатів реалізації моделей [25, c. 34].

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

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

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

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

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

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

Програмне забезпечення СППР включає:

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

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

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

У процесі використання СППР можна виділити такі ролі:

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

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

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

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

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

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

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

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

Класифікація на основі мер підтримки прийняття рішень. З кінця 70-х років розроблялася класифікація СППР, у якій розходження між елементами виділялися залежно від міри підтримки (заходу прямого впливу) управлінських рішень і характеру виконуваних дій. На основі емпіричних досліджень більше 50 різних СППР, проведених Альтером в 1983 році, було виділено два типи систем:

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

У свою чергу, ці групи систем розбиваються на 7 окремих видів:

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

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

1 -й - спеціалізовані СППР (прикладні);

2-й - генератори СППР

3-й - інструментарій СППР.

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

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

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

Класифікація по ступені залежності ОПР у процесі прийняття рішень

Відомі три типи організаційних рішень:

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

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

Технологія СППР розрахована на підвищення якості результатів колективних рішень, оскільки дає можливість групі ОПР прискорювати, змінювати або модифікувати напрямок обміну повідомленнями. Вона припускає три рівні пропонованого сервісу.

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

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

ГСППР повинні обслуговувати багато різних типів груп і контекстів завдань. До таких завдань ставляться генерування ідей і дій, вибір альтернатив або варіантів, проведення переговорів для досягнення рішень (що є унікальною особливістю групових процесів рішень).

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

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

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

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

2.2.2. Бази даних - основа СППР

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

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

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

Ієрархічна структура припускала зберігання даних у вигляді дерева. Це значно спрощувало створення й підтримку таких БД. Однак неможливість представити багато об'єктів реального миру у вигляді ієрархії привела до використання таких БД у сильно спеціалізованих областях. Типовим представником (найбільш відомим і розповсюдженим) ієрархічної СУБД є Information Management System (IMS) фірми IBM. Перша версія цього продукту з'явилася в 1968 році.

Спробою поліпшити ієрархічну структуру була мережна структура БД, що припускає подання даних у вигляді мережі. Вона заснована на пропозиціях групи Data Base Task Group (DBTG) Комітету з мовам програмування Conference on Data Systems Languages (CODASYL). Звіт DBTG був опублікований в 1971 році.

Робота з мережними БД представляє набагато більш складний процес, ніж робота з ієрархічною БД, тому дана структура не знайшла широкого застосування на практиці. Типовим представником мережних СУБД є Integrated Database Management System (IDMS) компанії Cullinet Software, Inc.

Найпоширеніші в цей час реляційні БД. Термін " реляційний" відбувся від латинського слова relatio- відношення. Така структура зберігання даних побудована на взаємовідношенні складових її частин. реляційний підхід став широко відомий завдяки роботам Е.Кодда, які вперше були опубліковані в 1970 році. У них Кодд сформулював наступних 12 правил для реляційної БД.

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

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

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

5. Повинен використатися єдина мова для взаємодії із СУБД -

для керування реляційною БД повинен використатися єдина мова. У цей час таким інструментом стала мова структурних запитів SQL.

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

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

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

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

10. За цілісність даних відповідає СУБД- під цілісністю даних у загальному випадку розуміється готовність БД до роботи. Розрізняють наступні типи цілісності:

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

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

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

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

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

Наприклад:

  •  БД має 1-ю НФ, якщо кожне значення, що зберігається в ній, нероздільно на більше примітивні (нерозкладність значень);
  •  БД має 2-ю НФ, якщо вона має 1-ю НФ, і при цьому кожне значення цілком і повністю залежить від ключа (функціонально незалежні значення);
  •  БД має 3-ю НФ, якщо вона має 2-ю НФ, і при цьому жодне зі значень не надає ніяких відомостей про інше значення (взаємно незалежні значення) і т.д.

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

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

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

Транзакція- це послідовність операцій над БД, розглянутих СУБД як єдине ціле. Транзакція переводить БД із одного цілісного стану в інше.

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

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

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

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

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

До цього класу систем відносяться перші СППР - інформаційні системи керівництва (ИСР, Executive Information Systems). Такі системи, як правило, будуються на основі реляційних СУБД, містять у собі підсистеми збору, зберігання й інформаційно-пошукового аналізу інформації, а також містять у собі визначену безліч запитів для повсякденної роботи. Кожен новий запит, непередбачуваний при проектуванні такої системи, повинен бути спочатку формально описаний, закодованим програмістом і тільки потім виконаний. Час очікування в такому випадку може становити годинни й дні, що неприйнятно для оперативного прийняття рішень [4, c. 156].

2.3. OLAP - оперативний аналіз

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

У процесі аналізу даних, пошуку рішень часто виникає необхідність у побудові залежностей між різними параметрами. Крім того, число таких параметрів може варіюватися в широких межах. Як ми вже відзначали, традиційні засоби аналізу, що оперують даними, які представлені у вигляді таблиць реляційної бази даних, не можуть повною мірою задовольняти таким вимогам. В 1993 р. Э. Ф. Кодд- основоположник реляційної моделі бази даних - розглянув її недоліки, указавши в першу чергу на неможливість "поєднувати, переглядати й аналізувати дані з погляду множинності вимірів, тобто самим зрозумілим для аналітиків способом".

Вимір- це послідовність значень одного з аналізованих параметрів. Наприклад, для параметра "час" це послідовність календарних днів, для параметра "регіон" це, наприклад, список міст.

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

По Кодду, багатомірне концептуальне подання (multi-dimensional conceptual view) - це множинна перспектива, що складається з декількох незалежних вимірів, уздовж яких можуть бути проаналізовані певні сукупності даних. Одночасний аналіз по декількох вимірах визначається як багатомірний аналіз.

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

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


Малюнок 2.3. Подання даних у вигляді гіперкуба

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

Над таким гіперкубом можуть виконуватися наступні операції:

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


Малюнок 2.4. Операція зрізу

  •  Обертання (Rotate) (малюнок 2.5) - зміна розташування вимірів, представлених у звіті або на відображуваній сторінці. Наприклад, операція обертання може укладатися в перестановці місцями рядків і стовпців таблиці або переміщенні вимірів, що цікавлять, у стовпці або рядки створюваного звіту, що дозволяє надавати йому бажаний вид. Крім того, обертанням куба даних є переміщення позатабличних вимірів на місце вимірів, представлених на відображуваній сторінці, і навпаки (при цьому позатабличне вимір стає новим виміром рядка або виміром стовпця). Як приклад для першого випадку може служити такий звіт, для якого елементи виміру "Час" розташовуються поперек екрана (є заголовками стовпців таблиці), а елементи виміру "Продукція" - уздовж екрана (є заголовками рядків таблиці). Після застосування операції обертання звіт буде мати такий вигляд: елементи виміру "Продукція" будуть розташовані по горизонталі, а елементи виміру "Час" - по вертикалі. Прикладом другого випадку може служити перетворення звіту з вимірами "Міри" й "Продукція", розташованими по вертикалі, і виміром "Час", розташованим по горизонталі, у звіт, у якого вимір "Міри" розташовується по вертикалі, а виміру "Час" й "Продукція" - по горизонталі. При цьому елементи виміру "Час" розташовуються над елементами виміру "Продукція". Для третього випадку застосування операції обертання можна привести приклад перетворення звіту з розташованим по горизонталі виміром "Час" і виміром "Продукція", розташованим по вертикалі, у звіт, у якого по горизонталі представлений вимір "Час", а по вертикалі - вимір "Географія" (синонім: Pivot).

Малюнок 2.5. Операція обертання

- Консолідація (Drill Up) і деталізація (Drill Down) (малюнок 2.6) - операції, які визначають перехід нагору по напрямку від детального (down) подання даних до агрегированному (up) і навпаки, відповідно. Напрямок деталізації (узагальнення) може бути задане як по ієрархії окремих вимірів, так і згідно іншим відносинам, установленим у рамках вимірів або між вимірами. Наприклад, якщо при аналізі даних про обсяги продажів у Північній Америці виконати операцію Drill Down для виміру "Регіон", то на екрані будуть відображені такі його елементи, як "Канада", "Східні Штати Америки" й "Західні Штати Америки". У результаті подальшої деталізації елемента "Канада" будуть відображені елементи "Торонто", "Ванкувер", "Монреаль" і т.д.

Малюнок 2.6. Операції консолідації й деталізації

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

OLAP (On-Line Analytical Processing) - технологія оперативної аналітичної обробки даних, що використовує методи й засоби для збору, зберігання й аналізу багатомірних даних з метою підтримки процесів прийняття рішень.

Основне призначення OLAP-систем - підтримка аналітичної діяльності, довільних (часто використається термін ad-hoc) запитів користувачів-аналітиків.

Ціль OLAP-аналізу - перевірка виникаючих гіпотез.

У джерел технології OLAP стоїть основоположник реляційного підходу Е. Кодд. В 1993 р. він опублікував статтю за назвою "OLAP для користувачів-аналітиків: яким він повинен бути". У даній роботі викладені основні концепції оперативної аналітичної обробки й визначені наступних 12 вимог, яким повинні задовольняти продукти, що дозволяють виконувати оперативну аналітичну обробку.

Дванадцять правил, викладених Коддом і визначальних OLAP:

1.  Багатомірність- OLAP-система на концептуальному рівні повинна представляти дані у вигляді багатомірної моделі, що спрощує процеси аналізу й сприйняття інформації.

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

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

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

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

6. Рівноправність вимірів - OLAP-система повинна підтримувати багатомірну модель, у якій всі виміри рівноправні. При необхідності додаткові характеристики можуть бути надані окремим вимірам, але така можливість повинна бути надана будь-якому виміру.

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

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

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

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

11. Гнучкі можливості одержання звітів - OLAP-система повинна підтримувати різні способи візуалізації даних, тобто звіти повинні представлятися в будь-якій можливій орієнтації. Засоби формування звітів повинні представляти синтезовані дані або інформацію, що випливає з моделі даних у її будь-якій можливій орієнтації. Це означає,  що  рядки,  стовпці  або  сторінки  повинні  показувати одночасно від 0 N до вимірів, де N- число вимірів всієї аналітичної моделі. Крім того, кожен вимір умісту, показане в одному записі, колонку або сторінці, повинне дозволяти показувати будь-яка підмножина елементів (значень), що втримуються у вимірі, у будь-якому порядку.

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

Набір цих вимог, що послужили де-факто визначенням OLAP, досить часто викликає різні дорікання, наприклад, правила 1, 2, 3, 6 є вимогами, а правила 10, 11 - неформалізованими побажаннями. Таким чином, перераховані 12вимог Кодда не дозволяють точно визначити OLAP. В 1995 р.

Кодд до наведеного переліку додав наступні шість правил:

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

14. Підтримка всіх моделей OLAP-аналізу - OLAP-система повинна підтримувати всі чотири моделі аналізу даних, певні Кодцом: категоріальну, умоглядну й стереотипну.

15. Обробка ненормалізованих даних - OLAP-система повинна бути інтегрована з ненормалізованими джерелами даних. Модифікації даних, виконані в середовищі OLAP, не повинні приводити до змін даних, збережених у вихідних зовнішніх системах.

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

17. Виключення відсутніх значень- OLAP-система, представляючи дані користувачеві, повинна відкидати всі відсутні значення. Інакше кажучи, відсутні значення повинні відрізнятися від нульових значень.

18. Обробка відсутніх значень - OLAP-система повинна ігнорувати всі відсутні значення без обліку їхнього джерела. Ця особливість пов'язана з 17-м правилом.

Крім того, Кодд розбив всі 18 правил на наступні чотири групи, назвавши їхніми особливостями. Ці групи одержали назви В, S, R й D.

Основні особливості (В) включають наступні правила:

  •  багатомірне концептуальне подання даних (правило 1);
  •  інтуїтивне маніпулювання даними (правило 10);
  •  доступність (правило 3);
  •  пакетний витяг проти інтерпретації (правило 13);
  •  підтримка всіх моделей OLAP-аналізу (правило 14);
  •  архітектура "клієнт-сервер" (правило 5);
  •  прозорість (правило 2);
  •  багатокористувачева підтримка (правило 8).

Спеціальні особливості (S):

  •  обробка ненормалізованих даних (правило 15);
  •  збереження результатів OLAP: зберігання їх окремо від вихідних даних (правило 16);
  •  виключення відсутніх значень (правило 17);
  •  обробка відсутніх значень (правило 18).

Особливості подання звітів (R):

  •  гнучкість формування звітів (правило 11);
  •  стандартна продуктивність звітів (правило 4);
  •  автоматичне настроювання фізичного рівня (змінене оригінальне правило 7).

Керування вимірами (D):

  •  універсальність вимірів (правило 6);
  •  необмежене число вимірів і рівнів агрегації (правило 12);
  •  необмежені операції між размірностями (правило 9).

Певні раніше особливості поширені. Більше відомий тест FASMI (Fast of Shared Multidimensional Information), створений в 1995 р. Найджелом Пендсом (Nigel Pendse) і Ричардом Критом (Richard Creeth) на основі аналізу правил Кодда. У даному контексті акцент зроблений на швидкість обробки, багато користуватсьвий доступ, релевантність інформації, наявність засобів статистичного аналізу й багатомірність, тобто подання аналізованих фактів як функцій від великого числа їхніх параметрів, що характеризують. Таким чином, вони визначили OLAP наступними п'ятьма ключовими словами: Fast (Швидкий), Analysis (Аналіз), Shared (Поділюваної), Multidimensional (Багатомірної), Information (Інформації). Викладемо ці п'ять ключових подань більш докладно.

FAST (Швидкий) - OLAP-система повинна забезпечувати видачу більшості відповідей користувачам у межах приблизно 5 с. При цьому найпростіші запити обробляються протягом 1с. і далеко не всі більше 20 с. Недавнє дослідження в Нідерландах показало, що кінцеві користувачі сприймають процес невдалим, якщо результати не отримані після закінчення 30 с. Вони здатні нажати комбінацію клавіш <Alt>+<Ctrl>+<Del>, якщо система не попередить їх, що обробка даних вимагає більшого часу. Навіть якщо система попередить, що процес буде тривати істотно довше, користувачі можуть відволіктися й втратити думки, при цьому якість аналізу страждає. Такої швидкості нелегко досягти з більшою кількістю даних, особливо якщо потрібні спеціальні обчислення "на лету". Для досягнення даної мети використаються різні методи, включаючи застосування апаратних платформ із більшою продуктивністю.

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

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

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

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

OLAP-система містить у собі два основних компоненти:

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

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

Виділяють три основних способи реалізації:

  •  MOLAP- для реалізації багатомірної моделі використають багатомірні БД;
  •  ROLAP- для реалізації багатомірної моделі використають реляційні БД;
  •  HOLAP - для реалізації багатомірної моделі використають і багатомірні й реляційні БД.

Часто в літературі по OLAP-системах можна зустріти абревіатури DOLAP й JOLAP.

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

JOLAP— нова, заснована на Java, колективна OLAP-API-ініціатива, призначена для створення й керування даними й метаданими на серверах OLAP. Основний розроблювач - Hyperion Solutions. Іншими членами групи, що визначає запропонований API, є компанії IBM, Oracle й ін.

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

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

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

Можна виділити наступні переваги використання багатомірних БД в OLAP-системах:

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

З іншого боку, є також істотні недоліки:

  •  за рахунок денормалізації й попередньо виконаної агрегації обсяг даних у багатомірної БД, як правило, відповідає (по оцінці Кодда) в 2,5... 100 разів меншому обсягу вихідних деталізованих даних;
  •  у переважній більшості випадків інформаційний гіперкуб є сильно розрідженим, а оскільки дані зберігаються в упорядкованому виді, невизначені значення вдається видалити тільки за рахунок вибору оптимального порядку сортування, що дозволяє організувати дані в максимально більші безперервні групи. Але навіть у цьому випадку проблема вирішується тільки частково. Крім того, оптимальний з погляду зберігання розріджених даних порядок сортування, швидше за все, не буде збігатися з порядком, що найчастіше використається в запитах. Тому в реальних системах доводиться шукати компроміс між швидкодією й надмірністю дискового простору, зайнятого базою даних;
  •  багатомірні БД чутливі до змін у багатомірній моделі. Так при додаванні нового виміру доводиться змінювати структуру всієї БД, що спричиняє більші витрати часу.

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

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

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

У цей час поширені дві основні схеми реалізації багатомірного подання даних за допомогою реляційних таблиць: схема "зірка" і схема "сніжинка".Основними складовими таких схем є денормалізована таблиця фактів (Fact Table) і безліч таблиць вимірів (Dimension Tables).

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

  •  факти, пов'язані із транзакціями (Transaction facts). Вони засновані на окремих подіях (типовими прикладами яких є телефонний дзвінок або зняття грошей з рахунку за допомогою банкомата);
  •  факти, пов'язані з "моментальними знімками" (Snapshot facts). Засновані на стані об'єкта (наприклад, банківського рахунку) у певні моменти часу, наприклад на кінець дня або місяця. Типовими прикладами таких фактів є обсяг продажів за день або денний виторг;? факти, пов'язані з елементами документа (Line-item facts). Засновані на тім або іншому документі (наприклад, рахунку за товар або послуги) і містять докладну інформацію про елементи цього документа (наприклад, кількості, ціні, відсотку знижки);
  •  факти, пов'язані з подіями або станом об'єкта (Event or state facts). Представляють виникнення події без подробиць про нього (наприклад просто факт продажу або факт відсутності такий без інших подробиць).

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

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

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

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

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

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

Використання реляційних БД в OLAP-системах має наступні достоїнства:

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

Головний недолік ROLAP у порівнянні з багатомірними СУБД- менша продуктивність. Для забезпечення продуктивності, порівнянної з MOLAP, реляційні системи вимагають ретельного пророблення схеми бази даних і настроювання індексів, тобто більших зусиль із боку адміністраторів БД. Тільки при використанні схем типу "зірка" продуктивність добре настроєних реляційних систем може бути наближена до продуктивності систем на основі багатомірних баз даних.

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

2.4. Прийняття рішень у сфері матеріально-технічного забезпечення шахти

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

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

Логістика - наука про планування, організацію, керування й контролі руху матеріальних й інформаційних потоків у просторі й у часі від їхнього первинного джерела до кінцевого споживача [2, c. 74].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


3. Програмне забезпечення інформаційної системи

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

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

3.1.1. Концептуальне моделювання

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

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

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

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

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

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

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

Одна з найбільш популярних семантичних моделей даних - модель «сутність-зв'язок» (часто неї називають коротко ER-моделлю).

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

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

Малюнок 3.1 Діаграма «сутність-зв'язок»

3.1.2. Фізичне моделювання

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

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

Малюнок 3.2 Фізична модель даних

3.2. Побудова розмірностної моделі даних

Проектована система повинна являти собою СППР.

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

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

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

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

  •  інформаційно-пошуковий - СППР здійснює пошук необхідних даних. Характерною рисою такого аналізу є виконання заздалегідь певних запитів;
  •  оперативно-аналітичний – СППР провадить групування й узагальнення даних у будь-якому виді, необхідному аналітикові. На відміну від інформаційно-пошукового аналізу в цьому випадку неможливо заздалегідь пророчити необхідні аналітикові запити;
  •  інтелектуальний – СППР здійснює пошук функціональних і логічних закономірностей у накопичених даних, побудова моделей і правил, які пояснюють знайдені закономірності й/або (з певною ймовірністю) прогнозують розвиток деяких процесів [4, c. 71].

Розроблювальна СППР відноситься до типу оперативно-аналітичних СППР.

Дані СППР реалізовуються засобами OLAP-систем і багатомірного аналізу.

OLAP (On-Line Analytical Processing) - технологія оперативної аналітичної обробки даних, що використає методи й засоби для збору, зберігання й аналізу багатомірних даних з метою підтримки процесів прийняття рішень.

Основне призначення OLAP-систем - підтримка аналітичної діяльності, довільних (часто використається термін ad-hoc) запитів користувачів-аналітиків. Ціль OLAP-аналізу - перевірка виникаючих гіпотез.

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

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

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

Вимір - це послідовність значень одного з аналізованих параметрів. Наприклад, для параметра «час» це послідовність календарних днів, для параметра «регіон» це, наприклад, список міст.

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

По Кодду, багатомірне концептуальне подання (multi-dimensional conceptual view) - це множинна перспектива, що складається з декількох незалежних вимірів, уздовж яких можуть бути проаналізовані певні сукупності даних. Одночасний аналіз по декількох вимірах визначається як багатомірний аналіз.

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

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

Здійснимо побудову багатомірної моделі даних на підставі вимог до системи. Для вибору необхідної моделі розглянемо основні архітектури OLAP-систем.

OLAP-система містить у собі два основних компоненти:

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

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

MOLAP - для реалізації багатомірної моделі використають багатомірні БД;

ROLAP - для реалізації багатомірної моделі використають реляційні БД;

HOLAP - для реалізації багатомірної моделі використають і багатомірні й реляційні БД.

Тому що в розроблювальній системі не будуть використатися спеціальні OLAP-сервери, те обрана реалізація ROLAP.

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

СППР буде представляти наступну інформацію для аналізу ОПР:

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

3.3. Обґрунтування вибору алгоритму й інструментальних засобів аналізу даних

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

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

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

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

Для реалізації системи СППР для підприємства розроблений програмний продукт за допомогою середовища розробки Delphi і спеціальних компонентів Decision Cube, що входять до складу Delphi і реалізують OLAP-функціональність.

На сьогодні Delphi є одним з найпоширеніших засобів створення програм баз даних для корпоративних застосувань. Простота й природність мови, орієнтація системи на розробку саме такого роду програм, нарешті, ефективність (більша продуктивність і відносно невеликі розміри) створюваних з її допомогою програм зробили Delphi незамінними засобами розробки різного роду клієнтських місць, тобто програм для доступу до БД [29, c. 20].

Ще одним важливим перевагою системи програмування Delphi є її універсальність. Справа в тому, що багато сучасних мов і відповідні системи програмування створені для рішення вузькоспеціальних завдань. Так мова Cobol призначена в першу чергу для створення програм у галузі економіки, мова Fortran - для інженерно-технічних розрахунків, мови Lisp й Prolog - для роботи над системами штучного інтелекту й т.д. Система ж Delphi дозволяє створювати професійні й ефективно працюючі програми, використовувані у всіляких сферах людської діяльності [21, c. 8].

Decision Cube компанії Inprise поставляється як VCL-компонент. По нашій класифікації ставиться до ROLAP-компонентів, тобто містить у своєму складі OLAP-машину й призначений тільки для роботи з реляційними СУБД або локальними таблицями. Він відрізняється досить скромними можливостями. Наприклад, у ньому не можна відкрити один елемент виміру, або встановити фільтр по декількох вимірах, відобразити кілька фактів одночасно. Продуктивність компонента невисока. Межею є близько 4000 записів при 5 вимірах. Компонент відображає в таблиці одночасно тільки один факт. До достоїнств можна віднести простоту застосування й освоєння компонента. При правильному використанні й невеликих обсягах дані продукти на базі цього компонента можуть виявитися корисними й прийнятними по швидкодії.

3.4. Опис і порядок роботи із програмою

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

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

Малюнок 3.3. Програма СППР на прикладі вікна «Залишки»

У програмі дані відображаються за визначений користувачем період (місяць), по умовчанням поточний місяць. Вікно «Прихід» (малюнок 3.4) відповідає за внесення й зміну даних про прихід матеріалів. Вікно «Витрата» (малюнок 3.5) відповідає за внесення й зміну даних про прихід матеріалів. Вікно «Залишки» (малюнок 3.3) відповідає за перегляд і формування залишків матеріалів. Вікно «Довідники» (малюнок 3.6) відповідає за внесення й зміну даних про постачальників, споживачів, номенклатуру товарів.

Малюнок 3.4. Вікно «Прихід»

Малюнок 3.5. Вікно «Витрата»

Малюнок 3.6. Вікно «Довідники»

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

Малюнок 3.7 Вікно аналізу даних програми СППР

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

Таким чином, ОПР відкриває вікно програми «Залишки», провадить формування залишків за необхідний період, потім натискає кнопку «Аналіз», указує тимчасові рамки аналізу у відповідь на запит системи. Вибирає у верхній частині вікна виміру рік, місяць, товар, як міра «Витрата обсяг» і провадить зіставлення показників.


Висновок

У даній роботі розроблена СППР для шахти «Самсонівська-Західна». Інформаційна система ґрунтується на технології багатомірного OLAP-аналізу. Це дозволить ОПР підприємства оперувати максимально можливою кількістю параметрів системи для виявлення залежностей й аналізу.

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

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


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

  1.  Анализ хозяйственной деятельности в промышленности. / Под редакцией Стражева В.И. - М.: Высшая школа, 2001.
  2.  Аникин Б.А. Логистика: Учебник. – М.: ИНФРА-М, 2000. – 352 с.
  3.  Архангельский А.Я. Программирование в Delphi 7. – М.: ООО «Бином-Пресс», 2003 г. – 1152 с.
  4.  Барсегян А.А., Куприянов М.С., Степаненко В.В., Холод И. И. Методы и модели анализа данных: OLAP и Data Mining. – СпБ.: БХВ-Петербург, 2004 г. – 336 с.6 ил.
  5.  Бердникова Т. Б. Анализ и диагностика финансово-хозяйственной деятельности предприятия: Учеб. пособие. – М.: ИНФРА-М, 2007. – 215с.
  6.  Бухгалтерський облік у вугільної промисловості: Практ.посіб./За ред. Б94 В.В. Сопка, О.І. Шатохіної.- К.: Логос, 2004-.-410с.
  7.  Геловани В.Л., Башлыков А.А., Бритков В.Б., Вязилов Е.Д. Интеллектуальные системы поддержки принятия решений в нештатных ситуациях с использованием информации о состоянии природной среды. - М.: Эдиториал УРСС, 2001
  8.  Годин В.В., Корнеев И.К.. Информационное обеспечение управленческой деятельности. – М.: Высшая школа; Мастерство, 2001. - 239с.
  9.  Голубков Е.П. Основы маркетинга. –М.: ДИС, 2003. -56с.
  10.  Горев А., Макашарипов С., Ахаян Р. Эффективная работа с СУБД., 445 с.
  11.  Деордица Ю.С., Савченко В.Т. Компьютерные технологии в экономике и маркетинге. Учебное пособие.-Луганск: издательство ВУГУ, 1999.
  12.  Дорф Р., Бишоп Р. Современные системы управления. – М.: Лаб. Базовых Знаний: Юнимедстайл, 2002. – 832 с.
  13.  Информационные технологии управления: Учебное пособие /Под ред. Ю.М. Черкасова. – М.: ИНФРА-М, 2001. - 216 с.
  14.  Канке А. А., Кошевая И. П. Анализ финансово-хозяйственной деятельности предприятия: Учебное пособие. – 2-е изд., испр. и доп. – М.; ИД «ФОРУМ»; ИНФРА-М, 2007. – 288 с.
  15.  Карданская Н.Л. Принятие управленческих решений. – М.: Юнити, 1999. – 407 с.
  16.  Когаловский М.Р. Перспективные технологии информационных систем. – М.: ДМК Пресс; М.: Компания АйТи, 2003. – 288 с.
  17.  Козубенко В.А. Анализ хозяйственной деятельности угольной шахты: Учеб.пособие для техникумов.- 4-е изд., перераб. и доп. – М.: Недра, 2000г.-232с.
  18.  Корнеев И.К., Машурцев В.А. Информационные технологии в управлении. – М: ИНФРА-М, 2001. - 158 с.
  19.  Кэнту М. Delphi 7: Для профессионалов. – СПб.: Питер. 2004. – 1101 с.
  20.  Майкл Р. Линдерс, Харольд Е. Фирон. Управление снабжением и запасами. Логистика /Пер с англ.- СПб.: ООО «Изд-во Полигон», 1999.- 768с.
  21.  Пестриков В. М., Маслобоев Л. Н. Delphi на примерах. — СПб: БХВ-Пстербург, 2005. — 496 с: ил.
  22.  Практикум по теории управления: Учебное пособие /Под ред. Ю.В. Васильева, В. Н. Парахиной, Л. И. Ушвицкого. – 2-е изд., доп. – М.: Финансы и статистика, 2005. - 304 с: ил.
  23.  Принятие решений в организациях: Учеб. пособие /О.А.Кулагин.- СПб: Изд.дом "Сентябрь",2001.-98с.
  24.  Разработка управленческого решения: Учебное пособие / В.Б.Ременников. -М. .-ЮНИТИ-ДАНА, 2001 . -144с.
  25.  Рамазанов С.К., Гіркін Є.Й, Інтелектуальні   системи  та   теорія   прийняття   рішень.   Навчальне видання. - Луганськ: Вид-во СНУ, 2000.
  26.  Савицкая Г.В. Теория анализа хозяйственной деятельности: Учеб. пособие. – М.: ИНФРА-М, 2007. – 288 с.
  27.  Системи підтримки прийняття рішень. Під ред. д-ра екон. наук В.Ф.Ситника, К.: Техніка, 1995.
  28.  Смирнов Э. А. Разработка управленческих решений : Учебник для вузов. –М.: ЮНИТИ-ДАНА, 2000 - 162с.
  29.  Фаронов В.В., Шумаков П.В. Delphi 5. Руководство разработчика баз данных — М.: «Нолидж», 2000.
  30.  Чуев И.Н., Чуева Л.Н. Комплексный экономический анализ хозяйственной деятельности: Учебник для вузов. – М.: Издательско-торговая корпорация «Дашков и К°», 2006. – 368 с.
  31.  Шеремет А.Д. Комплексный анализ хозяйственной деятельности. – М,: ИНФРА-М, 2006. – 415с.
  32.  Эддоус М., Стенсфилд Р. Методы принятия решений. – М.: Аудит: ЮНИТИ, 1997. - 325с.
  33.  Эффективное принятие решений /Пер. с англ. – М.: Альпина Бизнес Букс, 2006. – 184 с.


Додатки



Додаток Б

Класифікація управлінських рішень


Додаток В

Програма OLAP-аналізу

unit UDM;

interface

uses

 SysUtils,Classes,Forms,ActnList, DB, DBTables, ADODB, MXDB, MXTABLES,

 Mxstore,Variants,Controls,Windows;

type

 TDMSklad = class(TDataModule)

   ALSklad: TActionList;

   ACOpenPrichod: TAction;

   DB1: TDatabase;

   QPrichod: TQuery;

   DSPrichod: TDataSource;

   QPostavshik: TQuery;

   DSPostavshik: TDataSource;

   QPrichodID: TIntegerField;

   QPrichodIDPostavshik: TIntegerField;

   QPrichodIDTovar: TIntegerField;

   QPrichodDYear: TStringField;

   QPrichodDMonth: TSmallintField;

   QPrichodDDay: TSmallintField;

   QPrichodCena: TFloatField;

   QPrichodKolvo: TFloatField;

   QPrichodSumma: TFloatField;

   QPrichodPostavshikNazv: TStringField;

   QTovar: TQuery;

   DSTovar: TDataSource;

   QPrichodTovarNazv: TStringField;

   ACIFormPrichod: TAction;

   ACOpenSprav: TAction;

   ACSelectSprav: TAction;

   DecisionCube1: TDecisionCube;

   DecisionQuery1: TDecisionQuery;

   DecisionSource1: TDecisionSource;

   ACOpenOlap: TAction;

   QRashod: TQuery;

   QOstatok: TQuery;

   DSRashod: TDataSource;

   DSOstatok: TDataSource;

   ACOpenRashod: TAction;

   QRashodID: TIntegerField;

   QRashodIDTovar: TIntegerField;

   QRashodDYear: TStringField;

   QRashodDMonth: TSmallintField;

   QRashodDDay: TSmallintField;

   QRashodCena: TFloatField;

   QRashodKolvo: TFloatField;

   QRashodSumma: TFloatField;

   QRashodTovarNazv: TStringField;

   ACOpenOstatok: TAction;

   ACIFormRashod: TAction;

   ACIFormOstatok: TAction;

   QOstatokID: TIntegerField;

   QOstatokDYear: TStringField;

   QOstatokDMonth: TSmallintField;

   QOstatokIDTovar: TIntegerField;

   QOstatokCena: TFloatField;

   QOstatokOst_n_kol: TFloatField;

   QOstatokOst_n_sum: TFloatField;

   QOstatokPrihod_kol: TFloatField;

   QOstatokPrihod_sum: TFloatField;

   QOstatokRashod_kol: TFloatField;

   QOstatokRashod_sum: TFloatField;

   QOstatokOst_k_kol: TFloatField;

   QOstatokOst_k_sum: TFloatField;

   QOstatokTovarNazv: TStringField;

   QForm: TQuery;

   QFormHelp: TQuery;

   ACFormOstatok: TAction;

   ACSetWorkPeriod: TAction;

   ACOpenPrihodQuery: TAction;

   ACOpenRashodQuery: TAction;

   ACOpenOstatokQuery: TAction;

   QPotrebitel: TQuery;

   DSPotrebitel: TDataSource;

   QRashodIDPotrebitel: TIntegerField;

   QRashodPotrebitelNazv: TStringField;

   procedure ACOpenPrichodExecute(Sender: TObject);

   procedure ACIFormPrichodExecute(Sender: TObject);

   procedure ACOpenSpravExecute(Sender: TObject);

   procedure ACSelectSpravExecute(Sender: TObject);

   procedure ACOpenOlapExecute(Sender: TObject);

   procedure ACOpenRashodExecute(Sender: TObject);

   procedure ACOpenOstatokExecute(Sender: TObject);

   procedure ACIFormRashodExecute(Sender: TObject);

   procedure ACIFormOstatokExecute(Sender: TObject);

   procedure ACFormOstatokExecute(Sender: TObject);

   procedure ACSetWorkPeriodExecute(Sender: TObject);

   procedure ACOpenPrihodQueryExecute(Sender: TObject);

   procedure ACOpenRashodQueryExecute(Sender: TObject);

   procedure ACOpenOstatokQueryExecute(Sender: TObject);

 private

   { Private declarations }

 public

   WorkYear:String[4];

   WorkMonth:byte;

   FormNum:byte;

   function IsConnection:boolean;

   { Public declarations }

 end;

var

 DMSklad: TDMSklad;

implementation

uses UFmPrichod, UFmMain, UFmSprav, Math, UOlap, UFmRashod, UFmOstatok,

 UFmPeriod, UFmPeriodAnaliz;

{$R *.dfm}

procedure TDMSklad.ACOpenPrichodExecute(Sender: TObject);

begin

 if  Assigned(FmPrichod) then

   FmPrichod.Show

 else

 begin

   FmPrichod:=TFmPrichod.Create(Application);

   DMSklad.ACOpenPrihodQuery.Execute;

   DMSklad.ACIFormPrichod.Execute;

   FmPrichod.WindowState:=wsMaximized;

   FmPrichod.Show;

 end;

 FormNum:=0;

end;

procedure TDMSklad.ACIFormPrichodExecute(Sender: TObject);

begin

 FmPrichod.DBGRashod.Columns[1].Title.Caption:='Год';

 FmPrichod.DBGRashod.Columns[2].Title.Caption:='Месяц';

 FmPrichod.DBGRashod.Columns[3].Title.Caption:='День';

 FmPrichod.DBGRashod.Columns[5].Title.Caption:='Поставщик';

 FmPrichod.DBGRashod.Columns[6].Title.Caption:='Ном. №';

 FmPrichod.DBGRashod.Columns[7].Title.Caption:='Товар';

 FmPrichod.DBGRashod.Columns[8].Title.Caption:='Цена';

 FmPrichod.DBGRashod.Columns[9].Title.Caption:='Кол-во';

 FmPrichod.DBGRashod.Columns[10].Title.Caption:='Сумма';

end;

procedure TDMSklad.ACOpenSpravExecute(Sender: TObject);

begin

 if Assigned(FmSprav) then

   FmSprav.Show

 else

 begin

   FmSprav:=TFmSprav.Create(Application);

   FmSprav.WindowState:=wsMaximized;

   FmSprav.Show;

 end;

end;

procedure TDMSklad.ACSelectSpravExecute(Sender: TObject);

begin

 if FmSprav.TRVSprav.Selected.AbsoluteIndex<>-1 then

   case FmSprav.TRVSprav.Selected.AbsoluteIndex of

     0:begin

         FmSprav.DBGSprav.DataSource:=DSPostavshik;

         FmSprav.DBNSprav.DataSource:=DSPostavshik;

         FmSprav.DBGSprav.Columns[0].Title.Caption:='Код';

         FmSprav.DBGSprav.Columns[1].Title.Caption:='Наименование';

         FmSprav.DBGSprav.Columns[0].Width:=60;

         FmSprav.DBGSprav.Columns[1].Width:=500;

       end;

     1:begin

         FmSprav.DBGSprav.DataSource:=DSTovar;

         FmSprav.DBNSprav.DataSource:=DSTovar;

         FmSprav.DBGSprav.Columns[0].Title.Caption:='Код';

         FmSprav.DBGSprav.Columns[1].Title.Caption:='Наименование';

         FmSprav.DBGSprav.Columns[0].Width:=60;

         FmSprav.DBGSprav.Columns[1].Width:=500;

       end;

    2:begin

         FmSprav.DBGSprav.DataSource:=DSPotrebitel;

         FmSprav.DBNSprav.DataSource:=DSPotrebitel;

         FmSprav.DBGSprav.Columns[0].Title.Caption:='Код';

         FmSprav.DBGSprav.Columns[1].Title.Caption:='Наименование';

         FmSprav.DBGSprav.Columns[0].Width:=60;

         FmSprav.DBGSprav.Columns[1].Width:=500;

       end;

       else

       begin

         FmSprav.DBGSprav.DataSource:=nil;

         FmSprav.DBNSprav.DataSource:=nil;

       end;

   end;

end;

procedure TDMSklad.ACOpenOlapExecute(Sender: TObject);

begin

 FmPeriodAnaliz.ShowModal;

 if FmPeriodAnaliz.ModalResult<>mrOk then

   Exit;

 FmOlap:=TFmOlap.Create(Application);

 FmOlap.DecisionGrid1.DecisionSource:=nil;

 DecisionQuery1.SQL.Clear;

 case FormNum of

 0:begin

     DecisionQuery1.SQL.Add('SELECT Tovar.Nazv,Prichod.DYear,Prichod.DMonth,Prichod.DDay,Postavshik.Nazv, Tovar.Nazv,Prichod.Cena,SUM(Prichod.Kolvo),COUNT(*),SUM(summa)');

     DecisionQuery1.SQL.Add('FROM ((Prichod');

     DecisionQuery1.SQL.Add('   LEFT  JOIN Postavshik');

     DecisionQuery1.SQL.Add('   ON  (Prichod.idPostavshik = Postavshik.id))');

     DecisionQuery1.SQL.Add('   LEFT  JOIN Tovar');

     DecisionQuery1.SQL.Add('   ON  (Prichod.idTovar = Tovar.id))');

     DecisionQuery1.SQL.Add('where Prichod.DYear>='+#39+FmPeriodAnaliz.YearS+#39+' and '+'Prichod.DYear<='+#39+FmPeriodAnaliz.YearPo+#39);

     //' and '+'Prichod.DMonth>='+inttostr(FmPeriodAnaliz.MonthS)+')');

     //  +' and '+'(('+'Prichod.DYear<='+#39+FmPeriodAnaliz.YearPo+#39+') and ('+'Prichod.DMonth<='+inttostr(FmPeriodAnaliz.MonthPo)+'))');

     DecisionQuery1.SQL.Add('GROUP BY Tovar.Nazv,Prichod.DYear,Prichod.DMonth,Prichod.DDay,Postavshik.Nazv,Tovar.Nazv,Prichod.Cena');

   end;

 1:begin

     DecisionQuery1.SQL.Add('SELECT Tovar.Nazv,Rashod.DYear,Rashod.DMonth,Rashod.DDay,Potrebitel.Nazv,Tovar.Nazv,Rashod.Cena,SUM(Rashod.Kolvo),COUNT(*),SUM(summa)');

     DecisionQuery1.SQL.Add('FROM (Rashod');

     DecisionQuery1.SQL.Add('   LEFT  JOIN Potrebitel');

     DecisionQuery1.SQL.Add('   ON  (Rashod.IDPotrebitel = Potrebitel.ID))');

     DecisionQuery1.SQL.Add('   LEFT  JOIN Tovar');

     DecisionQuery1.SQL.Add('   ON  (Rashod.idTovar = Tovar.id)');

     DecisionQuery1.SQL.Add('where Rashod.DYear>='+#39+FmPeriodAnaliz.YearS+#39+' and '+'Rashod.DYear<='+#39+FmPeriodAnaliz.YearPo+#39);

     DecisionQuery1.SQL.Add('GROUP BY Tovar.Nazv,Rashod.DYear,Rashod.DMonth,Rashod.DDay,Potrebitel.Nazv,Tovar.Nazv,Rashod.Cena');

   end;

 2:begin

     DecisionQuery1.SQL.Add('SELECT   Tovar.Nazv,Ostatok.DYear,Ostatok.DMonth,Tovar.Nazv,Ostatok.Cena,');

     DecisionQuery1.SQL.Add('SUM(Prihod_kol),SUM(Prihod_sum),SUM(Rashod_kol),SUM(Rashod_sum),SUM(Ostatok.Ost_k_kol),SUM(Ostatok.Ost_k_sum)');

     DecisionQuery1.SQL.Add('FROM Ostatok');

     DecisionQuery1.SQL.Add('   LEFT  JOIN Tovar');

     DecisionQuery1.SQL.Add('   ON  (Ostatok.idTovar = Tovar.id)');

     DecisionQuery1.SQL.Add('where Ostatok.DYear>='+#39+FmPeriodAnaliz.YearS+#39+' and '+'Ostatok.DYear<='+#39+FmPeriodAnaliz.YearPo+#39);

     DecisionQuery1.SQL.Add('GROUP BY Tovar.Nazv,Ostatok.DYear,Ostatok.DMonth,Tovar.Nazv,Ostatok.Cena');

   end;

 end;

//  FmMain.Memo1.Lines.Text:=DecisionQuery1.SQL.GetText;

 DecisionQuery1.Open;

 case FormNum of

 0:begin

     DecisionCube1.DimensionMap.Items[0].Name:='Товар';

     DecisionCube1.DimensionMap.Items[1].Name:='Год';

     DecisionCube1.DimensionMap.Items[2].Name:='Месяц';

     DecisionCube1.DimensionMap.Items[3].Name:='День';

     DecisionCube1.DimensionMap.Items[4].Name:='Поставщик';

     DecisionCube1.DimensionMap.Items[5].Name:='Товар';

     DecisionCube1.DimensionMap.Items[6].Name:='Цена';

     DecisionCube1.DimensionMap.Items[7].Name:='Объемы поставок ';

     DecisionCube1.DimensionMap.Items[8].Name:='Кол-во поставок';

     DecisionCube1.DimensionMap.Items[9].Name:='Суммы поставок';

   end;

 1:begin

     DecisionCube1.DimensionMap.Items[0].Name:='Товар';

     DecisionCube1.DimensionMap.Items[1].Name:='Год';

     DecisionCube1.DimensionMap.Items[2].Name:='Месяц';

     DecisionCube1.DimensionMap.Items[3].Name:='День';

     DecisionCube1.DimensionMap.Items[4].Name:='Потребитель';

     DecisionCube1.DimensionMap.Items[5].Name:='Товар';

     DecisionCube1.DimensionMap.Items[6].Name:='Цена';

     DecisionCube1.DimensionMap.Items[7].Name:='Объемы потребления ';

     DecisionCube1.DimensionMap.Items[8].Name:='Кол-во потребления';

     DecisionCube1.DimensionMap.Items[9].Name:='Суммы потребления';

   end;

 2:begin

     DecisionCube1.DimensionMap.Items[0].Name:='Товар';

     DecisionCube1.DimensionMap.Items[1].Name:='Год';

     DecisionCube1.DimensionMap.Items[2].Name:='Месяц';

     DecisionCube1.DimensionMap.Items[3].Name:='Товар';

     DecisionCube1.DimensionMap.Items[4].Name:='Цена';

     DecisionCube1.DimensionMap.Items[5].Name:='Приход объем';

     DecisionCube1.DimensionMap.Items[6].Name:='Приход суммы';

     DecisionCube1.DimensionMap.Items[7].Name:='Расход объем';

     DecisionCube1.DimensionMap.Items[8].Name:='Расход суммы';

     DecisionCube1.DimensionMap.Items[9].Name:='Остатки объем';

     DecisionCube1.DimensionMap.Items[10].Name:='Остатки суммы';

    end;

 end;

 FmOlap.DecisionGrid1.DecisionSource:=DecisionSource1;

 FmOlap.WindowState:=wsMaximized;

 FmOlap.ShowModal;

 FreeAndNil(FmOlap);

 DecisionQuery1.Close;

end;

procedure TDMSklad.ACOpenRashodExecute(Sender: TObject);

begin

 if  Assigned(FmRashod) then

   FmRashod.Show

 else

 begin

   FmRashod:=TFmRashod.Create(Application);

   ACOpenRashodQuery.Execute;

   DMSklad.ACIFormRashod.Execute;

   FmRashod.WindowState:=wsMaximized;

   FmRashod.Show;

 end;

 FormNum:=1;

end;

procedure TDMSklad.ACOpenOstatokExecute(Sender: TObject);

begin

 if  Assigned(FmOstatok) then

   FmOstatok.Show

 else

 begin

   FmOstatok:=TFmOstatok.Create(Application);

   ACOpenOstatokQuery.Execute;

   DMSklad.ACIFormOstatok.Execute;

   FmOstatok.WindowState:=wsMaximized;

   FmOstatok.Show;

 end;

 FormNum:=2;

end;

procedure TDMSklad.ACIFormRashodExecute(Sender: TObject);

begin

 FmRashod.DBGPrichod.Columns[1].Title.Caption:='Год';

 FmRashod.DBGPrichod.Columns[2].Title.Caption:='Месяц';

 FmRashod.DBGPrichod.Columns[3].Title.Caption:='День';

 FmRashod.DBGPrichod.Columns[4].Title.Caption:='Потребитель';

 FmRashod.DBGPrichod.Columns[5].Title.Caption:='Ном. №';

 FmRashod.DBGPrichod.Columns[6].Title.Caption:='Товар';

 FmRashod.DBGPrichod.Columns[7].Title.Caption:='Цена';

 FmRashod.DBGPrichod.Columns[8].Title.Caption:='Кол-во';

 FmRashod.DBGPrichod.Columns[9].Title.Caption:='Сумма';

end;

procedure TDMSklad.ACIFormOstatokExecute(Sender: TObject);

begin

 FmOstatok.DBGPrichod.Columns[1].Title.Caption:='Год';

 FmOstatok.DBGPrichod.Columns[2].Title.Caption:='Месяц';

 FmOstatok.DBGPrichod.Columns[3].Title.Caption:='Ном. №';

 FmOstatok.DBGPrichod.Columns[4].Title.Caption:='Товар';

 FmOstatok.DBGPrichod.Columns[5].Title.Caption:='Цена';

 FmOstatok.DBGPrichod.Columns[6].Title.Caption:='ОстНКол';

 FmOstatok.DBGPrichod.Columns[7].Title.Caption:='ОстНСум';

 FmOstatok.DBGPrichod.Columns[8].Title.Caption:='ПрКол';

 FmOstatok.DBGPrichod.Columns[9].Title.Caption:='ПрСум';

 FmOstatok.DBGPrichod.Columns[10].Title.Caption:='РасКол';

 FmOstatok.DBGPrichod.Columns[11].Title.Caption:='РасСум';

 FmOstatok.DBGPrichod.Columns[12].Title.Caption:='ОстККол';

 FmOstatok.DBGPrichod.Columns[13].Title.Caption:='ОстКСум';

end;

procedure TDMSklad.ACFormOstatokExecute(Sender: TObject);

var

Year:string[4];

YearPrev:string[4];

Month:byte;

MonthPrev:byte;

begin

 FmPeriod.ShowModal;

 if FmPeriod.ModalResult=mrOk then

 begin

   Month:=FmPeriod.Month;

   Year:=FmPeriod.Year;

 end

 else

   Exit;

 if Month<>1 then

 begin

   MonthPrev:=Month-1;

   YearPrev:=Year;

 end

 else

 begin

   MonthPrev:=12;

   YearPrev:=inttostr(strtoint(Year)-1);

 end;

 QFormHelp.Close;

 QFormHelp.SQL.Clear;

 QFormHelp.SQL.Add('select * from Ostatok');

 QFormHelp.SQL.Add('where DYear='+#39+YearPrev+#39+' and DMonth='+inttostr(MonthPrev));

 QFormHelp.Open;

 QForm.Close;

 QForm.SQL.Clear;

 QForm.SQL.Add('select * from Ostatok');

 QForm.SQL.Add('where DYear='+#39+Year+#39+' and DMonth='+inttostr(Month));

 QForm.Open;

 QFormHelp.First;

 while not QFormHelp.Eof do

 begin

   if QForm.Locate('IDTovar;Cena',VarArrayOf([QFormHelp.FieldByName('IDTovar').AsInteger,

     QFormHelp.FieldByName('Cena').AsFloat]),[]) then

   begin

     QForm.Edit;

     QForm.FieldByName('Ost_n_kol').AsString:=QFormHelp.FieldByName('Ost_k_kol').AsString;

     QForm.FieldByName('Ost_n_sum').AsString:=QFormHelp.FieldByName('Ost_k_sum').AsString;

     QForm.Post;

   end

   else

   begin

     QForm.Insert;

     QForm.FieldByName('DYear').AsString:=Year;

     QForm.FieldByName('DMonth').AsInteger:=Month;

     QForm.FieldByName('IDTovar').AsInteger:=QFormHelp.FieldByName('IDTovar').AsInteger;;

     QForm.FieldByName('Cena').AsString:=QFormHelp.FieldByName('Cena').AsString;;

     QForm.FieldByName('Ost_n_kol').AsString:=QFormHelp.FieldByName('Ost_k_kol').AsString;

     QForm.FieldByName('Ost_n_sum').AsString:=QFormHelp.FieldByName('Ost_k_sum').AsString;

     QForm.Post;

   end;

   QFormHelp.Next;

 end;

 QFormHelp.Close;

 QFormHelp.SQL.Clear;

 QFormHelp.SQL.Add('select DYear,DMonth,IDTovar,Cena,sum(Kolvo) as SumKolvo,sum(Summa) as SumSumma from Prichod');

 QFormHelp.SQL.Add('where DYear='+#39+Year+#39+' and DMonth='+inttostr(Month));

 QFormHelp.SQL.Add('Group By DYear,DMonth,IDTovar,Cena');

 QFormHelp.Open;

 QForm.Close;

 QForm.Open;

 QFormHelp.First;

 while not QFormHelp.Eof do

 begin

   if QForm.Locate('IDTovar;Cena',VarArrayOf([QFormHelp.FieldByName('IDTovar').AsInteger,

     QFormHelp.FieldByName('Cena').AsFloat]),[]) then

   begin

     QForm.Edit;

     QForm.FieldByName('Prihod_kol').AsString:=QFormHelp.FieldByName('SumKolvo').AsString;

     QForm.FieldByName('Prihod_sum').AsString:=QFormHelp.FieldByName('SumSumma').AsString;

     QForm.Post;

   end

   else

   begin

     QForm.Insert;

     QForm.FieldByName('DYear').AsString:=Year;

     QForm.FieldByName('DMonth').AsInteger:=Month;

     QForm.FieldByName('IDTovar').AsInteger:=QFormHelp.FieldByName('IDTovar').AsInteger;;

     QForm.FieldByName('Cena').AsString:=QFormHelp.FieldByName('Cena').AsString;;

     QForm.FieldByName('Prihod_kol').AsString:=QFormHelp.FieldByName('SumKolvo').AsString;

     QForm.FieldByName('Prihod_sum').AsString:=QFormHelp.FieldByName('SumSumma').AsString;

     QForm.Post;

   end;

   QFormHelp.Next;

 end;

 QFormHelp.Close;

 QFormHelp.SQL.Clear;

 QFormHelp.SQL.Add('select DYear,DMonth,IDTovar,Cena,sum(Kolvo) as SumKolvo,sum(Summa) as SumSumma from Rashod');

 QFormHelp.SQL.Add('where DYear='+#39+Year+#39+' and DMonth='+inttostr(Month));

 QFormHelp.SQL.Add('Group By DYear,DMonth,IDTovar,Cena');

 QFormHelp.Open;

 QForm.Close;

 QForm.Open;

 QFormHelp.First;

 while not QFormHelp.Eof do

 begin

   if QForm.Locate('IDTovar;Cena',VarArrayOf([QFormHelp.FieldByName('IDTovar').AsInteger,

     QFormHelp.FieldByName('Cena').AsFloat]),[]) then

   begin

     QForm.Edit;

     QForm.FieldByName('Rashod_kol').AsString:=QFormHelp.FieldByName('SumKolvo').AsString;

     QForm.FieldByName('Rashod_sum').AsString:=QFormHelp.FieldByName('SumSumma').AsString;

     QForm.Post;

   end

   else

   begin

     QForm.Insert;

     QForm.FieldByName('DYear').AsString:=Year;

     QForm.FieldByName('DMonth').AsInteger:=Month;

     QForm.FieldByName('IDTovar').AsInteger:=QFormHelp.FieldByName('IDTovar').AsInteger;;

     QForm.FieldByName('Cena').AsString:=QFormHelp.FieldByName('Cena').AsString;

     QForm.FieldByName('Rashod_kol').AsString:=QFormHelp.FieldByName('SumKolvo').AsString;

     QForm.FieldByName('Rashod_sum').AsString:=QFormHelp.FieldByName('SumSumma').AsString;

     QForm.Post;

   end;

   QFormHelp.Next;

 end;

 QFormHelp.Close;

 QForm.Open;

 QForm.First;

 while not QForm.Eof do

 begin

   QForm.Edit;

   QForm.FieldByName('Ost_k_kol').AsFloat:=QForm.FieldByName('Ost_n_kol').AsFloat+

     QForm.FieldByName('Prihod_kol').AsFloat-QForm.FieldByName('Rashod_kol').AsFloat;

   QForm.FieldByName('Ost_k_sum').AsFloat:=QForm.FieldByName('Ost_n_sum').AsFloat+

     QForm.FieldByName('Prihod_sum').AsFloat-QForm.FieldByName('Rashod_sum').AsFloat;

   QForm.Post;

   QForm.Next;

 end;

 QForm.Close;

 QOstatok.Close;

 QOstatok.Open;

{  FmOstatok.DBGPrichod.Columns.Clear;

 DSOstatok.DataSet:=QFormHelp;}

end;

procedure TDMSklad.ACSetWorkPeriodExecute(Sender: TObject);

begin

 FmPeriod.ShowModal;

 if FmPeriod.ModalResult=mrOk then

 begin

   WorkMonth:=FmPeriod.Month;

   WorkYear:=FmPeriod.Year;

   ACOpenPrihodQuery.Execute;

   ACOpenRashodQuery.Execute;

   ACOpenOstatokQuery.Execute;

 end;

end;

procedure TDMSklad.ACOpenPrihodQueryExecute(Sender: TObject);

begin

 QPrichod.Close;

 QPrichod.SQL.Clear;

 QPrichod.SQL.Add('select * from Prichod');

 QPrichod.SQL.Add('where DYear='+#39+WorkYear+#39+' and DMonth='+inttostr(WorkMonth));

 QPrichod.Open;

end;

procedure TDMSklad.ACOpenRashodQueryExecute(Sender: TObject);

begin

 QRashod.Close;

 QRashod.SQL.Clear;

 QRashod.SQL.Add('select * from Rashod');

 QRashod.SQL.Add('where DYear='+#39+WorkYear+#39+' and DMonth='+inttostr(WorkMonth));

 QRashod.Open;

end;

procedure TDMSklad.ACOpenOstatokQueryExecute(Sender: TObject);

begin

 QOstatok.Close;

 QOstatok.ParamByName('Year').AsString:=WorkYear;

 QOstatok.ParamByName('Month').AsInteger:=WorkMonth;

 QOstatok.Open;

end;

function TDMSklad.IsConnection: boolean;

begin

 Result:=true;

 try

   DB1.Connected:=true;

 except

   Result:=false;

   MessageBox(Application.Handle,'Ошибка соединения с БД'+#13+'Убедитесь что установлен BDE'+

   #13+'и настроен драйвер ODBC'+#13+'Подробности в Инструкции но настройке','Ошибка',MB_OK+MB_ICONERROR);

 end;

end;

end.

unit UFmMain;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, ComCtrls, Menus, ToolWin,DateUtils, StdCtrls;

type

 TFmMain = class(TForm)

   MainMenu1: TMainMenu;

   StatusBar1: TStatusBar;

   Punkt11: TMenuItem;

   N1: TMenuItem;

   N2: TMenuItem;

   N3: TMenuItem;

   N4: TMenuItem;

   ToolBar1: TToolBar;

   ToolButton1: TToolButton;

   ToolButton2: TToolButton;

   ToolButton3: TToolButton;

   ToolButton4: TToolButton;

   N5: TMenuItem;

   N6: TMenuItem;

   procedure FormShow(Sender: TObject);

 private

   { Private declarations }

 public

   { Public declarations }

 end;

var

 FmMain: TFmMain;

implementation

uses UDM;

{$R *.dfm}

procedure TFmMain.FormShow(Sender: TObject);

begin

 DMSklad.WorkYear:=inttostr(YearOf(Now));

 DMSklad.WorkMonth:=MonthOf(Now);

 DMSklad.ACOpenPrichod.Execute;

end;

end.

unit UFmOstatok;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, ExtCtrls, DBCtrls, ToolWin, ComCtrls, Grids, DBGrids;

type

 TFmOstatok = class(TForm)

   DBGPrichod: TDBGrid;

   ToolBar1: TToolBar;

   DBNavigator1: TDBNavigator;

   ToolButton1: TToolButton;

   ToolButton2: TToolButton;

   procedure FormClose(Sender: TObject; var Action: TCloseAction);

 private

   { Private declarations }

 public

   { Public declarations }

 end;

var

 FmOstatok: TFmOstatok;

implementation

uses UDM;

{$R *.dfm}

procedure TFmOstatok.FormClose(Sender: TObject; var Action: TCloseAction);

begin

 Action:=cafree;

 FmOstatok:=nil;

end;

end.

unit UFmPeriod;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, StdCtrls;

type

 TFmPeriod = class(TForm)

   Label1: TLabel;

   Label2: TLabel;

   Edit1: TEdit;

   Edit2: TEdit;

   Button1: TButton;

   Button2: TButton;

   procedure Button1Click(Sender: TObject);

   procedure Button2Click(Sender: TObject);

   procedure FormShow(Sender: TObject);

 private

   { Private declarations }

 public

   Year:string[4];

   Month:byte;

   { Public declarations }

 end;

var

 FmPeriod: TFmPeriod;

implementation

uses UDM;

{$R *.dfm}

procedure TFmPeriod.Button1Click(Sender: TObject);

begin

 Year:=trim(Edit1.Text);

 Month:=strtoint(Edit2.Text);

 ModalResult:=mrOk;

end;

procedure TFmPeriod.Button2Click(Sender: TObject);

begin

 ModalResult:=mrCancel;

end;

procedure TFmPeriod.FormShow(Sender: TObject);

begin

 Edit1.Text:=DMSklad.WorkYear;

 Edit2.Text:=inttostr(DMSklad.WorkMonth);

 Edit1.SetFocus;

end;

end.

unit UFmPeriodAnaliz;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, StdCtrls,DateUtils;

type

 TFmPeriodAnaliz = class(TForm)

   Label1: TLabel;

   Label2: TLabel;

   Edit1: TEdit;

   Edit2: TEdit;

   Button1: TButton;

   Button2: TButton;

   Label5: TLabel;

   Label6: TLabel;

   Edit3: TEdit;

   Edit4: TEdit;

   procedure Button1Click(Sender: TObject);

   procedure Button2Click(Sender: TObject);

   procedure FormShow(Sender: TObject);

 private

   { Private declarations }

 public

   YearS:string[4];

   MonthS:byte;

   YearPo:string[4];

   MonthPo:byte;

   { Public declarations }

 end;

var

 FmPeriodAnaliz: TFmPeriodAnaliz;

implementation

uses UDM;

{$R *.dfm}

procedure TFmPeriodAnaliz.Button1Click(Sender: TObject);

begin

 YearS:=trim(Edit1.Text);

 MonthS:=strtoint(Edit2.Text);

 YearPo:=trim(Edit3.Text);

 MonthPo:=strtoint(Edit4.Text);

 ModalResult:=mrOk;

end;

procedure TFmPeriodAnaliz.Button2Click(Sender: TObject);

begin

 ModalResult:=mrCancel;

end;

procedure TFmPeriodAnaliz.FormShow(Sender: TObject);

begin

 Edit1.Text:='1900';

 Edit2.Text:='1';

 Edit3.Text:=inttostr(YearOf(Now));

 Edit4.Text:=inttostr(MonthOf(Now));

 Edit1.SetFocus;

end;

end.

unit UFmPrichod;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, ExtCtrls, DBCtrls, ToolWin, ComCtrls, Grids, DBGrids;

type

 TFmPrichod = class(TForm)

   DBGRashod: TDBGrid;

   ToolBar1: TToolBar;

   ToolButton1: TToolButton;

   DBNavigator1: TDBNavigator;

   ToolButton3: TToolButton;

   procedure FormClose(Sender: TObject; var Action: TCloseAction);

 private

   { Private declarations }

 public

   { Public declarations }

 end;

var

 FmPrichod: TFmPrichod;

implementation

uses UDM;

{$R *.dfm}

procedure TFmPrichod.FormClose(Sender: TObject; var Action: TCloseAction);

begin

 Action:=cafree;

 FmPrichod:=nil;

end;

end.

unit UFmRashod;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, ExtCtrls, DBCtrls, ToolWin, ComCtrls, Grids, DBGrids;

type

 TFmRashod = class(TForm)

   DBGPrichod: TDBGrid;

   ToolBar1: TToolBar;

   ToolButton1: TToolButton;

   ToolButton3: TToolButton;

   DBNavigator1: TDBNavigator;

   procedure FormClose(Sender: TObject; var Action: TCloseAction);

   procedure ToolButton1Click(Sender: TObject);

 private

   { Private declarations }

 public

   { Public declarations }

 end;

var

 FmRashod: TFmRashod;

implementation

uses UDM;

{$R *.dfm}

procedure TFmRashod.FormClose(Sender: TObject; var Action: TCloseAction);

begin

 Action:=cafree;

 FmRashod:=nil;

end;

procedure TFmRashod.ToolButton1Click(Sender: TObject);

begin

 DMSklad.QRashod.ApplyUpdates;

end;

end.

unit UFmSprav;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, ExtCtrls, ToolWin, ComCtrls, DBCtrls, Grids, DBGrids, StdCtrls;

type

 TFmSprav = class(TForm)

   ToolBar1: TToolBar;

   Panel1: TPanel;

   DBGSprav: TDBGrid;

   DBNSprav: TDBNavigator;

   TRVSprav: TTreeView;

   procedure FormClose(Sender: TObject; var Action: TCloseAction);

   procedure TRVSpravClick(Sender: TObject);

 private

   { Private declarations }

 public

   { Public declarations }

 end;

var

 FmSprav: TFmSprav;

implementation

uses UDM;

{$R *.dfm}

procedure TFmSprav.FormClose(Sender: TObject; var Action: TCloseAction);

begin

 Action:=cafree;

 FmSprav:=nil;

end;

procedure TFmSprav.TRVSpravClick(Sender: TObject);

begin

 DMSklad.ACSelectSprav.Execute;

end;

end.

unit UOlap;

interface

uses

 Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

 Dialogs, DB, ADODB, Mxstore, MXDB, DBTables, MXTABLES, Grids, MXGRID,

 StdCtrls, ExtCtrls, MXPIVSRC;

type

 TFmOlap = class(TForm)

   DecisionGrid1: TDecisionGrid;

   DecisionPivot1: TDecisionPivot;

   procedure Button1Click(Sender: TObject);

 private

   { Private declarations }

 public

   { Public declarations }

 end;

var

 FmOlap: TFmOlap;

implementation

uses MXCOMMON, UDM, DateUtils;

{$R *.dfm}

procedure TFmOlap.Button1Click(Sender: TObject);

begin

 with DMSklad do

 begin

   DecisionGrid1.DecisionSource:=nil;

   DecisionQuery1.SQL.Clear;

   DecisionQuery1.SQL.Add('SELECT Tovar.Nazv,Prichod.DYear,Prichod.DMonth,Prichod.DDay,Postavshik.Nazv, Tovar.Nazv,Prichod.Cena,SUM(Prichod.Kolvo),COUNT(*),SUM(summa)');

   DecisionQuery1.SQL.Add('FROM ((Prichod');

   DecisionQuery1.SQL.Add('   LEFT  JOIN Postavshik');

   DecisionQuery1.SQL.Add('   ON  (Prichod.idPostavshik = Postavshik.id))');

   DecisionQuery1.SQL.Add('   LEFT  JOIN Tovar');

   DecisionQuery1.SQL.Add('   ON  (Prichod.idTovar = Tovar.id))');

   DecisionQuery1.SQL.Add('GROUP BY Tovar.Nazv,Prichod.DYear,Prichod.DMonth,Prichod.DDay,Postavshik.Nazv,Tovar.Nazv,Prichod.Cena');

   DecisionQuery1.Open;

   DecisionCube1.DimensionMap.Items[0].Name:='Товар';

   DecisionCube1.DimensionMap.Items[1].Name:='Год';

   DecisionCube1.DimensionMap.Items[2].Name:='Месяц';

   DecisionCube1.DimensionMap.Items[3].Name:='День';

   DecisionCube1.DimensionMap.Items[4].Name:='Поставщик';

   DecisionCube1.DimensionMap.Items[5].Name:='Товар';

   DecisionCube1.DimensionMap.Items[6].Name:='Цена';

   DecisionCube1.DimensionMap.Items[7].Name:='Объемы поставок ';

   DecisionCube1.DimensionMap.Items[8].Name:='Кол-во поставок';

   DecisionCube1.DimensionMap.Items[9].Name:='Суммы поставок';

   DecisionGrid1.DecisionSource:=DecisionSource1;

 end;

end;

end.

PAGE  104


 

А также другие работы, которые могут Вас заинтересовать

19531. Определение настроек регулятора методом незатухающих колебаний 36.5 KB
  Определение настроек регулятора методом незатухающих колебаний. Суть метода заключается в нахождении критической настройками П – регулятора при которой в замкнутой системе устанавливаются не затухающие колебания то есть система находится на границе устойчивости. На ...
19532. Цифровая обработка сигналов. Основные понятия 608.07 KB
  Лекция 1.Цифровая обработка сигналов. Основные понятия Введение В настоящее время методы цифровой обработки сигналов digital signal processing DSP находят все более широкое применение вытесняя постепенно методы основанные на аналоговой обработке. В данном курсе рассматрива...
19533. Преобразование Фурье и обобщенные функции 641.26 KB
  2 Лекция 2. Преобразование Фурье и обобщенные функции Вспомогательные утверждения Лемма. Справедлива формула 1 Доказательство. Хотя формула 1 хорошо известна мы приведем ее доказательство поскольку она является основой многих дальнейших выкл...
19534. Восстановление дискретного сигнала 146.5 KB
  Лекция 3 Восстановление дискретного сигнала Наша цель найти необходимые условия при которых сигнал может быть восстановлен по дискретной выборке Прежде всего отметим часто часто используемый факт: Преобразование Фурье от последовательности Пусть имеется сиг...
19535. Дискретное преобразование Фурье (ДПФ) 487.85 KB
  2 Лекция 4. Дискретное преобразование Фурье ДПФ В данной лекции установим свойства дискретного преобразования Фурье аналогичные свойствам непрерывного преобразования. Как обычно преобразования типа почленного интегрирования ряда перестановки порядка с
19536. Цифровые фильтры. Основные понятия 489.7 KB
  2 Лекция 5. Цифровые фильтры. Основные понятия Цифровые фильтры являются частным случаем линейных инвариантных систем. Существенное ограничение связано с физической реализуемостью системы. Определение. Система называется физически реализуемой если сигн...
19537. Z-преобразование. Фильтры первого порядка 192.23 KB
  2 Лекция 6. Zпреобразование. Фильтры первого порядка Zпреобразование Иногда вместо преобразования Фурье используют Zпреобразование. Оно определяется формулой 1 В формуле 1 ряд является формальным если же он сходится то определяет аналитическую ф...
19538. Фильтры второго и высших порядков 452.79 KB
  1 Лекция 7. Фильтры второго и высших порядков Определение фильтра второго порядка Примером фильтра вторго порядка является фильтр . Рассматриваем только вещественный случай. Переходя к Z преобразованию получим: . Найдя корни многочлена в знаменателе пере
19539. Фильтры Баттеруорта 297.97 KB
  2 Лекция 8. Фильтры Баттеруорта Отыскание параметров фильтра В левой и правой частях в знаменателе находятся многочлены от переменной z. Найдем корни этих многочленов. Множество корней по построению инвариантно относительно замены . Для устойчивости фильтр...