Grunnleggende databasemodeller. Databasemodeller

Enhver database gjenspeiler informasjon om en bestemt fagområde. Avhengig av hvilket abstraksjonsnivå fagområdet er representert på, finnes det ulike nivåer datamodeller. Under informasjonsmodell data refererer til en måte å beskrive informasjonen i et fagområde. I det følgende vil strukturerte datamodeller bli vurdert. For disse modellene er det fire hovednivåer av modeller: infologiske (konseptuelle), datalogiske eller logiske, fysiske og nivå av eksterne modeller.

På det første nivået er beskrivelsen av fagområdet konstruert slik at den er så generell som mulig, ikke avhenger av funksjonene i det senere valgte DBMS, og informasjonen er tilgjengelig for en bred kategori brukere: fra kunder til systemprogrammerere som skal designe en database basert på denne modellen. For å gjøre dette blir den første informasjonen om fagområdet analysert og presentert i en formalisert form. Denne formaliserte beskrivelsen av fagområdet skal gjenspeile dets spesifikke egenskaper og brukes på de neste stadiene av utformingen av databasestrukturen i sammenheng med funksjonene til den valgte spesifikke DBMS. En slik formalisert beskrivelse av fagområdet kalles en infologisk eller konseptuell modell.

Deretter bygges en modell i forhold til den spesifikke DBMS som er valgt for databasedesign. Dette nivået kalles en datalogisk (logisk) modell. Beskrivelsen av den datalogiske strukturen til en database på språket til den valgte DBMS kalles dens skjema.

Neste nivå er fysisk modell data. Innenfor rammen av denne modellen fastsettes metoder for fysisk plassering av data i et lagringsmiljø, og det utvikles et såkalt datalagringsskjema. Siden forskjellige DBMS-er har forskjellige muligheter og funksjoner i den fysiske organiseringen av data, da fysisk modellering utføres først etter utviklingen av en datalogisk modell.

Rad moderne DBMS ha evnen til å beskrive strukturen til databasen fra en bestemt brukers synspunkt. Denne beskrivelsen kalles ekstern modell. For hver type bruker lar ekstern modellering deg utvikle et databaseunderskjema basert på behovene til ulike kategorier av brukere. Denne tilnærmingen er praktisk fra synspunktet om å lette arbeidet til brukere med databasen, siden brukeren kan, uten å vite om hele strukturen til databasen, bare jobbe med den delen av den som er direkte relatert til ham. I tillegg tjener mekanismen for å lage underkretser ekstra midler beskyttelse av informasjon som er lagret i databasen.

Således, hvis DBMS støtter muligheten til å lage underskjemaer, blir databasearkitekturen tre-nivå: lagringsskjemanivå, skjemanivå og underskjemanivå.

La oss nå vurdere hovedtypene av datamodeller.

Den hierarkiske databasemodellen er en av de første databasemodellene. Dette er først og fremst på grunn av det faktum at det er nettopp denne modellen som mest naturlig gjenspeiler flere forbindelser mellom objekter i den virkelige verden, når ett objekt fungerer som en forelder, som et stort antall underordnede objekter er assosiert med.

Prinsippet for den hierarkiske databasemodellen er at alle sammenhenger mellom data beskrives ved å konstruere en ordnet graf (tre). Et tre er ordnet i henhold til et hierarki av sett med elementer kalt noder. Alle noder er forbundet med hverandre med grener. I dette tilfellet, for å beskrive skjemaet til en hierarkisk database, brukes konseptet "tre" som en spesifikk datatype. Denne datatypen er sammensatt og kan inkludere undertyper eller undertrær. En database er en samling av trær, som hver på språket til den hierarkiske modellen kalles en fysisk database. Hvert tre består av en enkelt rottype (hoved, overordnet) og et tilhørende ordnet sett med underordnede (underordnede) typer. En rottype er en som har undertyper og ingen overordnede typer. Barnetyper som har samme foreldretype kalles tvillinger. Hver av de underordnede typene for en gitt rottype kan enten være enkle eller kompositt type"ta opp".

Det er tre typer trær - balanserte, ubalanserte og binære trær. I et balansert tre har hver node samme antall grener. Denne typen dataorganisasjon er fysisk den enkleste, men ofte logisk struktur data krever et variabelt antall grener ved hver node, som tilsvarer et ubalansert tre. Binære trær tillater maksimalt to grener per node.

Dermed kan en hierarkisk databasemodell tolkes som en ordnet samling av treforekomster, som hver inneholder postforekomster. Det faktiske innholdet i databasen lagres i feltene til postene. Et postfelt er definert som den minste, udelelige enheten av data.

Når du bygger en hierarkisk databasemodell, må du alltid huske å støtte integriteten til relasjoner, noe som betyr at:

  • - alltid tilgjengelig i det minsteén overordnet type, som kan ha et vilkårlig antall underordnede typer;
  • - underordnede typer kan ikke eksistere uten tilstedeværelsen av en overordnet type, og for hver underordnet type i databasen er det et enkelt rotlag;
  • - rottypen har ikke nødvendigvis underordnede typer.

Det skal bemerkes at noen notasjoner kan bruke annen terminologi. Således, i notasjonen til American Database Association DBTG (Data Base Task Group), tilsvarer begrepet "record" begrepet "segment", og en post er hele settet med poster som tilhører en forekomst av "treet" type.

Hovedfordelen med den hierarkiske databasemodellen er den relativt høy hastighet behandle informasjon ved tilgang til data. Ulempene inkluderer dens besværlighet i nærvær av komplekse logiske forbindelser mellom dataene.

Nettverksdatabasemodellen er på en måte en generalisering av den hierarkiske modellen. Hovedforskjellen mellom en nettverksmodell og en hierarkisk er at i en nettverksmodell kan en underordnet type ha et vilkårlig antall overordnede typer. Hovedkonseptene i nettverksmodellen er sett, aggregering, registrering og dataelement. Under dataelementet i i dette tilfellet bør bety det samme som i den hierarkiske modellen - minimumsenhet data. Det finnes to typer dataaggregater: et vektoraggregat og et gjentakende gruppeaggregat. Et aggregat av typen vektor tilsvarer et sett med dataelementer. Et aggregat av typen repeterende gruppe tilsvarer en samling av datavektorer. En post er en samling av dataaggregater. Hver post har en bestemt type og består av en samling av postforekomster. Et sett er en graf som forbinder to typer poster. Dermed gjenspeiler settet det hierarkiske forholdet mellom de to typene poster. Skriv inn overordnet post dette settet kalles eieren av settet, og den underordnede posttypen kalles et medlem av samme sett. For alle to typer poster kan et hvilket som helst antall sett som forbinder dem spesifiseres. I dette tilfellet kan det bestemmes mellom de to typene poster forskjellig mengde settene. Den samme posttypen kan imidlertid ikke være både eier og medlem av et sett.

En utvilsom fordel med nettverksdatamodellen er muligheten for mer fleksibel visning av flere forbindelser mellom objekter. En av de mest betydelige mangler ligger i den høye kompleksiteten til databasekonstruksjonsordningen, som forverres av svekket kontroll over integriteten til tilkoblinger på grunn av deres store antall.

Den relasjonsdatamodellen er basert på konseptet om en relasjon, som er en todimensjonal tabell som inneholder mange rader (tupler) og kolonner (felt eller attributter). Tabellen tilsvarer et spesifikt objekt i fagområdet, feltene beskriver egenskapen av dette objektet, og strenger er spesifikke forekomster av et objekt. Hver relasjon må alltid inneholde et attributt eller sett med attributter som unikt identifiserer den eneste tuppelen av denne relasjonen - primærnøkkel. For å gjenspeile forholdet mellom objekter, er tabeller koblet i henhold til visse regler ved bruk av såkalte fremmednøkler, som vil bli diskutert i detalj i de følgende avsnittene.

Hovedfordelen med relasjonsmodellen er dens enkelhet og logiske lukkethet, og ulempen er kompleksiteten til beskrivelsessystemet ulike forbindelser mellom bordene.

Utviklingen av relasjonsmodellen førte til fremveksten av den såkalte post-relasjonelle datamodellen, hvor hovedforskjellen er tillattheten av felt med flere verdier (felt hvis verdier består av mange underverdier). Felt med flere verdier kan tolkes som uavhengige tabeller innebygd i kildetabellen. I tillegg støtter den post-relasjonelle modellen flere assosierte felt som sammen danner en assosiasjon: i hver rad tilsvarer den første verdien i en assosiasjonskolonne de første verdiene i alle andre assosiasjonskolonner.

