Kardinalitet (datamodellering)

Innen datamodellering viser **kardinaliteten** til en skjøt (*join*) til den numeriske relasjonen mellom radene i en tabell og radene i en annen tabell. Noen vanlige kardinaliteter inkluderer *en-til-en* (ofte redundant), *en-til-mange* (svært vanlig), og *mange-til-mange* (ikke uvanlig, men krever en logikk). *Mange-til-en* er mindre vanlig.

Kardinalitet brukes for eksempel til å bestemme hvordan man skal knytte sammen faktatabeller og dimensjonstabeller.

* En *[[En-til-mange (datamodellering)|en-til-mange]]-*kardinalitet brukes for eksempel noen ganger for å knytte én rad i en dimensjonstabell (som inneholder relasjonsinformasjon om dimensjonen) til en kolonne i en faktatabell (som inneholder for eksempel måleverdier). En-til-mange kardinalitet er vanlig i mange tilfeller.
* En *[[Mange-til-mange (datamodellering)|mange-til-mange]]*-kardinalitet kan medføre tvetydigheter, og bør i noen tilfeller unngås. Er også ganske vanlig.
* En *[[En-til-en (datamodellering)|en-til-en]]*-kardinalitet er redundant, og tilsier i mange tilfeller at dataene istedet kunne vært samlet i én tabell.

## Retning på kryssfilter (''cross-filter direction'')
Data kan filtreres på en eller begge sider av en relasjon, og dette kan visualiseres med en pil i datadigrammer. 

Med et enveis kryssfilter (*single cross-filter direction*) kan bare én tabell i relasjonen brukes for å filtrere dataene, og pilen i visualiseringen vil peke i *til*-argumentets retning. Retningen av pilen peker ofte i retning av faktatabellen i en relasjon, hvilket for eksempel vil være mot midten i en stjernemodell. På denne måten vil filtreringen skje i den tabellen som (ofte) har flere verdier (altså faktatabellen).

Med et toveis kryssfilter (*bi-directional cross filtering*) kan begge av tabellene i en relasjon brukes for å filtrere den andre. Dette kan imidlertid medføre dårligere ytelse, tvetydigheter, overrepresentasjon eller uventede resultater, og bør ikke implementeres uten at man har full forståelse for alle implikasjoner dette medfører. På grunn av dette er *mange-til-mange*-relasjoner og/eller toveisrelasjoner kompliserte.

## Eksempler
For eksempel kan en database i en elektronisk pasientjournal inneholde følgende tabeller:

* Tabellen `lege` med informasjon om legene.
* Tabellen `pasient` med informasjon om de som behandles.
* Tabellen `møter` med oppføringer for hvert sykehusbesøk.

Det eksisterer noen naturlige relasjoner mellom disse entitetene, som for eksempel et møte mellom mange leger. Det er også en *mange-til-mange*-relasjon mellom oppføringene i `lege` og oppføringene i `pasient`, fordi leger har mange pasienter og pasienter kan ha mange leger. Det er en *en-til-mange*-relasjon mellom oppføringer i `pasient` og oppføringer `møter`, fordi pasienter kan ha mange møter og hvert møte involverer bare en pasient.

En *en-til-en*-relasjon brukes som regel for å dele en tabell i to slik at informasjonen skal kunne gis på en mer konsis og forståelig måte. I et sykehuseksempel kan en slik relasjon brukes for å skille en enkelt leges faglige informasjon fra administrative detaljer.

Innen datamodellering grupperes samlinger av dataelementer i tabeller som inneholder grupper av datafeltnavn kalt "databaseattributter", og tabellene er lenket sammen ved hjelp av nøkkelfelter. En primærnøkkel brukes for identifisere en oppføring, og alle relasjoner i en database skal ha en og bare en primærnøkkel. For eksempe kan feltet `legens_etternavn` kanskje bli tildelt som en primærnøkkel for tabellen `lege`, hvor alle etternavn er sortert alfabetisk i henhold til de tre første bokstavene i fornavnet. En tabell kan også ha en fremmednøkkel som indikerer hvilket felt som er lenket til primærnøkkelen i en annen tabell.

En kompleks datamodell kan inneholde hundrevis av tabeller med relasjoner seg imellom, og informatikeren Edgar F. Codd laget og publiserte en systematisk metode for å dekomponere og organisere relasjonsdatabaser. Codd sine steg for å organisere databasetabeller og deres nøkler kalles databasenormalisering, og er ment å unngå visse skjulte designfeil for databaser (**sletteanomalier** eller **oppdateringsanomalier**). I praksis medfører normalisering ofte at tabeller brytes opp i et større antall av mindre tabeller.

Datamodellering er kritisk fordi data lenket med nøkler etterhvert blir nødvendig for å hente ut data raskt når datamengden vokser. Dersom en datamodell er dårlig utformet kan man få uakseptabel responstid hos sluttbrukerne allerede ved en million oppføringer, og datamodellering anses derfor som en av nøkkelferdighetene som trengs hos en moderne programvareutvikler.

## Teknikker for databasemodellering
En entitet–relasjonsmodell er et eksempel på en teknikk for å fremstille entitet-relasonsdiagrammer (ERD-diagrammer) som kan anvendes for å fange opp informasjon om entitetstyper, relasjoner og kardinalitet i en datamodell. Eksempelvis kan en kråkefot (*crow's foot*) i et slikt diagram vise en *en-til-mange*-relasjon. Alternativt representerer en enkelt linje en *en-til-en*-relasjon.

## Tilnærminger til modellering for applikasjonsprogrammering
I det objektorienterte programmeringsparadigmet (som er relatert til design av databasestrukturer) kan UML-klassediagrammer brukes til objektmodellering. I så fall blir relasjonene mellom objektene modellerte ved hjelp av UML-assosiasjoner, og multiplisitet brukes på disse assosiasjonene for å betegne kardinalitet. Noen eksempler er:

## Se også
* Aritet

## Eksterne lenker
* UML-multiplisitet som kardinalitet i datamodellering - http://www.agiledata.org