Relationella databasmodellelement, hur man gör det, exempel

han Relationsmodell av databaser Det är en metod för att strukturera data med hjälp av förhållanden, genom nätformade strukturer, som består av kolumner och rader. Det är den konceptuella principen för relationsdatabaser. Föreslogs av edgar f. CODD 1969.

Sedan dess har det blivit den dominerande databasmodellen för kommersiella applikationer, om de jämförs med andra databasmodeller, till exempel hierarkiska, nätverk och objekt.

Källa: Pixabay.com

CODD hade ingen aning om det extremt vitala och inflytelserika som skulle vara hans arbete som en plattform för relationsdatabaser. De flesta är mycket bekanta med det fysiska uttrycket för en relation i en databas: tabellen.

Den relationella modellen 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 att använda vanliga fält till varje relaterad tabell.

[TOC]

Databashantering

En databas liknar ett kalkylblad. De förhållanden som kan skapas mellan tabellerna gör det dock möjligt för en relationsdatabas att lagra en stor mängd data, som kan återvinnas effektivt.

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

Å andra sidan låter de programvaran i databashanteringssystemet vara ansvarigt för att beskriva datastrukturer för lagring och återhämtning för att svara.

De flesta relationsdatabaser använder SQL -språket för samråd och definition av uppgifterna. Det finns för närvarande många relationella databashanteringssystem eller RDBM: er (relationella databashanteringssystem), såsom Oracle, IBM DB2 och Microsoft SQL Server.

Egenskaper och element

- All data representeras konceptuellt som en ordnad disposition av data i rader och kolumner, kallad relation eller tabell.

- Varje bord måste ha en rubrik och en kropp. Rubriken är helt enkelt kolumnlistan. Kroppen är uppsättningen av data som fyller tabellen, organiserad i rader.

- Alla värden är klättringar. Det vill säga i en given position av rad/kolumn i tabellen finns det bara ett unikt värde.

-Föremål

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

Tupla

Varje rad med data är en tupla, även känd som registrering. Varje rad är en n-tupla, men "n-" utesluts vanligtvis.

Kolumn

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

Ledtråd

Varje rad har en eller flera kolumner som kallas tabellen. Detta kombinerade värde är unikt för alla rader i en tabell. Genom denna nyckel kommer varje tupla att identifieras på ett univocal sätt. Det vill säga nyckeln kan inte dupliceras. Det kallas primärnyckel.

Å andra sidan är en extern eller sekundärnyckel fältet för en tabell som hänvisar till den primära nyckeln för någon annan tabell. Det används för att hänvisa till den primära tabellen.

-Integritetsregler

Vid utformning av den relationella modellen definieras vissa villkor som måste uppfyllas i databasen, som kallas integritetsregler.

Kan tjäna dig: makrocomputers: historia, egenskaper, användningar, exempel

Nyckelintegritet

Den primära nyckeln måste vara unik för alla tuples och kan inte ha nollvärdet (NULL). Annars kommer du inte att kunna identifiera raden uteslutande.

För en nyckel som består av flera kolumner kan ingen av dessa kolumner innehålla noll.

Referensintegritet

Varje värde på en extern nyckel måste sammanfalla med ett värde på den primära nyckeln i den refererade eller primära tabellen.

I den sekundära tabellen kan endast en rad sättas in med en extern nyckel om det värdet finns i en primär tabell.

Om värdet på nyckeländringarna i primärtabellen, för att uppdatera eller eliminera raden, måste alla rader i de sekundära tabellerna med denna externa nyckel uppdateras eller elimineras i enlighet därmed.

Hur man gör en relationell modell?

-Samla in data

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

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

-Definiera primära nycklar

För varje tabell måste du välja en kolumn (eller några kolumner) som en primär nyckel, som unikt identifierar varje rad i tabellen. Den primära nyckeln används också för att hänvisa till andra tabeller.

-Skapa relationer mellan tabellerna

En databas som består av oberoende och oberoende tabeller har lite syfte.

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

En till många

I en "klasser" -databas kan en lärare undervisa i noll eller fler klasser, medan en klass undervisas av en enda lärare. Denna typ av relation kallas en för många.

Detta förhållande kan inte representeras i en enda tabell. I databasen "klasslista" kan du ha en tabell som heter lärare, som lagrar information om lärare.

För att lagra de klasser som lärs ut av varje lärare kan ytterligare kolumner skapas, men ett problem skulle möta: hur många kolumner skapar.

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

Men som lärare kan undervisa i många klasser skulle hans data fördubblas i många rangordningar i klassens tabell.

Designa två tabeller

Därför måste två tabeller utformas: en klassstabell för att lagra information om klasser, med klassen som huvudnyckel och en mastertabell för att lagra information om lärare, med Teacher_id som huvudnyckel.

Då kan du skapa förhållandet en till många lagring av den primära nyckeln för mastertabellen (master_id) i klassstabellen, som illustreras nedan.

MASTER_ID -kolumnen i klassens tabell är känd som extern eller sekundär nyckel.

För varje master_id -värde i mastertabellen kan det finnas noll eller fler rader i klassens tabell. För varje klass_id -värde i tabellen är det bara en rad i mastertabellen.

Många för många

I en "produktförsäljning" -databas kan en kunds beställning innehålla flera produkter, och en produkt kan visas i flera beställningar. Denna typ av relation kallas många för många.

Det kan tjäna dig: IKT (Information and Communication Technologies)

Du kan starta databasen "produktförsäljning" med två tabeller: produkter och beställningar. Produkttabellen innehåller information om produkterna, med produkten som en primär nyckel.

Å andra sidan innehåller beställningarna kundorder med begäran som primär kod.

