De relasjonsmodell av databaser er en metode for å strukturere data ved hjelp av relasjoner, ved hjelp av rutenettlignende strukturer, bestående av kolonner og rader. Det er det konseptuelle prinsippet om relasjonsdatabaser. Det ble foreslått av Edgar F. Codd i 1969.
Det har siden blitt den dominerende databasemodellen for forretningsapplikasjoner, sammenlignet med andre databasemodeller, som hierarki, nettverk og objekt..
Codd hadde ingen anelse om hvor ekstremt viktig og innflytelsesrik hans arbeid som plattform for relasjonsdatabaser ville være. De fleste er veldig kjent med det fysiske uttrykket for en relasjon i en database: tabellen.
Relasjonsmodellen er definert som databasen som gjør det mulig å gruppere dataelementene i en eller flere uavhengige tabeller, som kan relateres til hverandre ved bruk av felt som er felles for hver relatert tabell..
Artikkelindeks
En databasetabell ligner et regneark. Forholdene som kan opprettes mellom tabellene, tillater imidlertid at en relasjonsdatabase effektivt lagrer en stor mengde data, som effektivt kan hentes..
Formålet med relasjonsmodellen er å gi en deklarativ metode for å spesifisere data og spørsmål: brukere erklærer direkte hvilken informasjon databasen inneholder og hvilken informasjon de vil ha fra den.
På den annen side lot de databasestyringssystemprogramvaren ha ansvaret for å beskrive datastrukturene for lagring og hentingsprosedyren for å svare på spørsmålene..
De fleste relasjonsdatabaser bruker SQL-språket til å spørre og definere dataene. For tiden er det mange relasjonelle databasesystemer eller RDBMS (Relational Data Base Management System), som Oracle, IBM DB2 og Microsoft SQL Server.
- Alle data er konseptuelt representert som et ordnet arrangement av data i rader og kolonner, kalt en relasjon eller tabell.
- Hvert bord må ha en overskrift og en kropp. Overskriften er ganske enkelt listen over kolonner. Kroppen er datasettet som fyller tabellen, organisert i rader.
- Alle verdier er skalarer. Det vil si at det på en hvilken som helst rad / kolonneposisjon i tabellen bare er en enkelt verdi.
Følgende figur viser en tabell med navnene på de grunnleggende elementene, som utgjør en komplett struktur.
Hver rad med data er en tupel, også kjent som en post. Hver rad er en n-tuppel, men "n-" blir vanligvis kastet.
Hver kolonne i en tuple kalles et attributt eller felt. Kolonnen representerer verdisettet som et bestemt attributt kan ha.
Hver rad har en eller flere kolonner kalt tabellnøkkel. Denne kombinerte verdien er unik for alle rader i en tabell. Ved hjelp av denne nøkkelen vil hver tuple bli identifisert unikt. Det vil si at nøkkelen ikke kan dupliseres. Det kalles primærnøkkelen.
På den annen side er en fremmed eller sekundær nøkkel feltet i en tabell som refererer til primærnøkkelen til en annen tabell. Brukes til å referere til primærtabellen.
Når du designer relasjonsmodellen, definerer du noen betingelser som må oppfylles i databasen, kalt integritetsregler.
Primærnøkkelen må være unik for alle tupler og kan ikke være null. Ellers vil du ikke kunne identifisere raden unikt.
For en flerkolonnøkkel kan ingen av disse kolonnene inneholde NULL.
Hver verdi av en fremmed nøkkel må matche en verdi av primærnøkkelen til den refererte eller primære tabellen.
En rad med en fremmed nøkkel kan bare settes inn i den sekundære tabellen hvis den verdien finnes i en primær tabell.
Hvis verdien på nøkkelen endres i overordnet tabell, ved å oppdatere eller slette raden, bør alle radene i underordnede tabeller med denne utenlandske nøkkelen oppdateres eller slettes tilsvarende.
Nødvendige data må samles inn for å bli lagret i databasen. Disse dataene er delt inn i forskjellige tabeller.
En passende datatype må velges for hver kolonne. For eksempel: hele tall, flytende tall, tekst, dato osv..
For hver tabell må en kolonne (eller få kolonner) velges som primærnøkkel, som unikt vil identifisere hver rad i tabellen. Primærnøkkelen brukes også til å referere til andre tabeller.
En database som består av uavhengige og ikke-relaterte tabeller har liten hensikt.
Det mest avgjørende aspektet ved utformingen av en relasjonsdatabase er å identifisere forholdet mellom tabellene. Forholdstypene er:
I en "Class Listing" -database kan en lærer undervise i null eller flere klasser, mens en klasse blir undervist av en enkelt lærer. Denne typen forhold er kjent som en-til-mange..
Dette forholdet kan ikke vises i en enkelt tabell. I databasen "Liste over klasser" kan du ha en tabell som heter Lærere, som lagrer informasjon om lærere.
For å lagre klassene som undervises av hver lærer, kan du opprette flere kolonner, men du vil møte et problem: hvor mange kolonner du skal lage.
På den annen side, hvis du har en tabell som heter Classes, som lagrer informasjon om en klasse, kan du opprette flere kolonner for å lagre informasjon om læreren..
Imidlertid, som en lærer kan undervise i mange klasser, vil dataene hans bli duplisert i mange rader i klassetabellen.
Derfor må det utformes to tabeller: en klassetabell for å lagre informasjon om klassene, med Class_Id som primærnøkkel, og en Teachers-tabell for å lagre informasjon om lærerne, med Teacher_Id som primærnøkkel..
Da kan en-til-mange-relasjonen opprettes ved å lagre hovednøkkelen til mastertabellen (Master_Id) i Classes-tabellen, som illustrert nedenfor.
Master_Id-kolonnen i Classes-tabellen er kjent som en fremmed nøkkel eller sekundær nøkkel.
For hver Master_Id-verdi i mastertabellen kan det være null eller flere rader i Classes-tabellen. For hver Class_Id-verdi i Classes-tabellen er det bare en rad i Teachers-tabellen.
I en "Produktsalg" -database kan en kundes bestilling inneholde flere produkter, og et produkt kan vises i flere ordrer. Denne typen forhold er kjent som mange for mange.
Du kan starte databasen "Produktsalg" med to tabeller: Produkter og ordrer. Produkttabellen inneholder informasjon om produktene, med produktID som primærnøkkel.
På den annen side inneholder ordretabellen kundens bestillinger, med orderID som primærnøkkel.
Du kan ikke lagre de bestilte produktene i ordretabellen, siden du ikke vet hvor mange kolonner du skal reservere for produktene. Bestillinger kan heller ikke lagres i Produkttabellen av samme grunn.
For å støtte et mange-til-mange forhold, må du opprette en tredje tabell, kjent som en sammenføyningstabell (OrderDetails), der hver rad representerer et element i en bestemt rekkefølge.
For OrderDetails-tabellen består den primære nøkkelen av to kolonner: orderID og productID, som unikt identifiserer hver rad.
Kolonnene OrderID og productID i OrderDetails-tabellen brukes til å referere til ordre- og produkttabellene. Derfor er de også fremmednøkler i OrderDetails-tabellen..
I databasen "Salg av produkter" kan et produkt ha valgfri informasjon, for eksempel tilleggsbeskrivelse og bilde. Hvis du holder det inne i produkttabellen, vil det generere mange tomme mellomrom.
Derfor kan det opprettes en annen tabell (ProductExtras) for å lagre de valgfrie dataene. Bare en post vil bli opprettet for produkter med valgfri data.
De to tabellene, Products og ProductExtras, har et en-til-en-forhold. For hver rad i produkttabellen er det maksimalt én rad i ProductExtras-tabellen. Samme produkt-ID må brukes som primærnøkkel for begge tabeller.
I relasjonsdatabasemodellen påvirker ikke endringer i databasestrukturen datatilgang.
Når det er mulig å gjøre endringer i databasestrukturen uten å påvirke DBMSs evne til å få tilgang til dataene, kan det sies at strukturell uavhengighet er oppnådd.
Den relasjonelle databasemodellen er enda mer konseptuelt enkel enn den hierarkiske eller nettverksdatabasemodellen.
Siden relasjonsdatabasemodellen frigjør designeren fra detaljene i den fysiske lagringen av dataene, kan designere fokusere på den logiske visningen av databasen.
Relasjonsdatabasemodellen oppnår både datauavhengighet og strukturuavhengighet, noe som gjør design, vedlikehold, administrasjon og bruk av databasen mye enklere enn de andre modellene..
Tilstedeværelsen av en veldig kraftig, fleksibel og brukervennlig spørringskapasitet er en av hovedårsakene til den enorme populariteten til den relasjonelle databasemodellen.
Spørrespråket til relasjonsdatabasemodellen, kalt Structured Query Language, eller SQL, gjør ad-hoc-spørsmål til virkelighet. SQL er et fjerde generasjons språk (4GL).
En 4GL lar brukeren spesifisere hva som skal gjøres, uten å spesifisere hvordan det skal gjøres. Dermed, med SQL, kan brukere spesifisere hvilken informasjon de ønsker og legge igjen detaljene for hvordan de skal få informasjonen til databasen.
Den relasjonelle databasemodellen skjuler kompleksiteten i implementeringen og detaljene i den fysiske lagringen av brukerdata.
For å gjøre dette trenger relasjonelle databasesystemer datamaskiner med kraftigere maskinvare og datalagringsenheter..
Derfor trenger RDBMS kraftige maskiner for å kjøre problemfritt. Ettersom prosessorkraften til moderne datamaskiner øker eksponentielt, er imidlertid ikke behovet for mer prosessorkraft i dagens scenario lenger et veldig stort problem..
Relasjonsdatabasen er enkel å designe og bruke. Brukere trenger ikke å vite de komplekse detaljene i fysisk datalagring. De trenger ikke å vite hvordan dataene faktisk lagres for å få tilgang til dem.
Denne enkle utformingen og bruken kan føre til utvikling og implementering av dårlig utformede databasesystemer. Siden databasen er effektiv, vil disse ineffektivitetene i design ikke komme frem når databasen er designet, og når det bare er en liten mengde data.
Når databasen vokser, vil dårlig utformede databaser redusere systemet og føre til ytelsesforringelse og datakorrupsjon..
Som nevnt tidligere er relasjonelle databasesystemer enkle å implementere og bruke. Dette vil skape en situasjon der for mange mennesker eller avdelinger lager egne databaser og applikasjoner..
Disse informasjonsøyene vil forhindre integrering av informasjon, noe som er viktig for at organisasjonen skal fungere effektivt..
Disse individuelle databasene vil også skape problemer som datainkonsistens, dataduplisering, dataredundans osv..
Anta en database som består av leverandørene, delene og forsendelsestabellene. Tabellenes struktur og noen eksempler er som følger:
Hver rad i tabellen Leverandører identifiseres av et unikt leverandørnummer (SNo), som hver rad i tabellen identifiserer. På samme måte har hver del et unikt delenummer (PNo).
Videre kan det ikke være mer enn en forsendelse for en gitt leverandør / del-kombinasjon i forsendelsestabellen, siden denne kombinasjonen er den viktigste nøkkelen til forsendelser, som fungerer som et fagforeningsbord, siden det er et forhold mellom mange og mange..
Forholdet mellom delene og forsendelsestabellene er gitt ved å ha feltet PNo (delnummer) til felles, og forholdet mellom leverandører og forsendelser oppstår ved å ha feltet SNo (leverandørnummer) til felles.
Ved å analysere forsendelsestabellen kan det fås som informasjon om at det sendes totalt 500 nøtter fra Suneet og Ankit-leverandører, 250 hver.
Tilsvarende ble 1100 bolter totalt sendt fra tre forskjellige leverandører. 500 blå skruer ble sendt fra Suneet-leverandøren. Ingen forsendelser med røde skruer.
Ingen har kommentert denne artikkelen ennå.