Hovedfordelen med den post-relasjonelle modellen er at den lar deg lagre data mer effektivt, og antallet tabeller i denne modellen er merkbart mindre sammenlignet med den relasjonelle. Ulempen er at det er vanskelig å opprettholde logisk konsistens av dataene.

Teorien om flerdimensjonale datamodeller utvikler seg aktivt i I det siste. Konseptet med en flerdimensjonal modell betyr flerdimensjonaliteten til den logiske representasjonen av strukturen til informasjon. Hovedkonseptene i en flerdimensjonal modell er dimensjon og celle.

En dimensjon er et sett med data av samme type som danner overflaten til en n-dimensjonal kube. En celle er et felt hvis verdi bestemmes av hele settet med målinger. Celleverdien kan være en variabel eller en formel.

Å jobbe med flerdimensjonale modeller data brukes spesielle flerdimensjonale DBMS-er, som er basert på begrepene aggregerbarhet, historisitet og forutsigbarhet. Dataaggregerbarhet refererer til ulike nivåer av informasjonsgeneralisering. Datahistorikk betyr høy level den statiske karakteren til både selve dataene og forbindelsene mellom dem, samt rekkefølgen av data over tid under behandlingen og presentasjonen for brukerne. Å sikre forutsigbarhet bestemmes ved å bruke spesielle funksjoner prognoser.

Flerdimensjonale DBMS-er bruker to dataorganisasjonsskjemaer - polykubisk og hyperkubisk. I den polykubiske modellen kan n-dimensjonale kuber ha enten ulike dimensjoner, og forskjellige dimensjoner-ansikter. I den hyperkubiske modellen er alle dimensjonene til kubene like, og dimensjonene til forskjellige kuber er like.

En skive er en viss delmengde av en n-dimensjonal kube, definert ved å fikse et gitt antall dimensjoner. En skive har en dimensjon mindre enn n og brukes spesielt til å presentere informasjon til brukere i form av lesbare todimensjonale tabeller. Rotasjon brukes også ofte til å representere data i to dimensjoner og innebærer å endre rekkefølgen på dimensjonene. Aggregering og drill-down operasjoner betyr en mer generell eller mer detaljert presentasjon av informasjon.

Multidimensjonale datamodeller er spesielt praktiske for å jobbe med store databaser, siden de tillater effektiv behandling av betydelige mengder informasjon, og dette er deres utvilsomme fordel.

Hovedforskjellen mellom den objektorienterte modellen og de som er diskutert ovenfor, er bruken av objektorienterte metoder for datamanipulering - innkapsling, arv og polyformisme.

Innkapsling betyr evnen til å differensiere tilgang ulike programmer, applikasjoner, metoder og funksjoner (i en bredere forstand og tilgang for ulike kategorier av brukere) til ulike egenskaper til dataobjekter. I sammenheng med begrepet "innkapsling" brukes ofte begrepet synlighet - graden av tilgjengelighet til individuelle egenskaper til et objekt. Moderne objektorienterte programmeringssystemer (som Delphi eller C++ Builder) har neste nivåer innkapsling (synlighet), som vanligvis kalles seksjoner:

  • 1. Seksjoner Offentlig, Publisert og Automatisert - med mindre særegne trekk objektegenskaper beskrevet som tilhørende disse seksjonene er fullt tilgjengelige.
  • 2. Privat seksjon - denne seksjonen pålegger de strengeste restriksjonene på synligheten av objektegenskaper. Som regel er slike egenskaper kun tilgjengelige for eieren av dette objektet ( programvaremodul, der dette objektet ble opprettet).
  • 3. Beskyttet seksjon - i motsetning til Privat seksjon, blir eiendommene til en gjenstand tilgjengelig for arvingene til objekteieren.

I motsetning til innkapsling innebærer arv fullstendig overføring av alle egenskapene til et overordnet objekt til underordnede objekter. Om nødvendig kan arv av egenskaper til ett objekt utvides til objekter som ikke er dets barn.

Polymorfisme betyr evnen til samme applikasjon til å manipulere data forskjellige typer- applikasjoner (metoder, prosedyrer og funksjoner) som behandler objekter forskjellige typer, kan ha samme navn.

Hovedfordelen med objektorienterte modeller er muligheten til å modellere en rekke komplekse forhold mellom objekter.

Data i databaser er organisert etter en av datamodellene.

Ved hjelp av en datamodell kan domeneobjekter og relasjonene mellom dem representeres. At. Grunnlaget for enhver database er datamodellen.

Datamodell – et sett med datastrukturer og operasjoner for deres behandling.

TIL klassiske modeller Datarepresentasjoner inkluderer hierarkisk, nettverk og relasjonell. Hierarkiske og nettverksdatamodeller begynte å bli brukt i databasestyringssystemer på begynnelsen av 60-tallet. På begynnelsen av 70-tallet ble det foreslått relasjonsmodell data. De tre modellene skiller seg hovedsakelig i måten de representerer forhold mellom objekter.

Grunnleggende datapresentasjonsmodeller:

1. Hierarkisk datamodellen representerer informasjon vises objekter i den virkelige verden - enheter og deres forbindelser i formen rettet graf eller tre (fig. 2). Nodene og grenene danner en hierarkisk trestruktur. En node er en samling av attributter som beskriver et objekt. Den høyeste noden i hierarkiet kalles rotnoden (dette er hovedtype gjenstand). Rotnoden er på første nivå. Avhengige noder (underordnede typer objekter) er plassert på andre, tredje og andre nivåer. I en slik modell har hvert objekt kun én kilde (med unntak av rotobjektet), men i prinsippet kan det være flere avhengige (barn).

Fig. 17. Hierarkisk modellstruktur

Grener mellom objekter gjenspeiler tilstedeværelsen av et eller annet forhold, og navnet på forholdet er skrevet på kanten. For eksempel, mellom objektene "kunde" og "ordre" kan det være en relasjon kalt "gjør", og mellom "ordre" og "produkter" kan det være en relasjon kalt "består av". Denne typen modell reflekterer vertikale forbindelser, underordningen av det nedre nivået til det øvre, dvs. Hver databasepost har bare én (hierarkisk) bane fra rotposten.

Et eksempel på en slik modell er en database som inneholder informasjon om et universitet (ved å bruke eksemplet med BelGSHA)

2. Nettverksmodell – er en utvidelse av den hierarkiske modellen , Men i motsetning til det er det horisontale forbindelser (fig. 3). I denne datamodellen kan ethvert objekt være både en master og en slave. En struktur kalles nettverk hvis, i relasjonene mellom data, et underordnet element har mer enn ett overordnet element. Nettverksmodellen gir større muligheter sammenlignet med den hierarkiske, men den er vanskeligere å implementere og bruke. Et eksempel er strukturen til en database som inneholder informasjon om studenter som deltar i forskningsarbeid. Det er mulig for én student å delta i flere temaer, samt flere elever i utviklingen av ett tema.

Ris. 18. Representasjon av forbindelser i en nettverksmodell

3. Relasjonsmodell. Konseptet med en relasjonsdatamodell (fra engelsk relasjon) er assosiert med utviklingen til Erich Codd. Denne modellen er preget av en enkel datastruktur, brukervennlig tabellpresentasjon og evnen til å bruke apparatet til relasjonsalgebra for databehandling.


Den relasjonsmodellen er fokusert på å organisere data i form av todimensjonale tabeller koblet sammen av visse relasjoner.

En relasjonstabell har følgende egenskaper :

ü tabellen må ha et navn;

ü hvert tabellelement er ett dataelement;

ü alle kolonnene i tabellen er homogene, dvs. alle elementene i en kolonne har samme type(numerisk, tegn eller annet) og lengde;

ü hver kolonne har unikt navn;

ü det er ingen identiske rader i tabellen;

ü rekkefølgen på rader og kolonner kan være vilkårlig;

ü tabellen skal være enkel, dvs. inneholder ikke sammensatte kolonner;

Primærnøkkelen må være kjent.

En relasjonsdatabasetabell består av et visst antall poster av samme type, eller tupler. Ordet «samme type» betyr at alle poster har samme sett med attributter, eller felt, selv om hvert attributt kan ha sin egen verdi.

Tenk på en tabell som inneholder data om ansatte i en bedrift

Det er mange måter å implementere elementære dataenheter på, og derfor er en rekke datamodeller kjent. Datamodellen gir regler for å strukturere den. Som regel er operasjoner på data relatert til deres struktur. Varianter eksisterende modeller data tilsvarer en rekke applikasjoner og brukerpreferanser.

For å representere data brukes modeller basert på former for informasjonsrepresentasjon. Slike modeller kalles syntaktisk.

