Korvaava avain - Surrogate key

Korvike avain (tai synteettinen avain , pseudokey , entiteettitunniste , faktatonta avain , tai tekninen avain ), joka tietokanta on yksilöllinen tunniste joko yksikön mallinnetun maailmassa tai objekti tietokannassa. Korvaava avain ei johdu sovellustiedoista, toisin kuin luonnollinen (tai liiketoiminnan ) avain .

Määritelmä

Surrogaatilla on ainakin kaksi määritelmää:

Korvaaja (1) - Hall, Owlett ja Todd (1976)
Korvaava edustaa kokonaisuutta ulkomaailmassa. Korvaava tuote on järjestelmän sisäinen, mutta käyttäjä tai sovellus näkee sen.
Surrogaatti (2) - Wieringa ja De Jonge (1991)
Korvaava edustaa objektia itse tietokannassa. Korvaaja on järjestelmän sisäisesti luoma ja se on näkymätön käyttäjälle tai sovellukselle.

Surrogate (1) määritelmä koskee tietomallin sijasta varastointi malli ja sitä käytetään koko tämän artikkelin. Katso Päivämäärä (1998).

Tärkeä ero korvaavan ja ensisijaisen avaimen välillä riippuu siitä, onko tietokanta nykyinen vai ajallinen tietokanta . Koska nykyinen tietokanta tallentaa vain tällä hetkellä voimassa olevia tietoja, mallinnetun maailman sijaisen ja tietokannan ensisijaisen avaimen välillä on henkilökohtainen vastaavuus. Tässä tapauksessa korviketta voidaan käyttää ensisijaisena avaimena, jolloin tuloksena on termi korvikeavain . Ajallisessa tietokannassa ensisijaisten avainten ja sijaisen välillä on kuitenkin monenvälinen suhde. Koska tietokannassa voi olla useita kohteita, jotka vastaavat yhtä sijaissynnyttäjää, emme voi käyttää korviketta ensisijaisena avaimena; toinen ominaisuus vaaditaan sijaisen lisäksi kunkin kohteen yksilöimiseksi yksilöllisesti.

Vaikka Hall et ai. (1976) eivät sano tästä mitään, toiset ovat väittäneet, että korvikkeella pitäisi olla seuraavat ominaisuudet:

  • arvo on ainutlaatuinen koko järjestelmässä, joten sitä ei koskaan käytetä uudelleen
  • arvo luodaan järjestelmästä
  • arvoa ei voi muokata käyttäjä tai sovellus
  • arvo ei sisällä semanttista merkitystä
  • arvo ei näy käyttäjälle tai sovellukselle
  • arvo ei koostu useista arvoista eri toimialueilta.

Surrogaatit käytännössä

On nykyisen tietokannan , korvike avain voi olla ensisijainen avain , syntyy tietokannan hallintajärjestelmä ja ei peräisin mistä tahansa sovelluksen tiedot tietokantaan. Ainoavaimen ainoa merkitys on toimia ensisijaisena avaimena. On myös mahdollista, että korvaava avain on olemassa tietokannan luoman UUID - tunnuksen lisäksi (esimerkiksi jokaisen työntekijän HR-numero, joka ei ole kunkin työntekijän UUID).

Korvike avain on usein juokseva numero (esim Sybase tai SQL Server "identtisyys sarakkeessa", joka on PostgreSQL tai Informix serial , Oracle tai SQL Server SEQUENCE tai sarakkeen määritelty AUTO_INCREMENTsisään MySQL ). Jotkut tietokannat tarjoavat UUID- / GUID -tunnuksen mahdollisena tietotyypinä sijaisavaimille (esim. PostgreSQLUUID tai SQL ServerUNIQUEIDENTIFIER ).

Avaimen riippumattomuus kaikista muista sarakkeista eristää tietokannan suhteet tietoarvojen muutoksista tai tietokannan suunnittelusta (tekee tietokannasta ketterämmän ) ja takaa ainutlaatuisuuden.

