Реферати

Наукова праця: Узагальнення моделей даних у створенні ИС

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

Типи і функції держави. Уведення 2 Виникнення держави 2 ТИПИ ДЕРЖАВИ 7 ФУНКЦІЇ ДЕРЖАВИ 13 Поняття і класифікація функцій держави 13 Основні внутрішні функції 16

Рішення проблем соціального розвитку дитини в неблагополучній родині. ЗМІСТ УВЕДЕННЯ......2 РОЗДІЛ 1 НАУКОВО - ТЕОРИТИЧЕСКИЕ ОСНОВИ СОЦІАЛЬНОГО РОЗВИТКУ ДІТЕЙ З НЕБЛАГОПОЛУЧНИХ РОДИН......6

Алксніс, Яків Іванович. Уведення 1 Біографія 2 Родина 3 Ризьке вище військове авіаційне інженерне училище ім. Я. Алксніса 4 Нагороди Список літератури Алксніс, Яків Іванович

Грабіж 4. Забайкальський Державний Гуманитарно-Педагогический Університет ім. Н. Г. Чернишевського Юридичний факультет Кафедра карного права і процесу

АВТОНОМНА НЕКОМЕРЧЕСКАЯ ОРГАНІЗАЦІЯ

ЄВРАЗІЙСЬКИЙ ВІДКРИТИЙ ІНСТИТУТ

Коломенська філія

НАУКОВО-ДОСЛІДНА РОБОТА

Узагальнення моделей даних у створенні ИС

Виконали:

Студентки 4 курси групи 41-П

Хромова Валентина Сергіївна

ИНС № 0021-02014

Литвиненко Марія Миколаївна

ИНС № 0021-01931

м. Коломна, 2009 рік

ЗМІСТ

Уведення

Глава I. Класичні моделі даних

1.1 Ієрархічна модель даних

1.2 Мережна модель даних

1.3 Реляционная модель даних

Глава II. Некласичні моделі даних

2.1 Постреляционная модель даних

2.2 Багатомірна модель даних

2.3 Объектно-ориентированная модель даних

Глава III. Порівняння класичних моделей даних

3.1 Достоїнства і недоліки реляционной моделі

3.3 Достоїнства і недоліки мережної моделі

3.2 Достоїнства і недоліки ієрархічної моделі

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

Додаток

Уведення

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

- забезпечувати одержання загальних і/чи деталізованих звітів по

підсумкам роботи;

- дозволяти легко визначати тенденції зміни найважливіших

показників;

- забезпечувати одержання інформації, критичної за часом, без

істотних затримок;

- виконувати точний і повний аналіз даних.

Сучасні системи керування базами даних (СУБД) в основному є додатками Windows, тому що дане середовище дозволяє більш повно використовувати можливості персональної ЕОМ, ніж середовище DOS. Зниження вартості високопродуктивних ПК обумовив не тільки широкий перехід до середовища Windows, де розроблювач програмного забезпечення може в меншому ступені піклуватися про розподіл ресурсів, але також зробив програмне забезпечення ПК у цілому і СУБД зокрема менш критичними до апаратних ресурсів ЕОМ. Серед найбільш яскравих представників систем керування базами даних можна відзначити: LotusApproach, MicrosoftAccess, BorlanddBase, BorlandParadox, MicrosoftVisualFoxPro, MicrosoftVisualBasic, а також баз даних Microsoft SQL Server і Oracle, використовувані в додатках, побудованих за технологією "клієнт-сервер". Фактично, у будь-який сучасної СУБД існує аналог, що випускається іншою компанією, що має аналогічну область застосування і можливості, будь-яке додаток здатний працювати з багатьма форматами представлення даних, здійснювати експорт і імпорт даних завдяки наявності великого числа конвертерів. Загальноприйнятими, також, є технології, що дозволяють використовувати можливості інших додатків, наприклад, текстових процесорів, пакетів побудови графіків і т.п., і убудовані версії мов високого рівня (частіше - діалекти SQL і/чи VBA) і засобу візуального програмування інтерфейсів розроблювальних додатків. Тому вже не має істотного значення на якій мові і на основі якого пакета написане конкретний додаток, і який формат даних у ньому використовується. Більш того, стандартом "де-факто" стала "швидка розробка додатків" чи RAD (від англійського Rapid Application Development), заснована на широко декларируемом у літературі "відкритому підході", тобто необхідність і можливість використання різних прикладних програм і технологій для розробки більш гнучких і могутніх систем обробки даних. Тому в одному ряді з "класичними" СУБД усі частіше згадуються мови програмування Visual Basic 4.0 і Visual C++, що дозволяють швидко створювати необхідні компоненти додатків, критичні по швидкості роботи, що важко, а іноді неможливо розробити засобами "класичних" СУБД. Сучасний підхід до керування базами даних має на увазі також широке використання технології "клієнт-сервер".

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

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

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