I den spesialiserte litteraturen er det en beskrivelse av ganske stor kvantitet datamodeller. Hierarkiske, nettverks- og relasjonelle metoder er mye brukt. I tillegg til dem er de mest kjente den binære modellen og det semantiske nettverket.

Den klassiske, lengst brukte datamodellen anses å være basert på hierarkisk struktur type tre(et fragment er vist i fig. 10). Modellen "ordnet tre" brukes også ofte, der den relative rekkefølgen til undertrærne er signifikant. I en slik modell er hver påfølgende informasjonsenhet assosiert med kun en tidligere, og tidligere kan assosieres med flere påfølgende.


Nettverksdatamodell basert på en representasjon av informasjon der én informasjon kan assosieres med hvilket som helst tall andre (fig. 11).


Relasjonsdatamodell basert på tabellformede metoder og midler til å presentere og manipulere data. I en slik modell vises informasjon om fagområdet i en tabell som kalles en «relasjon» (fig. 12). En rad i en slik tabell kalles en tuppel, og en kolonne kalles et attributt. Hvert attributt kan ta et visst delsett av verdier fra et spesifikt område - domene.

De aller fleste DBMS-er fokuserte på personlige datamaskiner, er systemer bygget på grunnlag av en relasjonsdatamodell - relasjonell DBMS.

Binær datamodell er en grafmodell der toppunktene reflekterer representasjoner av enkle, entydige attributter, og buer representerer representasjoner av binære forhold mellom attributter (fig. 13).


Den binære modellen er ikke mye brukt, men i noen tilfeller finner den praktisk bruk. Ja, i området kunstig intelligens Det har lenge vært utført forskning for å representere informasjon i form av binære relasjoner.

Semantiske nettverk ble foreslått som datamodeller av forskere som jobber med ulike problemer kunstig intelligens. Akkurat som i nettverk og binære modeller, grunnleggende strukturer semantisk nett kan representeres av en graf, hvis sett med toppunkter og buer danner et nettverk. Semantiske nettverk er imidlertid utformet for å representere og systematisere kunnskap av svært generell karakter.

Dermed kan enhver grafmodell (for eksempel en merket binær graf) betraktes som et semantisk nettverk hvis det i utgangspunktet er klart angitt hva toppunktene og buene betyr og hvordan de brukes.

Semantiske nettverk er en rik kilde til datamodelleringsideer som er ekstremt nyttige for å løse representasjonsproblemet vanskelige situasjoner. De kan brukes uavhengig eller sammen med ideer som ligger til grunn for andre datamodeller. Deres interessant funksjon viser at avstanden målt på nettverket (semantisk avstand, eller metrisk) spiller viktig rolle, bestemme nærheten av sammenhengende konsepter. Samtidig er det mulig å eksplisitt understreke at den semantiske avstanden er stor. Som vist i fig. 14, STORE korrelerer med personligheten til SELGER, og samtidig har SELGER VEKT. Forholdet mellom personlighet og spesialitet er åpenbart, men dette betyr ikke nødvendigvis forholdet mellom BUTIKK og VEKT.


Det må sies at datamodeller som det semantiske nettverket, for all rikdommen av deres evner til å modellere komplekse situasjoner, er preget av kompleksitet og en viss ineffektivitet i konseptuelle termer.

La oss dvele mer detaljert ved relasjonelle, hierarkiske og nettverksmodeller data.

Relasjonsmodell data er preget av følgende komponenter:

– informasjonskonstruksjon: et forhold til en struktur på to nivåer;

– gyldige operasjoner: projeksjon, utvalg, tilkobling og noen andre;

– restriksjoner: funksjonelle avhengigheter mellom attributter i forholdet.

Hver klasse av objekter R den materielle verden er satt i samsvar med et visst sett av attributter, for eksempel EN 1 , EN 2 , ..., A n. Enkeltklasseobjekt R beskrevet av en streng med verdier ( en 1, en 2, ..., a n), Hvor en i– attributtverdi A i.

Linje ( en 1, en 2, ..., en n) kalles en tuppel. En hel objektklasse har et tilsvarende sett med tupler kalt en relasjon. La oss betegne relasjonen som beskriver klassen av objekter R, også gjennom R.

Uttrykk R(A 1, A 2, ..., A n) kalles et relasjonsskjema R.

For hver tuppelkomponent må forholdet til det tilsvarende attributtet spesifiseres. I den relasjonsdatamodellen, for å sikre denne forbindelsen, faller rekkefølgen av komponentene i tupelen sammen med rekkefølgen på attributtene i relasjonsskjemaet.

Hvert forhold gjenspeiler tilstanden til en klasse av objekter på et tidspunkt. Følgelig kan forskjellige relasjoner tilsvare det samme relasjonsskjemaet på forskjellige tidspunkter.

Settet med relasjonsverdier kan representeres i form av en tabell der følgende samsvar er observert:

– navnet på tabellen og listen over kolonnenavn tilsvarer relasjonsdiagrammet;

– en tabellrad tilsvarer en relasjonstuppel;

– alle rader i tabellen (og derfor alle tupler) er forskjellige;

– rekkefølgen på rader og kolonner er vilkårlig (spesielt krever ikke relasjonsdatamodellen spesiell sortering av rader).

Beskrivelsen av relasjonsbehandlingsprosesser kan gjøres på to måter:

- som indikerer en liste over operasjoner, hvis implementering fører til det nødvendige resultatet (prosedyremessig tilnærming),

– en beskrivelse av egenskapene som den resulterende relasjonen må tilfredsstille (deklarativ tilnærming).

La oss vurdere prosedyremessig tilnærming. Et sett med relasjoner og operasjoner på dem dannes relasjonsalgebra. Vanligvis inneholder listen over operasjoner projeksjon, seleksjon, forening, skjæring, subtraksjon og sammenføyning.

En projeksjon er en operasjon som overfører kolonnene til den opprinnelige relasjonen spesifisert i operasjonsbetingelsen til den resulterende relasjonen. Den algebraiske representasjonen av projeksjonen har formen

T = R[X],

Hvor R– innledende holdning; T- resulterende relasjon; X– liste over attributter i relasjonsstrukturen T(projeksjonstilstand).

Vurder forholdet O 1, som inneholder informasjon om produktsalg i 2010 (tabell 1).

Tabell 1

Holdning T 1, som kun inneholder informasjon om den faktiske produksjonen av produkter, er oppnådd som et resultat av å utføre projeksjonen

T 1 = O 1[Butikk, produkter, fakta]

og ser ut som et bord. 2.

tabell 2

Kolonner kan spesifiseres i hvilken som helst rekkefølge:

T 1 = OM 1 [Produkter, Butikk, Fakta].

En seleksjon er en operasjon som overfører til den resulterende relasjonen de radene fra den opprinnelige relasjonen som tilfredsstiller seleksjonsbetingelsen. Valgbetingelsen testes på hver rad i relasjonen individuelt og kan ikke spenne over informasjon på tvers av flere rader. Det er to enkleste typer prøvetakingsbetingelser:

1) Attributtnavn 1<знак сравнения>Verdi der sammenligningstegn =, #, >, ≥ er tillatt<, ≤. Например: Цена > 100.

Attributtnavnene må inneholdes i kilderelasjonsstrukturen. Den algebraiske notasjonen for prøven har formen

T = R[s],

Hvor R– innledende holdning; T- resulterende relasjon; R– prøvetakingstilstand.

For eksempel får vi verdiene T 2 = OM 1 [Produkt = "P 1"] (tabell 3).

Tabell 3

Operasjonene union, skjæring og subtraksjon utføres på to originale relasjoner med samme struktur.

La oss betegne de innledende relasjonene med R 1 og R 2 , den resulterende – gjennom T.

En forening T = U(R 1 , R 2) inneholder rader til stede enten i relasjon R 1, eller inn R 2 .

Kryss T = Jeg(R 1 , R 2) inneholder radene som er tilstede i relasjonene R 1 og R 2 samtidig.

Subtraksjon T = M(R 1 , R 2) inneholder disse linjene fra R 1 som mangler i R 2 .

En relasjonssammenføyningsoperasjon utføres på to kilderelasjoner og skaper én resulterende relasjon. Hver rad i den første kilderelasjonen sammenlignes etter tur med alle radene i den andre relasjonen, og hvis sammenføyningsbetingelsen er oppfylt for dette paret av rader, blir de sammenkoblet og danner den neste raden i den resulterende relasjonen. Tilkoblingsbetingelsen har formen

Attributtnavn 1<знак сравнения>Attributtnavn 2,

