Коли слід денормалізувати?

Я думаю, що ми всі знайомі з нормалізацією баз даних .

Моє запитання: Які деякі вказівки ви використовуєте, коли хочете денормалізувати таблиці?

Денормалізувати, коли це операції OLAP, нормалізувати, коли OLTP (із пов'язаної статті у розділі Денормалізація)

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

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

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

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

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

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

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

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

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

Ви не можете використовувати обмеження CHECK для порівняння стовпців у різних рядках або в різних таблицях, якщо ви не загорнете таку функціональність у скалярні UDF, на які посилається, не встановити обмеження CHECK. Що робити, якщо вам дійсно потрібно порівняти стовпці в різних рядках або в різних таблицях для забезпечення ділового правила? Наприклад, припустимо, що ви знаєте робочий час лікаря і хочете переконатися, що всі призначення відповідають робочому часу? Звичайно, ви можете використовувати тригер або збережену процедуру для реалізації цього бізнес-правила, але ні тригер, ні збережена процедура не можуть дати вам 100% гарантію, що всі ваші дані чисті - хтось може відключити або відпустити ваш тригер, ввести якийсь брудні дані та знову ввімкніть або відтворите ваш тригер. Також хтось може безпосередньо змінювати вашу таблицю, минаючи збережені процедури.

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

Ще один приклад - це спосіб забезпечити, щоб періоди часу не мали прогалин і не перекривались .