Што такое Пераходная Dependency ў базе дадзеных

Пазбягайце транзітыўнасць залежнасці, каб дапамагчы забяспечыць нармалізацыю

Транзітыўнасць залежнасці ў базе даных з'яўляецца ўскоснай залежнасцю паміж значэннямі ў той жа табліцы , што выклікае функцыянальную залежнасць . Для дасягнення стандартнай нормировки трэцяй нармальнай формы (3НФ), вы павінны ліквідаваць любую пераходную залежнасць.

Па сваёй прыродзе, транзітыўнай залежнасцю патрабуе трох ці больш атрыбутаў (або слупкі базы дадзеных), якія маюць функцыянальную залежнасць паміж імі, а гэта азначае, што калонка А ў табліцы належыць на калонцы B праз прамежкавы калонцы C.

Давайце паглядзім, як гэта можа працаваць.

Пераходная Залежнасць Прыклад

АЎТАРЫ

У прыкладзе вышэй AUTHORS:

• Кніга → Аўтар: Тут атрыбут Book вызначае атрыбут Author. Калі вы ведаеце назву кнігі, вы можаце даведацца імя аўтара. Аднак аўтар не вызначае кнігі, таму што аўтар можа напісаць некалькі кніг. Так, напрыклад, толькі таму, што мы ведаем імя аўтара Орсон Скот Кард, мы яшчэ не ведаем, назва кнігі.
• Аўтар → Author_Nationality: Сапраўды гэтак жа, атрыбут аўтар вызначае Author_Nationality, але не наадварот; толькі таму, што мы ведаем, што нацыянальнасць не азначае, што мы можам вызначыць аўтар.

Але гэтая табліца ўяўляе пераходную залежнасць:

• Кніга → Author_Nationality: Калі мы ведаем , назва кнігі, мы можам вызначыць грамадзянства праз калонку Аўтара.

Як пазбегнуць транзітыўных залежнасцяў

Для забеспячэння трэцяй нармальнай формы, давайце выдалім пераходную залежнасць.

Мы можам пачаць з выдаленнем слупка кнігі з табліцы Аўтараў і стварэння асобнай табліцы кнігі:

КНІГІ

АЎТАРЫ

Ці дапамагло гэта выправіць? Давайце разгледзім нашу залежнасць у цяперашні час:

BOOKS стол:

• Book_ID → Кніга: Кніга залежыць ад Book_ID.
• Ніякіх іншых залежнасцяў у гэтай табліцы не існуе, таму мы ўсё ў парадку. Звярніце ўвагу , што знешні ключ спасылкі AUTHOR_ID гэтую табліцу ў табліцу АЎТАРАЎ праз першасны ключ AUTHOR_ID. Мы стварылі адносіны, каб пазбегнуць пераходнай залежнасці, ключавой дызайнам рэляцыйных баз дадзеных.

АЎТАРЫ табліца:

• AUTHOR_ID → Аўтар: Аўтар залежыць ад AUTHOR_ID.
• Аўтар → Author_Nationality: Грамадзянства можа быць вызначана аўтарам.
• AUTHOR_ID → Author_Nationality: Грамадзянства можа быць вызначана з AUTHOR_ID праз атрыбут Author. У нас ёсць яшчэ транзітыўнасць залежнасць.

Нам трэба дадаць трэцюю табліцу, каб нармалізаваць гэтыя дадзеныя:

КРАІНЫ

АЎТАРЫ

Цяпер у нас ёсць тры табліцы, выкарыстоўваючы знешнія ключы, каб звязаць паміж табліцамі:

• Знешні ключ AUTHOR_ID Кніжнай табліцы звязвае кнігу аўтара ў табліцы АЎТАРАЎ.
• Знешні ключ COUNTRY_ID У табліцы Аўтарскай спасылка аўтара ў краіну , у табліцы краін.

• У табліцы КРАІН не мае знешні ключа, паколькі ён не мае ніякай неабходнасці спасылкі на іншую табліцу ў гэтай канструкцыі.

Чаму Пераходныя залежнасці Bad Database Design

Што такое значэнне пазбягаючы залежнасці пераходных для забеспячэння 3NF? Давайце разгледзім нашу першую табліцу зноў і ўбачыць праблемы, якія ён стварае:

АЎТАРЫ

Такі дызайн можа спрыяць анамаліях і супярэчлівасці дадзеных, напрыклад:

• Калі вы выдалілі дзве кнігі «Дзіця Розуму» і «Гульня Эндера», вы б выдаліць аўтар «Orson Scott Card» і яго нацыянальнасць цалкам з базы дадзеных.

• Вы не можаце дадаць новы аўтар у базу дадзеных, калі вы таксама дадаць кнігу; што, калі аўтар яшчэ неапублікаваны ці вы не ведаеце назва кнігі, яна з'яўляецца аўтарам?
• Калі «Орсон Скот Кард» змяніў сваё грамадзянства, вы павінны змяніць яго ва ўсіх запісах, у якіх ён з'яўляецца. Маючы некалькі запісаў з тым жа аўтарам можа прывесці да недакладным дадзеных: што калі запіс дадзеных чалавек не разумее, ёсць некалькі запісаў для яго і змяняе дадзеныя толькі аднаго запісу?
• Вы не можаце выдаліць кнігу, як «Аповяд Служанкі» без выдалення і аўтара цалкам.

Такія толькі некаторыя прычыны , па нармалізацыі і пазбягаючы пераходных залежнасцяў, абароны дадзеных і забеспячэння ўзгодненасці.