Об'єктом исследованияявляются наступні класичні моделі даних.

1. Ієрархічна;

2. Мережна;

3. Реляционная;

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

1. постреляционная;

2. багатомірна;

3. объектно-ориентированная.

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

B деяких СУБД підтримуються одночасно кілька моделей даних. Наприклад, у системі ИНТЕРБАЗА для додатків застосовується мережна мова маніпулювання даними, а в користувальницькому інтерфейсі реалізовані мови SQL і QBE.

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

Задачі дослідження:

1. Вивчити ієрархічну модель даних;

2. Вивчити мережну модель даних;

3. Вивчити реляционную модель даних;

4. Вивчити постреляционную модель даних;

5. Вивчити багатомірну модель даних;

6. Вивчити об'єктно-орієнтовану модель даних;

7. Порівняти класичні моделі даних.

Теоретична основа дослідження - структури моделей, представлення зв'язків, недоліки і достоїнства, кожної моделі. Використано роботи авторів: А. И. Мишенин, И. Г. Семакин, Е. К. Хеннер, Г. Н. Смирнова, А. А. Сорокін, Ю. Ф. Тельнов, А. Д. Хомоненко, В. М. Циганков, М. Г. Мальцев

Главаі. Класичні моделі даних

1.1 Ієрархічна модель даних

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

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

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

Ієрархічна БД, являє собою упорядковану сукупність екземплярів даних типу "дерево" (дерев), що містять екземпляри типу "запис" (запису). Часто відносини споріднення між типами переносять на відносини між самими записами. Поля записів зберігають власне числові чи символьні значення, що складають основний зміст БД. Обхід всіх елементів ієрархічної БД звичайно виробляється зверху вниз і ліворуч праворуч.

В ієрархічних СУБД може використовуватися термінологія, що відрізняється від приведеної. Так, у системі IMS поняттю "запис" відповідає термін "сегмент", а під "записом БД" розуміється вся сукупність записів, що відноситься до одного екземпляра типу "дерево".

Дані в базі з приведеною схемою (мал.2.) можуть виглядати, наприклад, як показано на мал.3. (см. Додаток мал. 3.)

Для организациифизическогоразмещения ієрархічних даних у пам'яті ЕОМ можуть використовуватися наступні групи методів:

1. представлення лінійним списком з послідовним розподілом пам'яті (адресна арифметика, левосписковие структури);

2. представлення зв'язними лінійними списками (методи, що використовують покажчики і довідники).

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

1. пошук зазначеного екземпляра БД;

2. перехід від одного дерева до іншого;

3. перехід від одного запису до інший усередині;

4. вставка нового запису в зазначену позицію;

5. видалення поточної запису і т.д.

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

Кдостоинствам ієрархічної моделі даннихотносятся ефективне використання пам'яті ЕОМ і непогані показники часу виконання основних операцій над даними. Ієрархічна модель даних зручна для роботи з ієрархічно упорядкованою інформацією. Недоліком ієрархічної моделиявляется її громіздкість для обробки інформації з досить складними логічними зв'язками, а також складність розуміння для звичайного користувача. На ієрархічній моделі даних заснована порівняно обмежена кількість СУБД, у числі яких можна назвати закордонні системи IMS, PC/Focus, Теам-Up і Data Еdgе, а також вітчизняні системи Ока, ИНЕС і МИРИС.

1.2 Мережна модель даних

Мережна модель даних дозволяє відображати різноманітні взаємозв'язки елементів даних у виді довільного графа, узагальнюючи тим самим ієрархічну модель даних (мал. 4.). Найбільше повно концепція мережних БД уперше була викладена в Пропозиціях групи КОДАСИЛ (KODASYL). (см. Додаток мал.4.) Для опису схеми мережний БД використовується дві групи типів: "запис" і "зв'язок". Тип "зв'язок" визначається для двох типів "запис": предка і нащадка. Перемінна типу "зв'язок" є екземплярами зв'язків. Мережна БД складається з набору записів і набору відповідних зв'язків. На формування зв'язку особливих обмежень не накладається. Якщо в ієрархічних структурах запис-нащадок могла мати тільки одного запису-предка, то в мережній моделі даних запис-нащадок може мати довільне число записів-предків (зведених батьків). Приклад схеми найпростішої мережний БД показаний на мал.5. Типи зв'язків тут позначені написами на з'єднуючих типи записів лініях. (см. Додаток мал.5.) B різних СУБД мережного типу для позначення однакових по суті понять найчастіше використовуються різні терміни. Наприклад, такі як елементи й агрегати даних, запису, набори, області і т.д.

