RELATIONSDATABASMODELL: ELEMENT, HUR MAN GÖR DET, EXEMPEL - TEKNOLOGI - 2025

Den relationsdatabasmodellen är en metod för att strukturera data med hjälp av relationer, använda rutnätsliknande strukturer, bestående av kolumner och rader. Det är den konceptuella principen för relationsdatabaser. Det föreslogs av Edgar F. Codd 1969.

Sedan har den blivit den dominerande databasmodellen för affärsapplikationer jämfört med andra databasmodeller, såsom hierarkiska, nätverk och objekt.

Källa: pixabay.com

Codd hade ingen aning om hur extremt viktigt och inflytelserikt hans arbete som plattform för relationsdatabaser skulle vara. De flesta människor är mycket bekanta med det fysiska uttrycket för en relation i en databas: tabellen.

Relationsmodellen definieras som databasen som tillåter gruppering av dess dataelement i en eller flera oberoende tabeller, som kan relateras till varandra genom användning av fält som är gemensamma för varje relaterad tabell.

Databashantering

En databastabell liknar ett kalkylblad. Förhållandena som kan skapas mellan tabellerna tillåter emellertid att en relationsdatabas effektivt lagrar en stor mängd data, som kan hämtas effektivt.

Syftet med den relationella modellen är att tillhandahålla en deklarativ metod för att specificera data och frågor: användarna förklarar direkt vilken information databasen innehåller och vilken information de vill ha från den.

Å andra sidan lämnar de det till databashanteringssystemets programvara för att beskriva datastrukturerna för lagring och hämtningsförfarandet för att besvara frågorna.

De flesta relationsdatabaser använder SQL-språket för att fråga och definiera data. För närvarande finns det många relationsdatabashanteringssystem eller RDBMS (Relational Data Base Management System), såsom Oracle, IBM DB2 och Microsoft SQL Server.

Funktioner och element

- All data representeras konceptuellt som ett ordnat arrangemang av data i rader och kolumner, kallad en relation eller tabell.

- Varje tabell måste ha en rubrik och en kropp. Rubriken är helt enkelt listan med kolumner. Kroppen är den uppsättning data som fyller tabellen, organiserad i rader.

- Alla värden är skalor. Det vill säga att vid varje given rad / kolumnposition i tabellen finns det bara ett enda värde.

Beståndsdelar

Följande bild visar en tabell med namnen på dess grundelement, som utgör en komplett struktur.

tupel

Varje rad med data är en tupel, även känd som en post. Varje rad är en n-tupel, men "n-" kasseras vanligtvis.

Kolumn

Varje kolumn i en tupel kallas ett attribut eller fält. Kolumnen representerar uppsättningen värden som ett specifikt attribut kan ha.

Nyckel

Varje rad har en eller flera kolumner som kallas en tabellnyckel. Detta kombinerade värde är unikt för alla rader i en tabell. Med hjälp av denna nyckel kommer varje tupel att identifieras unikt. Det vill säga nyckeln kan inte dupliceras. Det kallas den primära nyckeln.

Å andra sidan är en utländsk eller sekundär nyckel fältet i en tabell som hänvisar till primärnyckeln i någon annan tabell. Den används för att referera till den primära tabellen.

-Regler för integritet

När du utformar relationsmodellen definierar du vissa villkor som måste uppfyllas i databasen, kallade integritetsregler.

Nyckelintegritet

Den primära nyckeln måste vara unik för alla tuplingar och kan inte vara noll (NULL). Annars kan du inte identifiera raden på ett unikt sätt.

För en nyckel med flera kolumner kan ingen av dessa kolumner innehålla NULL.

Referensintegritet

Varje värde på en utländsk nyckel måste matcha ett värde för den primära nyckeln i den refererade eller primära tabellen.

En rad med en utländsk nyckel kan bara infogas i den sekundära tabellen om det värdet finns i en primärtabell.

Om värdet på nyckeln ändras i den primära tabellen, på grund av att raden uppdateras eller raderas, bör alla raderna i sekundärtabellerna med denna utländska nyckel uppdateras eller raderas i enlighet därmed.

Hur man gör en relationell modell?

-Samla in data

De nödvändiga uppgifterna måste samlas in för att lagras i databasen. Dessa data är indelade i olika tabeller.

En lämplig datatyp måste väljas för varje kolumn. Till exempel: hela siffror, flytande punktnummer, text, datum etc.

