Послідовність створення інформаційної моделі

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

У процесі проектування об'єкти перетворяться у відносини, властивості в поля таблиць, методи - у процедури, форми й т.д. Правильно проведений об'єктно-орієнтований аналіз дозволяє значно полегшити роботу [31].

 

6.2 Електронні таблиці (на прикладі Excel)
.

Електронні таблиці, також як файли баз даних формату.DBF, виникли як якась метафора таблиці. Проста ідея про те, що було б добре, якби в деяких клітках таблиці відразу ж відображався результат обчислень, що залежить від даних в інших клітках таблиці, привела до появи в 1979 році програми VisiCalc. У лютому 1981 року з'явилася програма SuperCalc, а на початку 1983 року - пакет Lotus 1-2-3. В останній із цих програм було передбачене відображення результатів розрахунків у графічній формі й це багато в чому визначило успіх Lotus 1-2-3 на ринку в середині 80-х років. Наприкінці 80-х років ситуація на ринку електронних таблиць змінилася - завзята конкурентна боротьба йшла між програмами 1-2-3 версії 2.01 і 3.0 фірми Lotus Development Corporation, Excel 2.1 фірми Microsoft, Quattro 1.0 фірми Borland International і SuperCalc 5 фірми Computer Associates. До середини 1990 років найбільшу популярність придбав пакет Excel, чому чимало сприяли ринкові успіхи системи Microsoft Windows.

Електронні таблиці Excel дозволяють вирішувати дуже багато завдань обробки даних, сформованих у таблиці. В Excel передбачений автоматичне уведення даних з SQL-Серверів і різних СУБД. Обробка даних передбачає, крім арифметичних операцій, можливість маніпулювання комплексними числами й матрицями, обчислення параметрів регресійних залежностей, перетворень Фур'є й інших статистичних характеристик. Передбачені дуже різноманітні методи для графічного висновку результатів, у тому числі, починаючи з Excel 7.0, відображення одержуваних результатів на числові карти у форматі ГІС MapInfo. Складні завдання можуть вирішуватися в межах декількох зв'язаних таблиць, мають назву в Excel’і робочою книгою.
У пакеті Excel передбачені різні засоби для збереження логічної цілісності інформації - автоматична заміна номерів аркушів і осередків при внесенні змін у книгу, автоматичне копіювання формул зі зрушенням номерів осередків у межах стовпців з подібними обчисленнями й багато чого іншого [25].

Питання для самоперевірки

 

1. Принципи логічного і фізичного проектування БД.

2. Корпоративні та «настільні» СУБД.

3. Переваги й недоліки корпоративних та «настільних» СУБД.

4. Послідовність створення інформаційної моделі.

5. Електроні таблиці.

Запити до баз даних

 

Запити мови обробки даних бувають "плановані" і "неплановані".

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

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