Ноу Інти, лекція, діалект sql фірми oracle

Проектування реляційної бази даних

Завданням проектування реляційної бази даних можна вважати досягнення такої системи

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

Існуюча теорія проектування реляційної БД не вчить, як потрібно будувати БД. Замість цього вона вчить тому, якими неприємностями загрожує "неправильне" проектування: її іноді називають "хорошим джерелом поганих прикладів".

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

Простий приклад усунення надмірності показаний нижче.

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

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

Нормалізація реляційної бази даних

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

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

Нехай у відношенні з даними про співробітників присутні і номер відділу співробітника, і назва відділу. Щоб усунути залежність між номером і назвою відділу щодо "співробітники", досить залишити в ньому тільки один з двох атрибутів (швидше за все, це буде "номер відділу"), створити відношення "відділи" з атрибутами "номер відділу" і "назва" , оголосити в ньому "номер відділу" ключем. "Номер відділу" в "співробітників" слід оголосити зовнішнім ключем, зв'язавши його з "номером відділу" з "відділів":

Позбавлятися від подібного роду функціональних залежностей у відносинах можна, поки вони не опиняться приведеними до "нормальної формі BCNF", Бойса-Кодда (Boyce-Codd); по праву першості її слід було б назвати "нормальною формою Хіта" (Heath). У таких відносинах, образно висловлюючись, "кожне зведення відноситься до ключа, всьому ключу (з усіма його атрибутами) і тільки до ключу" (в оригінальній фразі англійською замість "відомості" дослівно сказано "факт"), з тим додаванням, що ключів може бути кілька. Іншими словами, в відношенні, що задовольняє BCNF. свавілля значень визначається тільки правилами ключа - можливо, зовнішнього ключа і типів атрибутів. Трохи менш суворий варіант BCNF іменується "3-й нормальною формою".

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

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

Нормалізація відносин сприяє:

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

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

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

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

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

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

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