Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Об'єктний підхід

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

Використання атрибутів первинного ключа символьного типу для баз даних, які передбачають обробку великого обсягу даних, є досить неефективним рішенням, яке ніяк не може бути дозволено за допомогою правил нормалізації. Его видно по результату нормалізації в документарному підході побудови моделі бази даних, де деякі первинні ключі є символьними. З огляду на, що найменувань товарів буде не дуже багато і їх кількість не перевищить 1000-2000 примірників, така ситуація з символьним первинним ключем серйозних проблем не створить, але в разі номера замовлення, який також представлений символьним типом даних, все стає набагато складніше. Перший час використання інформаційної системи, коли тільки буде починати формуватися база замовлень, проблеми швидкості не будуть помічені і побудовані запити по вибірці і обробці даних, при їх оцінці, не покажуть низьку швидкість обробки. Однак з часом база замовлень буде поповнюватися і кількість примірників замовлень і позицій товарів в цих замовленнях, які, до речі, також мають в якості первинного ключа символьний атрибут "Найменування товару", буде експоненціально збільшуватися. В кінцевому рахунку після закінчення 3-5 років використання інформаційної системи, а може бути і раніше, якщо магазин буде користуватися популярністю, кількість примірників позицій товарів в замовленнях може вимірюватися мільйонами або навіть десятками мільйонів записів, що відразу позначиться на швидкості і ефективності обробки даних . Хоч атрибути первинних ключів, за замовчуванням, індексуються і внутрішні механізми СУБД забезпечують оптимізацію запитів, але при спробах зробити запити, де необхідно виконувати пошук за цими первинним ключам в рамках, наприклад, з'єднання таблиць в запитах, все оптимізаційні механізми СУБД не зможуть впоратися з обсягом оброблюваних символьних даних і швидкість отримання результату запитів буде дуже низькою.

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

  • 1. Читання двох порівнюваних значень в символьному вигляді.
  • 2. Поділ кожного значення на безліч (масив) окремих символів.
  • 3. Переклад всіх символів в числовий вигляд (код таблиці символів).
  • 4. Послідовне посимвольного порівняння кодів символів.

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

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

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

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

правило

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

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

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

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

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

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

Ефективність об'єктного підходу полягає в тому, що:

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

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

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

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

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

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

image230

Мал. 4.19. Процес використання об'єктного підходу проектування бази даних


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

 
<<   ЗМІСТ   >>