Mikä on kolmas normaali muoto? (Tietokannat)

Se Kolmas normaali muoto (tietokannat) Se on relaatiotietokannan suunnittelutekniikka, jossa sitä muodostavat eri taulukot eivät vain täytä toista normaalia muotoa, vaan kaikki niiden ominaisuudet tai kentät riippuvat suoraan pääavaimesta.

Kun tietokanta on suunniteltu, päätavoitteena on luoda tarkka esitys tietoista, niiden välisistä suhteista ja asiaankuuluvien tietojen rajoituksista.

Lähde: Pixabay.com

Tämän tavoitteen saavuttamiseksi voidaan käyttää joitain tietokannan suunnittelutekniikoita, joista on standardointi.

Tämä on tietokannan tietojen järjestämisprosessi irtisanomisten ja mahdollisten poikkeavuuksien välttämiseksi tietojen asettamisessa, päivittämisessä tai hävittämisessä, mikä tuottaa sille yksinkertaisen ja vakaan suunnittelun käsitteellisen mallin suunnittelun.

Alkaa tutkimalla ominaisuuksien toiminnallista suhdetta tai riippuvuutta. Nämä kuvaavat jonkin tiedon ominaisuutta tai niiden välistä suhdetta.

[TOC]

Normaalimuodot

Standardointi käyttää sarjaa testejä, joita kutsutaan normaaliksi muodoiksi, näiden ominaisuuksien optimaalisen ryhmittelyn tunnistamiseksi ja lopulta riittävien suhteiden määrittämiseksi, jotka tukevat yrityksen tietovaatimuksia

Toisin sanoen normalisointitekniikka on rakennettu normaalin tavan käsitteen ympärille, joka määrittelee rajoitusjärjestelmän. Jos suhde täyttää rajoitukset tietyllä normaalilla tavalla, sanotaan, että suhde on tällä normaalilla tavalla.

Ensimmäinen normaali muoto (1FN)

Sanotaan, että taulukko on 1FN: ssä, jos kaikki sen ominaisuudet tai kentät sisältävät vain ainutlaatuisia arvoja. Eli kunkin määritteen kaiken arvon on oltava jakamattomia.

Määritelmän mukaan relaatiotietokanta normalisoidaan aina ensimmäiseen normaalimuotoon, koska määritteet arvot ovat aina atomia. Kaikki tietokannan suhteet ovat 1FN: ssä.

Voi palvella sinua: vakio (ohjelmointi): konsepti, tyypit, esimerkit

Tietokannasta poistuminen stimuloi kuitenkin yksinkertaisesti sarjaa ongelmia, kuten redundanssi ja mahdolliset päivityspoikkeamat. Korkeimmat normaalimuodot kehitettiin näiden ongelmien korjaamiseksi.

Toinen normaali muoto (2FN)

Se käsittelee taulukon eliminointia pyöreät yksiköt. Sanotaan.

Attribuutti ei avain on mikään ominaisuus, joka ei ole osa suhteessa ensisijaista avainta.

Kolmas normaali muoto (3FN)

Se käsittelee transitiivisten riippuvuuksien poistamisesta taulukosta. Eli eliminoi ei -avainominaisuudet, jotka eivät riipu ensisijaisesta avaimesta, vaan toisesta ominaisuudesta.

Transitiivinen riippuvuus on funktionaalisen riippuvuuden tyyppi, jossa attribuutin tai kentän arvoa ei määritetä toisen kentän arvolla, joka ei ole avain.

Toistuvia arvoja tulisi etsiä muissa kuin avainominaisuuksissa varmistaakseen, että nämä ominaisuudet, jotka eivät ole avainta, eivät ole riippuvaisia ​​pelkästään ensisijaisesta avaimesta.

Sanotaan. Tämä keskinäinen riippumattomuus takaa, että ominaisuudet voidaan päivittää erikseen ilman vaaraa vaikuttaa toiseen ominaisuuteen.

Siksi, jotta tietokantasuhde on kolmannessa normaalimuodossa, sen on noudatettava:

- Kaikki 2FN -vaatimukset.

Voi palvella sinua: ICT talossa

- Jos on ominaisuuksia, jotka eivät liity ensisijaiseen avaimeen, ne on poistettava ja asetettava erilliseen taulukkoon, joka liittyy molemmat taulukot ulkoisen avaimen kautta. Eli transitiivistä riippuvuutta ei pitäisi olla.