Vuonna ajallinen tietokanta , on syytä erottaa toisistaan korvike avaimen ja liiketoiminnan keskeiset . Jokaisella rivillä olisi sekä liikeavain että korvaava avain. Korvaava avain tunnistaa yhden ainutlaatuisen rivin tietokannassa, liiketoiminta -avain yksilöi yhden ainutlaatuisen kokonaisuuden mallinnetusta maailmasta. Yksi taulukon rivi edustaa ajanjaksoa, joka sisältää kaikki entiteetin määritteet määrätyn ajanjakson ajan. Nämä viipaleet kuvaavat yhden liiketoimintayksikön koko elinkaaren. Esimerkiksi taulukko EmployeeContracts voi sisältää ajallisia tietoja seuratakseen sovittuja työaikoja. Yhden sopimuksen liiketoiminta-avain on identtinen (ei-ainutlaatuinen) molemmilla riveillä, mutta jokaisen rivin korvaava avain on yksilöllinen.

SurrogateKey BusinessKey Työntekijän nimi TyöajatPerWeek RowValidFrom RiviValidTo
1 BOS0120 John Smith 40 2000-01-01 2000-12-31
56 P0000123 Bob Brown 25 1999-01-01 2011-12-31
234 BOS0120 John Smith 35 2001-01-01 2009-12-31

Jotkut tietokannan suunnittelijat käyttävät korvaavia avaimia järjestelmällisesti riippumatta muiden ehdokasavainten soveltuvuudesta , kun taas toiset käyttävät datassa jo olevaa avainta, jos sellainen on.

Jotkut vaihtoehtoiset nimet ("järjestelmän luoma avain") kuvaavat tapaa luoda uusia korvaavia arvoja pikemminkin kuin sijaiskonseptin luonnetta .

Vaihtoehtoja korvikkeiden tuottamiseen ovat:

Edut

Vakaus

Korvausavaimet eivät yleensä muutu, kun rivi on olemassa. Tällä on seuraavat edut:

  • Sovellukset eivät voi menettää viittaustaan ​​tietokannan riville (koska tunniste ei muutu).
  • Ensisijaisia ​​tai luonnollisia avaintietoja voidaan aina muokata, vaikka tietokannat eivät tue päivitettyjen päivitysten liittämistä toisiinsa liittyviin vieraisiin avaimiin .

Vaatimukset muuttuvat

Määritteet, jotka yksilöivät kokonaisuuden yksilöllisesti, saattavat muuttua, mikä voi mitätöidä luonnollisten avainten soveltuvuuden. Harkitse seuraavaa esimerkkiä:

Työntekijän verkon käyttäjänimi valitaan luonnollisena avaimena. Sulautuessaan toisen yrityksen kanssa uusia työntekijöitä on lisättävä. Jotkut uusista verkon käyttäjätunnuksista aiheuttavat ristiriitoja, koska niiden käyttäjänimet luotiin itsenäisesti (kun yritykset olivat erillisiä).

Näissä tapauksissa luonnollinen avain on yleensä lisättävä uuteen määritteeseen (esimerkiksi sarake original_company ). Korvausavainta käytettäessä on vaihdettava vain taulukko, joka määrittelee korvaavan avaimen. Luonnollisilla avaimilla kaikki taulukot (ja mahdollisesti muut niihin liittyvät ohjelmistot), jotka käyttävät luonnollista avainta, on vaihdettava.

Jotkin ongelma -alueet eivät tunnista selkeästi sopivaa luonnollista avainta. Korvaavat avaimet eivät välttämättä valitse väärää luonnollista avainta.

Esitys

Korvaava avain on yleensä kompakti tietotyyppi, kuten neljän tavun kokonaisluku. Tämä mahdollistaa tietokannan kyselyn yksittäisestä avainsarakkeesta nopeammin kuin se voisi tehdä useita sarakkeita. Lisäksi avainten ei-redundanttijako saa tuloksena olevan b-puu- indeksin täysin tasapainoiseksi. Korvaavat avaimet ovat myös halvempia liittyä (vähemmän sarakkeita vertailtavaksi) kuin yhdistelmäavaimet .

Yhteensopivuus

