Normaalilomakkeet eivät ole vain tietokantoja varten

Voit soveltaa samanlaisia ​​sääntöjä myös dataobjektityyppeihin.

Olet todennäköisesti oppinut termin Normal Form yhteydessä määritellessäsi skeemejä relaatiotietokannoille. Tietokannan normalisointi pyrkii vähentämään tietojen redundanssia taulukkoriveillä ja -sarakkeilla. Näin ollen tietojen poikkeavuuksia esiintyy vähemmän.

Mikä on tietojen poikkeama?

Oletetaan, että meillä oli tämä tilanne:

Taulukko A sisältää arvot ominaisuuksille X, Y, Z riville, jonka identifioi x : n tunnus ; nämä ovat väitteitä x: stä. Oletetaan, että rivillä x olevan Y: n väitetään olevan arvo 3.

Taulukko B sisältää myös samat väitteet miksi Y x: lle

Taulukolle A kerrotaan myöhemmin: ”Tosiasiat ovat muuttuneet. Y on nyt 4 ”

Taulukosta B kysytään myöhemmin ja sanotaan, että Y on edelleen 3.

Nyt A ja B väittävät kaksi eri tosiasiaa Y: stä riippuen siitä, mitä taulukkoa haet.

Se on tietojen poikkeama: kaksi erilaista väitettä tosiasiasta. Ja tosiasiat ovat tärkeitä tietokonejärjestelmissä.

Mitä ja miksi normaalilomakkeille

Käytän termiä tyyppi merkitsemään objektin metatietoja. Tämä voidaan toteuttaa luokan määritelmällä, mikillä, piirteellä, leimalla tai millä tahansa mekanismilla, jota mieltymyksesi ja valitsemasi kieli tukevat. Keskityn myös dataobjekteihin , kuten POJO, PODO, JSON ja vastaaviin yksinkertaisiin objekteihin.

Epävirallisesti ilmaistuna kolme ensimmäistä normaalia lomaketta kuvataan seuraavasti:

Ensimmäinen normaali muoto (1NF): Ei toistuvia elementtejä tai elementtiryhmiä

Toinen normaali lomake (2NF): Kaikki avaimen ulkopuoliset määritteet riippuvat kaikesta avaimesta

Kolmas normaalilomake (3NF): Ei riippuvuuksia muista kuin avainominaisuuksista

Se on melko kuiva lukeminen. Näiden periaatteiden soveltaminen objektityypin määrittelyihin on kuitenkin melko intuitiivista. Kun olet sisäistänyt nämä säännöt, et edes ajattele niitä tietoisesti uudelleen.

Objektit ovat myös suhteellisia

Relaatiotietokannat tukevat yhdistyksiä ensisijaisen ja ulkomaisen avaimen rajoitusten avulla. Hierarkiat ovat implisiittisiä, jos niitä on olemassa. Yhdistykset ovat löyhempiä kuin hierarkiat ja taksonomiat, mutta myös vaikeampi ajatella.

Hierarkiassa sinulla on vanhemman ja lapsen väliset suhteet. Usein on myös tietotyyppien hierarkia (luokka-alaluokka), joka on myös mallinnettu. Suhteet objektin suojarakennehierarkiassa ovat tiukempia, yleensä yksisuuntaisia ​​(vanhempi ja lapsi), mutta myös helpommin ymmärrettäviä kuin yleisempi (ja joustavampi) yhdistys.

1NF: Ei toistuvia elementtejä tai elementtiryhmiä

Sano, että meillä on seuraavat yhteystiedot:

Missä toistuvat elementit ovat?

  1. Nimimääritteet: tätä voidaan pitää yhdestä moneen -suhteena, jossa nimien lukumäärä on määrittelemätön (kuten brittiläinen rojaltimaksu). Käytännössä etu-, viimeinen ja mahdollisesti toinen nimi riittää useimmille sovellusalueille, joten ei ole todellista tarvetta normalisoida näitä kenttiä.
  2. puhelimet: Puhelimen ominaisuuksien toistaminen näyttää mahdolliselta ongelmalta: riittääkö kaksi puhelinta? Entä jos myöhemmin puhelinnumeroon liitetään lisätietoja, kuten käytettävissä oleva aika?
  3. osoiterivit: jälleen kerran, riittääkö kaksi? Joissakin maissa katuosoitteet voivat olla neljä riviä pitkiä, mutta se on raja. Koska ne ovat yksinkertaisia ​​merkkijonoja, ei ole tragediaa, jos yksi tai kaksi muuta osoiteriviä lisätään myöhemmin.

Tässä on mahdollinen malli, yhteystiedoilla ja puhelintyypeillä:

2NF: Kaikki avaimen ulkopuoliset määritteet riippuvat kaikesta avaimesta

Mitä tämä tarkoittaa englanniksi? Tietokannassa se tarkoittaa, että kaikkien rivin sarakkeiden tulisi olla suoraan riippuvaisia ​​kyseisen rivin ehdokasavaimista.