-Definiera primära nycklar

För varje tabell måste en kolumn (eller få kolumner) väljas som primärnyckel, som identifierar varje rad i tabellen på ett unikt sätt. Den primära nyckeln används också för att hänvisa till andra tabeller.

- Skapa relationer mellan tabeller

En databas som består av oberoende, oberoende tabeller tjänar litet syfte.

Den mest avgörande aspekten vid utformningen av en relationsdatabas är att identifiera förhållandena mellan tabellerna. Relationstyperna är:

En till många

I en "Klasslistning" -databas kan en lärare lära noll eller fler klasser, medan en klass undervisas av en enda lärare. Denna typ av relation kallas en-till-många.

Detta förhållande kan inte representeras i en enda tabell. I databasen «Lista över klasser» kan du ha en tabell som heter Lärare, som lagrar information om lärare.

För att lagra klasserna som lärs ut av varje lärare kan du skapa ytterligare kolumner, men du skulle få problem: hur många kolumner du ska skapa.

Å andra sidan, om du har en tabell som heter klasser, som lagrar information om en klass, kan du skapa ytterligare kolumner för att lagra information om läraren.

Men eftersom en lärare kan lära många klasser, skulle hans data dupliceras över många rader i klassen tabell.

Design två bord

Därför måste du designa två tabeller: en klasstabell för att lagra information om klasserna, med Class_Id som primärnyckel, och en lärartabell för att lagra information om lärarna, med Teacher_Id som den primära nyckeln.

Förhållandet en till många kan sedan skapas genom att lagra den primära nyckeln från Master-tabellen (Master_Id) i klasser-tabellen, som illustreras nedan.

Kolumnen Master_Id i tabellen Klasser kallas en utländsk nyckel eller sekundärnyckel.

För varje Master_Id-värde i Master-tabellen kan det finnas noll eller fler rader i Classtabellen. För varje Class_Id-värde i Classtabellen finns det bara en rad i tabellen Lärare.

Många till många

I en "Produktförsäljnings" -databas kan en kundorder innehålla flera produkter och en produkt kan visas i flera beställningar. Denna typ av relation är känd som många till många.

Du kan starta databasen "Produktförsäljning" med två tabeller: Produkter och beställningar. Produkttabellen innehåller information om produkterna, med produktID som den primära nyckeln.

Å andra sidan innehåller ordertabellen kundens beställningar, med orderID som den primära nyckeln.

Du kan inte lagra de beställda produkterna i tabellen Order, eftersom du inte vet hur många kolumner du ska reservera för produkterna. Beställningar kan inte lagras i produkttabellen av samma anledning.

För att stödja en relation mellan många och många måste du skapa en tredje tabell, känd som en sammanfogningstabell (OrderDetails), där varje rad representerar ett objekt i en viss ordning.

För tabellen OrderDetails består primärnyckeln av två kolumner: orderID och produktID, som identifierar varje rad unikt.

Kolumnerna orderID och produktID i tabellen OrderDetails används för att referera till tabellerna Order och produkter. Därför är de också utländska nycklar i OrderDetails-tabellen.

En och en

I databasen "Försäljning av produkter" kan en produkt ha valfri information, till exempel ytterligare beskrivning och dess bild. Att hålla den inne i produkttabellen skulle generera många tomma utrymmen.

Därför kan en annan tabell (ProductExtras) skapas för att lagra valfri data. Endast en post skapas för produkter med valfri data.

De två tabellerna, Produkter och ProductExtras, har en en-mot-en-relation. För varje rad i tabellen Produkter finns det högst en rad i tabellen ProductExtras. Samma produkt-ID måste användas som den primära nyckeln för båda tabellerna.

Fördel

Strukturell oberoende

I den relationella databasmodellen påverkar inte ändringar i databasens struktur tillgången till data.

När det är möjligt att göra ändringar i databasstrukturen utan att påverka DBMS: s förmåga att få åtkomst till uppgifterna, kan man säga att strukturellt oberoende har uppnåtts.

Konceptuell enkelhet

Den relationsdatabasmodellen är ännu mer begreppsmässigt enkel än den hierarkiska eller nätverksdatabasmodellen.

Eftersom den relationsdatabasmodellen befriar designern från detaljerna i fysisk lagring av data, kan designers fokusera på den logiska vyn på databasen.

Enkel design, implementering, underhåll och användning

