База даних і система управління базою даних у СППР

Вимога мінімізаціїї надлишковості полягає у мінімальній кількості копій для одних і тих же даних з урахуванням орієнтації на кілька застосувань. Ці надлишкові копії використовуються для підтримки зв'язків між даними. Як приклад, розглянемо відомості, що зберігаються у відділі кадрів деякого підприємства про своїх співробітників. Користувачами цієї інформації виступають адміністрація, профспілкова організація та бухгалтерія підприємства. Адміністрацію цікавлять дані про кваліфікацію, професійний рівень і досвід роботи, профспілки використовують відомості соціально-побутового характеру, а бухгалтерія оброблює ті дані, що потрібні для нарахувань заробітної плати та підрахунку податків, інших нарахувань та відрахувань. Хоча інформація і різнорідна, але все ж має значну спільну частину. Всім користувачам потрібні службовий номер, прізвище, ім'я, по-батькові співробітника, його рік народження, дані про умови праці. Інформація про сімейний стан та склад сім'ї використовується бухгалтерією і профспілками. Якщо для зберігання даних застосувати технологію ФС, то можливі два крайні варіанти: а)незалежні один від одного файли, відсортовані згідно з потребами того чи іншого користувача, передбачають значну надлишковість даних; б)всі дані знаходяться у одному файлі, відсортованому так, як потрібно одному з користувачів (наприклад, адміністрації) - надлишковість при цьому практично відсутня, але зручно працювати тільки одному з користувачів. Концепція БД займає проміжне становище між вищеописаними крайніми позиціями[11,ст.149].

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

Про незалежність даних часто говорять, як про одну з основних властивостей БД. Під цим поняттям розуміється  можливість зміни структури даних  без зміни програм, що її використовують, а також рівень самоінтерпрето-ваності  даних. Міра незалежності даних тісно  пов'язана з ступенем необхідної деталізації відомостей про організацію  їх зберігання. Проілюструємо цю ситуацію дещо абстрагованим прикладом. Припустимо, що ви збираєтесь переглянути фільм  у кінотеатрі, а для того, щоб  прибути на місце плануєте скористатись послугами таксі. Поінформованість та досвід водія таксі відповідають мірі незалежності. У одному випадку  Вам достатньо вказати лише назву  фільму, а все інше зробить водій. У іншому випадку Вам потрібно буде визначити назву кінотеатру. Наступне зниження рівня - це адреса кінотеатру, а ще далі - вказівки по дорозі типу "їхати прямо, звернути наліво, а  через 500 метрів - направо і т.п.". Аналогічно і користувачу при  підвищенні ступеня незалежності даних  треба менше задавати (і знати) "процедурної" інформації щодо доступу  до даних. Зауважимо, що певний (хоч  і досить низький) рівень незалежності мають сучасні ФС: при доступі  до файлу достатньо вказати його ім'я, а інформація про треки та сектори непотрібна, але зміна  розміру запису вимагає корекції всіх програм, що звертались до цього файла[7,ст.241].

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

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

1.3 Системи керування даними в СППР

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

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

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

Розглядаючи технологію баз  даних з позиції перспектив розвитку СППР, необхідно зазначити, що не всі  структури баз даних є однаковими за гнучкістю та/або практичністю. Існують три фундаментальні класичні структури баз даних — єрархічна, мережева (або сітьова) та реляційна, — кожна з яких має свої переваги та недоліки. Ураховуючи всі їхні переваги та недоліки, можна висновувати, що реляційна структура є найперспективнішою з погляду дальшого розвитку СППР. Розроблені також семантичні моделі даних. Розглянемо коротко класичні структури моделей баз даних[3,ст.271].

                                  Моделі баз даних

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

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

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

2. В єрархічних моделях підтримуються лише співвідношення між елементами даних типу «один до одного» (1 : 1) або «один до багатьох»» (1 : Б).

3. Взаємозв’язки в єрархічних базах даних будуються за принципом «вихідний—породжений», тому доступ до кожного вузла (за виключенням кореневого) здійснюється через його вихідний екземпляр, у зв’язку з чим шлях доступу до кожного вузла є унікальним і лінійним за структурою. Кожен породжений вузол може мати лише один вихідний.