Katsotaanpa sitten Yhteystiedot uudelleen:

Täällä avain on luotu id-arvo, jota kutsutaan joskus korvaavaksi avaimeksi. Riippuvatko osoitteen määritteet yhteystunnuksesta? Hyvin…

Kaikki riippuu verkkotunnuksesta.

Kuusi osoitteen ominaisuutta eivät varmasti ole yhteystiedon attribuutteja, vaan ne ovat pikemminkin keinoja fyysisen sijainnin tunnistamiseksi. Yhteyshenkilöllä voi olla useita osoitteita, ja kenties sillä voi olla useita yhteystietoja.

Pitäisikö tämä mallintaa monta moneksi -suhteeksi joidenkin ContactAddress-objektityyppien kanssa, joilla on yhteystieto ja osoitetunnus? Se riippuu siitä, mikä on tärkeää sovellusalueellesi. Jotkut sovellukset saattavat pitää Yhteystietoja vahvana kokonaisuutena, riippumatta Osoitteesta, mutta Osoitteet kuin heikkoja kokonaisuuksia, riippuen Yhteystiedon olemassaolosta. Siinä tapauksessa yhdellä kontaktilla voi olla useita osoitteita, ja jokainen osoite viittaa yhteystietoon, kuten tämä:

On mahdollista tietojen poikkeavuus: jos muutat yhden yhteystiedon osoitetta, et muuta samaa osoitetta kaikille yhteystiedoille. Jos yhteystieto on ensisijainen lähdelähteesi, niin se voi olla toivottu käytös: yhteyshenkilösi siirtyy (esimerkiksi toiseen organisaatioon) ja loput kontaktit pysyvät paikallaan.

3NF: Ei riippuvuuksia muista kuin keskeisistä määritteistä

Kun tarkastelet osoitetta uudelleen, saatat havaita kaksi riippuvaa kenttää, alueen ja maan. Maalla voi olla tai ei ole alueita, mutta alueella on maa: et halua sekoittaa niitä.

Yksi tapa varmistaa, että alue kuuluu oikeaan maahan, on luoda tunniste kullekin (maa, alue) parille ja antaa sitten osoitteen viitata tunnukseen eikä alueeseen ja maahan itsenäisesti:

Sana luotuista tunnisteista

Luulen, että luodut tunnisteet ovat toteutuksen yksityiskohtia, ja niitä tarvitaan todellakin vain asiakaskoodille muutettaessa tai poistettaessa taustatietuetta (kuten tietokannan rivi), mutta ei koskaan vain luku-kyselyn osana. Järjestelmän käyttäjän ei myöskään pitäisi koskaan nähdä niitä, koska ne ovat merkityksettömiä.

Taulukko tyypin mukaan, taulukko tyypin hierarkian mukaan

Normalisoitujen objektityyppien siisti asia on, että ne kartoittuvat helposti relaatiotietokantataulukoihin. Relaatiotietokantatoteutusta varten taulukot peilaa objektityypit (taulukko tyypin mukaan) tai ainakin sisältävät tietoja useista perustyypistä johdetuista tyypeistä (taulukko tyypin hierarkiaa kohden). Tämä saattaa kuulostaa kannattavan objektisuhdekartoitusta, mutta ei ... Sanon vain, että on hyödyllistä, että loogisella mallillasi on samat fyysisen mallin ominaisuudet käsitteellisestitaso. Toteutus on kokonaan toinen aihe.

Viitteet

Suhdetietokantamallien normalisointiin on runsaasti resursseja:

Tietokannan normalisointi: ensimmäinen, toinen ja kolmas normaali muoto - Andrew Rollins

Luin suuren selityksen ensimmäisestä, toisesta ja kolmannesta normaalista muodosta muutama viikko sitten. Niille, jotka tietävät mitä tietokantaa ...

www.andrewrollins.com

Tietokannan toinen normaali muoto selitetty yksinkertaisella englanniksi

Toinen viesti keskittyi ensimmäiseen normaaliin muotoon, sen määritelmään ja esimerkkeihin sen lyömiseksi kotiin. Nyt on aika…

www.essentialsql.com

Mikä on toinen normaali muoto (2NF)? - Määritelmä Techopediasta

Toinen normaalilomake 2NF Määritelmä - Toinen normaalimuoto (2NF) on toinen vaihe tietokannan normalisoinnissa. 2NF rakentaa…

www.techopedia.com

Tietokanta Kolmas normaalilomake selitetty yksinkertaisella englanniksi

Kolmas viesti keskittyi toiseen normaalimuotoon, sen määritelmään ja esimerkkeihin sen lyömiseksi kotiin. Kun pöytä on…

www.essentialsql.com

Tutkiessani tätä viestiä törmäsin myös hieman erilaiseen otteeseen siitä, miten normalisointisääntöjä sovelletaan objektityyppeihin.

Johdatus luokan normalisointiin

www.agiledata.org