Vaikka käytät useita tietokannasovellusten kehittämisjärjestelmiä, ohjaimia ja objekti-relaatiokartoitusjärjestelmiä , kuten Ruby on Rails tai Hibernate , on paljon helpompaa käyttää kokonaisluku- tai GUID-sijaavaimia jokaiseen taulukkoon luonnollisten avainten sijaan tietokannan tukemiseksi. järjestelmäagnostiset toiminnot ja objektien välinen kartoitus.

Tasaisuus

Kun jokaisella taulukolla on yhtenäinen sijaisavain, jotkut tehtävät voidaan helposti automatisoida kirjoittamalla koodi taulukosta riippumattomalla tavalla.

Validointi

On mahdollista suunnitella avainarvoja, jotka noudattavat tunnettua mallia tai rakennetta ja jotka voidaan automaattisesti tarkistaa. Esimerkiksi avaimet, jotka on tarkoitettu käytettäväksi jonkin taulukon jossakin sarakkeessa, voidaan suunnitella "näyttämään erilaiselta" kuin ne, jotka on tarkoitettu käytettäväksi toisessa sarakkeessa tai taulukossa, mikä helpottaa niiden sovellusvirheiden havaitsemista, joissa avaimet ovat menneet väärään paikkaan. Tätä sijaisavainten ominaisuutta ei kuitenkaan saa koskaan käyttää minkään sovelluksen logiikan ohjaamiseen, koska se rikkoisi tietokannan normalisoinnin periaatteita .

Haitat

Erottaminen

Luotujen sijaisavainten arvoilla ei ole mitään yhteyttä peräkkäisten tietojen todelliseen merkitykseen . Tarkastettaessa riviä, jolla on vieraan avaimen viittaus toiseen taulukkoon, käyttämällä korvaavaa avainta, korvaavan avaimen rivin merkitystä ei voida erottaa avaimesta itsestään. Jokainen vieras avain on yhdistettävä, jotta siihen liittyvä tieto voidaan nähdä. Jos asianmukaisia ​​tietokantarajoituksia ei ole asetettu tai tietoja tuodaan vanhasta järjestelmästä, jossa viite-eheyttä ei käytetty, on mahdollista saada vieraan avaimen arvo, joka ei vastaa ensisijaisen avaimen arvoa ja on siksi virheellinen. (Tältä osin CJ Date pitää sijaavainten merkityksettömyyttä etuna.)

Tällaisten virheiden löytämiseksi on suoritettava kysely, joka käyttää ulkoista avainta sisältävän taulukon ja ensisijaisen avaimen taulukon välistä vasenta ulkoista liitosta , joka näyttää molemmat avainkentät tietueen erottamiseen tarvittavien kenttien lisäksi. kaikkien virheellisten vieraan avaimen arvojen ensisijaisen avaimen sarake on NULL. Tällaisen tarkistuksen tarve on niin yleinen, että Microsoft Access tarjoaa itse asiassa ohjatun "Etsi vertaansa vailla olevan kyselyn", joka luo sopivan SQL: n sen jälkeen, kun käyttäjä on käynyt läpi valintaikkunan. (Tällaisten kyselyiden kirjoittaminen manuaalisesti ei kuitenkaan ole liian vaikeaa.) "Etsi vertaansa vailla olevia" -kyselyitä käytetään tyypillisesti osana tietojen puhdistusprosessia , kun peritään vanhoja tietoja.

Korvaavat avaimet ovat luonnotonta viedylle ja jaetulle datalle. Erityinen ongelma on se, että kahden muuten identtisen kaavan (esimerkiksi testiskeeman ja kehityskaavion) ​​taulukoihin voi sisältyä tietueita, jotka ovat liiketoiminnallisesti samanarvoisia, mutta joilla on eri avaimet. Tätä voidaan lieventää EI viemällä korvaavia avaimia, paitsi ohimenevänä datana (ilmeisimmin suorittaessaan sovelluksia, joilla on "live" -yhteys tietokantaan).