Фізичне розміщення даних у базах мережного типу може бути організоване практично тими ж методами, що й в ієрархічних базах даних.

K числу найважливіших операцій маніпулювання даними баз мережного типу можна віднести наступні:

· пошук запису в БД;

· перехід від предка до першого нащадка;

· перехід від нащадка до предка;

· створення нового запису;

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

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

· включення запису в зв'язок;

· виключення запису зі зв'язку;

· зміна зв'язків і т.д.

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

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

Системи на основі мережної моделі не одержали широкого поширення на практиці. Найбільш відомими мережними СУБД є наступні: IDMS, db_VistaIII, МЕРЕЖА, СЕТОР і КОМПАС.

1.3 Реляционная модель даних

Реляционная модель даних запропонована співробітником фірми IBM Едгаром Коддом і ґрунтується на понятті відношення (relation).

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

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

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

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

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

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

Прикладами закордонних реляционних СУБД для ПЕВМ є наступні: DBaseIII Plus і dBase IY (фірма Ashton-Tate), DB2 (IBM), R:BASE (Microrim), FoxFro ранніх версій і EoxBase (Fox Software), Раrаdох і dBASE for Windows (Borland), FoxFro більш пізніх версій, Visual FoxFro і Access (Microsoft), Clarion (Clarion Software), Ingres (ASK Computer Systems) і Oracle (Oracle).

До вітчизняних СУБД реляционного типу відносяться системи: ПАЛЬМА (ИК АН УРСР), а також система HyTech (МИФИ).

Помітимо, що останні версії реляционних СУБД мають деякі властивості объектно-ориентированних систем. Такі СУБД часто називають объектно-реляционними. Прикладом такої системи можна вважати продукти Oracle 8. х. Системи попередніх версій аж до Oracle 7. х вважаються "чисто" реляционними.

Главаіі. Некласичні моделі даних

2.1 Постреляционная модель даних

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

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

На мал.6 на прикладі інформації про накладні і товари для порівняння приведене представлення тих самих даних за допомогою реляционной (а) і постреляционной (б) моделей. Таблиця INVOICES (накладні) містить дані про номери накладних (INVNO) і номерах покупців (CUSTNO). У таблиці INVOICE.ITEMS (накладн-товари) містяться дані про кожній з накладних: номер накладної (INVNO), назва товару (GOODS) і кількість товару (QTY). Таблиця INVOICES зв'язана з таблицею INVOICE.ITEMS по полю INVNO. (см. Додаток мал.6.)

Як видно з малюнка, у порівнянні з реляционной моделлю в постреляционной моделі дані зберігаються більш ефективно, а при обробці не потрібно виконувати операцію з'єднання даних із двох таблиць. Для доказу на мал.7 приводяться приклади операторів SELECT вибору даних із усіх полів бази мовою SQL для реляционной (а) і постреляционной (б) моделей. (см. Додаток мал.7.)

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

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

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

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

2.2 Багатомірна модель даних

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

Поштовхом послужила в 1993 році програмна стаття одного з основоположників реляционного підходу Е. 1Содда. B їй сформульовані 12 основних вимог до систем класу OLAP (OnLine Analytical Processing - оперативна аналітична обробка), найважливіші з який зв'язані з можливостями концептуального представлення й обробки багатомірних даних. Багатомірні системи дозволяють оперативно обробляти інформацію для проведення аналізу й ухвалення рішення.

B розвитку концепцій ИС можна виділити наступні два напрямки:

· системи оперативної (транзакционной) обробки;

· системи аналітичної обробки (системи підтримки прийняття рішень).

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

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

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

Историчностъданних припускає забезпечення високого рівня статичності (незмінності) власне даних і їхніх взаємозв'язків, а також обов'язковість прив'язки даних вчасно.

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

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

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

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

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

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

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

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

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

