Täysi toiminnallinen riippuvuus tietokannan normalisoinnissa

Täysi toiminnallinen riippuvuus on tila tietokannan normalisointi joka vastaa toisen normaalimuodon (2NF) normalisointistandardia. Lyhyesti sanottuna tämä tarkoittaa, että se täyttää 1NF (First Normal Form) -vaatimukset, ja kaikki ei-avainattribuutit ovat täysin toiminnallisesti riippuvaisia ​​ensisijaisesta avaimesta.

Tämä ei ole niin monimutkaista kuin miltä se saattaa kuulostaa. Katsotaanpa tätä tarkemmin.

Yhteenveto ensimmäisestä normaalimuodosta

Ennen kuin tietokanta voi olla täysin toiminnallisesti riippuvainen, sen on ensin täytettävä Ensimmäinen normaalimuoto. Kaikki tämä tarkoittaa, että jokaisella attribuutilla on oltava yksi atomiarvo.

Esimerkiksi seuraava taulukko ei ole 1NF: n mukainen, koska työntekijä Tina on linkitetty kahteen paikkaan, jotka molemmat ovat yhdessä solussa:

Työntekijä	Sijainti
John	Los Angeles
Tina	Los Angeles, Chicago

Tämän mallin salliminen voi vaikuttaa negatiivisesti tietopäivityksiin tai -merkintöihin. Varmista 1NF-yhteensopivuus järjestämällä taulukko uudelleen siten, että kaikilla määritteillä (tai sarakkeen soluilla) on yksi arvo:

Työntekijä	Sijainti
John	Los Angeles
Tina	Los Angeles
Tina	Chicago

Mutta 1NF ei vieläkään riitä tietojen ongelmien välttämiseen.

Kuinka 2NF toimii täydellisen riippuvuuden takaamiseksi

Ollakseen täysin riippuvainen, kaikkien muiden kuin ehdokasavainmääritteiden on oltava riippuvaisia ​​ensisijaisesta avaimesta.

Tietokannan suunnittelijat käyttävät merkintää kuvaamaan attribuuttien välisiä riippuvia suhteita:

Jos attribuutti A määrittää B: n arvon, kirjoitamme tämän A -> B, mikä tarkoittaa, että B on toiminnallisesti riippuvainen A: sta. Tässä suhteessa A määrittää B: n arvon, kun taas B riippuu A: sta.

Esimerkiksi seuraavassa työntekijäosastossa, Henkilöstökortti ja Osaston ID ovat molemmat ehdokasavaimet: Henkilöstökortti on taulukon ensisijainen avain while Osaston ID on vieras avain. Muut attribuutit – tässä tapauksessa Työntekijän nimi ja Osaston nimi— täytyy riippua ensisijaisesta avaimesta saadakseen sen arvon.

Henkilöstökortti	Työntekijän nimi	Osaston ID	Osaston nimi
Emp1	John	Osasto001	Rahoittaa
Emp2	Tina	Osasto003	Myynti
Emp3	Carlos	Osasto001	Rahoittaa

Tässä tapauksessa taulukko ei ole täysin riippuvainen, koska vaikka EmployeeName riippuu ensisijaisesta avaimesta Henkilöstökortti, Osaston nimi riippuu sen sijaan Osaston ID. Tätä kutsutaan osittaiseksi riippuvuudeksi.

Jotta tämä taulukko olisi 2NF: n mukainen, meidän on erotettava tiedot kahteen taulukkoon: Työntekijät-taulukkoon ja Osastot-taulukkoon. Tässä on työntekijätaulukko:

Henkilöstökortti	Työntekijän nimi	Osaston ID
Emp1	John	Osasto001
Emp2	Tina	Osasto003
Emp3	Carlos	Osasto001

Poistamme Osaston nimi attribuutti Työntekijät-taulukosta ja luo uusi taulukko Osastot:

Osaston ID	Osaston nimi
Osasto001	Rahoittaa
Osasto002	henkilöstöhallinto
Osasto003	Myynti

Nyt taulukoiden väliset suhteet ovat täysin riippuvaisia ​​tai 2NF: ssä.

Miksi täysi riippuvuus on tärkeää

Täysi riippuvuus tietokantamääritteiden välillä auttaa varmistamaan tietojen eheyden ja välttämään tietojen poikkeavuuksia.

Harkitse esimerkiksi yllä olevan osan taulukkoa, joka noudattaa vain 1NF: ää. Tässä se taas on:

Työntekijä	Sijainti
John	Los Angeles
Tina	Los Angeles
Tina	Chicago

Tiinalla on kaksi ennätystä. Jos päivitämme yhden ymmärtämättä, että niitä on kaksi, tuloksena olisi epäjohdonmukainen data.

Tai entä jos haluamme lisätä työntekijän tähän taulukkoon, mutta emme vielä tiedä sijaintia? Saatamme kieltäytyä edes lisäämästä uutta työntekijää, jos Sijainti attribuutti ei salli NULL-arvoja.

Täysi riippuvuus ei kuitenkaan ole koko kuva, kun on kyse normalisoinnista. Sinun on varmistettava, että tietokanta on tallennettu Kolmas normaalimuoto (3NF).