De relationsmodell av databaser är en metod för att strukturera data med hjälp av relationer, med hjälp av rutnäta strukturer, bestående av kolumner och rader. Det är den konceptuella principen för relationsdatabaser. Det föreslogs av Edgar F. Codd 1969.
Det har sedan dess blivit den dominerande databasmodellen för affärsapplikationer, jämfört med andra databasmodeller, såsom hierarki, nätverk och objekt..
Codd hade ingen aning om hur extremt viktigt och inflytelserikt hans arbete som en plattform för relationsdatabaser skulle vara. De flesta är mycket bekanta med det fysiska uttrycket för en relation i en databas: tabellen.
Relationsmodellen definieras som databasen som gör det möjligt att gruppera sina 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..
Artikelindex
En databastabell liknar ett kalkylblad. Relationerna som kan skapas mellan tabellerna gör det dock möjligt för en relationsdatabas att effektivt lagra en stor mängd data, som effektivt kan hämtas..
Syftet med relationsmodellen är att tillhandahålla en deklarativ metod för att specificera data och frågor: användare förklarar direkt vilken information databasen innehåller och vilken information de vill ha från den.
Å andra sidan låter de databashanteringssystemets programvara ha ansvaret för att beskriva datastrukturerna för lagring och hämtningsförfarandet för att svara på 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.
- All data representeras begreppsmässigt som ett ordnat arrangemang av data i rader och kolumner, kallat en relation eller tabell.
- Varje tabell måste ha en rubrik och en kropp. Rubriken är helt enkelt listan med kolumner. Brödtexten är den uppsättning data som fyller tabellen, organiserad i rader.
- Alla värden är skalära. Det vill säga, vid en viss rad / kolumnposition i tabellen finns det bara ett enda värde.
Följande bild visar en tabell med namnen på dess grundläggande element, som utgör en komplett struktur.
Varje rad med data är en tupel, även känd som en post. Varje rad är en n-tupel, men "n-" kastas vanligtvis.
Varje kolumn i en tuple kallas ett attribut eller fält. Kolumnen representerar den uppsättning värden som ett specifikt attribut kan ha.
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 tangent identifieras varje tuple unikt. Det vill säga att nyckeln inte kan dupliceras. Det kallas den primära nyckeln.
Å andra sidan är en främmande eller sekundär nyckel fältet i en tabell som refererar till den primära nyckeln i någon annan tabell. Används för att referera till primärtabellen.
När du utformar relationsmodellen definierar du några villkor som måste uppfyllas i databasen, så kallade integritetsregler.
Primärnyckeln måste vara unik för alla tuplar och kan inte vara noll. Annars kommer du inte att kunna identifiera raden unikt.
För en flerkolumnyckel kan ingen av dessa kolumner innehålla NULL.
Varje värde på en främmande nyckel måste matcha ett värde på den primära nyckeln i den refererade eller primära tabellen.
En rad med en främmande nyckel kan bara infogas i den sekundära tabellen om värdet finns i en primär tabell.
Om värdet på nyckeln ändras i modertabellen, genom att uppdatera eller radera raden, bör alla rader i underordnade tabeller med denna främmande nyckel uppdateras eller tas bort i enlighet med detta.
De nödvändiga uppgifterna måste samlas in för att lagras i databasen. Dessa data är uppdelade i olika tabeller.
En lämplig datatyp måste väljas för varje kolumn. Till exempel: heltal, flytande nummer, text, datum etc..
För varje tabell måste en kolumn (eller några kolumner) väljas som primärnyckel, som unikt identifierar varje rad i tabellen. Primärnyckeln används också för att hänvisa till andra tabeller.
En databas som består av oberoende och icke-relaterade tabeller har lite syfte.
Den viktigaste aspekten vid utformningen av en relationsdatabas är att identifiera förhållandena mellan tabellerna. Relationstyperna är:
I en databas "Klassuppgifter" kan en lärare undervisa noll eller fler, 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 undervisas av varje lärare kan du skapa ytterligare kolumner, men du får ett problem: hur många kolumner som ska skapas.
Å andra sidan, om du har en tabell som heter Classes, som lagrar information om en klass, kan du skapa ytterligare kolumner för att lagra information om läraren..
Eftersom en lärare kan undervisa i många klasser skulle hans data dock dupliceras i många rader i tabellen Klass.
Därför måste två tabeller utformas: 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 primärnyckel..
Då kan förhållandet en-till-många skapas genom att lagra huvudnyckeln för mastertabellen (Master_Id) i tabellen Klass, som illustreras nedan.
Master_Id-kolumnen i tabellen Klasser är känd som en främmande nyckel eller sekundär nyckel.
För varje Master_Id-värde i mastertabellen kan det finnas noll eller fler rader i tabellen Classes. För varje Class_Id-värde i Classes-tabellen finns det bara en rad i tabellen Teachers.
I en databas "Produktförsäljning" kan en kunds beställning innehålla flera produkter och en produkt kan visas i flera beställningar. Denna typ av relation är känd som många för många.
Du kan starta databasen "Produktförsäljning" med två tabeller: Produkter och order. Tabellen Produkter innehåller information om produkterna, med produkt-ID som primärnyckel.
Å andra sidan innehåller tabellen Order kundens beställningar, med orderID som primär nyckel.
Du kan inte lagra de beställda produkterna i ordertabellen, eftersom du inte vet hur många kolumner som ska reserveras för produkterna. Beställningar kan inte lagras i produkttabellen av samma anledning.
För att stödja en många-till-många-relation måste du skapa en tredje tabell, känd som en anslutningstabell (OrderDetails), där varje rad representerar ett objekt i en viss ordning.
För OrderDetails-tabellen består den primära nyckeln av två kolumner: orderID och productID, som identifierar varje rad unikt.
Kolumnerna orderID och produktID i tabellen OrderDetails används för att referera till tabellerna Order och Products. Därför är de också främmande nycklar i tabellen OrderDetails..
I databasen "Försäljning av produkter" kan en produkt ha valfri information, till exempel ytterligare beskrivning och dess bild. Att hålla det inne i tabellen Produkter 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, Products och ProductExtras, har en en-till-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 huvudnyckel för båda tabellerna.
I relationsdatabasmodellen påverkar inte ändringar i databasstrukturen åtkomst till data.
När det är möjligt att göra ändringar i databasens struktur utan att påverka DBMS: s förmåga att komma åt data, kan man säga att strukturellt oberoende har uppnåtts.
Den relationsdatabasmodellen är ännu mer begreppsmässigt enkel än den hierarkiska eller nätverksdatabasmodellen.
Eftersom relationsdatabasmodellen befriar designern från detaljerna i den fysiska lagringen av data kan designers fokusera på den logiska vyn av databasen.
Den relationsdatabasmodellen uppnår både dataoberoende och strukturoberoende, vilket gör design, underhåll, administration och användning av databasen mycket enklare än de andra modellerna..
Närvaron av en mycket kraftfull, flexibel och lättanvänd frågekapacitet är en av huvudorsakerna till den enorma populariteten hos relationsdatabasmodellen.
Frågespråket i relationsdatabasmodellen, kallat Structured Query Language, eller SQL, gör ad hoc-frågor till verklighet. SQL är ett fjärde generationens språk (4GL).
En 4GL tillåter användaren att specificera vad som ska göras, utan att specificera hur det ska göras. Således, med SQL, kan användare ange vilken information de vill ha och lämna information om hur man får informationen till databasen.
Den relationsdatabasmodellen döljer komplexiteten i dess implementering och detaljerna i den fysiska lagringen av användardata.
För att göra detta behöver relationsdatabassystem datorer med mer kraftfull hårdvara och datalagringsenheter..
Därför behöver RDBMS kraftfulla maskiner för att fungera smidigt. Eftersom processorkraften hos moderna datorer ökar i en exponentiell takt är behovet av mer processorkraft i dagens scenario inte längre ett mycket stort problem..
Relationsdatabasen är lätt att designa och använda. Användare behöver inte veta de komplexa detaljerna i fysisk datalagring. De behöver inte veta hur data faktiskt lagras för att få åtkomst till det.
Denna enkla design och användning kan leda till utveckling och implementering av dåligt utformade databashanteringssystem. Eftersom databasen är effektiv kommer inte dessa designineffektiviteter att dyka upp när databasen designas och när det bara finns en liten mängd data.
När databasen växer kommer dåligt utformade databaser att sakta ner systemet och leda till prestandaförsämring och datakorruption..
Som nämnts tidigare är relationsdatabassystem enkla att implementera och använda. Detta kommer att skapa en situation där för många människor eller avdelningar skapar egna databaser och applikationer..
Dessa informationsöar förhindrar integrering av information, vilket är viktigt för att organisationen ska fungera smidigt och effektivt..
Dessa enskilda databaser kommer också att skapa problem som datainkonsekvens, dataduplicering, dataredundans etc..
Antag att en databas består av tabellerna Leverantörer, delar och leveranser. Tabellens struktur och några exempelposter är som följer:
Varje rad i tabellen Leverantörer identifieras med ett unikt leverantörsnummer (SNo), vilket unikt identifierar varje rad i tabellen. På samma sätt har varje del ett unikt artikelnummer (PNo).
Dessutom kan det inte finnas mer än en försändelse för en given leverantör / delkombination i tabellen Sändningar, eftersom denna kombination är den primära nyckeln för sändningar, som fungerar som en facklig tabell, eftersom det är en många-till-många-relation..
Förhållandet mellan tabellerna Delar och försändelser ges genom att ha fältet PNo (artikelnummer) gemensamt och förhållandet mellan leverantörer och leveranser uppstår genom att fältet SNo (leverantörsnummer) har gemensamt.
När man analyserar sändningstabellen kan man få den som information om att totalt 500 nötter skickas från Suneet och Ankit-leverantörer, 250 vardera.
På samma sätt levererades 1100 bultar från tre olika leverantörer. 500 blå skruvar levererades från Suneet-leverantören. Inga transporter av röda skruvar.
Ingen har kommenterat den här artikeln än.