hjem > Godt å vite > Relasjonelle databaser. Konseptet med en relasjonsdatabase. Grunnleggende konsepter for relasjonsdatamodellen

Relasjonelle databaser. Konseptet med en relasjonsdatabase. Grunnleggende konsepter for relasjonsdatamodellen

Med denne artikkelen starter vi en ny serie viet til databaser, moderne teknologier for tilgang til og behandling av data. I løpet av denne syklusen planlegger vi å vurdere de mest populære desktop- og serverdatabasestyringssystemene (DBMS), datatilgangsmekanismer (OLD DB, ADO, BDE, etc.) og verktøy for å jobbe med databaser (administrasjonsverktøy, rapportgeneratorer, grafiske verktøy presentasjon av data). I tillegg planlegger vi å ta hensyn til metoder for å publisere data på Internett, så vel som populære metoder for behandling og lagring av data som OLAP (On-Line Analytical Processing) og opprettelse av datavarehus (Data Warehousing).

I denne artikkelen vil vi se på de grunnleggende konseptene og prinsippene som ligger til grunn for databasestyringssystemer. Vi vil diskutere den relasjonsdatamodellen, begrepet referanseintegritet og prinsipper for datanormalisering, samt datadesignverktøy. Deretter vil vi forklare hva DBMS-er er, hvilke objekter som kan inneholdes i databaser, og hvordan spørringer gjøres mot disse objektene.

Grunnleggende relasjonsdatabasekonsepter

La oss starte med de grunnleggende konseptene til et DBMS og en kort introduksjon til teorien om relasjonsdatabaser - den mest populære metoden for lagring av data i dag.

Relasjonsdatamodell

Relasjonsdatamodell ble foreslått av Dr. E.F. Codd, en anerkjent databaseforsker, i 1969 mens han var en IBM-ansatt. De grunnleggende konseptene for denne modellen ble først publisert i 1970. "A Relational Model of Data for Large Shared Data Banks", CACM, 1970, 13 N 6).

En relasjonsdatabase er et datavarehus som inneholder et sett med todimensjonale tabeller. Et sett med verktøy for å administrere slik lagring kalles relasjonsdatabasestyringssystem (RDBMS). En RDBMS kan inneholde verktøy, applikasjoner, tjenester, biblioteker, applikasjonsopprettingsverktøy og andre komponenter.

Enhver relasjonsdatabasetabell består av linjer(også kalt poster) Og kolonner(også kalt Enger). I denne serien skal vi bruke begge begrepsparene.

Radene i tabellen inneholder informasjon om fakta presentert i den (eller dokumenter, eller personer, i et ord - om gjenstander av samme type). I skjæringspunktet mellom en kolonne og en rad er de spesifikke verdiene for dataene i tabellen.

Dataene i tabellene oppfyller følgende prinsipper:

Hver verdi i skjæringspunktet mellom en rad og en kolonne må være atomisk(det vil si ikke delt opp i flere verdier).
Dataverdier i samme kolonne må tilhøre samme type tilgjengelig for bruk i et gitt DBMS.
Hver post i tabellen er unik, det vil si at det ikke er to poster i tabellen med et fullstendig samsvarende sett med verdier for feltene.
Hvert felt har et unikt navn.
Rekkefølgen av feltene i tabellen er ikke viktig.
Rekkefølgen av oppføringer er også uvesentlig.

Til tross for at tabellrader anses som uordnet, lar et hvilket som helst databasebehandlingssystem deg sortere rader og kolonner i utvalg fra det på den måten brukeren trenger.

Siden rekkefølgen av kolonner i en tabell ikke er viktig, refereres de til med navn, og disse navnene er unike for en gitt tabell (men trenger ikke å være unike for hele databasen).

Så nå vet vi at relasjonsdatabaser består av tabeller. For å illustrere noen teoretiske poeng og for å lage eksempler, må vi velge en slags database. For ikke å "finne opp hjulet på nytt" vil vi bruke NorthWind-databasen som følger med Microsoft SQL Server og Microsoft Access.

La oss nå se på relasjonene mellom tabeller.

Nøkler og tilkoblinger

La oss ta en titt på et utdrag av Kunder-tabellen fra NorthWind-databasen (vi har fjernet felt som ikke er avgjørende for å illustrere relasjonene mellom tabellene).

Fordi radene i en tabell er uordnet, trenger vi en kolonne (eller et sett med kolonner) for å identifisere hver rad unikt. En slik kolonne (eller sett med kolonner) kalles primærnøkkel (primærnøkkel). Primærnøkkelen til enhver tabell må inneholde unike ikke-tomme verdier for hver rad.

Hvis primærnøkkelen har mer enn én kolonne, kalles den sammensatt primærnøkkel (sammensatt primærnøkkel).

En typisk database består vanligvis av flere relaterte tabeller. Fragment av ordretabellen.

Kunde-ID-feltet i denne tabellen inneholder ID-en til kunden som la inn bestillingen. Hvis vi vil vite navnet på firmaet som la inn bestillingen, må vi se etter den samme kunde-ID-verdien i CustomerID-feltet i Kunder-tabellen og lese verdien av Firmanavn-feltet i raden som ble funnet. Med andre ord må vi koble sammen to tabeller, Kunder og Ordrer, ved å bruke KundeID-feltet. En kolonne som peker til en post i en annen tabell som er relatert til en gitt post kalles fremmednøkkel (fremmednøkkel). Som du kan se, i tilfellet med ordretabellen, er fremmednøkkelen CustomerID-kolonnen (fig. 1).

Med andre ord, en fremmednøkkel er en kolonne eller et sett med kolonner hvis verdier samsvarer med de eksisterende verdiene til primærnøkkelen til en annen tabell.

Dette forholdet mellom tabeller kalles kommunikasjon (forhold). Et forhold mellom to tabeller etableres ved å tilordne fremmednøkkelverdiene til en tabell til primærnøkkelverdiene til den andre.

Hvis hver kunde i Kunder-tabellen bare kan legge inn én bestilling, sies de to tabellene å være relatert til en til en (en-til-en forhold). Hvis hver kunde i Kunder-tabellen kan legge inn null, én eller mange bestillinger, sies de to tabellene å være relatert til en-til-mange (en-til-mange forhold) eller forhold master-detalj. Lignende relasjoner mellom tabeller brukes oftest. I dette tilfellet kalles tabellen som inneholder fremmednøkkelen detaljtabell, og en tabell som inneholder en primærnøkkel som definerer de mulige verdiene til en fremmednøkkel kalles mesterbord.

En gruppe relaterte tabeller kalles ordningen Database ( databaseskjema). Informasjon om tabeller, deres kolonner (navn, datatype, feltlengde), primær- og fremmednøkler, samt andre databaseobjekter kalles metadata (metadata).

Enhver manipulering av data i databaser som å velge, sette inn, slette, oppdatere data, endre eller velge metadata kalles be om til databasen ( spørsmål). Vanligvis er spørringer formulert på et eller annet språk, som enten kan være standard for forskjellige DBMS-er eller avhengig av en spesifikk DBMS.

Referanseintegritet

Vi har allerede sagt ovenfor at primærnøkkelen til enhver tabell må inneholde unike ikke-tomme verdier for en gitt tabell. Denne uttalelsen er en av reglene referanseintegritet (referanseintegritet). Noen (men ikke alle) DBMS-er kan kontrollere det unike til primærnøkler. Hvis DBMS kontrollerer det unike til primærnøkler, så hvis du prøver å tilordne en verdi til en primærnøkkel som allerede finnes i en annen post, vil DBMS generere en diagnosemelding, vanligvis inneholdende uttrykket primærnøkkelbrudd. Denne meldingen kan senere overføres til applikasjonen der sluttbrukeren manipulerer dataene.

Hvis to tabeller er knyttet til hverandre master-detalj, ekstern nøkkel detalj- tabellen skal bare inneholde de verdiene som allerede finnes blant de primære nøkkelverdiene herre- tabeller. Hvis riktigheten av fremmednøkkelverdier ikke kontrolleres av DBMS, kan vi snakke om brudd på referanseintegritet. I dette tilfellet, hvis vi sletter en post fra Kunder-tabellen som har minst én tilknyttet seg detalj- oppføring i bestillinger-tabellen, vil dette føre til bestillinger-tabellen som inneholder registreringer av bestillinger plassert av noen ukjent. Hvis DBMS kontrollerer riktigheten av verdiene til fremmednøkler, så når du prøver å tilordne en verdi til en fremmednøkkel som ikke er blant verdiene til primærnøklene til hovedtabellen, eller når du sletter eller endrer poster i hovedtabellen, som fører til brudd på referanseintegriteten, vil DBMS generere en diagnostisk melding, vanligvis inneholdende uttrykket brudd på fremmednøkkel, som senere kan sendes til brukerapplikasjonen.

De fleste moderne DBMS-er, som Microsoft Access 97, Microsoft Access 2000 og Microsoft SQL Server 7.0, er i stand til å overvåke overholdelse av referanseintegritetsregler, hvis noen er beskrevet i databasen. Til dette formål bruker slike DBMS-er forskjellige databaseobjekter (vi vil diskutere dem litt senere). I dette tilfellet vil alle forsøk på å bryte referanseintegritetsregler bli undertrykt med samtidig generering av diagnostiske meldinger eller unntak ( database unntak).

Introduksjon til datanormalisering

Datadesignprosessen er definisjonen av metadata i samsvar med målene for informasjonssystemet der den fremtidige databasen skal brukes. Detaljer om hvordan du analyserer et fagområde og lager entitetsforholdsdiagrammer ( ERD - entity-relationship diagrams) og datamodeller er utenfor omfanget av denne syklusen. De som er interessert i disse problemstillingene kan for eksempel referere til boken av K. J. Date "Introduction to Database Systems" (Dialectics, Kiev, 1998).

I denne artikkelen vil vi diskutere bare ett av de grunnleggende prinsippene for datadesign - prinsippet normalisering.

Normalisering er prosessen med å omorganisere data ved å eliminere gjentatte grupper og andre motsetninger i datalagring for å bringe tabeller til en form som tillater konsistent og korrekt redigering av data.

Normaliseringsteori er basert på begrepet normale former. En tabell sies å være i en gitt normal form hvis den tilfredsstiller et visst sett med krav. I teorien er det fem normalformer, men i praksis brukes vanligvis bare de tre første. Dessuten er de to første normalformene i hovedsak mellomtrinn for å bringe databasen til tredje normalform.

Første normalform

La oss illustrere normaliseringsprosessen med et eksempel ved å bruke data fra NorthWind-databasen. La oss anta at vi registrerer alle bestilte produkter i tabellen nedenfor. Strukturen til denne tabellen er som følger (fig. 2).

For at en tabell skal være i samsvar med første normalform, må alle feltverdiene være atomære, og

alle poster er unike. Derfor er enhver relasjonstabell, inkludert OrderedProducts-tabellen, per definisjon allerede i første normalform.

Denne tabellen inneholder imidlertid redundante data, for eksempel gjentas den samme kundeinformasjonen i posten for hvert bestilt produkt. Dataredundans resulterer i datamodifikasjonsavvik – problemer som oppstår når poster legges til, endres eller slettes. For eksempel, når du redigerer data i OrderedProducts-tabellen, kan følgende problemer oppstå:

En spesifikk kundes adresse kan kun inneholdes i databasen når kunden har bestilt minst ett produkt.
Når du sletter en registrering av et bestilt produkt, slettes samtidig informasjon om selve bestillingen og om kunden som la den.
Hvis, gud forby, kunden endrer adresse, må alle opplysningene om produktene han bestilte oppdateres.

