Introduktion til Access 2013

Introduktion til databaser

Surface Book enhedsfoto

Prøv det!

Databaser og webapps kan give store forretningsfordele. Databasedesign er afgørende for at nå dine mål, uanset om du vil administrere medarbejderoplysninger, levere ugentlige rapporter med data eller spore kundeordrer. Bruger du tid på at forstå databasedesign, vil det hjælpe dig med at opbygge databaser, som virker rigtigt fra begyndelsen og giver plads til skiftende behov.

Vigtigt!: Access-webapps er forskellige fra skrivebordsdatabaser. Denne artikel omhandler ikke design af webapps.

Koncepter og begreber

Lad os starte med at lære nogle grundlæggende begreber og koncepter. Hvis du vil designe en nyttig database, skal du oprette tabeller, som fokuserer på et enkelt emne. I dine tabeller registrerer du alle de nødvendige data for det pågældende emne i felter, som indeholder den mindste dataenhed.

Relationsdatabaser

En database, hvor data er opdelt i tabeller, der er forskellige med hensyn til regneark. Hver tabel har kun ét emne, f. eks kunder (én tabel) eller produkter (en anden tabel).

Poster og felter

Lagerplads til de diskrete data i en tabel. Rækker (eller poster) gemmer hvert entydige datapunkt, f. eks navnet på en kunde. Kolonner (eller felter) isolerer de oplysninger, der hentes om hvert datapunkt, til den mindst mulige enhed – fornavnet kan være én kolonne og efter navn, der kan være en anden.

Primær nøgle

En værdi, der sikrer, at hver post er entydig. For eksempel kan der være to kunder med det samme navn, Elizabeth Andersens. Men en af Elizabeth Andersens-poster har tallet 12 som den primære nøgle, og den anden har en primær nøgle på 58.

Relation mellem overordnet-underordnet

Fælles relationer mellem tabeller. En enkelt kunde kan for eksempel have flere ordrer. Overordnede tabeller har primære nøgler. Underordnede tabeller har fremmede nøgler, som er værdier fra den primære nøgle, der viser, hvordan de underordnede tabelposter er sammenkædet med den overordnede tabel. Disse nøgler er knyttet til en relation.

Hvad er et godt databasedesign?

To principper er grundlæggende for et godt databasedesign:

  • Undgå dublerede oplysninger (også kaldet overflødige data). Det er spild af plads og øger risikoen for fejl.

  • Sørg for, at dataene er korrekte og fuldstændige. Ufuldstændige eller forkerte oplysninger flyder gennem forespørgsler og rapporter og kan i sidste ende føre til fejlinformerede beslutninger.

Som hjælp til disse problemer:

  • Opdel databaseoplysninger i emnebaserede tabeller med et smalt fokus. Undgå dublerede oplysninger i flere tabeller. (F. eks. bør kundenavne kun placeres i én tabel).

  • Sammenkæd tabellerne ved hjælp af nøgler i stedet for at dublere data.

  • Inkluder processer, der understøtter og sikrer databaseoplysningers nøjagtighed og integritet.

  • Design din database med dit behov for databehandling og -rapportering i tankerne.

Følg disse fem designtrin for at forbedre den langsigtede anvendelighed af dine databaser:

Trin 1: Fastlæg formålet med din database

Før du går i gang, skal du have et mål for din database.

Hvis du vil holde dit design fokuseret, kan du summere formålet med databasen og henvise til oversigten ofte. Hvis du vil have en lille database til en privat virksomhed, kan du f. eks. skrive en enkel, f. eks., "kundedatabasen indeholder en liste over kundeoplysninger med henblik på at fremlægge mails og rapporter". For en virksomhedsdatabase skal du muligvis bruge flere afsnit til at beskrive, hvornår og hvordan personer i forskellige roller skal bruge databasen og dens data. Opret en specifik og detaljeret missions erklæring, der skal referere til hele designprocessen.

Trin 2: Søg efter og organiser nødvendige oplysninger

Indhent alle de typer oplysninger, du vil registrere, f.eks. dine produktnavne og ordrenumre.

Start med de eksisterende oplysninger og registreringsmetoder. For eksempel kan du i øjeblikket registrere indkøbsordrer i et dokument, eller du kan opbevare kundeoplysninger i papirformularer. Brug disse kilder til at angive de oplysninger, du aktuelt registrerer (f. eks. alle felterne i dine formularer). Hvis du ikke registrerer vigtige oplysninger i øjeblikket, skal du overveje, hvilke diskrete oplysninger du har brug for. Hver enkelt datatype bliver til et felt i din database.

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.

