Täydellinen funktionaalinen riippuvuus on tietokannan normalisoinnin tila, joka vastaa toisen normaalimuodon (2NF) normalisointistandardia. Lyhyesti sanottuna tämä tarkoittaa, että se täyttää ensimmäisen normaalimuodon (1NF) vaatimukset ja kaikki ei-avainmääritteet ovat täysin toiminnallisista riippuvaisia ensisijaisesta avaimesta.
Tämä ei ole niin monimutkainen kuin saattaa kuulostaa. Tarkastellaan tätä yksityiskohtaisemmin.
Yhteenveto ensimmäisestä normaalimuodosta
Ennen kuin tietokanta voi olla täysin toimintakykyinen, sen on ensin noudatettava ensimmäisen normaalin lomakkeen.
Kaikki tämä tarkoittaa, että jokaisella attribuutilla on oltava yksi atominen arvo.
Esimerkiksi seuraava taulukko on ei noudattaa 1NF, koska työntekijä Tina on kytketty kahteen paikkaan, jotka molemmat ovat samassa solussa:
| Työntekijä | Sijainti |
|---|---|
| Johannes | Los Angeles |
| tina | Los Angeles, Chicago |
Tämän mallin salliminen voisi vaikuttaa kielteisesti päivityksiin tai tietueisiin. Jotta varmistat 1NF: n noudattamisen, järjestä taulukon uudelleenjärjestely niin, että kaikki attribuutit (tai sarakennoilla) ovat yhtä arvoa:
Ensimmäinen normaali muodon noudattaminen
Mutta 1NF ei vieläkään riitä välttämään tietojen ongelmia.
Kuinka 2NF toimii varmistaakseen täydellisen riippuvuuden
Täysin riippuvainen, kaikki ehdokkaat, jotka eivät ole ehdokkaita, riippuvat ensisijaisesta avaimesta. (Muista, että ehdokkaan avainattribuutti on mikä tahansa avain (esimerkiksi ensisijainen tai ulkomainen avain), jota käytetään yksilöimään tietokannan tietue.
Tietokannan suunnittelijat käyttävät notaatiota kuvaamaan riippuvaisia suhteita attribuuttien välillä:
Jos attribuutti A määrittää B: n arvon, kirjoitamme tämänA -> B- tarkoittaa, että B on toiminnallisesti riippuvainen A. Tässä suhteessa A määrittää B: n arvon, kun taas B riippuu A: sta.
Esimerkiksi seuraavassa Työntekijöiden osastot taulukko, Työntekijän tunnus ja DeptID ovat molemmat ehdokas avaimia: Työntekijä-ID on taulukon ensisijainen avain, kun taas DeptID on ulkomaalainen avain.
Jokin muu attribuutti - tässä tapauksessa Työntekijän nimi ja DeptName - riippuu ensisijaisesta avaimesta sen arvon saavuttamiseksi.
| Henkilöstökortti | Työntekijän nimi | DeptID | DeptName |
|---|---|---|---|
| Emp1 | Johannes | Dept001 | Rahoittaa |
| Emp2 | tina | Dept003 | Myynti |
| Emp3 | Carlos | Dept001 | Rahoittaa |
Tällöin taulukko ei ole täysin riippuvainen, koska työntekijän nimi riippuu ensisijaisen avaimen työntekijän ID: stä, mutta DeptName riippuu DeptID: stä. Tätä kutsutaan osittainen riippuvuus .
Jotta tämä taulukko olisi 2NF: n mukainen, meidän on erotettava tiedot kahteen taulukkoon:
| Henkilöstökortti | Työntekijän nimi | DeptID |
|---|---|---|
| Emp1 | Johannes | Dept001 |
| Emp2 | tina | Dept003 |
| Emp3 | Carlos | Dept001 |
Poistamme DeptName-määritteen osoitteesta Työntekijät taulukko ja luo uusi taulukko osastot :
| DeptID | DeptName |
|---|---|
| Dept001 | Rahoittaa |
| Dept002 | henkilöstöhallinto |
| Dept003 | Myynti |
Taulukoiden väliset suhteet ovat täysin riippuvaisia tai 2NF: ssä.
Miksi koko riippuvuus on tärkeä
Täysi riippuvuus tietokantaominaisuuksien välillä auttaa varmistamaan tietojen eheyden ja välttämään tietojen poikkeavuuksia.
Katso esimerkiksi edellä olevan taulukon taulukko, joka noudattaa vain 1 NF. Tässä se on taas:
| Työntekijä | Sijainti |
|---|---|
| Johannes | Los Angeles |
| tina | Los Angeles |
| tina | Chicago |
Tinnalla on kaksi kirjaa. Jos päivitämme ilman, että huomaat, että on olemassa kaksi, tulos olisi epäjohdonmukaista tietoa.
Tai mitä jos haluamme lisätä työntekijän tähän taulukkoon, mutta emme vielä tunne sijaintia? Voimme olla esteenä jopa lisätä uusi työntekijä, jos sijainti-attribuutti ei salli NULL-arvoja.
Täysi riippuvuus ei kuitenkaan ole koko kuva, vaikka se normalisoituu. Sinun on varmistettava, että tietokanta on kolmannessa normaalimuodossa (3NF).