Noen av disse problemene kan løses ved å justere databasen andre normalform.

Andre normalform

Det sies at en relasjonstabell er inne andre normalform, hvis det er i første normal form og dets ikke-nøkkelfelt helt avhengig fra hele primærnøkkelen.

OrderedProducts-tabellen er i første normalform, men ikke andre normalform, fordi feltene CustomerID, Address og OrderDate bare avhenger av OrderID-feltet, som er en del av den sammensatte primærnøkkelen (OrderID, ProductID).

For å gå fra første normalform til andre normalform, må du følge disse trinnene:

Bestem hvilke deler primærnøkkelen kan deles inn i, slik at noen av ikke-nøkkelfeltene avhenger av en av disse delene ( disse delene trenger ikke å bestå av én kolonne!).
Opprett en ny tabell for hver slik del av nøkkelen og gruppen av felt som er avhengig av den, og flytt dem til denne tabellen. En del av den tidligere primærnøkkelen vil bli primærnøkkelen til den nye tabellen.
Fjern felt fra kildetabellen som har blitt flyttet til andre tabeller, bortsett fra de som vil bli fremmednøkler.

For eksempel, for å bringe OrderedProducts-tabellen til andre normal form, må du flytte feltene CustomerID, Address og OrderDate til en ny tabell (la oss kalle det OrdersInfo), og OrderID-feltet vil bli primærnøkkelen til den nye tabellen (fig. 3).

Som et resultat vil de nye tabellene se slik ut. Tabeller som er i andre normalform, men ikke tredje normalform, inneholder imidlertid fortsatt datamodifikasjonsavvik. Her er de for eksempel for OrdersInfo-tabellen:

En spesifikk kundeadresse kan fortsatt bare finnes i databasen når kunden har bestilt minst ett produkt.
Sletting av en ordreoppføring i OrdersInfo-tabellen vil resultere i sletting av oppføringen for kunden selv.
Hvis kunden har endret adressen, vil flere poster måtte oppdateres (selv om det som regel er færre av dem enn i forrige tilfelle).

Disse anomaliene kan elimineres ved å flytte til tredje normalform.

Tredje normalform

En relasjonstabell sies å være i tredje normalform, hvis den er i andre normal form og alle dens ikke-nøkkelfelt avhenger bare av primærnøkkelen.

OrderDetails-tabellen er allerede i tredje normal form. Ikke-nøkkel Antall-feltet er helt avhengig av den sammensatte primærnøkkelen (OrderID, ProductID). OrdersInfo-tabellen er imidlertid ikke i tredje normal form, siden den inneholder en avhengighet mellom ikke-nøkkelfelt (den kalles transitiv avhengighet- transitiv avhengighet) - Adressefeltet avhenger av CustomerID-feltet.

For å gå fra andre normalform til tredje normalform, må du følge disse trinnene:

Definer alle felt (eller grupper av felt) som andre felt er avhengige av.
Lag en ny tabell for hvert slikt felt (eller gruppe av felt) og gruppen av felt som er avhengig av det, og flytt dem til denne tabellen. Feltet (eller gruppen av felt) som alle andre flyttede felt er avhengige av, blir primærnøkkelen til den nye tabellen.
Fjern de flyttede feltene fra den opprinnelige tabellen, og la bare de som vil bli fremmednøkler.

For å bringe OrdersInfo-tabellen til tredje normal form, opprette en ny kundetabell og flytte CustomerID og Adresse-feltene til den. Vi vil fjerne Adresse-feltet fra kildetabellen, og forlate KundeID-feltet - nå er det en fremmednøkkel (fig. 4).

Så, etter å ha brakt den opprinnelige tabellen til tredje normal form, var det tre tabeller - kunder, bestillinger og ordredetaljer.

Fordeler med normalisering

Normalisering eliminerer dataredundans, noe som lar deg redusere mengden lagrede data og kvitte seg med dataendringene beskrevet ovenfor. For eksempel, etter å ha redusert databasen diskutert ovenfor til tredje normalform, er følgende forbedringer tydelige:

Kundeadresseinformasjon kan lagres i databasen, selv om det kun er en potensiell kunde som ennå ikke har lagt inn en bestilling.
Du kan slette informasjon om et bestilt produkt uten frykt for å slette kunde- og ordreinformasjon.

Endring av en kundes adresse eller ordreregistreringsdato krever nå bare å endre én post.

Hvordan databaser er utformet

Vanligvis inneholder moderne DBMS-er verktøy som lar deg lage tabeller og nøkler. Det er også verktøy som leveres separat fra DBMS (og til og med betjene flere forskjellige DBMSer samtidig) som lar deg lage tabeller, nøkler og relasjoner.

En annen måte å lage tabeller, nøkler og relasjoner i en database på er å skrive et såkalt DDL-script (DDL – Data Definition Language; vi skal snakke om det litt senere).

Til slutt er det en annen måte som blir mer og mer populær – bruken av spesialverktøy kalt CASE-verktøy (CASE står for Computer-Aided System Engineering). Det finnes flere typer CASE-verktøy, men de mest brukte verktøyene for å lage databaser er entity-relationship diagrams (E/R diagrams). Ved hjelp av disse verktøyene, den såkalte logisk en datamodell som beskriver fakta og objekter som skal registreres i den (i slike modeller kalles tabellprototyper entiteter, og felt kalles deres attributter) Etter å ha etablert relasjoner mellom entiteter, definert attributter og utført normalisering, kan en s.k. fysisk en datamodell for et spesifikt DBMS, der alle tabeller, felt og andre databaseobjekter er definert. Du kan deretter generere enten selve databasen eller et DDL-skript for å lage den.

Liste over for tiden mest populære CASE-verktøy.

Tabeller og felt

Tabeller støttes av alle relasjonelle DBMS-er, og feltene deres kan lagre data av forskjellige typer. De vanligste datatypene.

Indekser

Litt høyere snakket vi om rollen til primær- og fremmednøkler. I de fleste relasjonelle DBMS-er implementeres nøkler ved hjelp av objekter kalt indekser, som kan defineres som en liste over postnumre som indikerer i hvilken rekkefølge de skal gis.

Vi vet allerede at poster i relasjonstabeller er uordnet. Imidlertid har enhver post på et bestemt tidspunkt en veldig spesifikk fysisk plassering i databasefilen, selv om dette kan endres under prosessen med å redigere data eller som et resultat av de "interne aktivitetene" til selve DBMS.

Anta at postene i Kunder-tabellen på et tidspunkt ble lagret i denne rekkefølgen.

La oss si at vi trenger å få disse dataene sortert etter CustomerID-feltet. Hvis vi utelater de tekniske detaljene, kan vi si at indeksen på dette feltet er sekvensen av postnumre i samsvar med hvilke de må vises, det vil si:

1,6,4,2,5,3

Hvis vi ønsker å sortere poster etter adressefeltet, vil rekkefølgen av postnumre være annerledes:

5,4,1,6,2,3

Lagring av indekser krever betydelig mindre plass enn å lagre forskjellig sorterte versjoner av selve tabellen.