Du skal nu overveje, hvad du vil have ud af databasen, og de typer af rapporter eller mails, du vil oprette. Kontrollér derefter, at du henter de oplysninger, der er nødvendige for at opfylde disse mål. Hvis du for eksempel ønsker en rapport, der viser salg efter område, skal du registrere salgsdataene på regionalt niveau. Prøv at skitsere rapporten med de faktiske oplysninger, som du gerne vil have vist. Derefter skal du angive de data, du vil bruge til at oprette rapporten. Gør det samme for mails 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 du vil modtage mails, skal du have en mailadresse, som også kræver et felt. Hvis du vil medtage en korrekt starthilsen (f. eks Mr., Mrs. eller MS.), skal du medtage et starthilsen felt. Hvis du vil adressere kunder ved hjælp af deres første navn i mails, skal du tilføje et felt af fornavn.

Tip!: Husk at opdele hver oplysning i den mindste nyttige del, f. eks fornavn og efter navn for en kundetabel. Hvis du vil sortere, søge, beregne eller rapportere på baggrund af et oplysningselement (f. eks. kundens efter navn), skal du indsætte det pågældende element i et separat felt.

Trin 3: Inddel oplysninger i tabeller

Inddel dine oplysningselementer i overordnede enheder eller emner såsom produkter, kunder og ordrer. Hvert emne bliver en tabel.

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:

Skærmbillede af oplysningselementer, der er inddelt i emner

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.

Bemærk!: De bedste databaser indeholder flere tabeller. Undgå, at Temptation placerer alle dine oplysninger i en enkelt tabel. Dette resulterer i dublerede oplysninger, større databasestørrelse og forbedrede fejl. Design til at optage hver oplysning lige én gang. Hvis du finder flere oplysninger, som f. eks en leverandøradresse, kan du omstrukturere databasen for at indsætte disse oplysninger i en separat tabel.

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

Skærmbillede af data om Produkter og Leverandører

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.

Trin 4: Omdan oplysningselementer til kolonner

Find ud af, hvilke oplysninger du skal gemme i hver tabel. Disse diskrete data bliver til felter i tabellen. For eksempel kan tabellen Medarbejdere medtage felter som efter navn, fornavn og ansættelsesdato.

Når du har valgt emnet for en databasetabel, bør kolonnerne i tabellen kun gemme fakta om det enkelte emne. For eksempel bør en produkttabel kun gemme kendsgerninger om produkter – ikke om deres leverandører.

Hvis du vil beslutte, hvilke oplysninger der skal spores i tabellen, skal du bruge den liste, du oprettede tidligere. Tabellen kunder kan f. eks.: fornavn, efter navn, adresse, Send mail, starthilsen og mailadresse. Hver post (kunde) i tabellen indeholder det samme sæt kolonner, så du kan gemme nøjagtigt de samme oplysninger for hver kunde.

Opret din første liste, og gennemse og afgræns den derefter. Husk at bryde oplysninger ned i de mindst mulige felter. Hvis din oprindelige liste for eksempel har adresse som et felt, skal du sætte det ind i adresse, by, stat og postnummer – eller, hvis dine kunder er globale, til endnu flere felter. På den måde kan du f. eks. gøre mails i det rigtige format eller en rapport 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.

Trin 5: Angiv primære nøgler

Vælg en primær nøgle for hver tabel. Den primære nøgle, såsom produkt-ID eller ordre-ID, identificerer entydigt hver post. Hvis du ikke har et tydeligt, entydigt id, kan du bruge Access til at oprette et for dig.

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. En tabel med Ordredetaljer, der gemmer linjeelementer for ordrer, kan for eksempel 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 det også for en sammensat nøgle.

Skærmbillede af tabellen Produkter

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 (som del familie og delnummer), skal begge værdier altid være til at være tilgængelige.

  • 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 synligt id, kan du bruge et vilkårligt, entydigt tal som primær nøgle. Du kan for eksempel tildele hver ordre et entydigt ordrenummer til det eneste formål at identificere ordren.

Tip!: Hvis du vil oprette et entydigt tal som den primære nøgle, skal du tilføje en kolonne ved hjælp af datatypen automatisk nummerering. Datatypen automatisk nummerering tildeler hver post en entydig, numerisk værdi. Denne type identifikation indeholder ingen faktuelle oplysninger, der beskriver den række, den repræsenterer. Det er ideelt til brug som primær nøgle, da tallene ikke ændres – i modsætning til en primær nøgle, der indeholder fakta om en række, ligesom et telefonnummer eller et kundenavn.

Vil du have mere?

Retningslinjer for navngivning af felter, kontrolelementer og objekter

Introduktion til tabeller

Kursus i Excel

Kursus i Outlook

Bemærk!:  Denne side er oversat ved hjælp af automatisering og kan indeholde grammatiske fejl og unøjagtigheder. Det er vores hensigt, at dette indhold skal være nyttigt for dig. Var disse oplysninger nyttige? Her er artiklen på engelsk, så du kan sammenligne.

Har du brug for mere hjælp?

Udvid dine Office-færdigheder
Gå på opdagelse i kurser
Få nye funktioner først
Bliv Office Insider

Var disse oplysninger nyttige?

Tak for din feedback!

Tak for din feedback! Det lyder, som om det vil kunne hjælpe, hvis du bliver sat i forbindelse med en af vores Office-supportteknikere.

×