B прикладі на мал.8, б кожне значення осередку Обсяг продажів однозначно визначається комбінацією тимчасового виміру (Місяць продажів) і моделі автомобіля. Їжа практиці найчастіше потрібно більша кількість вимірів. Приклад тривимірної моделі даних приведений на мал.9. (см. Додаток мал.9.)

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

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

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

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

"Зріз" (S1ice) являє собою підмножина гіперкуба, отримана в результаті фіксації одного чи декількох вимірів. Формування "зрізів" виконується для обмеження використовуваних користувачем значень, тому що всі значення гіперкуба практично ніколи одночасно не використовуються. Наприклад, якщо обмежити значення виміру Модель автомобіля в гіперкубі (мал.9) маркою "Жигулі", те вийде двомірна таблиця продажів цієї марки автомобіля різними менеджерами по роках.

Операція "обертання" (Rotate) застосовується при двомірному представленні даних. Суть її полягає в зміні порядку вимірів при візуальному представленні даних. Так, "обертання" двомірної таблиці, показаної на мал.86, приведе до зміни її виду таким чином, що по осі X буде марка автомобіля, а по осі Y - час.

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

Операції "агрегація" (Dri11 Up) і "деталізація" (Dri11 Down) означають відповідно перехід до більш загального і до більш детального представлення інформації користувачу з гіперкуба.

Для ілюстрації змісту операції "агрегація" припустимо, що в нас мається гіперкуб, у якому крім вимірів гіперкуба, приведеного на мал.9, маються ще виміри: Підрозділ, Регіон, Фірма, Країна. Помітимо, що в цьому випадку в гіперкубі існує ієрархія (знизу нагору) відносин між вимірами: Менеджер, Підрозділ, Регіон, Фірма, Країна.

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

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

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

Прикладами систем, що підтримують багатомірні моделі даних, є Essbase (Arbor Software), Media Mu1ti-matгix (Speedware), Oracle Express Server (Огас1е) і Cache (InterSystems). Деякі програмні продукти, наприклад Media/M R (Speedware), дозволяють одночасно працювати з багатомірними і з реляционними БД. B СУБД Cache, і яке внутрішньою моделлю даних є багатомірна модель, реалізовані три способи доступу до даних: прямої (на рівні вузлів багатомірних масивів), об'єктний і реляционний.

2.3 Объектно-ориентированная модель даних

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

Стандартизована объектно-ориентированной модель описана в рекомендаціях стандарту ODMG-93 (Object Database Management Group - група керування объектно-ориентированними базами даних). Реалізувати в повному обсязі рекомендації ODMG-93 поки не вдається. Для ілюстрації ключових ідей розглянемо трохи спрощену модель объектно-ориентированной БД.

Структура объектно-ориентированной БД графічно представима у виді дерева, вузлами якого є об'єкти. Властивості об'єктів описуються деяким стандартним типом (наприклад, строковим - string) чи типом, конструируемим користувачем (визначається як class).

Значенням властивості типу string є рядок символів. Значення властивості типу class є об'єкт, що є екземпляром відповідного класу. Кожен об'єкт-екземпляр класу вважається нащадком об'єкта, у якому він визначений як властивість. Об'єкт-екземпляр класу належить своєму класу і має одного батька. Родові відносини в БД утворять зв'язну ієрархію об'єктів.

Приклад логічний структури объектно-ориентированной БД бібліотечного ціпа приведений на мал.10. (см. Додаток мал.10.)

Тут об'єкт типу БІБЛІОТЕКА є батьківським для об'єктів-екземплярів класів АБОНЕНТ, КАТАЛОГ і ВИДАЧА. Різні об'єкти типу КНИГА можуть мати одного чи різних батьків. Об'єкти типу КНИГА, що мають того самого батька, повинні розрізнятися принаймні інвентарним номером (унікальний для кожного екземпляра книги), але мають однакові значення властивостей isbn, удк, назва й автор.

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

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

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

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

Инкапсуляцияограничивает область видимості імені властивості межами того об'єкта, у якому воно визначено. 'Гак, якщо в об'єкт типу КАТАЛОГ додати властивість, що задає телефон автора книги і назва, що має, телефон, то ми одержимо однойменні властивості в об'єктів АБОНЕНТ і КАТАЛОГ Зміст такої властивості буде визначатися тим об'єктом, у який воно инкапсулировано.

