Å vite akkurat nok om relasjonsdatabaser

June 12  by Eliza

Bygge et system i Oracle eller noen andre relasjonsdatabase produktet ikke automatisk gjøre det til en relasjonsdatabase. På samme måte kan du designe en perfekt god relasjonsdatabase og implementere den i noe annet enn en relasjonsdatabase produkt. Vi diskuterer to viktige områder:

  • Hva folk mener med relasjonsdatabase gjør?
  • Hva er Oracle relasjonsdatabase produkt?

Hva gjør en database "relasjonell"?

Når en database som er beskrevet som relasjonelt, har det blitt utformet for å samsvare (i det minste for det meste) til et sett av fremgangsmåter som kalles reglene for normalisering. Et normalisert database er en som følger reglene for normalisering.

For eksempel, i en organisasjon, har du ansatte som jobber i bestemte avdelinger. Hver ansatt og avdelingen har et nummer og et navn. Man kunne organisere denne informasjon slik det er vist i tabell 1.

Tabell 1: Eksempel på Employee Informasjon

Empno Ename AVDNR DEPTNAME
101 Abigail 10 Markedsføring
102 Bob 20 Innkjøp
103 Carolyn 10 Markedsføring
104 Doug 20 Innkjøp
105 Evelyn 10 Markedsføring

Hvis du strukturere dine data på denne måten og gjøre visse endringer i den, vil du ha problemer. For eksempel vil slette alle de ansatte i innkjøpsavdelingen eliminere avdelingen selv. Hvis du endrer navnet på markedsføringsavdelingen til "Reklame", ville du trenger å endre registrering av hver ansatt i den avdelingen.

Bruke prinsippene for relasjonsdatabaser, kan de ansatte og Avdeling data bli omstrukturert i to separate tabeller (dept og EMP), som vist i tabell 2 og 3.

Tabell 2: En Sample Relasjons DEPT Table

AVDNR DEPTNAME
10 Markedsføring
20 Innkjøp

Tabell 3: En Sample Relasjons EMP Table

Empno Ename AVDNR
101 Abigail 10
102 Bob 20
103 Carolyn 10
104 Doug 20
105 Evelyn 10

Ved å bruke denne strukturen, kan du undersøke EMP tabellen for å finne ut at Doug jobber i avdeling 20. Deretter kan du sjekke DEPT tabellen for å finne ut at avdeling 20 er innkjøpssjef. Du tenker kanskje at tabell 1 ser mer effektiv. Men å hente den informasjonen du trenger på en rekke forskjellige måter er mye enklere med to-tabellen struktur. Bli med informasjonen i de to tabellene for mer effektiv gjenfinning er akkurat det problemet at relasjonsdatabaser ble utviklet for å løse.

Når tabellene er implementert i databasen, er informasjonen i de to tabellene knyttet ved hjelp av spesielle kolonner kalles fremmednøkler. I eksemplet er den AVDNR kolonne fremmednøkkelen knytte avdeling og medarbeider tabeller.

Tabellene 4 og 5 viser en annen felles database struktur, nemlig en kjøpsordre (PURCH_ORDER tabell) for en vare og informasjons detaljene knyttet til innkjøpsordren (PURCH_ORDER_DTL tabell).

Tabell 4: En Sample Relasjons PURCH_ORDER Table

PO_Nbr Dato
450 12.10.2006
451 2/26/2006
452 3/17/2006
453 6/5/2006

Tabell 5: En Sample Relasjons PURCH_ORDER_DTL Table

PO_Nbr Line_Nbr Element Antall Pris
450 1 Hammer 1 $ 10,00
451 1 Skrutrekker 1 $ 8,00
451 2 Tang 2 $ 6,50
451 3 Wrench 1 $ 7,00
452 1 Wrench 3 $ 7,00
452 2 Hammer 1 $ 10,00
453 1 Tang 1 $ 6,50

En innkjøpsordre kan inneholde mange elementer. Tabell 5 viser at innkjøpsordre 451 inkluderer tre separate elementer. Linken (fremmednøkkel) mellom bordene er innkjøpsordrenummeret.

Forstå grunnleggende database terminologi

En database består av tabeller og kolonner, som beskrevet i foregående avsnitt. Det er noen andre vilkår du trenger å vite for å forstå hvordan databaser fungerer. En database er bygget i to trinn. Først oppretter du en logisk datamodell for å legge ut utformingen av databasen og hvordan dataene vil bli organisert. Så du implementere databasen i henhold til den fysiske datamodellen, som setter opp selve tabeller og kolonner. Forskjellig terminologi gjelder elementer av de logiske og fysiske utførelser. I tillegg relasjonsdatabase designere bruker forskjellige ord fra objektorientert (OO) database designere til å beskrive databaseelementene. Tabell 6 viser ordene som brukes i hvert av disse tilfellene.

Tabell 6: Database Design Terminologi

Logisk / Relasjons Logisk / Objektorientert Fysisk Implementering
Entity Klasse Bord
Attributt Attributt Kolonne
Forekomst Objekt Rad

Definisjonene av ordene i Tabell 6 er som følger:

  • Entity: En enhet tilsvarer noe i den virkelige verden som er av interesse og at du ønsker å lagre informasjon om. Eksempler på enheter inkluderer ting som for eksempel avdelinger i en organisasjon, ansatte, eller salg. Hver bestemt avdeling eller ansatt anses en forekomst av denne enheten. For eksempel i tabell 3, er Doug en forekomst av foretaket Employee. (I OO verden, ville Doug være et objekt i Employee klassen.)
  • Attributt: Dette ordet er brukt i både relasjonelle og OO databaser for å representere informasjon om en enhet forekomst eller et objekt som skal spores. Et eksempel på et attributt kan være fødselsdato eller personnummer til en ansatt.
  • Enheter (klasser), deres attributter, og forekomster (objekter): Disse er implementert i databasen som tabeller, kolonner og rader hhv.

En ekstra viktig begrep for å forstå når du arbeider med relasjonsdatabaser er primærnøkkelen. En primærnøkkel identifiserer en bestemt forekomst av en enhet. Ikke to tilfeller av et foretak kan ha samme primærnøkkel. Verdiene av alle deler av primærnøkkelen må aldri være null. De vanligste typene av primærnøkler i relasjonsdatabaser er ID-numre. For eksempel, i tabell 3, kan det EmpID være hovednøkkel. Noen ganger mer enn en egenskap (eller sett av attributter) kan brukes som en primærnøkkel. Disse egenskapene kalles kandidatnøkler, ett sett som må utpekt som primærnøkkel.