der attributtnavn 1 er i en kilderelasjon og attributtnavn 2 er i en annen. Vi vil bruke følgende notasjon for sammenføyningsoperasjonen:

T = R l [ s] R 2 ,

Hvor R 1 og R 2 - innledende relasjoner; T- resulterende relasjon; R– tilkoblingstilstand.

Et av de viktigste spesialtilfellene av en sammenføyning kalles en naturlig sammenføyning og har følgende funksjoner:

– sammenligningstegnet i tilkoblingsbetingelsen er "=";

– Attributtnavn 1 og attributtnavn 2 må samsvare, eller rettere sagt, inneholde skjæringspunktet mellom attributtlistene til kilderelasjonene;

– listen over attributter til den resulterende relasjonen dannes som et resultat av å kombinere listene over attributter til de opprinnelige relasjonene.

Betegnelsen for en naturlig forbindelse inneholder ikke en sammensatt tilstand og har formen T = R l* R 2 .

Deklarativ tilnærming for behandling relasjonsdatabaser data er basert på tolkning av begreper og metoder for matematisk logikk. Spesielt er relasjonsregning basert på predikatregning. La oss nevne begrepene i matematisk logikk som er nødvendig for relasjonsregning.

1. Symboler for variabler og konstanter. I språkkonstruksjonene til relasjonsregning tilsvarer de navnene på attributter og variabler, samt konstanter.

2. Logiske koblinger "og", "eller", "ikke" og sammenligningstegn =, # (ikke lik), >,<, ≥, ≤.

3. Termer, dvs. eventuelle konstanter og variabler, samt funksjoner hvis argumenter er termer.

4. Elementære formler er predikater hvis argumenter er termer. Predikater forbundet med operasjonene "og", "eller", "ikke" er også elementære formler. Elementære formler er for eksempel uttrykkene Etternavn = «Petrov» og Beløp ≤ Totalt.

5. Formler, dvs. resultatet av å bruke kvantifiserere for generalitet eller eksistens på elementære formler. Formelen tilsvarer en spørring til en relasjonsdatabase, uttrykt i form av relasjonsregning.

Hovedoppgaven med å designe en EIS-database er å bestemme antall relasjoner (eller andre konstituerende informasjonsenheter) og deres attributtsammensetning.

Problemet med å gruppere attributter i relasjoner, hvis sett ikke er løst på forhånd, åpner for mange forskjellige løsninger. Rasjonelle grupperingsalternativer må ta hensyn til følgende krav:

– sett med relasjoner bør sikre minimal redundans i presentasjonen av informasjon;

– justering av forhold bør ikke føre til tvetydighet eller tap av informasjon;

– restrukturering av settet med relasjoner ved å legge til nye attributter til databasen bør være minimal.

Normalisering er en av de mest studerte metodene for å transformere relasjoner, som gjør det mulig å forbedre egenskapene til databasen i henhold til de listede kriteriene.

Det er mange restriksjoner på verdiene som er lagret i en relasjonsdatabase. Overholdelse av disse restriksjonene i spesifikke henseender er forbundet med tilstedeværelsen av såkalte normale former. Prosessen med å konvertere databaserelasjoner til en eller annen normal form kalles relasjonsnormalisering . Normale former er nummerert sekvensielt fra 1 i stigende rekkefølge. Jo større det normale skjemanummeret er, desto flere begrensninger på de lagrede verdiene må overholdes i det relevante henseende.

Begrensninger som er typiske for den relasjonsdatamodellen er funksjonelle og flerverdiede avhengigheter, så vel som deres generaliseringer. I prinsippet kan settet med ytterligere restriksjoner vokse, og derfor vil antallet normale former øke. De anvendte restriksjonene er rettet mot å redusere redundant informasjon i relasjonsdatabasen.

En relasjon i første normalform (1NF) er en ordinær relasjon med en to-nivå struktur. De neste normalformene (andre og tredje) bruker begrensninger knyttet til begrepet funksjonell avhengighet. Funksjonelle avhengigheter er definert for attributter som er i samme relasjon som tilfredsstiller 1NF.

Det enkleste tilfellet av funksjonell avhengighet involverer to attributter. I et forhold R(EN, B, ..., J) Egenskap EN definerer funksjonelt et attributt I, hvis til enhver tid hver verdi EN I(betegnet EN → I).

Med andre ord, I funksjonelt avhenger av EN (I = f(EN)). Den første betegnelsen viser seg å være mer praktisk når antallet funksjonelle avhengigheter vokser og relasjonene deres blir vanskelige å skjelne; det vil bli brukt i fremtiden. Fraværet av funksjonell avhengighet er betegnet som EN → I.

For attributter EN Og I noen sammenheng, er følgende situasjoner mulige:

- mangel på funksjonell avhengighet;

- Tilgjengelighet EN → I(eller I → EN), men ikke begge avhengighetene sammen;

– Tilstedeværelse av en-til-en korrespondanse EN ↔ I.

Begrepet funksjonell avhengighet strekker seg til situasjoner med tre eller flere attributter i følgende form. Attributtgruppe ( EN, I, MED) definerer funksjonelt attributtet D i et forhold T(EN, B, C, D, ..., J), hvis hver kombinasjon av verdier<a, b, Med> samsvarer med en enkelt verdi d (EN- mening EN; b- mening I; Med- mening MED; d- mening D). Tilstedeværelsen av en slik funksjonell avhengighet vil bli betegnet med EN, I, MED → D.

Eksistensen av funksjonelle avhengigheter er assosiert med metodene for attributtkoding som brukes. For mange institusjoner kan det således hevdes at hver avdeling (som et objekt av fagområdet) tilhører en enkelt institusjon. Dette er imidlertid ikke nok til å bevise den funksjonelle avhengigheten til Institutt → Institusjon. Hvis avdelingene i hver institusjon er nummerert sekvensielt, starter med 1, er funksjonsforholdet feil. Dersom avdelingskoden i tillegg til nummeret også inneholder institusjonskoden (eller kodenes unikhet er sikret på annen måte), så er funksjonsrelasjonen Avdeling → Institusjon gyldig.

For en indikator med mange attributtattributter R = (R 1 , R 2 , ..., P n) og baseattributtet Q funksjonell avhengighet er gyldig R → Q, selv om det ikke kan sies at dette er den eneste avhengigheten av de spesifiserte attributtene.

Sannsynlig ledetråd relasjon er et slikt sett med attributter, der hver kombinasjon av verdier bare forekommer i en rad av relasjonen, og ingen undergruppe av attributter har denne egenskapen. Det kan være flere mulige nøkler i en relasjon. Deres betydning i databehandling bestemmes av det faktum at sampling med en kjent verdi av en sannsynlig nøkkel resulterer i én relasjonsrad eller ingen.

I praksis er attributtene til den sannsynlige nøkkelen til en relasjon assosiert med egenskapene til de objektene og hendelsene som det er lagret informasjon om i relasjonen. Hvis, som et resultat av justering av forholdet, navnene på attributtene som utgjør nøkkelen har endret seg, vil informasjonen bli alvorlig forvrengt. Derfor gjør systematisk kontroll av egenskapene til en sannsynlig nøkkel det mulig å kontrollere påliteligheten til informasjon i en relasjon.

Når det er flere kandidatnøkler i en relasjon, er det svært vanskelig å observere dem samtidig. Det anbefales å velge en av dem som den viktigste (primære). Primærnøkkel Et forhold kalles en sannsynlig nøkkel, hvis verdier brukes til å kontrollere påliteligheten til informasjon i forholdet.

Når det gjelder økonomisk informasjon, inneholder relasjoner hentet fra eksisterende økonomiske dokumenter i de aller fleste tilfeller én enkelt sannsynlig nøkkel, som også er primærnøkkelen. Dette er fordi innholdet i økonomiske dokumenter forstås likt av alle brukere. I det følgende skal vi bare huske på slike forhold. Tilstedeværelsen av to eller flere sannsynlige ledetråder i et forhold med meningsfull informasjon kan forklares med tilstedeværelsen av flere mulige måter å tolke de samme dataene på. Primærnøkkelen kalles ofte ganske enkelt en nøkkel.

I forhold til et stort antall rader er det ganske vanskelig å finne primærnøkkelen ved å bruke definisjonen direkte. I tillegg, på EIS-designstadiet, er verdiene til mange relasjoner rett og slett ukjente, så praktisk talt blir primærnøkkelen til en relasjon beregnet basert på de eksisterende funksjonelle avhengighetene.