Den relationsdatabasmodellen uppnår både datainständighet och strukturoberoende, vilket gör design, underhåll, hantering och användning av databasen mycket enklare än de andra modellerna.

Ad-hoc fråga kapacitet

Närvaron av en mycket kraftfull, flexibel och lättanvänd frågefunktion är en av de främsta orsakerna till den enorma populariteten för den relationella databasmodellen.

Frågespråket i den relationella databasmodellen, kallad strukturerat frågespråk, eller SQL, gör ad-hocfrågor till verklighet. SQL är ett fjärde generations språk (4GL).

En 4GL tillåter användaren att specificera vad som ska göras utan att ange hur det ska göras. Således kan användare med SQL specificera vilken information de vill och lämna informationen om hur man får informationen till databasen.

nackdelar

Hårdvarukostnader

Den relationsdatabasmodellen döljer komplexiteten i dess implementering och detaljerna om fysisk lagring av användardata.

För att göra detta behöver relationsdatabassystem datorer med kraftfullare hårdvaru- och datalagringsenheter.

Därför behöver RDBMS kraftfulla maskiner för att fungera smidigt. Eftersom bearbetningskraften för moderna datorer ökar exponentiellt är behovet av mer bearbetningskraft i dagens scenario inte längre ett mycket stort problem.

Enkel design kan leda till dålig design

Relationsdatabasen är lätt att designa och använda. Användare behöver inte veta de komplexa detaljerna för fysisk lagring av data. De behöver inte veta hur data faktiskt lagras för att komma åt dem.

Denna enkla design och användning kan leda till utveckling och implementering av dåligt utformade databashanteringssystem. Eftersom databasen är effektiv kommer dessa designeffektivitet inte att komma fram när databasen är designad och när det bara finns en liten mängd data.

I takt med att databasen växer, kommer dåligt utformade databaser att bromsa systemet och leda till prestandadegradering och datakorruption.

Fenomen av «informationsöar»

Som nämnts tidigare är relationsdatabassystem enkla att implementera och använda. Detta skapar en situation där för många människor eller avdelningar skapar sina egna databaser och applikationer.

Dessa informationsöar kommer att förhindra integration av information, vilket är avgörande för att organisationen ska fungera smidigt och effektivt.

Dessa enskilda databaser skapar också problem såsom datakonsekvens, dataduplicering, dataredundans, etc.

Exempel

Anta att en databas består av tabellerna Leverantörer, delar och leveranser. Strukturen för tabellerna och några exempelposter är följande:

Varje rad i leverantörstabellen identifieras av ett unikt leverantörsnummer (SNo) och identifierar varje rad i tabellen unikt. På samma sätt har varje del ett unikt artikelnummer (PNo).

Dessutom kan det inte finnas mer än en sändning för en given leverantör / delkombination i sändningstabellen, eftersom denna kombination är den primära nyckeln för sändningar, som fungerar som en fackföreningstabell, eftersom det är en relation mellan många och många.

Förhållandet mellan tabellerna för delar och leveranser ges genom att fältet PNo (delnummer) är gemensamt och förhållandet mellan leverantörer och leveranser uppstår genom att ha SNo-fältet (leverantörsnummer) gemensamt.

Genom att analysera sändningstabellen kan information erhållas att totalt 500 nötter skickas från Suneet- och Ankit-leverantörer, 250 vardera.

På samma sätt levererades 1 100 bultar totalt från tre olika leverantörer. 500 blå skruvar levererades från Suneet-leverantören. Det finns inga transporter av röda skruvar.

referenser

1. Wikipedia, gratis encyklopedi (2019). Relationsmodell. Hämtad från: en.wikipedia.org.
2. Techopedia (2019). Relationsmodell. Hämtad från: ceilingpedia.com.
3. Dinesh Thakur (2019). Relationsmodell. E-datoranteckningar. Hämtad från: ecomputernotes.com.
4. Geeks for Geeks (2019). Relationsmodell. Hämtad från: geeksforgeeks.org.
5. Nanyang Technological University (2019). En snabbstartstudie om relationell databasdesign. Hämtad från: ntu.edu.sg.
6. Adrienne Watt (2019). Kapitel 7 Relationsdatamodellen. BC Öppna läroböcker. Hämtad från: opentextbc.ca.
7. Toppr (2019). Relationsdatabaser och scheman. Hämtad från: toppr.com.