Du kan inte lagra de produkter som begärs i den beställda tabellen, eftersom det inte är känt hur många kolumner som reserverar för produkterna. Order kan inte heller lagras i tabellprodukterna av samma anledning.

För att erkänna en relation många för många är det nödvändigt att skapa en tredje tabell, känd som unionens tabell (begär), där varje rad representerar ett element i en viss ordning.

För den begärande tabellen består den primära nyckeln av två kolumner: ordning och produkt, identifiering av varje rad varje rad.

De begärda och produktkolumnerna i begäran om metoder används för att referera till beställningarna och produkterna. Därför är de också externa nycklar till begäran om begäran.

En och en

I databasen "Products Sale" kan en produkt ha valfri information, som en ytterligare beskrivning och dess bild. Håll det inuti produkterna skulle generera många tomma utrymmen.

Därför kan du skapa en annan tabell (Extexts -produkt) för att lagra valfria data. Endast en post för produkter med valfri data skapas.

De två borden, produkterna och produkten har en en -till -en relation. För varje rad i produkttabellen finns det en maximal rad i produkttabellexterna. Samma produkt bör användas som huvudnyckel för båda tabellerna.

Fördelar

Strukturellt självständighet

I den relationella databasmodellen påverkar inte förändringar i databasstrukturen tillgång till data.

När det är möjligt att göra ändringar i strukturen i databasen utan att påverka DBM: s förmåga att få åtkomst till uppgifterna kan det sägas att strukturell oberoende har uppnåtts.

Konceptuell enkelhet

Den relationella databasmodellen är ännu enklare på konceptuell nivå än den hierarkiska modellen eller databasnätverket.

Eftersom den relationella databasmodellen frigör designern från detaljerna om fysisk lagring av data kan designarna koncentrera sig på den logiska vyn av databasen.

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

Den relationella databasmodellen uppnår både oberoende av data och oberoende av strukturen, vilket gör design, underhåll, administration och användning av databasen mycket enklare än de andra modellerna.

Ad-hoc-konsultationskapacitet

Närvaron av en mycket kraftfull, flexibel och enkel konsultationskapacitet är en av de främsta orsakerna till den enorma populariteten för databasens relationsbasmodell.

Konsultationsspråket i den relationella databasmodellen, kallad strukturerat konsultationsspråk eller SQL, gör ad-hoc-frågor till verklighet. SQL är ett fjärde generationens språk (4GL).

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

Nackdelar

Hårdvaruutgifter

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

Kan tjäna dig: vad är G -koder? (Med exempel)

För att göra detta behöver relationsdatabassystem datorer med kraftfullare hårdvara och lagring.

Därför behöver RDBMS kraftfulla maskiner för att arbeta utan problem. Eftersom bearbetningskraften hos moderna datorer ökar i en exponentiell takt är behovet av mer bearbetningskraft i det aktuella scenariot inte längre ett mycket stort problem.

Designlätt kan leda till dålig design

Relationsdatabasen är enkel att designa och använda. Användare behöver inte känna till de komplexa detaljerna om fysisk lagring av data. De behöver inte veta hur data verkligen lagras för att komma åt dem.

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

När databasen växer kommer de dåligt utformade databaserna att bromsa systemet och orsaka en nedbrytning av dataprestanda och korruption.

Fenomen av "informationsöar"

Som sagt tidigare är relationella databassystem enkla att implementera och använda. Detta kommer att skapa en situation där för många människor eller avdelningar kommer att skapa sina egna databaser och applikationer.

Dessa informationsöar kommer att undvika integration av information, vilket är avgörande för organisationens flytande och effektiva funktion.

Dessa enskilda databaser kommer också att skapa problem som datakonsekvens, dataduplikation, dataredundans, etc.

Exempel

Anta att en databas består av de anmälande tabellerna, bitarna och leveranserna. Strukturen på tabellerna och vissa provregister presenteras nedan:

Varje rad i leveranstabellen identifieras av ett unikt leverantörsnummer (SNO), som unikt identifierar varje rad i tabellen. Likaså har varje bit ett unikt artikelnummer (PNO).

Dessutom kan det inte finnas mer än en leverans för en given leverantör / bit kombination i fraktbordet, eftersom denna kombination är den primära fraktnyckeln, som fungerar som en facklig tabell, eftersom många är en relation till många för många.

Förhållandet mellan tabeller och transporter ges genom att ha gemensamt PNO -fältet (styckenummer) och förhållandet mellan leverantörer och transporter uppstår från att ha gemensamt SNO -fältet (leverantörsnummer).

Analysera transporttabellen kan erhållas som information som skickas totalt 500 nötter från Suneet och Ankit -leverantörerna, 250 vardera.

På samma sätt skickades 1.100 bultar totalt från tre olika leverantörer. 500 blå skruvar skickades från Suneet -leverantören. Det finns inga röda skruvtransporter.

Referenser

1. Wikipedia, The Free Encyclopedia (2019). Relationsmodell. Taget från: i.Wikipedia.org.
2. Ravepedia (2019). Relationsmodell. Taget från: ravepedia.com.
3. Diesh Thakur (2019). Relationsmodell. ECOMPUTER NOTER. Taget från: ecomputerotes.com.
4. Geeks for Geeks (2019). Relationsmodell. Taget från: GeeksForgeeks.org.
5. Nanyang Technological University (2019). En snabbhandledning om relationsdatabasdesign. Taget från: ntu.Edu.Sg.
6. Adrienne Watt (2019). Kapitel 7 Relationell datamodell. BC öppna läroböcker. Taget från: OpenTextbc.Växelström.
7. Topppr (2019). Relationsdatabaser och scheman. Taget från: toppr.com.