Hver primærnøkkelverdi vises i bare én rad i relasjonen. Verdien til ethvert attributt på denne linjen er også unik. Hvis gjennom TIL angi attributtene til primærnøkkelen i relasjonen R(EN, B, C, ..., J), så er følgende funksjonelle avhengigheter gyldige: TIL → EN, TIL → I, TIL → MED, ..., TIL → J. Et sett med primærnøkkelattributter definerer funksjonelt alle attributter til en relasjon. Det motsatte er også sant: hvis en gruppe attributter blir funnet som funksjonelt definerer alle attributtene til en relasjon individuelt, og denne gruppen ikke kan reduseres, blir primærnøkkelen til relasjonen funnet.

For det innledende settet med funksjonelle avhengigheter er det en rekke mønstre, kunnskap om hvilke gjør det mulig å oppnå avledede avhengigheter. La oss merke noen av dem:

- Hvis EN, I → EN, deretter EN, I → I;

- A → I Og EN → MED da og bare når EN → Sol;

- Hvis EN → I Og I → MED, Det EN →MED;

- Hvis EN → I, Det AC → I (MED vilkårlig);

- Hvis EN → I, Det AC → Sol (MED vilkårlig);

- Hvis EN → I Og Sol → D, Det AC → D.

Hvis det er kjent på forhånd at det bare er én sannsynlig nøkkel i en relasjon, så kan den finnes på en enkel måte. En sannsynlig nøkkel (hvis den er unik, dvs. samsvarer med primærnøkkelen) er et sett med attributter som ikke forekommer på høyre side av alle funksjonelle avhengigheter. Med andre ord, fra den komplette listen over relasjonsattributter, er det nødvendig å slette attributtene som finnes på høyresiden av alle funksjonelle avhengigheter. De resterende attributtene utgjør primærnøkkelen.

En relasjon er i andre normalform (2NF) hvis den tilsvarer 1NF og ikke inneholder ufullstendige funksjonelle avhengigheter.

En ufullstendig funksjonell avhengighet består av to avhengigheter:

– en sannsynlig relasjonsnøkkel definerer funksjonelt et ikke-nøkkelattributt,

– en del av den sannsynlige nøkkelen definerer funksjonelt det samme ikke-nøkkelattributtet.

En relasjon som ikke er i samsvar med 2NF er preget av redundans av lagrede data. En database er i 2NF hvis alle dens relasjoner er i 2NF.

En relasjon tilsvarer 3NF hvis den tilsvarer 2NF og det ikke er noen transitive funksjonelle avhengigheter (FD) blant attributtene.

Transitiv føderal lov inkluderer to føderale lover:

– en sannsynlig relasjonsnøkkel definerer funksjonelt et ikke-nøkkelattributt;

– Dette attributtet definerer funksjonelt et annet ikke-nøkkelattributt.

Hvis TIL- nøkkelen til forhold, EN, I– ikke-nøkkelattributter og TIL → EN, EN → I er rettferdige føderale lover, så er de transitive. Et spesielt tilfelle av en transitiv føderal lov er en ufullstendig føderal lov, når TIL = MED, E Og TIL → E, E → EN.

En database er i 3NF hvis alle dens relasjoner er i 3NF.

En relasjonsdatabase, som generelt tilsvarer den tredje normalformen, kjennetegnes av en rekke egenskaper som kjennskap til letter og effektiviserer databehandlingsprosesser. Implementeringen av databasespørringer ved bruk av relasjonsalgebra-operatorer kan beskrives med følgende regler.

1. I den verbale formuleringen av forespørselen markerer du navnene på attributtene som utgjør skallet, inndata og utdata for forespørselen, samt utvalgsbetingelsene.

2. Fiks mange skallattributter. Hvis alle nødvendige attributter er i en relasjon, utføres påfølgende valg og projeksjonsoperasjoner bare med den. Hvis de nødvendige attributtene er fordelt på flere relasjoner, må disse relasjonene kobles sammen. Hvert par av relasjoner er forbundet med betingelsen om likhet av attributter med samsvarende navn (eller definert på et felles domene). Etter hver tilkobling, ved hjelp av projeksjon, kan du kutte av attributter som er unødvendige for påfølgende operasjoner.

4. Hvis en spørring kan deles inn i deler (underspørringer), er implementeringen også delt inn i deler, hvor resultatet av hver delspørring er en separat relasjon.

5. Denne handlingssekvensen er standard, men kan skape mellomliggende relasjoner som er for store. Denne ulempen kan kompenseres for ved å utføre noen valg og projeksjoner på de opprinnelige relasjonene (før sammenføyningen) og endre den relative rekkefølgen til de nødvendige sammenføyningene.

Nettverksdatabase er representert som et sett av relasjoner og fanrelasjoner. Relasjoner er delt inn i primære og avhengige.

Fanforhold W(R, S) er et par relasjoner som består av en hoved ( R), ett avhengig forhold ( S) og forbindelsene mellom dem, forutsatt at hver verdi av den avhengige relasjonen er assosiert med en enkelt verdi av hovedrelasjonen. Denne tilstanden er en begrensningskarakteristikk for nettverksdatamodellen som helhet. Måten å implementere denne begrensningen i datamaskinens minne er forskjellig for forskjellige nettverks-DBMS-er.

Operasjonene som er tillatt i nettverksdatamodellen representerer forskjellige samplingsalternativer.

Nettverksdatabaser, avhengig av begrensningene for oppføring av relasjoner i fan-forhold, er delt inn i to-nivå og multi-level nettverk.

En begrensning for to-nivå nettverk er at hvert forhold kan eksistere i en av følgende roller:

– utenfor eventuelle fanforhold;

– som hovedforholdet i et hvilket som helst antall fanforhold;

– som et avhengig forhold i et hvilket som helst antall fanforhold.

Det er forbudt at et forhold eksisterer som et hovedforhold i en sammenheng og samtidig som et avhengighetsforhold i en annen.

Flernivånettverk gir ingen begrensninger for sammenkobling av vifteforhold; i noen nettverks-DBMS-er er til og med sykliske nettverksstrukturer tillatt.

For to-nivå nettverks-DBMS-er introduseres ytterligere to begrensninger (fra et teoretisk synspunkt, valgfritt):

– primærnøkkelen til hovedrelasjonen kan bare være ett attributt;

– en vifterelasjon eksisterer hvis primærnøkkelen til hovedrelasjonen er en del av primærnøkkelen til den avhengige relasjonen.

For å organisere et vifteformet forhold i datamaskinens minne, introduseres en ekstra attributt kalt kommunikasjonsadressen i strukturen til hoved- og avhengige relasjoner. Kommunikasjonsadresseverdiene jobber sammen for å sikre at hver avhengige relasjonsverdi samsvarer med en vifterelasjon S til en enkelt verdi av hovedrelasjonen R.

Verdien av et forhold når det er lagret i datamaskinens minne kalles ofte en post. Kommunikasjonsadressen er et attributt i en post som lagrer startadressen eller nummeret til den neste posten som skal behandles.

Forbindelsen mellom verdiene til den avhengige relasjonen og enkeltverdien til hovedrelasjonen er i det enkleste tilfellet sikret som følger. Linkadressen til en bestemt hovedrelasjonspost peker til en av de avhengige relasjonspostene (verdien til hovedrelasjonslenkeadressen er startadressen til den avhengige relasjonsposten), lenkeadressen til den spesifiserte avhengige relasjonsposten peker til neste avhengige relasjonspost knyttet til den samme hovedrelasjonsposten, og etc. Den siste avhengige relasjonsposten i denne kjeden adresserer hovedrelasjonsposten nevnt ovenfor. Dette resulterer i en ringstruktur av kommunikasjonsadresser som kalles som en fan, der rollen som "håndtaket" til viften spilles av innspillingen av hovedforholdet. I grafiske illustrasjoner er kommunikasjonsadressen avbildet med en pil rettet fra kommunikasjonsadressen til en gitt post til posten hvis startadresse (nummer) tjener som verdien til denne kommunikasjonsadressen.

Det finnes standardkonvensjoner for hvordan man inkluderer og ekskluderer data i et fanforhold. Aktiveringsmetoden kan karakteriseres som automatisk eller ikke-automatisk.

Den automatiske metoden indikerer at når en ny verdi av hovedrelasjonen vises, blir den umiddelbart satt i samsvar med en eller annen verdi av den avhengige relasjonen og danner et nytt element i vifterelasjonen. Manglende overholdelse av denne regelen er typisk for den ikke-automatiske metoden.

Ekskluderingsmetoder kan være obligatoriske eller valgfrie. I den obligatoriske metoden, når en verdi er inkludert i hovedrelasjonen, blir den et permanent medlem av hovedrelasjonen. Den kan oppdateres, men kan ikke fjernes fra forholdet. Den valgfrie metoden lar deg fjerne enhver verdi fra den underliggende relasjonen.