Esimerkkejä kolmannesta normaalimuodosta

Esimerkki 1

Ole opiskelijataulukko, jonka ensisijainen avain on opiskelijan (id_estudiant) tunnistaminen ja koostuu seuraavista ominaisuuksista: opiskelijan nimi, katu, kaupunki ja_postal koodi, täyttämällä olosuhteet 2fn.

Tässä tapauksessa kadulla ja kaupungissa ei ole suoraa suhdetta ensisijaiseen identiteetin avaimeen, koska ne eivät liity suoraan opiskelijaan, mutta ne ovat täysin riippuvaisia ​​postinumerosta.

Koska opiskelija sijaitsee Code_Postal, Street ja kaupunki määrittelemällä sivustolla liittyy tähän ominaisuuteen. Tämän toisen riippuvuusasteen vuoksi ei ole välttämätöntä tallentaa näitä ominaisuuksia opiskelijataulukkoon.

Luo uusi taulukko

Oletetaan pöytäopiskelija.

Esimerkiksi, jos on tarpeen muuttaa “El Limón” -katu “El Limón II” -kadulla, sen on etsittävä “El Limón” koko opiskelijapöydästä ja päivitettävä se sitten ”El Limón II”.

Löydä valtavasta taulukosta ja päivittää ainutlaatuiset tai useat tietueet vaativat paljon aikaa, ja siksi se vaikuttaa tietokannan suorituskykyyn.

Sen sijaan nämä yksityiskohdat voidaan olla erillisessä (postikortti) -taulukossa, joka liittyy opiskelijataulukkoon CODE_Postal -määritteen avulla.

Postitaulussa on suhteellisen pienempi määrä tietueita, ja sen on päivitettävä vasta, kun tämä postitaulukko. Tämä heijastuu automaattisesti opiskelijataulukossa, yksinkertaistaen tietokantoja ja neuvotteluja. Siten taulukot ovat 3FN: ssä:

Se voi palvella sinua: Metabusters: Ominaisuudet, tyypit ja esimerkit

Esimerkki 2

Ole seuraava taulukko, jonka pääavain Num_project -kenttä on ja toistuvilla arvoilla ominaisuuksissa, jotka eivät ole avainta.

Puhelimen arvo toistetaan joka kerta, kun johtajan nimi toistetaan. Tämä johtuu siitä, että puhelinnumerossa on vain toinen -asukas riippuvuus projektinumerosta. Se todella riippuu johtajasta, ja tämä puolestaan ​​riippuu projektinumerosta, mikä tekee transitiivisen riippuvuuden.

Manager_project -ominaisuus ei voi olla mahdollinen avain taulukkoprojekteissa, koska sama johtaja käsittelee useampaa kuin yhtä projektia. Ratkaisu tähän on määritteen poistaminen toistuvilla tiedoilla (puhelin), erillisen taulukon luominen.

Vastaavat määritteet on ryhmiteltävä, luomalla uusi taulukko niiden tallentamiseksi. Tiedot syötetään ja varmistetaan, että toistetut arvot eivät ole osa ensisijaista avainta. Kunkin taulukon ensisijainen avain on määritetty ja tarvittaessa lisätään ulkoiset avaimet.

Kolmannen normaalin lomakkeen täyttämiseksi luodaan uusi taulukko (johtajat) ongelman ratkaisemiseksi. Molemmat taulukot liittyvät Manager_project -kentän kautta:

Viitteet

1. Teradata (2019). Ensimmäinen, toinen ja kolmas normaalimuoto. Otettu: Docs.Teradata.com.
2. Cup -opetusohjelma (2019). Normaali kolmas muoto (3NF). Otettu: TutorialCup.com.
3. Tietokanta Dev (2015). Normaali kolmas muoto (3NF) - Tietokannan normalisointi. Otettu: DatabedEvEv.yhteistyö.Yhdistynyt kuningaskunta.
4. Suhteellinen DB -suunnittelu (2019). Johdanto kolmanteen normaalimuotoon. Otettu: relationalDBDesign.com.
5. Nukkeja (2019). SQL ensin, toinen ja kolmas normaalimuoto. Otettu: nukkeja.com.