Avsnittene nedenfor viser hvordan databasetabellrelasjonene ble utformet. Objektnavnene angis, slik at du enkelt kan undersøke dem i Northwind 2.0 Starter Edition-databasen.
Hvis du vil åpne relasjonsdiagrammet som viser de seks tabellene og relasjonene mellom dem, velger du Databaseverktøy > Relasjoner.
Dette diagrammet viser alle seks tabellene. I diagrammet identifiserer linjer mellom tabeller relasjoner mellom dem. 1- og uendeligsymbolet (∞) på slutten av linjene representerer én side av en relasjon (for eksempel én kunde) og mange-siden av en relasjon. Én kunde sender for eksempel inn mange ordrer. Hvis du vil ha mer informasjon, kan du se Veiledning for tabellrelasjoner.
Følgende prinsipper gjelder for tabeller i Northwind 2.0 Starter Edition samt tabeller generelt.
Primærnøkler Identifiser hver post i en tabell unikt. Alle tabeller har en primærnøkkel. Nøkkelsymboler identifiserer disse primærnøklene i relasjonsdiagrammet. Primærnøkkelnavnekonvensjoner er oppkalt etter tabellen de er i, for eksempel «TableNameID».
Effektivitet Primærnøkler bør være numeriske for bedre ytelse og mer effektiv lagring. I tillegg er det mer praktisk å la Access automatisk generere den nye, unike verdien for primærnøkkelen for hver nye post. Datatypen Autonummerering har begge egenskapene. Autonummer er ellers ikke-meningsfulle tall og tjener ikke noe annet formål. Hvis du vil ha mer informasjon, kan du se Legge til et Autonummer-felt som primærnøkkel.
Sekundærnøkler En tabell kan også ha én eller flere sekundærnøkler, avhengig av om den er relatert til andre tabeller i databasen. En sekundærnøkkel inneholder verdier som tilsvarer verdier i primærnøkkelen for den relaterte tabellen.
Unike indekser Andre felt i tabeller kan også ha sine egne unike indekser, for eksempel OrderStatus.StatusCode. Det er ulogisk å ha to ordrestatuser i OrderStatus-tabellen med samme kode, selv om StatusCode i seg selv ikke er primærnøkkelen. En unik indeks ber Access om å forhindre dupliserte verdier i dette feltet.
Ikke-unike indekser Tabeller kan også ha indekser for å øke hastigheten på søk og sorteringer i disse feltene, for eksempel Orders.OrderDate. Mange bestillinger kan legges inn på samme dag, og du vil ofte søke etter og sortere etter ordredatoer. Det finnes en ikke-unik indeks på dette feltet for å øke hastigheten på søking og sortering.
Tabell- og feltnavn Du kan gi navn til ting slik du vil, men konsekvens er viktig. Vi anbefaler at tabell- og feltnavn bør være ett eller flere ord uten mellomrom mellom dem, og ingen spesialtegn, for eksempel skråstrek (/), nummertegn (#) eller prosent (%). Bruk for eksempel Ordredato, men ikke Ordredato. bruk OrderNumber eller OrderNo, men ikke Order#.
Camelcase Bruk stor forbokstav i ord for å utheve individuelle deler av navnet, for eksempel OrderDate, men ikke Orderdate eller orderDate.
Obligatorisk verdi Dette prinsippet viser viktigheten av forretningsregler for et program. Noen situasjoner krever verdier eller bestemte verdier i enkelte felt. Hva er for eksempel en bestilling uten å kjenne kunden som plasserte den? Det betyr at CustomerID er et obligatorisk felt for Ordrer-tabellen.
Beregnede felt Access støtter beregnede felt i tabeller, for eksempel Ansatte.FullName-feltet. Du foretrekker kanskje å opprette beregnede felt i en spørring i stedet for i en tabell.
Vedleggsfelt Access støtter vedleggsfelt, for eksempel Ansatte.Bilde, som inneholder et bilde av den ansatte. Vedlegg kan lagre bilder, dokumenter, e-postmeldinger og annen binær informasjon. Vedlegg bruker mye plass i databasen. det er mer effektivt å lagre vedlegg på en filserver i stedet.
Felt med flere verdier Som navnet tilsier, lagrer felt med flere verdier én eller flere verdier i ett enkelt felt, for eksempel Ansatte.Tittel. Vi foreslår at du bruker dem med måte, spesielt hvis du vil oppskalere databasen. De fleste andre databasesystemer har dem ikke, så det krever mye arbeid på nytt.
Hvis du vil ha mer informasjon om datatyper, kan du se Innføring i datatyper og feltegenskaper.
Denne delen tar for seg de viktigste funksjonene i hver tabell. Hvis du vil se gjennom utformingen av en tabell, merker du den i navigasjonsruten, høyreklikker den, velger Utformingsvisning eller velger Databaseverktøy > Relasjoner, og høyreklikker deretter et tabellobjekt. Hvis du vil ha mer informasjon, kan du se Innføring i tabeller.
Viktig!: Unngå bruk av reserverte ord som kan føre til navngivningskonflikter. Hvis du vil ha mer informasjon, kan du se Lær om reserverte ord og symboler i Access.
Ansatte-tabell
Denne tabellen inneholder informasjon om Northwinds ansatte.
|
Felt |
Beskrivelse |
|
Fornavn, Etternavn |
Begge navnene er obligatoriske, og i Northwind må de sammen være en unik kombinasjon. Når du åpner dialogboksen Indekser i tabellutformingen, kan du se at Fornavn + Etternavn har en unik indeks. Siden Fornavn og Etternavn er unikt indeksert, kan ikke Northwind-tabellen lagre to ansatte med samme navn. I andre situasjoner kan du bruke en annen forretningsregel. |
|
FullNameFNLN, FullNameLNFN |
Se på uttrykksegenskapen for beregnede felt for å se hvordan Access kombinerer verdier i beregnede felt. Hvis du vil inkludere en initial i midten, legger du det til i det eksisterende uttrykket med riktig avstand mellom komponenter. |
|
Telefonfelt |
Forretningsregelen for telefoner er at de ansattes preferanser er mer relevante enn tjenestetypen. Derfor brukes primære og sekundære telefonnumre i stedet for celle, kontor, hjemme og så videre. |
|
Hilsen |
Hilsen er et kort tekstfelt. For å illustrere funksjonen for felt med flere verdier i Access, er det en kombinasjonsboks med en redigerbar liste over forhåndsdefinerte verdier. Korte, statiske lister som dette er ofte kandidater for flerverdifelt fordi de ikke endrer mye, om noen gang. |
|
JobTitle |
JobTitle er et annet obligatorisk felt. |
Kundetabell
Denne tabellen inneholder informasjon om Northwinds kunder.
|
Felt |
Beskrivelse |
|
CustomerName |
Northwinds kunder er bedrifter, og det kreves et kundenavn. I motsetning til ansattnavn er det imidlertid ikke unikt indeksert, slik at to eller flere kunder kan ha samme navn. |
|
PrimaryContactFirstName, PrimaryContactLastName, PrimaryContactJobTitle |
Primærkontaktens for- og etternavn og stilling kreves ikke fordi kunder kanskje ikke har én person som primærkontakt. Kontakter kan ikke gi jobbtittelen sin for en ordre. |
|
BusinessPhone |
Northwind krever bare ett telefonnummer for hver kunde, selv om dette eliminerer muligheten til å registrere flere telefonnumre for kunder eller kontakter fra kunder. I virkelige situasjoner gjelder vanligvis mer komplekse forretningsregler for kontaktinformasjon. |
|
Adresse, poststed Delstat, ZIP |
Northwind trenger en adresse for å sende ordrer til kunder. Det finnes bare én generell adresse for en kunde. I virkelige situasjoner har kunder ofte separate fakturerings-, leverings- eller andre adresser. En annen forretningsregel for organisasjonen krever flere felt. |
|
Merknader |
Notater-feltet er en datatype for lang tekst, som lagrer opptil 1 GB tekst. Dette gjør at du kan skrive inn detaljerte kommentarer om kunder for bruk i etterfølgende bestillingssituasjoner. |
Ordretabell
Denne tabellen inneholder informasjon om Northwinds ordrer.
|
Felt |
Beskrivelse |
|
Ordredato, SendtDato, Betaltdato |
Ordrer krever tre datoer. De er alle datatype for dato/klokkeslett, men med to formater. OrderDate har både en dato og et klokkeslett fordi du kanskje er interessert i å analysere ordrevolum for ulike deler av dagen. Bare datoen er nødvendig for de to andre datoene. En tabellvalideringsregel for ShippedDate og PaidDate sikrer at disse datoene ikke er før Ordredato. |
|
OrderStatusID |
Ordrestatusen angir hvor rekkefølgen er i Northwind-arbeidsflyten. Ordrer går gjennom fire faser: Ny – > fakturert – > Sendt – > Lukket.Sekundærnøkkelen for gjeldende OrderStatus bruker OrderStatusID fra oppslagstabellen OrderStatus. Hvis du bruker en statusoppslagstabell, sikrer du at bare de fire forhåndsdefinerte statusene kan tilordnes til en ordre. |
Ordredetaljer-tabell
Denne tabellen inneholder informasjon om Northwinds ordredetaljer.
|
Felt |
Beskrivelse |
|
Ordreid |
Hvert linjeelement i Ordredetaljer-tabellen må tilhøre én ordre i Ordrer-tabellen. OrderID er en sekundærnøkkel som identifiserer denne rekkefølgen. Som nevnt tidligere illustrerer én rekkefølge som inneholder ett eller flere linjeelementer en én-til-mange-relasjon. |
|
Produksjon |
Hver post i Ordredetaljer-tabellen inkluderer produkt-ID-en for produktet som er bestilt. ProductID er en sekundærnøkkel i OrderDetails-tabellen, som identifiserer produktet i den rekkefølgen. Dette er også en én-til-mange-relasjon. |
|
OrderID+ ProductID |
Som du så i Ansatte-tabellen, kan flere felt ha en unik indeks. Den unike indeksen over OrderID+ProductID i OrderDetails-tabellen sikrer at hver ordre bare inneholder et produkt én gang. Når du åpner egenskapsarket Indekser fra båndet, kan du se denne unike indeksen. |
Produkttabell
Denne tabellen inneholder informasjon om Northwinds produkter.
|
Felt |
Beskrivelse |
|
ProductCode |
I tillegg til primærnøkkelen, ProductID, har Northwind-produkter en menneskelig vennlig, unik indeksert, produktkode. Ansatte refererer vanligvis til produktkoder som ikke er primærnøkkelverdier. Produktkoden er en sammensatt verdi som består av en kategoriangivelse og et tall, for eksempel B-1 for «Drikkevare», produkt 1. |
|
Produktnavn, Produktbeskrivelse |
I tillegg til korte produktnavn for tekst, gjelder en lang tekstbeskrivelse for produkter. Denne verdien kan brukes i en katalogbeskrivelse eller til å svare på kundespørsmål. |
|
Enhetspris |
Alle produkter selges med en enhetspris for hver vare som forenkler databasen som en presentasjon av funksjoner. I de fleste virkelige situasjoner, priser er ofte betydelig mer komplisert. |
Se også
