Introduktion til databaser

Hvis du vil holde dit design fokuseret, kan du opsummere formålet med databasen og ofte referere til oversigten. Hvis du f.eks. vil have en lille database til en hjemmebaseret virksomhed, kan du skrive noget simpelt, f.eks. "Kundedatabasen fører en liste over kundeoplysninger med henblik på at producere forsendelser og rapporter". For en virksomhedsdatabase skal du muligvis bruge flere afsnit for at beskrive, hvornår og hvordan personer i forskellige roller skal bruge databasen og dens data. Opret en specifik og detaljeret missionserklæring, som du kan referere til under hele designprocessen.

Start med dine eksisterende oplysninger og sporingsmetoder. Det kan f.eks. være, at du i øjeblikket registrerer indkøbsordrer i en hovedbog, eller at du opbevarer kundeoplysninger på papirformularer. Brug disse kilder til at få vist de oplysninger, du aktuelt registrerer (f.eks. alle felterne i formularerne). Hvis du i øjeblikket ikke registrerer vigtige oplysninger, skal du overveje, hvilke diskrete oplysninger du skal bruge. Hver enkelt datatype bliver til et felt i databasen.

Du skal ikke være bange for, at din første liste ikke bliver perfekt – du kan finjustere den med tiden. Men tænk på alle de personer, der bruger disse oplysninger, og spørg dem om deres idéer.

Dernæst skal du tænke over, hvad du vil have ud af databasen og de typer rapporter eller forsendelser, du vil producere. Derefter skal du sikre dig, at du henter de oplysninger, der er nødvendige for at nå disse mål. Hvis du f.eks. vil have en rapport, der viser salg efter område, skal du registrere salgsdataene på det regionale niveau. Prøv at skitsere rapporten med de faktiske oplysninger, som du gerne vil se den. Derefter skal du oprette en liste over de data, du skal bruge til at oprette rapporten. Gør det samme for forsendelser eller andre output, du vil have fra databasen.

Eksempel

Antag, at du giver kunder mulighed for at tilmelde sig (eller framelde sig) periodiske mailopdateringer, og du vil udskrive en liste over dem, der har tilmeldt sig. Du har brug for en Send mail-kolonne i Kundetabellen med de tilladte værdier Ja og Nej.

Hvis en af dem, der er villig til at modtage mails, har brug for en mailadresse, som også kræver et felt. Hvis du vil medtage en rigtig starthilsen (f.eks. hr., fru eller ms.), skal du medtage et starthilsenfelt. Hvis du vil henvende dig til kunder med deres fornavn i mails, skal du tilføje et felt med Fornavn.

Når du har din liste over påkrævede oplysninger, skal du fastlægge de overordnede enheder (eller emner), du skal bruge til at organisere dine data. Undgå at dublere data på tværs af enheder. Den foreløbige liste for en produktsalgsdatabase kan eksempelvis se således ud:

De overordnede enheder er: kunder, leverandører, produkter og ordrer. Start med disse fire tabeller: én til fakta om kunder, én til fakta om leverandører osv. Dette er muligvis ikke dit endelige design, men det er et godt udgangspunkt.

Hvis du vil forstå, hvorfor flere tabeller er bedre end færre, kan du tage et kig på den tabel, der vises her:

Hver række indeholder oplysninger om både produktet og dets leverandør. Da du kan have mange produkter fra den samme leverandør, skal oplysninger om leverandørens navn og adresse gentages mange gange. Det er spild af diskplads. Registrer i stedet kun leverandøroplysningerne én gang i en separat tabel Leverandører, og knyt derefter den pågældende tabel til tabellen Produkter.

Et andet problem med dette design fremgår tydeligt, når du vil redigere oplysninger om leverandøren. Antag, at du vil ændre en leverandørs adresse. Da den vises mange forskellige steder, ændrer du måske adressen ved et uheld ét sted, men glemmer at ændre den de andre steder. Du løser dette problem ved kun at registrere leverandørens adresse ét sted.