Fra analogien til definisjonene av en fan-relasjon og funksjonell avhengighet følger utsagnet: hvis det er en fan-relasjon, så bestemmer nøkkelen til den avhengige relasjonen funksjonelt nøkkelen til hovedrelasjonen, og omvendt, hvis nøkkelen til en relasjon bestemmer funksjonelt nøkkelen til den andre relasjonen, så kan den første relasjonen være avhengig, og den andre - hoved på en eller annen vifte-aktig måte.

I et nettverksdatabasediagram blir relasjoner og vifterelasjoner ofte behandlet som filer og tilkoblinger, noe som gjør at nettverksstrukturen kan sees på som et sett med filer

F = {F l ( X 1), F 2 (X 2), ..., F i(X i), ..., Fn(X n)},

Hvor X i– nøkkelattributter i filen F i.

I tillegg introduseres en nettverksstrukturgraf I med hjørner ( X jeg, X 2 , ..., X i, ..., X n). Bue<X i, Xj> i kolonnen I eksisterer hvis X i er en del Xj Og Fj[X i] er en delmengde F i. Den siste betingelsen har samme betydning som den syntaktiske inkluderingen av relasjoner i den relasjonsdatamodellen. Dette forutsetter at hovedfilnøkkelen er inneholdt i den avhengige filen. Kurve I ligner på koblingsgrafen for en relasjonsdatabase.

Database DBA kalt asyklisk, hvis mellom to punkter på grafen I det er høyst én vei. To-lags nettverk er alltid asykliske .

For mange filer F asyklisk database DBA operasjonen er ganske anvendelig

m(DBA) = F 1 & F 2 & ... & F i & ...& Fn,

kalt maksimalt kryss. Dens analoge kan være en sekvens av forbindelser i en relasjonsdatabase.

I nettverks-DBMS-er er antallet samplingsoperasjoner ganske stort. Projeksjonsoperasjonsfunksjonene for et nettverks-DBMS utfører beskrivelsen av et nettverksdatabaseunderskjema. Et nettverksdatabaseskjema er en beskrivelse av alle relasjoner som indikerer attributtsammensetningen og nøklene til hver relasjon, samt fanrelasjoner. I applikasjonsprogrammet er det mulig å deklarere deler av relasjonene til en nettverksdatabase, i hvert forhold - et visst undersett av attributter (med obligatorisk oppbevaring av nøkkelattributter) og bare noen fan-forhold. Den tilsvarende databeskrivelsen kalles et underskjema. Relasjoner, fanrelasjoner og attributter som ikke er spesifisert i underskjemaet, blir utilgjengelige for applikasjonsprogrammet. I motsetning til projeksjonsoperasjonen, opprettes ikke databasen som tilsvarer underskjemaet fysisk, men ved å begrense tilgangen til kildedatabasen, som er definert i skjemaet.

Resultatene av gyldige tilkoblinger registreres faktisk i nettverkets DBMS ved å bruke kjeder med kommunikasjonsadresser. Tilgang til resultatene av en mulig sammenføyning starter fra en hovedrelasjon til en fan av verdier i den tilsvarende avhengige relasjonen, de oppnådde nøkkelverdiene i den avhengige relasjonen huskes og brukes til å søke i en annen hovedrelasjon; fra dette hovedforholdet er en overgang til en ny forsørger mulig osv.

Hierarkisk modell data har mange likheter med nettverksdatamodellen; kronologisk dukket det opp enda tidligere. Gyldige informasjonsstrukturer i en hierarkisk datamodell er relasjon, fanrelasjon og hierarkisk database. I motsetning til de tidligere omtalte datamodellene, hvor det ble antatt at informasjonskartleggingen av ett fagområde er én database, tillater den hierarkiske modellen kartlegging av ett fagområde til flere hierarkiske databaser.

Begrepene relasjon og fanrelasjon i den hierarkiske datamodellen endres ikke.

En hierarkisk database er et sett med relasjoner og fanrelasjoner der to begrensninger er oppfylt:

1) det er en enkelt relasjon, kalt roten, som ikke er avhengig i noen vifterelasjon;

2) alle andre relasjoner (bortsett fra roten) er avhengige relasjoner i bare en fanrelasjon.

Det hierarkiske databaseskjemaet er identisk i sammensetningen med nettverksdatabasen. Restriksjonene ovenfor støttes av hierarkiske DBMS-er.

Begrensningen som opprettholdes i den hierarkiske datamodellen er at det er umulig å bryte kravene som fremgår av definisjonen av den hierarkiske databasen. Denne begrensningen er sikret av et spesielt arrangement av relasjonsverdier i datamaskinens minne. Nedenfor vil vi se på en av de enkleste implementeringene for å legge ut en hierarkisk database.

Det skal bemerkes at det er forskjellige muligheter for å gå gjennom hierarkisk organiserte verdier i en lineær sekvens. Prinsippet som brukes for hierarkiske databaser kalles endepassasje. La oss liste opp reglene.

1. Fra den første verdien av rotrelasjonen, er de første verdiene av de tilsvarende relasjonene på hvert nivå oppført, opp til den siste.

2. Alle verdier i vifteforholdet der trinn 1 stoppet er oppført.

3. Verdiene til alle fans av denne fanrelasjonen er oppført.

4. Fra det oppnådde nivået skjer stigningen til forrige nivå, og hvis det er mulig å bruke trinn 1, gjentas prosessen.

En hierarkisk databasepost er et sett med verdier som inneholder én verdi av rotrelasjonen og alle fans som strekker seg fra den i samsvar med strukturen til den hierarkiske databasen. I vårt eksempel består én post av data knyttet til ett fakultet (se fig. 11).

For fanrelasjoner i en hierarkisk database er det allerede kjente mønsteret gyldig: hvis det er en fanrelasjon, bestemmer nøkkelen til den avhengige relasjonen funksjonelt nøkkelen til hovedrelasjonen. Og omvendt: hvis nøkkelen til en relasjon funksjonelt bestemmer nøkkelen til den andre relasjonen, kan den første relasjonen være avhengig, og den andre - den viktigste i en eller annen fanrelasjon.

I tillegg oversetter begrensningen at det er en enkelt rotrelasjon i en hierarkisk database til kravet om at primærnøkkelen til hver ikke-rotrelasjon funksjonelt må definere primærnøkkelen til rotrelasjonen.

Algoritmen for å få strukturen til en hierarkisk database ble kompilert av A.I. Mishenin.

Når man sammenligner datamodeller, er det svært vanskelig å skille faktorer som kjennetegner modellens grunnleggende funksjoner fra faktorer knyttet til implementeringen av disse datamodellene ved bruk av spesifikke DBMS-er.

Tatt i betraktning fordelene og ulempene med de mest kjente datamodellene, er det verdt å merke seg en rekke utvilsomme fordeler med den relasjonelle tilnærmingen:

– enkelhet: i relasjonsmodellen er det bare én informasjonsstruktur, som formaliserer den tabellformede presentasjonen av data, kjent for økonombrukere;

- teoretisk begrunnelse: tilstedeværelsen av teoretisk begrunnede metoder for å normalisere relasjoner og kontrollere strukturens asyklisitet gjør det mulig å skaffe databaser med de nødvendige egenskapene;

– datauavhengighet: endring av strukturen til en relasjonsdatabase fører som regel til minimale endringer i applikasjonsprogrammer.

Blant ulempene med relasjonsdatamodellen er følgende:

– lav hastighet når du utfører en tilkoblingsoperasjon;

– høyt minneforbruk for å representere en relasjonsdatabase. Selv om design i 3NF er designet for minimal redundans (hvert faktum er representert i databasen én gang), gir andre datamodeller under samme forhold mindre minneforbruk. For eksempel er lengden på en kommunikasjonsadresse vanligvis mye kortere enn lengden på en attributtverdi.

Fordelene med en hierarkisk datamodell er:

– enkelhet: selv om modellen bruker tre informasjonsstrukturer, er det hierarkiske prinsippet om underordning av konsepter naturlig for mange økonomiske oppgaver (for eksempel for å organisere statistisk rapportering);

– minimalt minneforbruk: for oppgaver som kan implementeres ved hjelp av en av de tre datamodellene, lar den hierarkiske modellen deg få en representasjon med minimum nødvendig minne.

Ulemper med den hierarkiske modellen:

– ikke-universalitet: mange viktige alternativer for datasammenkobling kan ikke implementeres ved hjelp av en hierarkisk modell uten å øke redundansen i databasen;

