27.03.06 • 1 kommentar
Fra tid til annen får jeg spørsmål om hvordan søking i databaser fungerer, for eksempel i søkemotorer. La det være sagt med en gang: Dette er et svært omfattende fagområde, og jeg er slett ingen guru på området. Hos min arbeidsgiver har vi ansatte som er sertifiserte på området, og som kun driver med databaser, det være seg installasjon, oppsett, drift og ikke minst optimalisering. Jeg er ikke en av de, men vil allikevel besvare det mest banale i denne artikkelen.
En database består av minst en tabell, som igjen består av minst en kolonne og en post. Et eksempel kan være et personregister, illustrert med en tabell vi kaller “personregister”, slik:
| Personnr | Fornavn | Etternavn | Adresse | Postnr | Sted | Telefon |
|---|---|---|---|---|---|---|
| 012345678901 | Ola | Nordmann | Veien 1 | 0123 | Oslo | 12345678 |
| 10987654321 | Kari | Nordmann | Veien 2 | 0123 | Oslo | 23456789 |
| 23456789012 | Jens | Nordmann | Veien 3 | 0123 | Oslo | 34567890 |
Når man skal gjøre søk i denne tabellen, vil det ved første øyekast være naturlig å lete igjennom hver eneste post i tabellen, for så å sjekke hvilke poster som matcher søkekriteriet. Det sier seg selv at dette vil ta uholdbart lang tid dersom tabellen inneholder mange poster. Derfor oppretter vi det vi kaller en indeks. En indeks kan kort beskrives som en innholdsfortegnelse, og opprettes som en egen, frittstående tabell i databasen, slik:
| Personnr |
|---|
| 012345678901 |
| 10987654321 |
| 23456789012 |
Et søk i en tabell uten indeks kalles “Table Scan” fordi søket ikke utføres mot en indeks (altså i indeks-tabellen), men i stedet går igjennom hver eneste post i tabellen.
Det opereres også med såkalte unike indekser. En unik indeks kun vil forekomme i én post i tabellen. I eksemplet over vil “Personnr” typisk være en unik indeks, da personnummeret er unikt for hver person. Forskjellen er at databasen vil stoppe søket i en unik indeks, når søkestrengen treffes, mens den vil søke igjennom hele indeksen i en vanlig indeks. En indeks kobles til en kolonne i hver tabell, omtrent slik:

Det kan opprettes en eller flere indekser per tabell, men det er viktig at designeren og utvikleren ikke oppretter for mange og store indekser, da dette fort kan få motsatt effekt, og går ut over hastigheten. Eksempelvis kan det i tillegg til “Personnr” kan det for eksempel opprettes en indeks på “Fornavn”, slik:
| Fornavn |
|---|
| Ola |
| Kari |
| Jens |
Vi sitter da igjen med selve tabellen og to indekser, slik:

På denne måten kan man legge til en indeks for hver kolonne i tabellen. Bakdelen er at også indeksene må vedlikeholdes. Det vil si at hvis programvaren skal gjøre en endring i en post, for eksempel endre etternavnet til Kari Nordmann til Hansen når hun gifter seg, vil databasen måtte skrive til samtlige indekstabeller, og således gå kraftig ut over hastigheten.
Et søk sendes til databasen fra programvarelaget via forretningslaget. I databasen vil et søk bli utført som en SQL-spørring, for eksempel:
Søket vil returnere hele tabellen, mens et begrenset søk, for eksempel på personnummer, kun vil returnere de utvalgte data.
Dette er som nevnt en ekstrem forenkling, men det er prinsippet som er poenget.
Med RSS kan du abonnere på nye kommentarer som postes til denne artikkelen.
Du kan legge igjen et trackback fra ditt eget nettsted ved å benytte trackback-adressen til denne artikkelen. Eventuelle tracback ser du under.
Enda flere artikler? Besøk arkivet.
Bekkelund.net er en blogg av Martin Bekkelund, hvor han lufter sine tanker om IT og IT-politikk. Martin arbeider til daglig som seniorrådgiver, foredragsholder og skribent i IT-bransjen, hvor han veileder bedrifter og organisasjoner i strategisk bruk av IT. Les mer...
© 1995-2012 Martin Bekkelund
Opphavsrett • RSS • Kontakt
Torbjørn Kravdal
28. mars 2006 13.15
Jeg kan også bare litt database-teori, men dette var en grei forklaring på indeksering! Neste artikkel må bli en forklaring på koblinger mellom tabeller (en-en og en-mange)…