Et sidste scenarie kan være, at Coho Winery kun leverer ét produkt, som du gerne vil slette, men du vil gerne bevare oplysningerne om leverandørens navn og adresse. Hvordan vil du med dette design slette produktposten uden at miste leverandøroplysningerne? Det kan du ikke. Da hver post indeholder oplysninger om et produkt ud over oplysninger om en leverandør, er det umuligt at slette det ene uden også at slette det andet. Du kan derfor inddele denne tabel i to dele for at holde disse fakta adskilt: den første til produktoplysninger og den anden til leverandøroplysninger. Når du derefter sletter en produktpost, sletter du kun oplysningerne om produktet – ikke oplysninger om leverandøren.

Når du har valgt emnet for en databasetabel, bør kolonnerne i den pågældende tabel kun gemme oplysninger om det enkelte emne. Eksempelvis skal en produkttabel kun gemme oplysninger om produkter – ikke om deres leverandører.

Brug den liste, du oprettede tidligere, til at beslutte, hvilke oplysninger der skal spores i tabellen. Tabellen Kunder kan f.eks. omfatte: Fornavn, Efternavn, Adresse, Send mail, Starthilsen og Mailadresse. Hver post (kunde) i tabellen indeholder det samme sæt kolonner, så du gemmer præcis de samme oplysninger for hver kunde.

Opret din første liste, og gennemse og tilpas den derefter. Husk at opdele oplysninger i de mindst mulige felter. Hvis din første liste f.eks. har Adresse som et felt, skal du opdele det i Adresse, By, Stat og Postnummer – eller, hvis dine kunder er globale, i endnu flere felter. På den måde kan du f.eks. udføre forsendelser i det korrekte format eller rapportere om ordrer efter stat.

Når du har justeret datakolonnerne i hver tabel, er du klar til at vælge en primær nøgle for hver tabel.

Du har brug for en metode til at identificere hver række i hver tabel entydigt. Kan du huske eksemplet fra tidligere, hvor to kunder har det samme navn? Eftersom de deler et navn, skal du bruge en metode til at identificere hver enkelt.

Således bør hver tabel indeholde en kolonne (eller sæt af kolonner), som entydigt identificerer hver række. Dette kaldes den primære nøgle og er ofte et entydigt nummer, såsom et medarbejder-id eller et serienummer. Access bruger primære nøgler til hurtigt at tilknytte data fra flere tabeller og samle data for dig.

Nogle gange består den primære nøgle af to eller flere felter. Eksempelvis kan en tabel med ordredetaljer, der gemmer linjeelementer til ordrer, bruge to kolonner i den primære nøgle: Ordre-id og produkt-id. Når en primær nøgle anvender mere end én kolonne, kaldes den også en sammensat nøgle.

Hvis du allerede har et entydigt id for oplysningerne i en tabel, f.eks. produktnumre, som entydigt identificerer hvert produkt i dit katalog, kan du bruge dette, men kun hvis de opfylder disse regler for primære nøgler:

• Id’et vil altid være forskelligt for hver post. Dublerede værdier er ikke tilladt i en primær nøgle.

• Der er altid en værdi for elementet. Hver post i tabellen skal have en primær nøgle. Hvis du bruger flere kolonner til at oprette nøglen (f.eks. Delfamilie og Delnummer), skal begge værdier altid være til stede.

• Den primære nøgle er en værdi, der ikke ændres. Da nøglerne henviser til andre tabeller, betyder enhver ændring af en primær nøgle i en tabel en ændring af alt, hvad der henvises til. Hyppige ændringer øger risikoen for fejl.

Hvis du ikke har et indlysende id, kan du bruge et vilkårligt, entydigt nummer som den primære nøgle. Du kan f.eks. tildele hver ordre et entydigt ordrenummer med det eneste formål at identificere ordren.