– tillatelighet av kun navigasjonsprinsippet for tilgang til data;

– data er kun tilgjengelig gjennom rotrelasjonen.

Følgende fordeler med nettverksdatamodellen bør bemerkes:

– universalitet: de uttrykksfulle egenskapene til nettverksdatamodellen er de mest omfattende sammenlignet med andre modeller;

– muligheten til å få tilgang til data gjennom verdiene til flere relasjoner (for eksempel gjennom alle hovedrelasjoner).

Ulempene med nettverksdatamodellen inkluderer:

– kompleksitet, dvs. overflod av konsepter, varianter av deres relasjoner og implementeringsfunksjoner;

– tillatelighet av kun navigasjonsprinsippet for tilgang til data.

Resultatene oppnådd for asykliske databaser antyder at asykliske relasjonsdatabaser, to-nivå nettverksdatabaser og en hierarkisk database uten logiske forbindelser har tilsvarende informasjonspresentasjonsevner.

Analysen av datamodeller tok ikke opp problemet med å bestille verdier i databaserelasjoner. For relasjonsmodellen er denne rekkefølgen valgfri fra et teoretisk synspunkt, men i de to andre modellene er den mye brukt for å forbedre effektiviteten av spørringsimplementering.

Det endelige valget av en datamodell påvirkes av mange tilleggsfaktorer, for eksempel tilgjengeligheten av velprøvde DBMS-er, kvalifikasjonene til applikasjonsprogrammerere, størrelsen på databasen, etc.

Nylig har relasjonelle DBMS-er tatt en dominerende posisjon som et middel for å utvikle elektroniske informasjonssystemer. Ulempene med relasjonsmodellen kompenseres av økningen i hastighet og minneressurser til moderne datamaskiner. På grunn av prosessene med desentralisering av ledelsen i økonomien, har mange EIS-databaser en enkel struktur som lett kan transformeres til forståelige tabellsystemer (relasjoner).

Test spørsmål og oppgaver

1. List opp de mest kjente typene datamodeller.

2. Forklar hierarkiske og nettverksdatamodeller. Hva er deres likheter og forskjeller?

3. Beskriv relasjonsmodellen.

4. Beskriv den binære modellen og dens omfang.

5. Hva er spesifikke for semantiske nettverk og deres formål?

6. Liste informasjonskonstruksjoner for ulike teknologier.

7. Nevn komponentene i relasjonsdatamodellen.

8. Definer tuppel og relasjon.

9. På hvilke måter kan relasjonell prosessering beskrives?

10. Avslør essensen av den prosedyrebeskrivelsen av databehandlingsprosesser.

11. Forklar den deklarative tilnærmingen til behandling av relasjonsdatabaser.

12. Hva er normalisering av relasjoner?

13. Hvor mange attributter er det i den enkleste funksjonelle avhengigheten?

14. Definer funksjonell avhengighet av attributter i form av den relasjonelle tilnærmingen.

15. Hva er en sannsynlig relasjonsnøkkel?

16. Hva er en primærnøkkel? Hva er et annet navn for den?

17. Forklar mønstrene for mange funksjonelle avhengigheter.

18. Beskriv den andre og tredje normale formen for forhold.

19. Forklar tilgang til en relasjonsdatabase.

20. Navngi informasjonsstrukturene i nettverksmodellen.

21. Hva er en "fanattitude"?

22. Gi en definisjon av to-nivå nettverk.

23. Definer multi-level nettverk.

24. Hva er en "kommunikasjonsadresse"?

25. Hva kalles en "fan"?

26. Hvilke komponenter inneholder et nettverksdatabaseskjema?

27. Hvilke standardkonvensjoner vet du om hvordan du inkluderer og ekskluderer data i et fanforhold?

28. Hva er filer og lenker?

29. Hva er "maksimalt kryss"?

30. Navngi informasjonsstrukturene i den hierarkiske modellen.

31. Definer en hierarkisk database.

32. Fortell oss om reglene for sluttpassasje.

33. Definer en hierarkisk basispost.

34. Nevn fordeler og ulemper ved den relasjonelle tilnærmingen.

35. List opp fordeler og ulemper ved den hierarkiske modellen.

36. Beskriv styrker og svakheter ved nettverksdatamodellen.

38. Gjennomfør oppgavene 2.1–2.20 om operasjoner på relasjoner fra verkstedet.

39. Gjennomfør oppgavene 2.21–2.32 om temaet «Funksjonelle avhengigheter og nøkler» fra verkstedet.

40. Gjennomfør oppgavene 2.33–2.60 om temaet «Normale former for relasjoner» fra workshopen.

41. Fullfør oppgavene 2.61–2.71 om temaet “Acyclic Databases” fra workshopen.

42. Gjennomfør oppgavene 2.72–2.93 om temaet «Nettverk og hierarkiske datamodeller» fra workshopen.

Klassifisering etter datamodell (etter organisasjonsstruktur).

Historie.

Historien om fremveksten og utviklingen av databaseteknologier kan sees fra både et bredt og et snevert perspektiv.

I bredt aspekt Konseptet om databasenes historie er generalisert til historien til alle midler som menneskeheten har lagret og behandlet data på. I denne sammenhengen nevnes for eksempel midler til regnskap for den kongelige skattkammer og skatter i det gamle Sumer (4000 f.Kr.), inkaenes knuteskrift, kileskrift som inneholder dokumenter fra det assyriske riket, etc. Det bør huskes at ulempen med denne tilnærmingen er uskarpheten av begrepet "database" og dets faktiske sammenslåing med begrepene "arkiv" og til og med "skriving".

Historien om databaser i smalt aspekt undersøker databaser i tradisjonell (moderne) forstand. Denne historien begynner i 1955, da programmerbart opptaksbehandlingsutstyr dukket opp. Programvare fra denne tiden støttet en filbasert platebehandlingsmodell. Hulkort ble brukt til å lagre data. Online operasjonelle databaser dukket opp på midten av 1960-tallet. Operasjoner på operasjonelle databaser ble behandlet interaktivt ved hjelp av terminaler. Enkle indekssekvensielle plateorganisasjoner utviklet seg raskt til en kraftigere settorientert platemodell. Charles Bachman mottok Turing-prisen for sin ledelse av Data Base Task Group (DBTG), som utviklet et standardspråk for å beskrive og manipulere data.

Samtidig utviklet COBOL-databasefellesskapet (et av de eldste programmeringsspråkene (første versjon i 1959), først og fremst ment for å utvikle forretningsapplikasjoner) konseptet med databaseskjemaer og konseptet datauavhengighet.

Det neste viktige stadiet var assosiert med fremveksten av relasjonsdatamodellen på begynnelsen av 1970-tallet, takket være arbeidet til Edgar F. Codd. Codds arbeid banet vei for en nær forbindelse mellom anvendt databaseteknologi og matematikk og logikk. Edgar F. Codd mottok også Turing-prisen for sine bidrag til teori og praksis.

Selve begrepet database(database) dukket opp på begynnelsen av 1960-tallet, og ble introdusert i bruk på symposier organisert av SDC (System Development Corporation) i 1964 og 1965, selv om det opprinnelig ble forstått i en ganske snever forstand, i sammenheng med kunstige intelligenssystemer. Begrepet kom i utbredt bruk i moderne forstand først på 1970-tallet.

Grunnleggende klassifiseringer av databaser.

Når du arbeider med en database, opprettholder DBMS en bestemt domenemodell i datamaskinens minne, kalt datamodell. Datamodellen bestemmes av typen DBMS.



Hierarkisk modell. Hierarkisk organisert data er svært vanlig i hverdagen. For eksempel strukturen til en høyere utdanningsinstitusjon. Hierarkisk datamodell- presentasjon av databasen i form av en trestruktur (hierarkisk) bestående av objekter (data) på ulike nivåer. Det øverste nivået er okkupert av ett objekt, det andre - av objekter på det andre nivået, etc. Det er forbindelser mellom objekter; hvert objekt kan inneholde flere objekter på et lavere nivå. Slike objekter er i forholdet mellom en stamfar (en gjenstand nærmere roten) til et barn (en gjenstand på et lavere nivå), og det er mulig at et forfedreobjekt ikke har noen etterkommere eller har flere av dem, mens et etterkommerobjekt må bare ha en stamfar. Gjenstander som har en felles stamfar kalles tvillinger. Den største ulempen med denne modellen er behovet for å bruke hierarkiet som var grunnlaget for databasen under utformingen. Behovet for konstant omorganisering av data førte til opprettelsen av en mer generell modell - en nettverksmodell.