4. Кожен вузол може мати кілька екземплярів конкретних значень атрибутів. Кожен екземпляр породженого вузла зв’язаний з екземпляром вихідного. Кожен екземпляр кореневого сегменту разом з багатьма взаємозв’язаними екземплярами породжених сегментів утворює один логічний запис. Якщо в цьому ланцюжку відсутній хоча би один екземпляр, то подібний запис існувати не може, і потрібно розв’язати питання про введення якихось штучних екземплярів[9,ст.303].

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

У сітьовій (мережевій) моделі бази даних відношення між типами записів не обмежуються єрархією, а можуть утворювати граф з поіменованими дугами і вершинами. Домінуючою сітьовою моделлю є модель, розроблена групою КОДАСИЛ; у ній відношення між типами подаються в термінах теорії множин.

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

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

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

З погляду застосування в  СППР реляційна модель будується  на базовій моделі індивідуальних записів. Вона дає змогу проводити операції над записами, зокрема, вводити нові записи, обновлювати поля, викреслювати наявні записи, а також утворювати і викреслювати відношення, зв’язувати чи об’єднувати два або більше відношень на основі спільних атрибутів. Можна вибирати записи за наявністю ознак певних відношень і проекції, що забезпечують вибір підмножини полів, які належать до відношення. Крім того, беззаперечною перевагою реляційних моделей баз даних є простота і гнучкість у проектуванні. Вони можуть підтримувати не лише дані, але і знання про певну предметну галузь. Вітчизняний ринок програмних продуктів пропонує кілька десятків реляційних СКБД, які можна застосовувати в СППР[6,ст.78].

Існує досить широкий клас семантичних моделей баз даних, включаючи прямі розширення класичних моделей баз даних, математичних моделей і багатьох інших. До найвідоміших представників цього класу належить семантична реляційна модель даних «об’єкт—зв’язок» (entity—relationship), яка уможливлює графічне відображення об’єкта, і семантичні єрархічні моделі, що розширюють реляційні моделі, забезпечуючи оброблення таких семантичних понять, як «класифікація», «агрегація», «узагальнення» й «асоціація»[5,ст.23].

Аналіз СКБД для  СППР

Існують десятки готових  програмних систем для реалізації компонента СКБД системи підтримки прийняття  рішень. Ураховуючи специфічні особливості  та вимоги щодо цих програмних продуктів, а також значну їх вартість, можна  висновувати, що вибір конкретної системи  керування базами даних не є тривіальним  для створеної СППР і заслуговує на саму серйозну увагу. Тим більше це важливо, оскільки продовжуються  теоретичні та прикладні дослідження  в цій галузі, а потенційному користувачеві  доводиться мати справу з масою рекламних  матеріалів. Тому існує проблема створення  когерентної (зрозумілої) і комплексної  основи оцінювання програмного забезпечення СКБД, як механізму для структурування процесу порівняння й вибору з різноманітних альтернативних варіантів СКБД за всім спектром апаратної бази. Найвідомішим способом розв’язання цієї проблеми є схема Захеді[5,ст.23].

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

Схема Захеді розроблена на основі низхідної структури оцінювання, яка не залежить від прийнятої  моделі бази даних, і містить два  типи аналізу: порівняння елементів  альтернативних СКБД на однакових рівнях і поєднання оцінок на різних рівнях відповідно до прийнятих асоціацій[12,ст.21].

Розділ II. Побудова виробничих функцій в середовищі Excel

В 1927 р. економіст Пол Дуглас виявив, що на діаграмі логарифмів капітальних  затрат (К), обсягів випуску (Y) та затрат праці (L) відстані від точок графіку ln Y до точок графіків ln K і ln L складають постійну пропорцію.

Математик Чарльз Кобб показав, що таку особливість має степенева  залежність Y=AK^bL^c, якщо показники степеня b і с в сумі дорівнюють одиниці (b+c=1).

Отже, отримуємо відому функцію  Кобба – Дугласа:

Y=AK^bL^1-b.

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

Коефіцієнт еластичності за капіталом E_Y/K показує, на скільки відсотків збільшиться обсяг випуску при збільшенні затрат капіталу на 1%. Аналогічно визначається коефіцієнт еластичності за працею E_Y/L.

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