Kun korvaavat avaimet korvaavat luonnolliset avaimet, verkkotunnuskohtainen viite -eheys vaarantuu. Esimerkiksi asiakkaan päätaulukossa samalla asiakkaalla voi olla useita tietueita erillisten asiakastunnusten alla, vaikka luonnollinen avain (yhdistelmä asiakkaan nimeä, syntymäaikaa ja sähköpostiosoitetta) olisi ainutlaatuinen. Kompromissien estämiseksi taulukon luonnollista avainta EI saa korvata: se on säilytettävä ainutlaatuisena rajoituksena , joka toteutetaan ainutlaatuisena indeksinä luonnollisen avaimen kenttien yhdistelmälle.

Kyselyn optimointi

Suhteelliset tietokannat olettavat , että taulukon ensisijaiseen avaimeen sovelletaan yksilöllistä indeksiä . Ainutlaatuisella indeksillä on kaksi tarkoitusta: (i) pakottaa kokonaisuuden eheys, koska ensisijaisten avaintietojen on oltava yksilöllisiä riveillä ja (ii) etsiä rivejä nopeasti, kun niitä kysytään. Koska korvaavat avaimet korvaavat taulukon tunnistemääritteet - luonnollisen avaimen - ja koska tunnistemääritteet ovat todennäköisesti kyselyitä, kyselynoptimointityökalu on pakko suorittaa täydellinen taulukon tarkistus, kun se täyttää todennäköiset kyselyt. Korjaus koko taulukon skannaukseen on indeksien käyttäminen tunnistaviin määritteisiin tai niiden joukkoihin. Jos tällaiset joukot ovat itse ehdokasavaimia , indeksi voi olla ainutlaatuinen indeksi.

Nämä lisäindeksit vievät kuitenkin levytilaa ja hidastavat lisäyksiä ja poistoja.

Normalisointi

Korvaava avain voi johtaa päällekkäisiin arvoihin missä tahansa luonnollisessa avaimessa . Päällekkäisyyksien välttämiseksi on säilytettävä luonnollisten avainten rooli ainutlaatuisina rajoituksina määritettäessä taulukkoa joko SQL: n CREATE TABLE -käskyn tai ALTER TABLE ... ADD CONSTRAINT -lausekkeen avulla, jos rajoitukset lisätään jälkikäteen.

Liiketoimintaprosessien mallintaminen

Koska korvaavat avaimet ovat luonnotonta, virheitä voi ilmetä liiketoimintavaatimusten mallinnuksessa. Liiketoiminnan vaatimukset, jotka perustuvat luonnolliseen avaimeen, on käännettävä korvaavaksi. Strategia on tehdä selvä ero loogisen mallin (jossa sijaisavaimet eivät näy) ja kyseisen mallin fyysisen toteutuksen välillä, jotta voidaan varmistaa, että looginen malli on oikea ja kohtuullisen hyvin normalisoitu, ja varmistaa, että fyysinen malli on loogisen mallin oikea toteutus.

Tahaton paljastaminen

Omistajan tietoja voi vuotaa, jos korvaavat avaimet luodaan peräkkäin. Vähentämällä aiemmin luotu peräkkäinen avain äskettäin luodusta peräkkäisestä avaimesta voidaan oppia lisätyn rivin määrä kyseisenä ajanjaksona. Tämä voi paljastaa esimerkiksi tapahtumien tai uusien tilien määrän kauden aikana. Katso esimerkiksi saksalainen säiliöongelma .

On olemassa muutamia tapoja ratkaista tämä ongelma:

  • suurenna peräkkäistä lukua satunnaisella määrällä;
  • Luo satunnainen avain, kuten UUID .

Tahattomia oletuksia

Peräkkäisesti luodut sijaisavaimet voivat merkitä sitä, että tapahtumat, joilla on suurempi avainarvo, tapahtuivat tapahtumien jälkeen, joilla on pienempi arvo. Tämä ei välttämättä ole totta, koska tällaiset arvot eivät takaa aikasekvenssiä, koska insertit voivat epäonnistua ja jättää aukkoja, jotka voidaan täyttää myöhemmin. Jos kronologia on tärkeä, päivämäärä ja kellonaika on kirjattava erikseen.

Katso myös

Viitteet

Lainaukset

Lähteet