Спадкування, навпаки, поширює область видимості властивості на всіх нащадків об'єкта. Так, всім об'єктам типу КНИГА, що є нащадками об'єкта типу КАТАЛОГ, можна приписати властивості об'єкта-батька:isbn, удк, назва й автор. Якщо необхідно розширити дія механізму спадкування на об'єкти, що не є безпосередніми родичами (наприклад, між двома нащадками одного батька), то в їхньому загальному предку визначається абстрактна властивість типу abs. Так, визначення абстрактних властивостей 6wcem і номер в об'єкті БІБЛІОТЕКА приводить до спадкування етик властивостей усіма дочірніми об'єктами АБОНЕНТ, КНИГА і ВИДАЧА. Невипадково тому значення властивості квиток класів АБОНЕНТ і ВИДАЧА, показаних на малюнку, будуть однаковими - 00015.

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

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

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

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

B 90-e роки існували експериментальні прототипи объектно-ориентированних систем керування базами даних. B сьогодення час такі системи одержали широке поширення, зокрема, До них відносяться наступні СУБД: POET (POET Software), Jasmine (Computer Associates), Versant (Versant Technologies), 02 (Ardent Software), ODB-Jupiter (науково-виробничий центр "Интелтек Плюс"), а також Iris, Orion і Postgres.

Главаііі. Порівняння класичних моделей даних

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

3.1 Достоїнства і недоліки реляционной моделі

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

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

· Теоретичне обґрунтування. Наявність теоретично обґрунтованих методів нормалізації відносин і перевірки ацикличности структури дозволяє одержувати бази даних із заданими характеристиками.

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

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

· Низька швидкість при виконанні операції з'єднання.

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

3.2 Достоїнства і недоліки ієрархічної моделі

Достоїнствами ієрархічної моделиданних є наступні.

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

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

Недоліки ієрархічної моделі.

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

· Допустимість тільки навігаційного принципу доступу до даних.

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

3.3 Достоїнства і недоліки мережної моделі

Необхідно відзначити следующиепреимущества мережної моделі даних.

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

· Можливість доступу до даних через значення декількох

відносин (наприклад, через будь-які основні відносини).

У качественедостатков мережної моделі даннихможно назвати.

· Складність, тобто достаток понять, варіантів їхніх взаємозв'язків і особливостей реалізації.

· Допустимість тільки навігаційного принципу доступу до даних.

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

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

Висновок

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

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

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

Класифікація інформаційних конструкцій (інформаційних об'єктів) тісно зв'язана з областю їхнього використання в ЕИС.

1. Об'єкти для технології баз даних - відносини і віялові відносини.

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

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

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

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

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

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

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

1. Мишенин А. И. Теорія економічних інформаційних систем.-М.: "Фінанси і статистика", 2007

2. Семакин И. Г. Хеннер Е. К. Інформаційні системи і моделі. Навчальний посібник.-М.: "БІНОМ. Лабораторія знань", 2005

3. Смирнова Г. Н. Сорокін А. А. Тельнов Ю. Ф. Проектування економічних інформаційних систем.-М.: "Фінанси і статистика", 2003

4. Хомоненко А. Д. Циганков В. М. Мальцев М. М. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004

5. http://www.finstat.ru

6. http://www.refer.ru

Додаток

Рис.1. Представлення зв'язків в ієрархічній моделі

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

Рис.2. Приклад типу "дерево"

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

Рис.3. дані в ієрархічній базі

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

Рис.4. Представлення зв'язків у мережній моделі

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

Рис.5. Приклад схеми мережний БД

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004

А)

INVOICES

INVOICE.ITEMS

Б)

INVOICES

Рис.6. Структури даних реляционной і постреляционной моделей

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

А)

SELECT

INVOICES.INVNO, CUSTNO, GOODS, QTY

FROM

INVOICES, INVOICE.ITEMS

WHERE

INVOICES.INVNO=INVOICE.ITEMS.INVNO$

Б)

SELECT

INVNO, CUSTNO, GOODS, QTY

FROM

INVOICES;

Рис.7. ОператориSQLдля реляционной і постреляционной моделей

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

А)

Б)

Рис.8. Реляционние і багатомірне представлення даних

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

Рис.9. Приклад тривимірної моделі

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

Рис.10. Логічна структура БД бібліотечної справи

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)

Рис.11. Фрагмент БД з об'єктом-метою

(Хомоненко А. Д. Циганков В. М. Мальцев М. Г. Бази даних. Підручник для вищих навчальних закладів.-Санкт-Петербург: "КОРОНА принт", 2004)