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

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

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

1.Три основні категорії засобів моделювання даних.

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

3. Логічна модель баз даних.

4. Характеристики Aссеss.

5. Поняття адміністратор бази даних.

6. Інформаційна модель СУБД

6.1 Попереднє планування, підготовка даних,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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