Nettverksmodell. Nettverkstilnærmingen til dataorganisering er en utvidelse av den hierarkiske tilnærmingen. Til de grunnleggende konseptene nettverksdatabasemodell inkluderer: nivå, element (node), tilkobling. En node er en samling av dataattributter som beskriver et objekt. I et hierarkisk trediagram er noder representert som toppunkter i grafen. I en nettverksstruktur kan hvert element kobles til et hvilket som helst annet element. Nettverksdatabaser ligner hierarkiske databaser, bortsett fra at de har pekere i begge retninger som forbinder relatert informasjon. Selv om denne modellen løser noen av problemene knyttet til den hierarkiske modellen, er det fortsatt ganske komplekst å utføre enkle spørringer. Siden logikken til datahentingsprosedyren avhenger av den fysiske organiseringen av disse dataene, er denne modellen ikke helt uavhengig av applikasjonen. Med andre ord, hvis datastrukturen må endres, må applikasjonen endres.

(Denne modellen skiller seg fra den hierarkiske ved at hvert generert element kan ha mer enn ett skadelig element. Det vil si at i en nettverksstruktur kan hvert element kobles til et hvilket som helst annet element).

Relasjonsmodell. Relasjonsdatabase- en database basert på en relasjonsdatamodell. Den ble utviklet av Codd i 1969-70 på grunnlag av den matematiske relasjonsteorien og er basert på et begrepssystem, hvorav de viktigste er bord , holdning , felt , ta opp . Denne modellen har fått mest anerkjennelse. Ordet "relasjonell" kommer fra det engelske "relation", som betyr forhold. Det er praktisk å representere relasjoner i form av tabeller. De. Ordet tabell brukes ofte som et uformelt synonym for begrepet "forhold". Det må huskes at "bord" er et løst og uformelt begrep og betyr ofte ikke "forhold" som et abstrakt begrep, men en visuell representasjon av forholdet på papir eller skjerm. Feil og lemfeldig bruk av begrepet "tabell" i stedet for begrepet "relasjon" fører ofte til misforståelser. Den vanligste feilen er å tro at RMD omhandler "flate" eller "to-dimensjonale" tabeller, når slike bare kan være visuelle representasjoner av tabeller. Relasjoner er abstraksjoner, og kan verken være "flate" eller "ikke-flate"

En relasjonsdatabase er en der alle data presenteres for brukeren i form av tabeller, og alle operasjoner på databasen er redusert til manipulasjoner med tabeller.

Felt(kolonne) – et dataelement som gjenspeiler et attributt til et objekt (for eksempel, hvis objektet er en student, vil dets attributter være fullt navn, adresse, telefon, etc.). U Enger det finnes databaser alternativer, som bestemmer typen data som skal lagres, metoden for å vise dem og settet med operasjoner som utføres på den. En av de viktige feltparametrene er data-type.

Objekt- og objektorientert. Objektorientert database- en database der data formateres i form av objektmodeller, inkludert applikasjonsprogrammer som styres av eksterne hendelser. Resultatet av å kombinere egenskapene (funksjonene) til databaser og egenskapene til objektorienterte programmeringsspråk er Object-Oriented Database Management Systems (OODBMS). OODBMS lar deg jobbe med databaseobjekter på samme måte som med objekter i OOLP-programmering. OODBMS utvider programmeringsspråk ved å transparent introdusere vedvarende data, samtidighetskontroll, datagjenoppretting, tilknyttede spørringer og andre funksjoner. Objektorienterte databaser anbefales vanligvis for tilfeller der det kreves høyytelsesbehandling av data med en kompleks struktur.

Objekt-relasjonell- Relasjonsbasert DBMS (RSDBMS), som støtter noen teknologier som implementerer en objektorientert tilnærming.

Hierarkisk datamodell

Det er en rekkefølge av elementene i posten, ett element regnes som det viktigste, resten er underordnet. Dataene i posten er ordnet i en bestemt rekkefølge, som trinnene på en stige, og søket etter data kan bare utføres ved sekvensiell nedstigning fra trinn til trinn. Å søke etter et hvilket som helst dataelement i et slikt system kan være ganske arbeidskrevende på grunn av behovet for å gå gjennom flere tidligere hierarkiske trinn sekvensielt.

En hierarkisk database er dannet av en katalog med filer lagret på disk; Katalogtreet, tilgjengelig for visning i Total Commander, er en tydelig demonstrasjon av strukturen til en slik database og søket etter ønsket element i den. Den samme databasen er et slektstre.

Nettverksdatamodell

Det utmerker seg ved stor fleksibilitet, siden det er mulig å etablere horisontale forbindelser i tillegg til vertikale hierarkiske forbindelser. Dette gjør det lettere å finne de nødvendige dataelementene, siden det ikke lenger er nødvendig å gå gjennom alle de eksisterende trinnene.

Nettverksdatabasen er faktisk World Wide Web for det globale datanettverket Internett. Hyperkoblinger kobler hundrevis av millioner dokumenter sammen til én enkelt nettverksdatabase.

Relasjonsdatamodell

I en relasjonsdatabase er en post en rad i en rektangulær tabell. Elementene i en post danner kolonnene i denne tabellen (felt). Alle elementer i en kolonne har samme type (numerisk, tegn), og hver kolonne har et unikt navn. Det er ingen identiske rader i tabellen.

Fordelene med slike databaser er klarhet og klarhet i dataorganisering, hastighet på søk etter nødvendig informasjon.

Et eksempel på en relasjonsdatabase er et stipendoppgaveark, der oppføringen er en rad med data om en spesifikk student, og navnene på feltene (kolonnene) angir hvilke data om hver student som skal registreres i tabellcellene.

Enhver type kan reduseres til relasjonell.

Datatyper

Datatypen definerer settet med verdier som et gitt felt kan ta på seg i forskjellige poster.

Hoveddatatyper i moderne databaser:

    numerisk;

    tekst;

  • dato tid;

    monetære;

    logisk;

Nøkler

    Supernøkkel - dette er ett eller flere tabellfelt som unikt identifiserer hver rad i tabellen

    Potensiell (mulig) nøkkel dette er en supernøkkel som inneholder det minste settet med felt som er nødvendig for å identifisere hver rad i tabellen unikt.

    Primærnøkkel - Dette potensiell nøkkelen valgt for å identifisere hver rad i tabellen unikt; Vanligvis velges den kandidatnøkkelen som er lettest å legge inn, vanligvis en numerisk.

Nøkkelfelt tabeller i Access DBMS er primærnøkkelen til tabellen.

Typer relasjonelle relasjoner

    en til en;

Hver primærnøkkelverdi i hovedtabellen tilsvarer én eller flere poster i den underordnede tabellen.

Denne typen relasjoner brukes ikke så ofte fordi mesteparten av informasjonen relatert på denne måten kan plasseres i en enkelt tabell. En en-til-en-relasjon kan brukes til å partisjonere tabeller som inneholder mange felt, for å skille deler av tabellen av sikkerhetsgrunner, og til å lagre informasjon relatert til et undersett av poster i hovedtabellen.

    en-til-mange;

Hver primærnøkkelverdi i hovedtabellen har én, flere eller ingen poster i den underordnede tabellen.

En en-til-mange-relasjon er den mest brukte typen relasjon mellom tabeller.

    mange-til-mange.

I en mange-til-mange-relasjon kan én post i tabell A ha flere poster i tabell B, og én post i tabell B kan ha flere poster i tabell A. En mange-til-mange-relasjon er to én-til-en relasjoner. -mange" med den tredje tabellen.

Organisering av relasjoner mellom bord

    en til en - tabeller er koblet sammen med deres primærnøkler (primærnøklene til begge tabellene er satt til å være de samme);

    en-til-mange– hovedtabellen (en) er koblet med en primærnøkkel til en underordnet tabell (mange) med en fremmednøkkel (dette er primærnøkkelen til hovedtabellen satt inn i underordnet tabell)

    mange-til-mange – For å organisere et slikt forhold mellom to tabeller opprettes en tredje (mellom) tabell der primærnøklene til de to første tabellene settes inn. Den første og tredje, samt den andre og tredje tabellen er koblet til hverandre, en en-til-mange type forhold.

Eksempel på databaseorganisering

Betingelser for dataintegritet

Integritetsbetingelsen brukes for å sikre at postene i den underordnede tabellen samsvarer med postene i hovedtabellen, d.v.s. Du kan ikke slette data fra et nøkkelfelt i hovedtabellen.

Operasjonene kaskadeoppdatering og overlappende sletting av relaterte felt tillater redigering og sletting av data i nøkkelfeltet til hovedtabellen, men er ledsaget av automatiske endringer i den relaterte tabellen.