Relationsdatabas
 |
Den här artikeln behöver källhänvisningar för att kunna verifieras. (2023-06) Åtgärda genom att lägga till pålitliga källor (gärna som fotnoter). Uppgifter utan källhänvisning kan ifrågasättas och tas bort utan att det behöver diskuteras på diskussionssidan. |
 |
Den här artikeln saknar väsentlig information och behöver kompletteras. (2023-06) Saknad information: se bortkommenterad text Hjälp gärna Wikipedia att åtgärda problemet genom att eller diskutera saken på diskussionssidan. |
En relationsdatabas är en databas där information ("data") är organiserad i relationer (även kallade tabeller) bestående av rader (kallas också poster eller tupler) och kolumner (fält). En unik nyckel identifierar varje rad. Termen "relationsdatabas" definierades ursprungligen 1969 av Edgar Codd på IBM, men den strikta innebörden har luckrats upp av nutida databastillverkare.
Bland de mer kända större relationsdatabasmotorerna räknas idag Oracle, Microsoft SQL Server, IBM DB2 och ursprungligen svensk/finska MySQL (vilken också Wikipedia använder sig av). Bland mindre databaser är Microsoft Access vanligt förekommande eftersom det ingår i större versioner av sviten Microsoft Office. (I gratisprogrammet OpenOffice finns en databas som delvis liknar Access.) En användarvänlig databas, som finns i både mindre och större versioner är Filemaker Pro, som ursprungligen tagits fram för Macintosh men också finns för Microsoft Windows.
Beståndsdelar
Strängt taget består en relationsdatabas av tabeller. För att göra dessa meningsfulla, få dem att bli något mer än bara tabeller binds de samman av relationer och restriktioner. Sammantaget ger detta en strukturerad mängd information, en databas - en relationsdatabas.
Relationer
En relation definieras som en mängd av poster (tupler) som har samma attribut. Detta representeras i form av en tabell i vilken data är organiserad i rader och kolumner.
I en relationsdatabas måste all data i en specifik kolumn vara av samma typ, datatyp, (domän). I relationsmodellen behöver posterna inte ha någon specifik ordning, attributen behöver inte heller vara i någon specifik ordning inom en post.
I praktiken uppnår databaser inte detta matematiska ideal. Till exempel kräver SQL-standarden att kolumnerna i en tabell måste ha en definierad ordning. Alla data som lagras i ett datorminne måste också ha någon form av ordning eftersom datorminnen är linjära. Ordningen i vilken relationen lagras kan vara av avgörande betydelse för databasens prestanda. Poängen är dock att ordningen i vilken relationen är lagrad inte får påverka resultaten av databasfrågor.
Det är lätt att föreställa sig en relation om man tänker sig att varje post är en rad och varje attribut en kolumn. Så brukar det också presenteras på skärmen. En alternativ "vy" är att välja se varje post för sig med (samtliga eller några av) attributen inpassade i någon form av rapportblankett, och sedan "bläddra" mellan sidor och respektive poster.
Domän
En domän är den mängd värden som är tillåtna för ett visst attribut. Typiska domäner i relationsdatabaser är heltal, text och flaggor. Utöver dessa fördefinierade domäner kan man begränsa domänen ytterligare; till exempel kan ett textattribut vara begränsat till värdena "Man", "Kvinna" eller "Okänt".
Nycklar
En post motsvarar ofta något objekt och information förknippad med det, oavsett om objektet är ett fysiskt objekt eller ett abstrakt koncept. En nyckel är en slags restriktion som ser till att objektet eller kritisk information om ett objekt inte dupliceras. Till exempel kan man inom en familj ha restriktionen att inga två familjemedlemmar har samma förnamn. Om information om denna familj lagrades i en relationsdatabas skulle förnamnen kunna användas som nyckel.
Förnamn är sällan unika över grupper större än den innersta familjekretsen, som till exempel hela landets befolkning. Detta är ett skäl till Sveriges medborgare tilldelas ett nummer, ett personnummer, unikt för var och en i landet. Personnummer används som nyckel i både privata och offentliga relationsdatabaser.
De flesta relationer har åtminstone en nyckel, den så kallade primärnyckeln. Om nyckeln är faktiskt data med logisk anknytning till posten (som förnamnet i familjeexemplet ovan) kallas den naturlig nyckel. Om nyckeln istället är automatiskt genererad och inte har djupare anknytning till resten av objektets attribut (till exempel ett serienummer) kallas den surrogatnyckel.
Främmande nycklar
En främmande nyckel är inte en nyckel enligt definitionen ovan. Snarare är en främmande nyckel en hänvisning till en nyckel i en annan relation. Detta betyder att den hänvisande tupeln har, som del av sina attribut, värden som tillsammans bildar en nyckel i den hänvisade relationen.
Exempel: ett företag har flera avdelningar, och varje anställd är medlem i exakt en avdelning. Denna restriktion kan uttryckas med en främmande nyckel. Föreställ dig en relation för avdelningarna, "Avdelningar". Varje avdelning har ett avdelningsnamn och en surrogatnyckel för avdelningen som kallas "avdelningsID". Relationen över de anställda skulle då kunna ha ett attribut "avdelningsID" markerat som en främmande nyckel från relationen "Avdelningar". Relationsdatabassystemet kan nu styrka denna restriktion genom att se till att en nyanställd måste vara förknippad med ett avdelningsID, och att en avdelning inte kan tas bort från relationen "Avdelningar" om det fortfarande finns anställda kvar som hänvisar till den avdelningen.
Sekundärnycklar
En sekundärnyckel är inte per se en nyckel, snarare är den en hänvisning till en primärnyckel i en annan tabell.
Exempel: en skolklass. Tabell innehåller i sig inga fristående data. All information i denna tabell hämtas från två andra, fristående tabeller och därmed två fristående set av primärnycklar. Primärnycklar från elevtabellen och från skolans egna primärnyckel. I detta sammanhang skapar de ett samband, en relation. Skolklassens utgörs alltså att dessa två värden, primärnycklar från två tabeller som i denna tabell fungerar som sekundärnycklar.
Restriktioner
En restriktion är ett sätt att begränsa de data som får förekomma i databasen. Dessa restriktioner definieras vanligtvis i formella uttryck som resulterar i ett booleskt värde som anger huruvida restriktionen gäller eller inte. I den strikta definitionen av relationsdatabas är restriktioner inte del av själva databasen. Eftersom de ingår i databasmotorer och spelar en integrerad roll i informationens organisation betraktas dock restriktioner som komponenter i databasen.
Övergångsrestriktioner
En övergångsrestriktion är ett sätt att se till att data inte kan gå in i ett omöjligt tillstånd från ett tidigare tillstånd. Till exempel borde det inte vara möjligt för en person att byta civilstånd direkt från "ogift" till "frånskild". De enda tillåtna civilstånden efter "ogift" skulle kunna begränsas till "gift" eller "sambo".
Andra restriktioner
Andra restriktioner kan tillämpas för att uttrycka olika sorters affärsregler. Ett exempel är restriktionen "antalet bilar en individ äger måste vara icke-negativt".
Normalisering
För att få en lättadministrerbar databas bör sammanhörande uppgifter föras till samma relation. Förhållandena mellan relationer skapas sedan mellan en för två eller flera tabeller gemensamt nyckelattribut genom normalisering. Förhållandet kan vara ett till ett, en till många, många till en och många till många.
Att framställa de bästa relationerna och de korrekta förhållandena dem emellan är en utmaning vid skapandet av databasen, framför allt eftersom det är kostsamt att ändra på förhållandena när databasen tagits i drift.