Relationsdatabas: Skillnad mellan sidversioner

Innehåll som raderades Innehåll som lades till

Inline

Nuvarande version från 16 september 2023 kl. 21.45

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

Detta avsnitt är en sammanfattning av Nyckel (databas).

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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[redigera | redigera wikitext]

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.

Exempel på Relationsdatabashanterare[redigera | redigera wikitext]

@@ Rad 1: / Rad 1: @@
+{{källor|månad=2023-06}}{{Information saknas|avsnitt=nej|se bortkommenterad text |datum=2023-06}}
-En '''relationsdatabas''' är en [[databas]] där [[information]] ("data") är organiserad i ''relationer'' (även kallade tabeller), eventuellt med ''restriktioner'' inom en och samma relation eller mellan relationer. Termen "relationsdatabas" definierades ursprungligen [[1969]] av [[Edgar Codd]] på [[IBM]], men den strikta innebörden har luckrats upp av nutida databastillverkare.
+En '''relationsdatabas''' är en [[databas]] där [[information]] ("data") är organiserad i ''relationer'' (även kallade tabeller) bestående av rader (kallas också poster eller [[tupel|tupler]]) och kolumner (fält). En unik [[databasnyckel|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 relationsdatabaserna 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|FileMaker Pro]], som ursprungligen tagits fram för [[Macintosh]] men också finns för [[Microsoft Windows]].
+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|Filemaker Pro]], som ursprungligen tagits fram för [[Macintosh]] men också finns för [[Microsoft Windows]]. <!-- == Funktion == Behöver en lättöverskådlig översikt över vad en relationsdatabas kan göra som framhäver de relationella aspekterna mot andra sorters databaser -->
-<!-- == Funktion == Behöver en lättöverskådlig översikt över vad en relationdatabas kan göra som framhäver de relationella aspekterna mot andra sorters databaser -->
 == Beståndsdelar ==
@@ Rad 9: / Rad 8: @@
 === Relationer ===
-En ''relation'' definieras som en [[mängd]] av [[post]]er ([[tupel|tupler]]) som har samma [[attribut]]. Detta representeras i form av en [[tabell]] i vilken data är organiserad i [[rad]]er och [[kolumn]]er.
+En ''relation'' definieras som en [[mängd]] av poster ([[tupel|tupler]]) som har samma [[Attribut (programmering)|attribut]]. Detta representeras i form av en [[tabell]] i vilken data är organiserad i rader och [[Tabell|kolumn]]er.
 I en relationsdatabas måste all data i en specifik kolumn vara av samma typ, [[datatyp]], ([[domän (matematik)|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.
+I praktiken uppnår databaser inte detta matematiska ideal. Till exempel kräver [[Structured Query Language|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 [[flagga|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".
+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 (datavetenskap)|text]] och [[flagga (data)|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 ====
 {{Fördjupning|Nyckel (databas)}}
-En post mostvarar 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.
+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 famijlekretsen, 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.
+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.
 <!-- Nycklar kan bestå av flera attribut. Behöver ett bra exempel på sådana -->
 <!-- exempel: medlemsnummer i en förening, förnamn+efternamn+siffra, användarnamn -->
-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 har inte har djupare anknytning till resten av objektets attribut (till exempel ett [[serienummer]]) kallas den [[surrogatnyckel]].
+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 den 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.
+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 ====
@@ Rad 43: / Rad 42: @@
 == 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 [[boolesk]]t 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 betraktast dock restriktioner som komponenter i databasen.
+En ''restriktion'' är ett sätt att begränsa de data som får förekomma i databasen. Dessa restriktioner definieras vanligtvis i formella [[Matematiskt uttryck|uttryck]] som resulterar i ett [[boolesk]]t 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 ===
@@ Rad 56: / Rad 55: @@
 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.
-== Exempel på Relationsdatabaser ==
+== Exempel på Relationsdatabashanterare ==
-*[[4D (4th Dimension)|4D]]
+* [[4D (4th Dimension)|4D]]
-*[[dBase]]
+* [[dBase]]
-*[[DB2]]
+* [[DB2]]
-*[[Oracle]]
+* [[Oracle]]
-*[[MySQL]]
+* [[MySQL]]
-*[[Microsoft SQL Server]]
+* [[Microsoft SQL Server]]
-*[[Microsoft Access]]
+* [[Microsoft Access]]
-*[[FoxPro]]
+* [[Mimer SQL]]
-*[[Dataflex]]
+* [[FoxPro]]
-*[[Paradox (relationsdatabas)|Paradox]]
+* [[Dataflex]]
+* [[Paradox (relationsdatabas)|Paradox]]
-*[[FileMaker]]
+* [[Filemaker]]
-*[[PostgreSQL]]
+* [[PostgreSQL]]
-*[[FirebirdSQL]]
+* [[FirebirdSQL]]
+* [[Ingres (relationsdatabas)|Ingres]]
+* [[SQLite]]
 [[Kategori:Datavetenskap]]
-[[ar:قاعدة البيانات المترابطة]]
-[[bg:Релационна база данни]]
-[[bn:সাম্পর্কিক ডাটাবেস]]
-[[ca:Base de dades relacional]]
-[[cs:Relační databáze]]
-[[de:Relationale Datenbank]]
-[[en:Relational database]]
-[[eo:Rilata datumbazo]]
-[[es:Base de datos relacional]]
-[[fa:پایگاه‌های رابطه‌ای داده‌ها]]
-[[fr:Base de données relationnelle]]
-[[he:מסד נתונים יחסי]]
-[[hu:Relációs adatbázis]]
-[[is:Venslagagnagrunnur]]
-[[ja:関係データベース]]
-[[ko:관계형 데이터베이스]]
-[[lt:Reliacinė duomenų bazė]]
-[[nl:Relationele database]]
-[[no:Relasjonsdatabase]]
-[[pt:Banco de dados relacional]]
-[[ru:Реляционная база данных]]
-[[simple:Relational database]]
-[[ta:தொடர்புசால் தரவுத்தளம்]]
-[[te:రిలేషనల్ డేటాబేస్]]
-[[th:ฐานข้อมูลเชิงสัมพันธ์]]
-[[uk:Реляційна база даних]]
-[[zh:关系数据库]]