Проектування фізичної схеми бази даних

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

■ Створення файлів бази даних

■ Створення таблиць

■ Створення первинних і зовнішніх ключів

■ Створення стовпців даних

■ Створення обмежень, що гарантують цілісність даних

■ Створення індексів (в принципі індекси можуть бути без праці створені і змінені вже після реалізації фізичної схеми)

Перетворення логічної схеми бази даних у фізичну може включати кілька етапів

■ Перетворення складного логічного проекту в більш прості і гнучкі структури таблиць

■ Перетворення складових первинних ключів в спираються тільки на один стовпець

■ Перетворення бізнес-логіки в обмеження і тригери

■ Перетворення логічних відносин багато до багатьох в пари фізичних відносин один до багатьох, що використовують асоціативні (Або звязують) таблиці

Варіанти проектування фізичної схеми

Кожна команда проектувальників створює фізичну схему, виходячи з логічної, використовуючи наступні можливі підходи

■ Логічна схема бази даних створюється, а потім реалізується без оглядки на фізичну схему

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

■ Логічна схема бази даних створюється при хорошому розумінні вимог бізнес-логіки Грунтуючись на логічної моделі, команда розробників створює фізичну схему бази даних Даний підхід здатний забезпечити створення швидкої і життєздатною схеми

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

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

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

Коригування моделі даних

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

Часто рішення зводиться до розгляду даних з різних точок зору і пошуку в них спільних елементів Користувачі настільки щільно працюють з даними, що рідко здатні ідентифікувати коректні сутності Те, що користувачі бачать як різні сутності, команда програмістів може спроектувати як одну сутність з динамічними властивостями

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

Питання продуктивності

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

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

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

Питання масштабованості

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

■ Використання послідовного угоди про імена

■ Уникнення створення складних структур даних там, де з завданням можуть упоратися і більш прості структури

■ Використання сценаріїв, а не Management Studio

■ Уникнення використання нестерпних розширень, що не входять в стандарт ANSI SQL, якщо, звичайно, ви не збираєтеся створювати весь кінцевий продукт на продуктах Microsoft

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

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

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

Відповідальний підхід до денормалізації

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

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

. Додаткова Про нормалізацію см в главі 2

інформація

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

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

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

■ Якщо дані використовуються для постійних перетворень (тобто на перше місце виходить питання цілісності даних) – не потрібно займатися денормалізації Ніколи не денормалізуйте вихідні дані

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

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

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

В одному проекті, над яким я працював, кілька аналітиків вводили і обробляли дані, які публікувалися щокварталу Опублікована база даних залишалася статичною протягом всього кварталу і використовувалася виключно для пошукових завдань Це відмінний приклад проекту, який повинен одночасно відповідати вимогам OLTP і OLAP У цьому проекті для збільшення продуктивності пошуку і звітності було створено окрему денормалізованная база даних У даному випадку запускалася багатогодинна процедура, яка денормалізовала дані і заповнювала базу даних OLAP Як кажуть, і вовки ситі, і вівці цілі

Додаткова Індексовані подання у своїй основі представляють собою денор-інформація малізованние Групові індекси Тему індексованих уявлень ми розглянемо в главах 42 і 43 Там же ви знайдете поради щодо створення денормалізованних баз даних звітності, а також сховищ даних

Джерело: Нільсен, Пол Microsoft SQL Server 2005 Біблія користувача : Пер з англ – М: ООО ІД Вільямс , 2008 – 1232 с : Ил – Парал тит англ

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*