Hvis vi trenger å finne data om kunder hvis kunde-ID begynner med tegnene "BO", kan vi bruke indeksen til å finne plasseringen av disse postene (i dette tilfellet 2 og 5 (i indeksen er selvfølgelig tallene for disse postene fortløpende ), og les deretter spesifikt den andre og femte posten, i stedet for å skanne hele tabellen. Dermed reduserer bruken av indekser tiden for datahenting.

Vi har allerede sagt at den fysiske plasseringen av poster kan endres under prosessen med å redigere data av brukere, så vel som som et resultat av manipulasjoner med databasefiler utført av DBMS selv (for eksempel datakomprimering, søppelinnsamling, etc. ). Hvis tilsvarende endringer skjer i indeksen, kalles den støttes og slike indekser brukes i de fleste moderne DBMS-er. Implementeringen av slike indekser fører til det faktum at enhver endring i data i en tabell medfører en endring i indeksene knyttet til den, og dette øker tiden som kreves av DBMS for å utføre slike operasjoner. Derfor, når du bruker slike DBMS-er, bør du bare opprette de indeksene som virkelig er nødvendige, og bli veiledet av hvilke spørringer som vil bli møtt oftest.

Begrensninger og regler

De fleste moderne server-DBMS-er inneholder spesielle objekter kalt begrensninger(begrensninger), eller regler(regler). Disse objektene inneholder informasjon om restriksjoner på mulige feltverdier. For eksempel, ved å bruke et slikt objekt, kan du angi maksimums- eller minimumsverdien for et gitt felt, og etter dette vil DBMS ikke tillate deg å lagre en post i databasen som ikke tilfredsstiller denne betingelsen.

I tillegg til begrensningene knyttet til å angi rekkevidden av dataendringer, er det også referansebegrensninger (for eksempel kan et hoved-detaljforhold mellom kunde- og ordretabellene implementeres som en begrensning som krever at verdien av CustomerId-feltet (utenlandsk nøkkel) i Ordretabellen være lik en av de eksisterende verdiene i CustomerId-feltet i Kunder-tabellen.

Merk at ikke alle DBMS støtter begrensninger. I dette tilfellet kan du enten bruke andre objekter (for eksempel triggere) for å implementere lignende regelfunksjonalitet, eller lagre disse reglene i klientapplikasjoner som fungerer med denne databasen.

Representasjon

Nesten alle relasjonelle DBMS-er støtter visninger. Dette objektet er en virtuell tabell som gir data fra en eller flere virkelige tabeller. I virkeligheten inneholder den ingen data, men beskriver bare kilden deres.

Ofte lages slike objekter for å lagre komplekse spørringer i databaser. Faktisk er view en lagret spørring.

Opprettelsen av visninger i de fleste moderne DBMS-er utføres av spesielle visuelle verktøy som lar deg vise de nødvendige tabellene på skjermen, etablere forbindelser mellom dem, velge viste felt, innføre begrensninger på poster, etc.

Ofte brukes disse objektene for å gi datasikkerhet, for eksempel ved å tillate at data kan sees gjennom dem uten å gi direkte tilgang til tabellene. I tillegg kan noen visningsobjekter returnere forskjellige data avhengig av for eksempel brukernavnet, noe som gjør at han kun kan motta data som interesserer ham.

Triggere og lagrede prosedyrer

Utløsere og lagrede prosedyrer, støttet i de fleste moderne server-DBMS-er, brukes til å lagre kjørbar kode.

En lagret prosedyre er en spesiell type prosedyre som utføres av en databaseserver. Lagrede prosedyrer er skrevet på et prosedyrespråk som avhenger av den spesifikke DBMS. De kan ringe hverandre, lese og endre data i tabeller, og kan kalles fra en klientapplikasjon som kjører databasen.

Lagrede prosedyrer brukes vanligvis til å utføre hyppige oppgaver (for eksempel avstemming av en balanse). De kan ha argumenter, returverdier, feilkoder og noen ganger sett med rader og kolonner (dette datasettet kalles noen ganger et datasett). Den siste typen prosedyrer støttes imidlertid ikke av alle DBMS-er.

Triggere inneholder også kjørbar kode, men i motsetning til prosedyrer kan de ikke kalles fra en klientapplikasjon eller lagret prosedyre. En utløser er alltid knyttet til en spesifikk tabell og utføres når hendelsen den er knyttet til (for eksempel innsetting, sletting eller oppdatering av en post) inntreffer under redigering av den tabellen.

I de fleste DBMS-er som støtter utløsere, kan du definere flere utløsere som kjøres når samme hendelse inntreffer, og bestemme rekkefølgen for utførelse.

Objekter for generering av primærnøkler

Svært ofte genereres primærnøkler av selve DBMS. Dette er mer praktisk enn å generere dem i klientapplikasjonen, siden i flerbrukerarbeid er generering av nøkler ved hjelp av en DBMS den eneste måten å unngå duplisering av nøkler og få deres sekvensielle verdier.

Ulike DBMS-er bruker forskjellige objekter for å generere nøkler. Noen av disse objektene lagrer et heltall og reglene som den neste verdien genereres etter, vanligvis gjort ved å bruke triggere. Slike objekter støttes for eksempel i Oracle (i så fall kalles de sekvenser) og i IB Database (i så fall kalles de generatorer).

Noen DBMS-er støtter spesielle felttyper for primærnøkler. Når du legger til poster, fylles slike felt automatisk med sekvensielle verdier (vanligvis heltall). Når det gjelder Microsoft Access og Microsoft SQL Server, kalles slike felt Identitetsfelt, og i tilfellet Corel Paradox kalles de Autoincrement-felt.

Brukere og roller

Å hindre uautorisert tilgang til data er et alvorlig problem som kan løses på ulike måter. Det enkleste er passordbeskyttelse av enten hele tabellen eller noen av dens felt (denne mekanismen støttes for eksempel i Corel Paradox).

For øyeblikket er en annen metode for å beskytte data mer populær - å lage en liste over brukere med brukernavn og passord. I dette tilfellet eies ethvert databaseobjekt av en spesifikk bruker, og denne brukeren gir tillatelse til andre brukere til å lese eller endre data fra det objektet, eller til å endre selve objektet. Denne metoden brukes i alle servere og noen stasjonære DBMS-er (for eksempel Microsoft Access).

Noen DBMS-er, hovedsakelig servere, støtter ikke bare en liste over brukere, men også roller. En rolle er et sett med privilegier. Hvis en spesifikk bruker mottar en eller flere roller, og med dem alle privilegiene som er definert for denne rollen.

Databasespørringer

Modifisering og valg av data, endring av metadata og noen andre operasjoner utføres ved hjelp av spørringer. De fleste moderne DBMS-er (og noen applikasjonsutviklingsverktøy) inneholder verktøy for å generere slike spørringer.

En måte å manipulere data på kalles "søk etter eksempel" (QBE). QBE er et verktøy for visuelt å koble tabeller og velge hvilke felt som skal vises i søkeresultatet.

I de fleste DBMS-er (med unntak av noen stasjonære), fører visuell konstruksjon av en spørring ved bruk av QBE til generering av spørringstekst ved å bruke et spesielt spørringsspråk SQL (Structured Query Language). Du kan også skrive spørringen direkte i SQL.

Pekere

Ofte er resultatet av en spørring et sett med rader og kolonner (datasett). I motsetning til en relasjonstabell, er radene i et slikt sett ordnet, og rekkefølgen deres bestemmes av den opprinnelige spørringen (og noen ganger av tilstedeværelsen av indekser). Derfor kan vi definere gjeldende rad i et slikt sett og en peker til den, som kalles en markør.

De fleste moderne DBMS-er støtter såkalte toveismarkører, som lar deg navigere gjennom det resulterende datasettet både fremover og bakover. Noen DBMS-er støtter imidlertid bare ensrettede markører, som kun tillater forovernavigering gjennom et datasett.

SQL-språk

Structured Query Language (SQL) er et ikke-prosedyrespråk som brukes til å formulere databasespørringer i de fleste moderne DBMS-er og er for tiden en industristandard.

Språkets ikke-prosessuelle natur gjør at det kan indikere hva som må gjøres med databasen, men det kan ikke beskrive algoritmen for denne prosessen. Alle algoritmer for å behandle SQL-spørringer genereres av selve DBMS og er ikke avhengig av brukeren. SQL-språket består av et sett med setninger som kan deles inn i flere kategorier:

Data Definition Language (DDL) - et datadefinisjonsspråk som lar deg opprette, slette og endre objekter i databaser
Data Manipulation Language (DML) - et databehandlingsspråk som lar deg endre, legge til og slette data i eksisterende databaseobjekter
Data Control Languages (DCL) - språket som brukes til å kontrollere brukerprivilegier
Transaction Control Language (TCL) - et språk for å administrere endringer gjort av grupper av operatører
Cursor Control Language (CCL) - setninger for å definere en markør, forberede SQL-setninger for kjøring og noen andre operasjoner.

Vi vil fortelle deg mer om SQL-språket i en av de følgende artiklene i denne serien.

Brukerdefinerte funksjoner

Noen DBMS-er tillater bruk av brukerdefinerte funksjoner (UDF-brukerdefinerte funksjoner). Disse funksjonene er vanligvis lagret i eksterne biblioteker og må registreres i databasen før de kan brukes i spørringer, utløsere og lagrede prosedyrer.

Fordi brukerdefinerte funksjoner finnes i biblioteker, kan de opprettes ved hjelp av et hvilket som helst utviklingsverktøy som lar deg lage biblioteker for plattformen som DBMS kjører på.

Transaksjoner

En transaksjon er en gruppe operasjoner på data som enten utføres sammen eller kanselleres sammen.

Å foreta en transaksjon betyr at alle operasjoner som er inkludert i transaksjonen er fullført og resultatet av arbeidet deres er lagret i databasen.

Tilbakestilling av en transaksjon betyr at alle allerede fullførte operasjoner som var en del av transaksjonen blir kansellert og alle databaseobjekter som er berørt av disse operasjonene blir returnert til sin opprinnelige tilstand. For å implementere muligheten til å rulle tilbake transaksjoner, støtter mange DBMS-er skriving til loggfiler, som lar deg gjenopprette de opprinnelige dataene under en tilbakestilling.

En transaksjon kan bestå av flere nestede transaksjoner.

Noen DBMS-er støtter to-fase commit, en prosess som lar transaksjoner utføres på flere databaser som tilhører samme DBMS.

For å støtte distribuerte transaksjoner (det vil si transaksjoner over databaser administrert av forskjellige DBMS-er), finnes det spesielle verktøy som kalles transaksjonsovervåkere.

Konklusjon

I denne artikkelen diskuterte vi de grunnleggende konseptene for å bygge relasjonelle DBMS-er, de grunnleggende prinsippene for datadesign, og snakket også om hvilke objekter som kan opprettes i databaser.

I den neste artikkelen vil vi introdusere leserne våre til de mest populære desktop-DBMSene: dBase, Paradox, Access, Visual FoxPro, Works og diskutere hovedfunksjonene deres.

ComputerPress 3"2000

Forelesning 43. Relasjonell datastruktur. Generelle begreper om relasjonell tilnærming til databaseorganisasjon. Grunnleggende konsepter og vilkår

Fordeler og ulemper

Integritetsbegrensninger

Datamanipulasjon

Et omtrentlig sett med operasjoner kan være som følger:

Forelesning 26. Finn en spesifikk post i et sett med poster av samme type (ingeniør Sidorov);

Forelesning 27. Gå fra en stamfar til den første etterkommeren langs en eller annen forbindelse (til den første ansatte ved avdeling 310);

Forelesning 28. Gå til neste etterkommer i en eller annen forbindelse (fra Sidorov til Ivanov);

Forelesning 29. Gå fra en etterkommer til en stamfar ved hjelp av en eller annen forbindelse (finn Sidorovs avdeling);

Forelesning 30. Opprett en ny oppføring;

Forelesning 31. Ødelegg opptaket;

Forelesning 32. Endre posten;

Forelesning 33. Inkludere i kommunikasjon;

Forelesning 34. Utelukk fra tilknytning;

Forelesning 35. Omorganisere til en annen forbindelse, etc.

I prinsippet er vedlikehold ikke nødvendig, men noen ganger krever de referanseintegritet (som i den hierarkiske modellen).

Styrkene ved tidlig DBMS:

Forelesning 36. Utviklet virkemidler for å håndtere data i eksternt minne på lavt nivå;

Forelesning 37. Evnen til å manuelt bygge effektive applikasjonssystemer;

Forelesning 38. Mulighet for å lagre minne ved å skille delobjekter (i nettverkssystemer).

Feil:

Forelesning 39. For vanskelig å bruke;

Forelesning 40. Det kreves faktisk kunnskap om fysisk organisering;

Forelesning 41 Applikasjonssystemer avhenger av denne organisasjonen;

Forelesning 42. Logikken deres er overbelastet med detaljer om organisering av tilgang til databasen.

Relasjonsmodell

På slutten av 60-tallet dukket det opp arbeider der mulighetene for å bruke ulike tabellformede datalogiske datamodeller ble diskutert, d.v.s. evnen til å bruke kjente og naturlige måter å presentere data på. Den mest betydningsfulle av disse var en artikkel av IBM-ansatt Dr. E.F. (Codd E.F., A Relational Model of Data for Large Shared Data Banks. CACM 13: 6, juni 1970), der begrepet "relasjonsmodell" sannsynligvis ble brukt om førstegangsdata".

Som matematiker av opplæring, foreslo E. Codd å bruke apparatet for settteori (union, skjæringspunkt, forskjell, kartesisk produkt) for databehandling. Han viste at enhver representasjon av data reduseres til et sett med todimensjonale tabeller av en spesiell type, kjent i matematikk som holdning– forhold (engelsk).

Den minste enheten av data i relasjonsmodellen er individet atomisk(ukomponerbar) dataverdi for en gitt modell. Så i ett fagområde kan etternavnet, fornavnet og patronymet betraktes som en enkelt betydning, og i et annet - som tre forskjellige betydninger.

De grunnleggende begrepene i relasjonsdatabaser er datatype, domene, attributt, tuppel, primærnøkkel og relasjon.

Grunnleggende begreper om relasjonsdatabaser

Hovedkonseptene i relasjonsdatabaser er:

data-type

primærnøkkel og
holdning.

Til å begynne med, la oss vise betydningen av disse konseptene ved å bruke eksemplet med ANSATTE-forholdet,

Figur 4.1. Begrepshierarki i ANSATTE-databasen

Data-type

Konseptet med en datatype i den relasjonsdatamodellen er helt adekvat til konseptet med en datatype i programmeringsspråk. Vanligvis tillater moderne relasjonsdatabaser lagring av tegn, numeriske data, bitstrenger, spesialiserte numeriske data (som penger), så vel som spesielle tidsdata (dato, klokkeslett, tidsintervall).

Domene

Konseptet med et domene er mer spesifikt for databaser, selv om det har noen analogier med undertyper i noen programmeringsspråk. I sin mest generelle form er et domene definert ved å spesifisere en basedatatype som elementene i domenet tilhører, og et vilkårlig logisk uttrykk brukt på elementet i datatypen. Hvis evalueringen av dette boolske uttrykket returnerer sant, er dataelementet et domeneelement. Den mest korrekte intuitive tolkningen av konseptet med et domene er å forstå domenet som et tillatt potensielt sett med verdier av en gitt type. For eksempel er Names-domenet i vårt eksempel definert på en basistype av tegnstrenger, men verdiene kan bare inkludere strenger som kan representere et navn (spesielt kan slike strenger ikke begynne med et mykt tegn). Det bør også bemerkes den semantiske belastningen til domenekonseptet: data anses bare som sammenlignbare hvis de tilhører samme domene. I vårt eksempel er verdiene til domenene Skip Numbers og Group Numbers av typen heltall, men er ikke sammenlignbare.

Relasjonsskjema, databaseskjema

Et relasjonsskjema er et navngitt sett med par attributtnavn, domenenavn(eller skriv hvis domenekonseptet ikke støttes). Graden eller ariteten til et relasjonsskjema er kraften til dette settet. Graden av ANSATTE-relasjonen er fire, det vil si at den er 4-ær. Hvis alle attributtene til en relasjon er definert på forskjellige domener, er det fornuftig å bruke navnene på de tilsvarende domenene for å navngi attributtene (husk selvfølgelig at dette bare er en praktisk måte å navngi på og ikke eliminerer forskjellen mellom begrepene domene og attributt). Et databaseskjema (i strukturell forstand) er et sett med navngitte relasjonsskjemaer.

Tuppel, forhold

En tuppel som tilsvarer et gitt relasjonsskjema er et sett med par attributtnavn, verdi, som inneholder én forekomst av hvert attributtnavn som tilhører relasjonsskjemaet. Verdien er en gyldig verdi for domenet til attributtet (eller datatypen hvis domenekonseptet ikke støttes). Dermed kan graden eller ariteten til tupelen, dvs. antall elementer i den faller sammen med ariteten til det tilsvarende relasjonsskjemaet. Enkelt sagt er en tuppel en samling av navngitte verdier av en gitt type. En relasjon er et sett med tupler som tilsvarer et enkelt relasjonsskjema. Noen ganger, for å unngå forvirring, sier de skjemarelasjon og instansrelasjon, noen ganger kalles skjemaet til en relasjon relasjonens hode, og relasjonen som et sett med tupler kalles relasjonens kropp. Faktisk er konseptet med et relasjonsskjema nærmest konseptet med en strukturell datatype i programmeringsspråk. Det ville være ganske logisk å la en definere et relasjonsskjema separat, og deretter en eller flere relasjoner med det skjemaet. Dette er imidlertid ikke vanlig praksis i relasjonsdatabaser. Skjemanavnet til en relasjon i slike databaser er alltid det samme som navnet på den tilsvarende instansrelasjonen. I klassiske relasjonsdatabaser, når databaseskjemaet er definert, endres bare instansrelasjonene. Nye tuples kan vises i dem og eksisterende tuples kan slettes eller endres. Imidlertid er det i mange implementeringer også mulig å endre databaseskjemaet: definere nye og endre eksisterende relasjonsskjemaer. Dette kalles vanligvis databaseskjemaevolusjon. Den vanlige hverdagsrepresentasjonen av en relasjon er en tabell, hvis overskrift er skjemaet til relasjonen, og radene er tuplene til instansrelasjonen; i dette tilfellet navngir attributtnavnene kolonnene i den tabellen. Derfor sier de noen ganger tabellkolonne, som betyr en relasjonsattributt. Når vi går videre til å vurdere de praktiske spørsmålene rundt organisering av relasjonsdatabaser og administrasjonsverktøy, vil vi bruke denne dagligdagse terminologien. Denne terminologien følges i de fleste kommersielle relasjons-DBMS-er. En relasjonsdatabase er et sett med relasjoner hvis navn er de samme som navnene på relasjonsskjemaene i databaseskjemaet. Som du kan se, har de grunnleggende strukturelle konseptene til relasjonsdatamodellen (bortsett fra begrepet domene) en veldig enkel intuitiv tolkning, selv om de i teorien om relasjonsdatabaser alle er definert absolutt formelt og presist.

Grunnleggende egenskaper ved relasjoner

La oss nå dvele ved noen viktige egenskaper ved relasjoner som følger av de tidligere gitte definisjonene.

Ingen dupliserte tupler

Egenskapen at relasjoner ikke inneholder dupliserte tupler følger av definisjonen av en relasjon som et sett med tupler. I klassisk settteori består hvert sett per definisjon av forskjellige elementer. Denne egenskapen innebærer at hvert forhold har en såkalt primærnøkkel - et sett med attributter hvis verdier unikt definerer relasjonstuppelen. For hver relasjon har i det minste hele settet med attributtene denne egenskapen. Når man formelt definerer en primærnøkkel, er det imidlertid nødvendig å sikre dens minimalitet, dvs. settet med primærnøkkelattributter bør ikke inkludere attributter som kan forkastes uten å påvirke hovedegenskapen – unik identifisering av tuppelen. Konseptet med en primærnøkkel er ekstremt viktig i forbindelse med begrepet databaseintegritet. Når vi ser fremover, legger vi merke til at mange praktiske implementeringer av RDBMS tillater brudd på unikhetsegenskapen til tuples for mellomrelasjoner generert implisitt ved utføring av spørringer. Slike relasjoner er ikke sett, men multisett, som i noen tilfeller lar en oppnå visse fordeler, men noen ganger fører til alvorlige problemer.

Manglende bestilling av tupler

Egenskapen til fravær av rekkefølge av tuplene til en relasjon er også en konsekvens av definisjonen av en instansrelasjon som et sett med tupler. Fraværet av kravet om å opprettholde orden på settet med tupler av en relasjon gir ekstra fleksibilitet til DBMS ved lagring av databaser i eksternt minne og ved utføring av spørringer mot databasen. Dette motsier ikke det faktum at når du formulerer en databasespørring, for eksempel i SQL, kan du kreve at den resulterende tabellen sorteres i samsvar med verdiene til noen kolonner. Et slikt resultat er generelt sett ikke et forhold, men en ordnet liste over tupler.

Manglende rekkefølge av attributter

Attributtene til relasjoner er ikke ordnet, siden et relasjonsskjema per definisjon er et sett med par attributtnavn, domenenavn. For å referere til en attributtverdi i en relasjonstuppel, brukes alltid attributtnavnet. Denne egenskapen tillater teoretisk for eksempel å modifisere skjemaene til eksisterende relasjoner, ikke bare ved å legge til nye attributter, men også ved å fjerne eksisterende attributter. De fleste eksisterende systemer tillater imidlertid ikke denne muligheten, og selv om rekkefølgen av settet med relasjonsattributter ikke er eksplisitt påkrevd, brukes ofte rekkefølgen av attributtene i den lineære formen av relasjonsskjemadefinisjonen som en implisitt rekkefølge av attributtene. .

Atomitet til attributtverdier

Verdiene til alle attributter er atomære. Dette følger av definisjonen av et domene som et potensielt sett med verdier av en enkel datatype, dvs. Domeneverdier kan ikke inneholde flere verdier (relasjoner). Det er vanlig å si at i relasjonsdatabaser er bare normaliserte relasjoner eller relasjoner representert i første normalform tillatt. Et potensielt eksempel på et ikke-normalisert forhold er vist i fig. 4.2.1.

Figur 4.2.1. AVDELINGER forhold i ikke-normalisert form

Figur 4.2.2. Normalisert holdning ANSATTE

Vi kan si at her har vi en binær relasjon, verdiene til DEPARTMENTS-attributtet er relasjoner. Merk at den opprinnelige ANSATTE-relasjonen er en normalisert versjon av AVDELINGS-relasjonen (se fig. 4.2.2). Normaliserte relasjoner danner grunnlaget for den klassiske relasjonelle tilnærmingen til databaseorganisering. De har noen begrensninger (det er ikke praktisk å presentere all informasjon i form av flate tabeller), men de forenkler datamanipulering betydelig. Tenk for eksempel på to identiske tuppelinnsettingsoperatorer:

Registrer ansatt Kuznetsov (passnummer 3000, lønn 115.000) i avdelingsnummer 320 og registrer medarbeider Kuznetsov (passnummer 3000, lønn 115.000) i avdelingsnummer 310. Hvis ansattinformasjon er representert som ANSATTE-relasjonen, vil begge uttalelsene bli utført identisk (utført tupel i forhold til ANSATTE). Hvis du jobber med den ikke-normaliserte DEPARTMENTS-relasjonen, vil den første operatøren resultere i å legge til en tuppel, og den andre operatøren vil legge til informasjon om Kuznetsov til multippelverdien til DEPARTMENT-attributtet til tuppelen med primærnøkkel 310.

Relasjonsdatamodell

Da vi snakket om de grunnleggende konseptene for relasjonsdatabaser i tidligere avsnitt, stolte vi ikke på noen spesifikk implementering. Disse betraktningene gjaldt på samme måte for ethvert system i konstruksjonen der en relasjonell tilnærming ble brukt. Vi brukte med andre ord begrepene til den såkalte relasjonsdatamodellen. Datamodellen beskriver et visst sett med generiske konsepter og egenskaper som alle spesifikke DBMS-er og databasene de administrerer må ha hvis de er basert på denne modellen. Ved å ha en datamodell kan du sammenligne spesifikke implementeringer ved å bruke ett felles språk. Selv om konseptet med en datamodell er generelt, og vi kan snakke om hierarkisk, nettverk, noe semantisk, etc. datamodeller, bør det bemerkes at dette konseptet ble introdusert i forhold til relasjonssystemer og brukes mest effektivt i denne sammenhengen. Forsøk på direkte å anvende lignende modeller på prerelasjonelle organisasjoner viser at relasjonsmodellen er for stor for dem, og for postrelasjonelle organisasjoner viser den seg å være liten.

generelle egenskaper

Den vanligste tolkningen av den relasjonelle datamodellen ser ut til å være den til Data, som gjengir den (med forskjellige forbedringer) i nesten alle bøkene hans. I følge Date består relasjonsmodellen av tre deler som beskriver ulike aspekter ved den relasjonelle tilnærmingen: den strukturelle delen, manipulasjonsdelen og den helhetlige delen. Den strukturelle delen av modellen sier at den eneste datastrukturen som brukes i relasjonsdatabaser er den normaliserte n-ære relasjonen. Faktisk undersøkte vi i de to foregående delene av denne forelesningen nøyaktig begrepene og egenskapene til den strukturelle komponenten i relasjonsmodellen. Manipulasjonsdelen av modellen bekrefter to grunnleggende mekanismer for å manipulere relasjonsdatabaser - relasjonsalgebra og relasjonskalkulus. Den første mekanismen er hovedsakelig basert på klassisk settteori (med noen forbedringer), og den andre er basert på det klassiske logiske apparatet til førsteordens predikatregning. Deretter skal vi se på disse mekanismene mer detaljert, men foreløpig vil vi bare merke at hovedfunksjonen til manipulasjonsdelen av relasjonsmodellen er å gi et mål på relasjonaliteten til ethvert spesifikt relasjonsdatabasespråk: et språk kalles relasjonelt hvis den ikke har mindre uttrykksevne og kraft enn relasjonsalgebra eller relasjonsregning.

Entitet og referanseintegritet

Til slutt fikser den integrerte delen av relasjonsdatamodellen to grunnleggende integritetskrav som må støttes i enhver relasjonell DBMS. Det første kravet kalles enhetsintegritetskravet. Et objekt eller en enhet av den virkelige verden i relasjonsdatabaser tilsvarer tupler av relasjoner. Spesifikt er kravet at enhver tuppel av enhver relasjon må kunne skilles fra enhver annen tuppel av den relasjonen, dvs. med andre ord, ethvert forhold må ha en primærnøkkel. Som vi så i forrige avsnitt, er dette kravet automatisk oppfylt dersom systemet ikke bryter med de grunnleggende egenskapene til relasjonene. Det andre kravet kalles det referansemessige integritetskravet og er noe mer komplekst. Åpenbart, hvis relasjonene er normalisert, er komplekse enheter av den virkelige verden representert i en relasjonsdatabase i form av flere tupler av flere relasjoner. Tenk deg for eksempel at vi må representere DEPARTMENT-enheten i en relasjonsdatabase med attributtene DTD_NUMBER (avdelingsnummer), DTD_COL (antall ansatte) og DTD_COTR (sett med avdelingsansatte). For hver ansatt må du lagre COTR_NUMBER (ansattnummer), COTR_NAME (ansatts navn) og COTR_SARP (ansattlønn). Som vi snart vil se, med riktig utforming av den tilsvarende databasen, vil to relasjoner vises i den: DEPARTMENTS (DEPARTMENT_NUMBER, DEPARTMENT_COUNTY) (primærnøkkel - DEPARTMENT_NUMBER) og EMPLOYEES (COTR_NUMBER, COTR_NAME, COTR_SARP, COTR_DEPARTMENT_NUM) (primærnøkkel - COTR_NUMBER ). Som du kan se, vises attributtet SOTR_DEPARTMENT_NOM i ANSATTE-relasjonen, ikke fordi avdelingsnummeret er den ansattes egen eiendom, men bare for å kunne gjenopprette hele AVDELINGS-enheten om nødvendig. Verdien av STR_DEPARTMENT_NOM-attributtet i en hvilken som helst tuppel av EMLOYEES-relasjonen må samsvare med verdien av DEPARTMENT_NOM-attributtet i en tuppel av DEPARTMENTS-relasjonen. Et attributt av denne typen kalles en fremmednøkkel, siden dens verdier unikt karakteriserer enhetene representert av tuplene til en annen relasjon (dvs. de spesifiserer verdiene til primærnøkkelen deres). En relasjon der en fremmednøkkel er definert sies å referere til en tilsvarende relasjon der samme attributt er primærnøkkelen. Referensiell integritetskravet, eller fremmednøkkelkravet, er at for hver fremmednøkkelverdi som vises i en referanserelasjon, må det være en tuppel i den refererte relasjonen med samme primærnøkkelverdi, eller fremmednøkkelverdien må være helt usikker (dvs. ikke angi noe). For vårt eksempel betyr dette at hvis et avdelingsnummer er angitt for en ansatt, så må denne avdelingen eksistere. Entitets- og rmå støttes av DBMS. For å opprettholde integriteten til en enhet, er det nok å sikre at det ikke finnes tupler med samme primærnøkkelverdi i noen relasjon. Med referanseintegritet er ting litt mer komplisert. Det er klart at når du oppdaterer et referanseforhold (sett inn nye tupler eller modifisering av en fremmednøkkelverdi i eksisterende tupler), er det nok å sikre at uriktige fremmednøkkelverdier ikke vises. Men hva med å fjerne en tuppel fra en referert relasjon? Det er tre tilnærminger her, som hver støtter referanseintegritet. Den første tilnærmingen er å forby sletting av en referert tuppel (dvs. du må først enten slette de refererende tuplene eller endre deres fremmednøkkelverdier tilsvarende). I den andre tilnærmingen, når en referert tuppel slettes, blir fremmednøkkelverdien i alle refererende tuppel automatisk udefinert. Til slutt, den tredje tilnærmingen (kaskadesletting) er at når en tuppel slettes fra en referert relasjon, slettes alle refererende tupler automatisk fra den refererende relasjonen. I modne relasjonelle DBMS-er er det vanligvis mulig å velge hvordan man opprettholder referanseintegritet for hver enkelt definisjonssituasjon for fremmednøkkel. Selvfølgelig, for å ta en slik beslutning, er det nødvendig å analysere kravene til et spesifikt bruksområde.

Emne 4. Grunnleggende begreper om relasjonsdatabaser.

Databaser og informasjonssystemer.
Databasestyringssystemer.
Relasjonsdatamodell.
Stadier av utforming av relasjonsdatabaser.
Normalisering av relasjoner.
Operasjoner på relasjoner.

4.1. Databaser og informasjonssystemer.

Database (DB) et sett med data organisert i samsvar med visse regler og vedlikeholdt i datamaskinens minne, som karakteriserer den nåværende tilstanden til noenfagområdeog brukes til å tilfredsstille informasjon behov brukere. Den skal gjenspeile gjeldende data om fagområdet, akkumulere, lagre informasjon og gi ulike kategorier brukere rask tilgang til data.

Basert på arten av informasjonen som lagres, er databaser delt inn i fakta og dokumentar. Faktadatabaser inneholder kort informasjon om objektene som beskrives, presentert i et strengt definert format. For eksempel en katalog i et bibliotek. Dokumentardatabaser inneholder informasjon av ulike typer: tekst, grafikk, lyd. For eksempel en database med lovverk på strafferettsområdet.

Selve databasen inneholder kun informasjon.Informasjon Systemer en kombinasjon av en database og et sett med maskinvare- og programvareverktøy for innsamling, lagring, overføring og behandling av informasjon. IP kan også deles inn i fakta og dokumentarisk. Faktainformasjonssystemer utfører funksjonene til å behandle databaser som inneholder faktaspesifikke verdier av data om virkelige objekter. Dokumentariske informasjonssystemer tjener oppgaver som ikke krever et klart svar på spørsmålet som stilles. Formålet med systemet er å gi, som svar på en brukerforespørsel, en liste over dokumenter eller objekter som til en viss grad tilfredsstiller vilkårene formulert i forespørselen.

En spesiell type informasjonssystem er ekspertsystemer som imiterer oppførselen til en spesialist (ekspert) innen et bestemt fagområde. Ekspertsystemet kan generere ny informasjon på dette området forutsi.

Basert på databehandlingsteknologi er databaser delt inn i sentraliserte og distribuerte. En sentralisert database er lagret i minnet til ett datasystem. Hvis dette datasystemet er en komponent i et datanettverk, er distribuert tilgang til en slik database mulig. Denne metoden for å bruke en database brukes ofte i lokale nettverk.

En distribuert database består av flere, noen ganger overlappende eller dupliserende deler, som er lagret i minnet til forskjellige datamaskiner på et datanettverk. Arbeid med en slik database utføres ved hjelp av et distribuert databasestyringssystem (RDBMS).

Basert på metoden for tilgang til data er databaser delt inn i databaser med lokal og databaser med nettverk (fjern) tilgang. Sentraliserte databasesystemer med nettverkstilgang antar to hovedarkitekturer: fil-server, klient-server.

Filserverarkitekturen innebærer å velge en av nettverksmaskinene som en sentral (filserver), som en delt sentralisert database lagres på. De resterende maskinene på nettverket fungerer som arbeidsstasjoner. Databasefiler, basert på brukerforespørsler, overføres over nettverket til arbeidsstasjoner, hvor dataene hovedsakelig behandles. Brukere kan opprette lokale databaser på arbeidsstasjoner og bruke dem uavhengig.

Klient-tjener-arkitekturen gir at i tillegg til å lagre en sentralisert database, må databaseserveren håndtere volumet av databehandling. På forespørsel fra klienten fra arbeidsstasjonen, søker og henter systemet data på serveren. De utpakkede dataene overføres over nettverket fra serveren til klienten.

Når du designer og drifter en database, stilles følgende krav til den:

Tilstrekkelighet av representasjonen av fagområdet (fullstendighet, integritet, konsistens, relevans av data).
Mulighet for interaksjon mellom brukere av ulike kategorier; sikre høy tilgangseffektivitet.
Vennlig grensesnitt.
Sikre hemmelighold og konfidensialitet.
Sikre gjensidig uavhengighet av programmer og data.
Sikre databasens pålitelighet; databeskyttelse mot utilsiktet og forsettlig ødeleggelse; muligheten til å raskt og fullstendig gjenopprette data i tilfelle systemfeil.

Ansvarlig for opprettelse, drift og vedlikehold av databasen er databaseadministratoren. Hans ansvar inkluderer å utføre følgende funksjoner:

Analyse av fagområdet, dets beskrivelse, formulering av integritetsbegrensninger.
Designe databasestrukturen: sammensetning og struktur av databasefiler, forbindelser mellom dem.
Angi integritetsbegrensninger når du beskriver databasestrukturen og databehandlingsprosedyrer.
Databeskyttelse: sikre rekkefølgen av pålogging; bestemme brukertilgangsrettigheter til data; valg og oppretting av databeskyttelsesverktøy for programvare og maskinvare; testing av databeskyttelse; samle inn statistikk om databruk; sikre databasegjenoppretting.
Analyse av brukerforespørsler til databasen.
Arbeide med å forbedre og dynamisk utvikle databasen.

I livssyklusen til en database er et av de viktigste stadiene designstadiet, hvis resultater bestemmer effektiviteten av videre bruk av databasen for å løse problemer i fagområdet. Hovedoppgaven som løses under designprosessen er organisering av data: integrasjon, strukturering og bestemmelse av relasjoner. Måten data er organisert på er bestemt av den logiske modellen. Datamodell Dette er reglene som definerer strukturen til dataene, gyldige implementeringer av dataene og gyldige operasjoner på dataene. Ulike former for å representere forbindelser mellom objekter har bestemt eksistensen av forskjellige logiske datamodeller: hierarkisk, nettverk, relasjonell.

Hierarkiske databaser kan representeres grafisk som et invertert tre som består av objekter på forskjellige 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å lavere nivå. Slike objekter er i et stamfar (objekt nærmere roten) forhold til et barn (objekt på lavere nivå). I dette tilfellet kan et forfedreobjekt ikke ha noen etterkommere eller ha flere av dem, mens et etterkommerobjekt nødvendigvis bare har én stamfar. Gjenstander som har en felles stamfar kalles tvillinger. Et eksempel på en slik database er et hierarkisk fillagringssystem.

En nettverksdatabase er en generalisering av en hierarkisk database ved å la objekter ha mer enn én stamfar. Generelt er det ingen begrensninger på forbindelsene mellom objekter i nettverksmodellen. Et eksempel på en nettverksdatabase er World Wide Web.

Den relasjonsmodellen har fått størst popularitet på grunn av sin enkelhet og matematiske gyldighet. Konseptet med en relasjonsdatamodell er assosiert med utviklingen til E. Codd.

4.2. Databasestyringssystemer.

En av komponentene i IS er databasestyringssystemet (DBMS), et sett med språk- og programvareverktøy ved hjelp av hvilke databasen opprettes og vedlikeholdes under drift.

Hovedfunksjonene til DBMS inkluderer:

Pålitelig lagring av store mengder komplekse data i det eksterne minnet til et datasystem.
Direkte håndtering av data i eksternt minne og RAM-minne og sikre effektiv tilgang til dem i prosessen med å løse et problem.
Vedlikeholde dataintegritet og transaksjonshåndtering.
Sikre databasegjenoppretting etter teknisk feil eller programvarefeil.
Støtte for databeskrivelsesspråk og spørringsspråk.
Sikre datasikkerhet.
Gir parallell tilgang til data for flere brukere.

DBMS krav:

Konsistens av data. Det sikres av kravet om databaseintegritet. DB-integritet innebærer et system med regler som brukes i et DBMS for å opprettholde fullstendig, konsistent og adekvat reflektere emneområdet for informasjon, samt gi beskyttelse mot utilsiktet sletting eller endring av data i relaterte tabeller. Integritet må sikres uavhengig av hvordan dataene legges inn i minnet (online, gjennom import eller ved bruk av spesielle programmer). Transaksjonsbegrepet er knyttet til kravet om dataintegritet. Transaksjon en sekvens av operasjoner på en database, betraktet som en helhet (det vil si alt eller ingenting).
Flerdimensjonal bruk av data. Evnen til å motta informasjon i en enkelt database fra ulike kilder og muligheten til å bruke den av enhver bruker i samsvar med tilgangsrettigheter og funksjoner.
Muligheten til å modifisere systemet muligheten til å utvide det og endre data, samt legge til nye funksjoner uten å skade systemet som helhet.
Pålitelighet og sikkerhet Integriteten til databasen bør ikke kompromitteres på grunn av tekniske feil.
Tilgangshastighet gir rask tilgang til nødvendig informasjon.
Import-eksport av data evne til å utveksle data med annen programvare.

4.3. Relasjonsdatamodell.

Relasjonsdatamodellen er et sett med relasjoner som inneholder all informasjonen som må lagres i databasen.

Holdning ethvert forhold mellom objekter og (eller) deres egenskaper. Det er relasjoner mellom objekter, mellom egenskapene til ett objekt og mellom egenskapene til ulike objekter.

En relasjon er spesifisert med navnet og en liste over attributter for elementene som er knyttet til denne relasjonen:<имя отношения>(<список атрибутов>).

Navnet på relasjonen er valgt på en slik måte at det forklarer betydningen av sammenhengen mellom elementene i relasjonen (relasjonens semantikk).

For å beskrive en egenskap til et objekt eller en relasjon, brukes det enkleste udelelige dataelementet kalt et attributt. Et attributt er preget av et navn, type, verdi og andre egenskaper.

Attributtnavn er et symbol for et attributt i databehandlingsprosesser. Det må være unikt i ett forhold.

Attributtverdien størrelse som karakteriserer en eller annen egenskap ved et objekt og forbindelse. En liste over relasjonsattributtnavn og deres egenskaper kalles et relasjonsskjema.

Egenskapene til attributtene definerer utvalget av akseptable verdier (APV) for hvert argument i relasjonen.

Cortege ett eksempel på forholdet.

Et attributt eller sett med attributter som kan brukes til å identifisere en bestemt tuppel unikt kallesprimærnøkkelen i forholdeteller bare en nøkkel.

Detalj (< номер детали >, <название детали>, <цвет>, <вес>).

Forsørger (< код поставщика >, <фамилия>, <город>).

Levering av deler (< leverandørkode >,< номер детали >, <количество>).

En annen form for å representere relasjoner er tabellform. Hver relasjon tilsvarer en tabell med samme navn. Et attributt i en tabell tilsvarer en kolonne med attributtnavnet, og hver tuppel av en relasjon tilsvarer en tabellrad. En tabellrad kalles også en post, og attributtverdier kalles også et postfelt. Dermed fokuserer relasjonsmodellen på å organisere data i form av todimensjonale tabeller. En relasjonstabell er en todimensjonal matrise og har følgende egenskaper:

hvert tabellelement er ett dataelement;
- alle kolonner i tabellen er homogene, dvs. alle elementer i en kolonne har samme type (numerisk, tegn eller annet) og lengde;
- hver kolonne har et unikt navn;
- det er ingen identiske rader i tabellen;
- Rekkefølgen på rader og kolonner kan være vilkårlig.

Relasjonsmodeller har en rekke fordeler. Disse inkluderer: enkel datapresentasjon takket være en tabellform, minimal dataredundans ved normalisering av relasjoner, uavhengighet av brukerapplikasjoner fra data, tillater inkludering eller sletting av relasjoner, endring av attributtsammensetningen av relasjoner.

Ulemper: lavere datatilgangshastighet sammenlignet med andre modeller, stor mengde eksternt minne, emneområdet kan ikke alltid representeres som et sett med tabeller.

4.4. Stadier av utforming av en relasjonsdatabase.

Utforming av en relasjonsdatabase består av tre stadier: konseptuell, logisk og fysisk design

Hensikt konseptuell designer utvikling av en database basert på en beskrivelse av fagområdet. Beskrivelsen skal inneholde et sett med dokumenter og data som er nødvendig for innlasting i databasen, samt informasjon om objekter og prosesser som karakteriserer fagområdet. Databaseutvikling begynner med å bestemme sammensetningen av dataene som skal lagres i databasen for å sikre oppfyllelse av brukerforespørsler. Deretter blir de analysert og strukturert.

Eksempel.

Relasjonsnavn: Del
Felt		Nøkkeltegn	Feltformat
Feltnavn	Navn	Nøkkeltegn		Type	Lengde	Nøyaktighet
Detaljnummer	Detaljnummer		Numerisk	Hel
Delnavn	Delnavn		Symbolsk
Farge	Del farge		Symbolsk
Vekt	Delvekt, g		Numerisk	Flytende punkt

Logisk designutføres med sikte på å velge et spesifikt DBMS og konvertere den konseptuelle modellen til en logisk. Tabellstrukturer, forbindelser mellom dem utvikles og nøkkeldetaljer bestemmes.

Scene fysisk designsupplerer den logiske modellen med egenskaper som er nødvendige for å bestemme metodene for fysisk lagring og bruk av databasen, mengden minne og typen lagringsenheter. I den fysiske organiseringen av databaser omhandler de ikke presentasjon av data i applikasjonsprogrammer, men med deres plassering på lagringsenheter.

Som et resultat av utforming av en database bør det utvikles en informasjonslogisk datamodell, d.v.s. sammensetningen av relasjonstabeller, deres struktur og logiske sammenhenger bestemmes. Strukturen til en relasjonstabell bestemmes av sammensetningen av feltene, typen og størrelsen på hvert felt, samt tabellnøkkelen.

Driften av databasen begynner med å fylle databasen med reelle data. På dette stadiet kreves databasevedlikehold overvåking av dataintegritet, konsistens, sikkerhetskopiering, arkivering.

De siste årene har post-relasjonelle, flerdimensjonale og objektorienterte datamodeller blitt implementert mye. De tjener til å integrere databaser, kunnskapsbaser og programmeringsspråk.

Structured Query Language SQL er standard spørrespråk for arbeid med relasjonsdatabaser. Den er designet for å utføre operasjoner på tabeller (opprette, slette, endre struktur) og på tabelldata (velge, legge til, slette). SQL inneholder ikke kontrollsetninger, subrutineorganisasjon eller input/output og brukes derfor ikke uavhengig. Det er vanligvis nedsenket i DBMSs innebygde programmeringsspråkmiljø.

4.5. Normalisering av relasjoner.

I en relasjonsdatabase er hvert forhold underlagt følgende begrensning: de må normaliseres.

Normalisering av relasjoneret formelt apparat med restriksjoner på dannelsen av relasjoner, som eliminerer duplisering, sikrer konsistensen til de som er lagret i databasen, og reduserer arbeidskostnadene for å vedlikeholde (inngå, justere) databasen.

Grunnleggeren av relasjonsdatamodellen, E. Codd, identifiserte tre normale former for relasjoner. Dette settet ble senere supplert med Boyce-Codd normalformen, og deretter med den fjerde og femte normalformen.

Første normalform.

Dens essens ligger i kravet om atomitet (udelelighet) av felt og unike verdier på tvers av felt i relasjonsdatamodellen.

Eksempel: LIST

Student			Rekordboknummer	Disiplin	Semester	Karakter
Etternavn	Romnummer	Telefonnummer	Rekordboknummer	Disiplin	Semester	Karakter
Ivanov		29-07-64		Matematikk		Fint
Kuznetsov		29-07-64		Datavitenskap		Flott
Gorbunova		29-08-15		Psykologi		Fint

Denne relasjonen er ikke normalisert fordi den inneholder det komplekse Student-attributtet. For å bringe en holdning til en normalisert form, må du bli kvitt den. Det resulterende forholdet LIST (Etternavn, Romnummer, Telefonnummer

Operasjoner på relasjoner.

I en relasjonsdatabase pålegges en annen begrensning på hvert forhold – det må de være normalisert . Dette betyr at hver attributt må være enkel – inneholde atomære, udelelige verdier.

Normalisering av relasjoneret formelt apparat med restriksjoner på dannelsen av relasjoner (tabeller), som eliminerer duplisering, sikrer konsistensen til de som er lagret i databasen, og reduserer arbeidskostnadene for å vedlikeholde (inngå, justere) databasen.

E. Codd fremhevet trenormale former for forholdog en mekanisme er foreslått som gjør at enhver relasjon kan konverteres til den tredje (mest perfekte) normale formen.

Første normalform

Eksempel: Følgende STUDENT-relasjon er ikke normalisert fordi den inneholder det komplekse attributtet "Sports".

STUDENT

Etternavn

Vi vil

Spesialitet

Sport

Utsikt

Utflod

Ivanov

Savinov

Petrov

Regnskap

FIC

Statistikk

Svømming

Sjakk

Tennis

m.s.

k.m.s.

For å bringe denne holdningen til en normalisert form, må vi kvitte oss med den komplekse egenskapen "Sport". Deretter blir den resulterende relasjonen STUDENT(Etternavn, Sport_type, Kurs, Spesialitet, Sport_kategori) normalisert. Nøkkelen i den er sammensatt, bestående av attributtene "Etternavn" og "Type sport".

Relasjonen kalles normalisert eller redusert tilførste normalform,hvis alle dens attributter er enkle (ytterligere udelelige). Konvertering av en relasjon til første normalform kan føre til en økning i antall attributter (felt) til relasjonen og en endring i nøkkelen.

For eksempel, relasjonen STUDENT( Antall, Etternavn, fornavn, patronym, dato, gruppe) er i første normalform.

Andre normalform

For å vurdere spørsmålet om å redusere relasjoner til andre normalform, er det nødvendig å gi forklaringer på slike begreper som funksjonell avhengighet og fullstendig funksjonell avhengighet.

De beskrivende detaljene til informasjonsobjektet er logisk forbundet med nøkkelen som er felles for dem, denne sammenhengen er av dens naturfunksjonell avhengighet detaljer.

Funksjonell avhengighetdetaljer avhengighet der i en forekomst av et informasjonsobjekt en viss verdi av et nøkkelattributt tilsvarer bare én verdi av et beskrivende attributt.

Denne definisjonen av funksjonell avhengighet lar oss identifisere uavhengige informasjonsobjekter når vi analyserer alle relasjonene mellom detaljene i fagområdet.

Et eksempel på en grafisk representasjon av de funksjonelle avhengighetene til STUDENT-detaljene er vist i fig. 19, hvor nøkkeldetaljene er angitt *.

Ris. 19. Grafisk representasjon av detaljenes funksjonelle avhengighet

Ved en sammensatt nøkkel introduseres konseptetfunksjonelt komplett avhengigheter.

Funksjonell fullstendig avhengighetav ikke-nøkkelattributter er at hvert ikke-nøkkelattributt er funksjonelt avhengig av en nøkkel, men er ikke funksjonelt avhengig av noen del av den sammensatte nøkkelen.

En relasjon vil være i andre normalform hvis den er i første normalform og hvert ikke-nøkkelattributt er funksjonelt fullstendig avhengig av den sammensatte nøkkelen.

Eksempel: Relasjon STUDENT( Antall, Etternavn, Fornavn, Patronym, Dato, Gruppe) er i første og andre normalform samtidig, siden de beskrivende detaljene er unikt definert og funksjonelt avhenger av talltasten. FORHOLD YTELSE( Antall, Fullt navn, Disiplin, vurdering) er i første normalform og har en sammensatt nøkkel Tall + Disiplin. Denne relasjonen er ikke i andre normal form, siden attributtene Etternavn, Fornavn, Patronymic ikke er i full funksjonell avhengighet med den sammensatte nøkkelen til relasjonen.

Tredje normalform

Begrepet tredje normalform er basert på begrepet intransitiv avhengighet.

Transitiv avhengighetobservert når en av de to beskrivende attributtene avhenger av nøkkelen, og den andre beskrivende attributten avhenger av den første beskrivende attributten.

En relasjon vil være i tredje normalform hvis den er i andre normalform og hvert ikke-nøkkelattributt er intransitivt avhengig av primærnøkkelen.

Eksempel: Hvis de beskrivende detaljene til STUDENT-informasjonsobjektet inkluderer etternavnet til gruppelederen (Hovedmannen), som kun bestemmes av gruppenummeret, vil det samme etternavnet til lederen gjentas mange ganger i forskjellige tilfeller av dette informasjonsobjektet. I dette tilfellet er det vanskeligheter med å korrigere etternavnet til lederen i tilfelle utnevnelse av en ny leder, samt uberettiget forbruk av minne for lagring av duplikatinformasjon.

For å eliminere den transitive avhengigheten av beskrivende detaljer, er det nødvendig å "dele" det opprinnelige informasjonsobjektet. Som et resultat av splitting fjernes noen detaljer fra det opprinnelige informasjonsobjektet og inkluderes i andre (eventuelt nyopprettede) informasjonsobjekter.

"Splittingen" av et informasjonsobjekt som inneholder en transitiv avhengighet av beskrivende detaljer er vist i fig. 20. Som det fremgår av fig. 19, presenteres det initiale informasjonsobjektet GROUP STUDENT som et sett med korrekt strukturerte informasjonsobjekter (STUDENT og GROUP), hvis nødvendige sammensetning er identisk med det opprinnelige objektet. Holdning STUDENT(Antall, Etternavn, fornavn, patronym, dato, gruppe) er samtidig i første, andre og tredje normalform.

Ris. 20. Et eksempel på å "spalte" strukturen til et informasjonsobjekt

Normaliseringskrav.Detaljer inngår i ett informasjonsobjekt ihtkrav til den tredje normalformen av relasjonsmodellen.La oss vurdere disse kravene i forhold til et informasjonsobjekt.

Informasjonsobjektet må inneholde en unik nøkkelidentifikator (enkel eller sammensatt).
Alle beskrivende (ikke-nøkkel) detaljer må være gjensidig uavhengige.
Alle detaljer som inngår i den sammensatte nøkkelen må også være gjensidig uavhengige.
Hvert beskrivende attributt må funksjonelt avhenge fullstendig av nøkkelen til informasjonsobjektet. Dette betyr at hver nøkkelverdi kun tilsvarer én beskrivende attributtverdi.
Med en sammensatt nøkkel må de beskrivende detaljene avhenge helt av hele settet med detaljer som utgjør nøkkelen (fullstendig avhengighet av de beskrivende detaljene på noen del av nøkkelen er ikke tillatt).
Hvert beskrivende (ikke-nøkkel) attributt i et informasjonsobjekt kan ikke avhenge av nøkkelen transitivt, det vil si gjennom en annen mellomattributt.
1. Operasjoner på relasjoner

Databehandlingsoperasjoner inkluderer operasjoner på rader (tupler) av tabeller (relasjoner) og operasjoner på relasjoner som behandler data fra flere relasjoner.

Operasjoner utført på relasjonsradnivå er inkludere, slette, oppdatere. Når inkludert, legges en ny rad (tuppel) til i tabellen. For å utføre denne operasjonen må du spesifisere tabellnavnet og angi verdiene til de nye radattributtene (nøkkelverdier er påkrevd). Når den slettes, fjernes en rad fra tabellen. For å utføre denne operasjonen må du spesifisere tabellnavnet og angi verdien til primærnøkkelen til raden som skal slettes. For å slette en gruppe med rader, må du spesifisere en sekundær nøkkelverdi. Ved oppdatering endres attributtverdiene i radene. For å oppdatere må du spesifisere et tabellnavn, en primærnøkkelverdi for å identifisere raden som oppdateres, og spesifisere attributtnavnene og deres nye verdier.

Operasjoner på relasjoner

Den grunnleggende enheten for behandling i relasjonsdatamodelloperasjoner er forholdet, ikke dets individuelle poster. I dette tilfellet er resultatet av behandlingen alltid en ny relasjonstabell, som også kan behandles.

Grad Et forhold kalles antall attributter som er inkludert i det.Power (kardinalnummer)relasjonen kalles antall tupler av relasjonen.

For noen operasjoner må relasjoner ha kompatible skjemaer, dvs. har samme grad og samme type tilsvarende attributter.

Hovedoperasjonene på relasjoner i en relasjonsdatabase er følgende åtte:

tradisjonelle settoperasjoner som union, skjæringspunkt, forskjell, kartesisk produkt, divisjon;
spesielle relasjonsoperasjoner med projeksjon, sammenføyning og seleksjon.

Settet med disse operasjonene danner en komplett algebra av relasjoner.

En forening. Operasjonen utføres på to kompatible relasjoner: R1, R2 . Som et resultat av fagforeningsdriften bygges en ny relasjon R = R1UR2. Forhold har samme sammensetning av attributter og sett med tupler av de opprinnelige relasjonene. Dessuten er duplikater ikke inkludert i denne helheten.

R 1 "Kunder til Bank A"

	By	Etternavn
K11	Moskva	Petrov
K12	Saint Petersburg	Smirnov
K13	Voronezh	Sokolov

R 2 "Bank B-kunder"

	By	Etternavn
K21	Samara	Petrov
	Moskva	Petrov
	Tver	Semenov

R "Kunder"

	By	Etternavn
K11	Moskva	Petrov
K12	Saint Petersburg	Smirnov
K13	Voronezh	Sokolov
K21	Samara	Petrov
K23	Tver	Semenov

Inn i en ny holdning R K22-tuppelen var ikke inkludert, siden den dupliserer K11-tuppelen. Resultatet av foreningen inkluderer alle tupler fra 1. relasjon og de manglende tupler fra 2. relasjon. Forhold R1 og R2 operander og relasjonen R resultat.

Kryss R 1, R 2 . Resulterende relasjon RP = R 1 3 R 2 , inneholder identiske tupler som er i hver av de to originale, dvs. resultatet av skjæringspunktet inneholder bare de tuplene av den første relasjonen som er i den andre. Resultatet av krysset har samme sammensetning av attributter som i de opprinnelige.

Handlingen skjer på de samme operandene. Skjæringspunktet mellom to forhold R 1 "Kunder til Bank A" og R 2 "Kunder av Bank B" gir én relasjon R.P. "Klient", som blir resultatet.

RP "klient"

Skjæringspunktet mellom relasjoner

R klient	By	Etternavn
	Moskva	Petrov	K11 (K22)

Subtraksjon operasjonen utføres på to kompatible relasjoner R1, R2 med et identisk sett med attributter. Som et resultat av subtraksjonsoperasjonen blir en ny relasjon konstruert RV = R 1 R 2 med et identisk sett med attributter, som bare inneholder de tuplene av den første relasjonen R 1 , som ikke gjentas i et annet henseende R 2 . Subtraksjonsforhold R 2 "Kunder til Bank B" fra forholdet R 1 "Kunder til Bank A", siden K11 = K22, gir RV "Client"-relasjon:

RV = R 1 R 2 = (K11, K12, K13) (K21, K22, K23) = (K12, K13)

RV "Client"

Forholdsforskjell

	By	Etternavn
K12	Saint Petersburg	Smirnov
K13	Voronezh	Sokolov

RV holdning "Klient" er resultatet av forskjellen i relasjoner når du utfører handlinger på de samme operandene ( R1 og R2).

Kartesisk produkt utført på to relasjoner R1, R2 med ulike opplegg. Som et resultat av den kartesiske produktdriften dannes en ny relasjon RD = R 1 * R 2 , som inkluderer alle attributtene til de opprinnelige relasjonene. Den resulterende relasjonen består av alle mulige kombinasjoner av tupler av de opprinnelige relasjonene R1, R2 . Antall tupler av et kartesisk produkt er lik produktet av antall tupler i de opprinnelige relasjonene, dvs. graden av den resulterende relasjonen er lik summen av gradene av operandrelasjonene, og makten er produktet av deres krefter.

Eksempel: Kartesisk produkt av to relasjoner R 1 "Student" og R 2 «Objekt» gir en ny holdning R.D. "Eksamensark", som inneholder alle attributtene til det opprinnelige forholdet. Forhold R1 og R2 operander og relasjonen RD-resultat.

R 1 "Student"

	Antall	Etternavn
K11		Ivanov
K12		Petrov
K13		Sidorov

R 2 "Vare"

	KODE	Navn
K21		Matematikk
K22		Datavitenskap

R.D. "Eksamensark"

		Antall	Etternavn	Kode	Navn	Karakter
K11	K21		Ivanov		Matematikk
K11	K22		Petrov		Matematikk
K12	K21		Sidorov		Matematikk
K12	K22		Ivanov		Datavitenskap
K13	K21		Petrov		Datavitenskap
	K22		Sidorov		Datavitenskap

Merk at det er tilrådelig å legge til "Karakter"-attributtet til den resulterende relasjonen for å registrere eksamensresultatene.

Inndeling operasjonen utføres på to relasjoner R 1, R 2, har generelt forskjellige strukturer og noen identiske attributter. Som et resultat av operasjonen dannes en ny relasjon, hvis struktur oppnås ved ekskludering fra settet med relasjonsattributter R 1 , sett med relasjonsattributter R 2 . Divisorrelasjonen må inneholde en delmengde av attributtene til utbytterelasjonen. Den resulterende relasjonen inneholder bare de attributtene til utbyttet som ikke er tilstede i divisoren. Det inkluderer bare de tuplene hvis kartesiske produkter med divisor er inkludert i utbyttet. De resulterende radene må ikke inneholde duplikater.

R 1 «Example_statement» R 2 «Resultater» R «Studenter»

Etternavn	Punkt	Karakter	Punkt	Karakter	Etternavn
Antonov	Datavitenskap		Datavitenskap		Antonov
Antonov	Økonomi		Økonomi		Pavlov
Pavlov	Datavitenskap				Pavlov
Pavlov	Økonomi
Seleznev	Datavitenskap
Seleznev	Økonomi

Projeksjon. Denne operasjonen utføres på én relasjon R for noen attributter. Resulterende relasjon ( RPR ) inkluderer en del av attributtene til den opprinnelige relasjonen R , som projeksjonen utføres på. Det kan inneholde færre tuples fordi etter forkasting i den opprinnelige relasjonen R deler av attributtene (eventuelt unntatt primærnøkkelen), kan det dannes tupler som dupliserer hverandre. Dupliserte tupler er ekskludert fra den resulterende relasjonen. Projeksjon lar domener omorganiseres i en relasjon.

Nedenfor er et eksempel på den opprinnelige relasjonen R "Ansatt" og resultatet av projeksjon ( RPR ) av denne relasjonen til de to attributtene "posisjon" og "avdelingsnummer".

R "Ansatt"

Ansatt	Avdelingsnummer	Jobbtittel
Ivanov		ingeniør
Petrov		ingeniør
Nesterov		ingeniør
Nikitin		laboratorie assistent

RPR-forhold

Avdelingsnummer	Jobbtittel
	ingeniør
	ingeniør
	laboratorie assistent

Sammensatt er oppfylt for en gitt sammenføyningsbetingelse over to logisk relaterte relasjoner. Opprinnelig forhold R1 og R2 har ulike strukturer som inneholder de samme attributtene fremmednøkler (tilkoblingsnøkler). Sammenføyningsoperasjonen danner en ny relasjon, hvis struktur er settet med alle attributter til de opprinnelige relasjonene. De resulterende tuplene dannes ved å sette sammen hver tuppel fra R 1 med de tuplene R 2 , som betingelsen er oppfylt for. I dette tilfellet er tilstanden vanligvis de samme fremmednøkkelverdiene i kilderelasjonene.

Som et eksempel, la oss utføre en sammenføyning på en relasjon R 1 "Grupper" og R 2 "Studenter", som vil være operandene.

R 1 "Grupper" R 2 "Studenter"

Spesialitet	Studentkode	Studentkode	Etternavn	Vi vil
Matematikk			Davydov
Fysikk			Kald
Regnskap			Nekrasov
			Pushkin
			Nevzorov

Du kan velge "Student_Code"-nøkkelen som et attributt for tilkoblingen. Den resulterende relasjonen inkluderer alle attributter til 1. og 2. relasjoner og tupler med samme nøkkelverdi. Resultatet vil være forholdet R «Gruppeledere».

R "Gruppeledere"

Spesialitet	Studentkode	Etternavn	Vi vil
Matematikk		Davydov
Fysikk		Pushkin
Regnskap		Nevzorov

Utvalg operasjonen utføres på en relasjon R. For forholdet R Basert på en gitt betingelse (predikat), velges en undergruppe av tupler. Den resulterende relasjonen har samme struktur, men antallet tupler vil være mindre (eller lik) den opprinnelige.

Eksempel: Fra et forhold R "Klient" for å velge tupler i henhold til betingelsen "Alder> 30 år."

R "Klient"-resultat

Etternavn	Alder	Etternavn	Alder
Panfilov		Panfilov
Korolev		Lomov
Mikhailov
Lomov

Operasjonene omtalt ovenfor er i en eller annen grad implementert i DBMS-verktøy som gir behandling av relasjonstabeller. Disse verktøyene inkluderer spørringsverktøy og andre språkkonstruksjoner.

Utviklingen av den relasjonelle tilnærmingen førte til opprettelsen av relasjonsspråk. For eksempel språk SQL , implementert i de fleste DBMS-er, er mer enn relasjonsmessig komplett, siden den i tillegg til relasjonsalgebra-operasjoner inneholder et komplett sett med operatorer på strenger "inkluder", "slett", "oppdater", og implementerer også aritmetiske operasjoner og sammenligningsoperasjoner.

RELASJONELL DATABASE OG DENS FUNKSJONER. TYPER RELASJONER MELLOM RELASJONSTABELLER

Relasjonsdatabase er en samling av sammenkoblede tabeller, som hver inneholder informasjon om objekter av en bestemt type. En tabellrad inneholder data om ett objekt (for eksempel et produkt, en kunde), og tabellkolonnene beskriver ulike egenskaper ved disse objektene - attributter (for eksempel navn, produktkode, kundeinformasjon). Poster, dvs. tabellrader, har samme struktur - de består av felt som lagrer objektattributter. Hvert felt, dvs. kolonne, beskriver kun én egenskap ved objektet og har en strengt definert datatype. Alle poster har de samme feltene, bare de viser ulike informasjonsegenskaper for objektet.

I en relasjonsdatabase må hver tabell ha en primærnøkkel - et felt eller en kombinasjon av felt som unikt identifiserer hver rad i tabellen. Hvis en nøkkel består av flere felt, kalles den sammensatt. Nøkkelen må være unik og identifisere oppføringen unikt. Ved å bruke nøkkelverdien kan du finne én enkelt post. Nøkler tjener også til å organisere informasjon i databasen.

Relasjonsdatabasetabeller må oppfylle kravene til normalisering av relasjoner. Normalisering av relasjoner er et formelt apparat med restriksjoner på dannelsen av tabeller, som eliminerer duplisering, sikrer konsistens av data som er lagret i databasen, og reduserer arbeidskostnadene for vedlikehold av databasen.

La det lages en studenttabell som inneholder følgende felt: gruppenummer, fullt navn, studentpostnummer, fødselsdato, spesialitetsnavn, fakultetsnavn. En slik organisering av informasjonslagring vil ha en rekke ulemper:

duplisering av informasjon (navnet på spesialiteten og fakultetet gjentas for hver student), derfor vil volumet av databasen øke;
prosedyren for å oppdatere informasjon i tabellen er komplisert på grunn av behovet for å redigere hver tabelloppføringer.

Tabellnormalisering er utformet for å løse disse manglene. Tilgjengelig tre normale former for forhold.

Første normalform. En relasjonstabell reduseres til første normalform hvis og bare hvis ingen av radene inneholder mer enn én verdi i noen av feltene og ingen av nøkkelfeltene er tomme. Så hvis du trenger å få informasjon fra elevtabellen etter studentens navn, bør feltet Fullt navn deles inn i Etternavn, Fornavn og Patronym.

Andre normalform. En relasjonstabell er definert i andre normalform hvis den tilfredsstiller kravene til første normalform og alle dens felt som ikke er inkludert i primærnøkkelen har full funksjonell avhengighet av primærnøkkelen. For å redusere en tabell til andre normalform, er det nødvendig å bestemme den funksjonelle avhengigheten til feltene. En funksjonell avhengighet av felt er en avhengighet der i en forekomst av et informasjonsobjekt en viss verdi av et nøkkelattributt tilsvarer bare én verdi av et beskrivende attributt.

Tredje normalform. En tabell er i tredje normalform hvis den tilfredsstiller kravene til andre normalform om at ingen av dens ikke-nøkkelfelt er funksjonelt avhengig av andre ikke-nøkkelfelt. For eksempel, i elevtabellen (Gruppenr., Fullt navn, Karakterboknr., Fødselsdato, Leder), er tre felt – Karakterboknr., Gruppenr., Leder i transitiv avhengighet. Gruppenummeret avhenger av karakterboknummeret, og rektor avhenger av gruppenummeret. For å eliminere den transitive avhengigheten, er det nødvendig å overføre noen av feltene i Student-tabellen til en annen gruppetabell. Tabellene vil ha følgende form: Student (gruppenummer, fullt navn, karakterboknummer, fødselsdato), Gruppe (gruppenummer, rektor).

Følgende operasjoner er mulige på relasjonstabeller:

Slå sammen tabeller med samme struktur. Resultatet er en felles tabell: først den første, deretter den andre (sammenkjetting).
Kryss av tabeller med samme struktur. Resultat - de postene som er i begge tabellene er valgt.
Trekk fra tabeller med samme struktur. Resultat - de postene er valgt som ikke er i den subtraherte.
Prøve (horisontal delmengde). Resultat – poster som oppfyller visse betingelser velges.
Projeksjon (vertikal delmengde). Resultatet er en relasjon som inneholder noen av feltene fra kildetabellene.
Kartesisk produkt av to tabeller Den resulterende tabellens poster oppnås ved å kombinere hver post i den første tabellen med hver post i den andre tabellen.

Relasjonstabeller kan være relatert til hverandre, derfor kan data hentes fra flere tabeller samtidig. Tabeller er koblet til hverandre for å redusere størrelsen på databasen. Hvert tabellpar er koblet sammen hvis de har identiske kolonner.

Det er følgende typer informasjonslenker:

en til en;
en-til-mange;
mange-til-mange.

En-til-en kommunikasjon antar at ett attributt i den første tabellen tilsvarer bare ett attributt i den andre tabellen og omvendt.

En-til-mange kommunikasjon antar at ett attributt i den første tabellen tilsvarer flere attributter i den andre tabellen.

Mange-til-mange kommunikasjon antar at ett attributt i den første tabellen tilsvarer flere attributter i den andre tabellen og omvendt.

Artikler Av emne:

Hvordan et av de mest lovende mobile OS ble ødelagt Da Microsoft annonserte ytterligere permitteringer i mobildivisjonen sin, sendte Terry Meerson ut et brev til ansatte, der han fortalte om selskapets fremtidsplaner. Det viste seg at dette brevet ikke var det eneste. Microsoft-partnere ble også varslet	Hosts-fil - hvor den ligger, hvordan den skal se ut, hvordan redigerer og lagrer Hvordan åpner du mappen etc. Hva er Hosts-filen for? Hensikten med denne systemfilen er å tildele bestemte nettstedsadresser en spesifikk IP. Alle typer virus og skadelig programvare er veldig glad i denne filen for å skrive inn dataene sine i den eller ganske enkelt erstatte den. Resultat
Den beste versjonen av Windows Hva er bedre Windows 8 eller 8 Detaljert sammenligning av Windows 7 og Windows 8. De viktigste nyvinningene i Windows 8 er beskrevet, samt en detaljert sammenligning av ytelsen med Windows 7 i ulike applikasjoner og spill. Generell informasjon om Windows For en tid siden ble den tilgjengelig	Hvordan slette en unødvendig side i en PDF-fil Sorter og slett sider med PDF-filer online gratis, hvor som helst Hvordan omorganisere sider i en PDF-fil For å redigere en PDF-fil, dra den inn i boksen ovenfor. Du kan også laste ned filen fra enheten din eller fra skyen. Etter å ha lastet ned deg

Populær

2023-12-26 20:16:41	Elleve analoger av siri på Android OS: kort beskrivelse og anbefalinger
2023-12-26 20:16:41	Konseptet med en relasjonsdatabase
2023-12-25 19:44:53	Ny mal for JakoDorgen PRO i form av Invision Power Board (IPB) forum
2023-12-25 19:44:53	Overfør applikasjoner fra enhetsminne til minnekort i Android Overfør applikasjoner til minnekort android 7
2023-12-25 19:44:53	Hvorfor høyttaleren ikke fungerer på iPhone X Høyttaleren fungerer ikke på iPhone 4
2023-12-25 19:44:53	Installere en harddisk i stedet for en DVD-stasjon i en bærbar datamaskin Hastighetsegenskaper for SATA Revision-spesifikasjonsgrensesnittet
2023-12-24 18:55:20	Håndtering av lukking av fane Hvordan samhandle med et vindu etter at det er åpnet
2023-12-24 18:55:20	Hva er et kallenavn for registrering
2023-12-24 18:55:20	Hvordan lage en elektronisk lommebok
2023-12-23 19:59:14	Den billigste Huawei-smarttelefonen er Huawei Y3 (2017)

2023-12-23 19:59:14	Test og gjennomgang: Samsung Gear Fit2 Pro – Fitness Band for Svømmeaktivitetssporing
2023-12-23 19:59:14	Slik oppretter og beskytter du Gmail-innboksen din
2023-12-23 19:59:14	Datamaskinen ser ikke flash-stasjonen: hva er årsaken?
2023-12-23 19:59:14	Gjenoppretting av en flash-stasjon via kontrolleren firmware Kingston flash-stasjon er ikke formatert
2023-12-23 19:59:14	Hvordan etterfylle en laserpatron selv?
2023-12-22 21:10:39	Fjerner mikrofonstøy på stream
2023-12-26 20:16:41	Hvordan et av de mest lovende mobile OS ble ødelagt
2023-12-26 20:16:41	Hosts-fil - hvor den ligger, hvordan den skal se ut, hvordan redigerer og lagrer Hvordan åpner du mappen etc.
2023-12-26 20:16:41	Den beste versjonen av Windows Hva er bedre Windows 8 eller 8
2023-12-26 20:16:41	Hvordan slette en unødvendig side i en PDF-fil
2023-12-26 20:16:41	Elleve analoger av siri på Android OS: kort beskrivelse og anbefalinger
2023-12-26 20:16:41	Konseptet med en relasjonsdatabase