Hver nettsideeier vet at for at nettsiden skal fungere ordentlig, trenger du ikke bare filer med sidekode, men også databaser. Databasestyringssystemer (DBMS) brukes til å samhandle med databaser. I denne artikkelen vil jeg snakke om databaser og DBMS-er, hvilke typer som finnes, og hvordan de skiller seg fra hverandre.
Database
En database er et spesifikt sett med data, som som regel er forbundet med en samlende funksjon eller egenskap (eller flere). Disse dataene er organisert for eksempel alfabetisk. Overfloden av forskjellige data som kan plasseres i en enkelt database fører til mange variasjoner i hva som kan registreres: brukerens personlige data, poster, datoer, bestillinger og så videre. Hvis du for eksempel har en nettbutikk, kan nettsidedatabasen din inneholde prislister, en katalog over varer eller tjenester, rapporter, statistikk og kundeinformasjon.
For det første er dette praktisk fordi informasjon raskt kan legges inn i en database og like raskt hentes om nødvendig. Hvis ved begynnelsen av utviklingen av webutvikling alle nødvendige data måtte skrives i sidekoden, er det nå ikke noe slikt behov - nødvendig informasjon kan bes om fra databasen ved hjelp av skript. Spesielle algoritmer for å lagre og hente informasjon som brukes i databaser gjør det mulig å finne nødvendig informasjon bokstavelig talt på et brøkdel av et sekund – og når du jobber i virtuelt rom Hastigheten til en ressurs er viktigere enn noe annet.
Forholdet mellom informasjon i databasen er også viktig: å endre en linje kan føre til betydelige endringer i andre linjer. Å jobbe med data på denne måten er mye enklere og raskere enn om endringene kun påvirket ett sted i databasen.
Dette betyr imidlertid ikke at hvert nettsted må ha en database - for eksempel hvis du har en visittkortside, og nei ny informasjon Hvis du ikke legger det ut på nettstedet, trenger du ganske enkelt ikke databasen. Mest enkel måte lag en enkel nettside - lag .
Databasestyringssystem
Som du kan gjette ut fra navnet, er et databasestyringssystem (eller DBMS for kort) programvare som brukes til å lage og jobbe med databaser. Hovedfunksjon DBMS er databehandling (som kan være både eksternt og internt tilfeldig tilgangsminne). DBMS støtter nødvendigvis databasespråk, og er også ansvarlig for å kopiere og gjenopprette data etter eventuelle feil.
Når det gjelder klassifisering av databaser, er ulike alternativer mulige.
Du kan for eksempel dele databasene med datamodeller: hierarkisk (har en trestruktur), nettverk (liknende i struktur som de hierarkiske), relasjonell (brukes til administrasjon relasjonsdatabaser data), objektorientert (brukes til objektmodell data) og objektrelasjonell (en slags sammensmelting av relasjonelle og objektorienterte typer databaser).
Eller, hvis inndelingen er basert på hvor er DBMS plassert?, kan de deles inn i lokale - hele DBMS er plassert på en datamaskin, og distribuert - deler av databasestyringssystemet er plassert på flere datamaskiner.
Filserver, klienttjener og innebygd - dette er navnene DBMS-er bærer hvis vi deler dem med måte å få tilgang til databaser på. Filserver DBMS på dette øyeblikket er allerede ansett som foreldet; I utgangspunktet brukes klient-server-systemer (DBMS-er som er plassert på serveren sammen med selve databasen) og innebygde systemer (som ikke krever separat installasjon) systemer.
Informasjonen som er lagret i databaser er ikke begrenset til bare tekst- eller grafikkfiler - moderne versjoner DBMS-er støtter også lyd- og videofilformater.
I denne artikkelen vil jeg fokusere på DBMS-er som brukes til å lagre informasjon fra ulike nettressurser.
Hvorfor trengs disse DBMS-ene? I tillegg til hovedfunksjonen deres - lagring og systematisering av en enorm mengde informasjon - lar de deg raskt behandle kundeforespørsler og gi fersk og relevant informasjon.
Dette gjelder også for endringer du gjør - i stedet for å endre informasjon i hver fil på siden, kan du endre den i databasen, og da vil riktig informasjon umiddelbart vises på hver side.
Relasjonelt DBMS og SQL-språk
Relasjonelle og objektrelasjonelle DBMS-er er blant de vanligste systemene. De er tabeller der hver kolonne (kalt et "felt") er ordnet og har et spesifikt unikt navn. Rekkefølgen av rader (de kalles "poster" eller "poster") bestemmes av rekkefølgen der informasjonen legges inn i tabellen. I dette tilfellet kan behandling av kolonner og rader skje i hvilken som helst rekkefølge. Tabeller med data er sammenkoblet av spesielle relasjoner, på grunn av hvilke data fra forskjellige bord du kan jobbe - for eksempel kombinere dem - med et enkelt søk.
Brukes til å administrere relasjonsdatabaser spesielt språk programmering - SQL. Forkortelsen står for "Structured query language", oversatt til russisk som "strukturert spørrespråk".
Kommandoene som brukes i SQL er delt inn i de som manipulerer data, de som definerer data og de som manipulerer data.
Opplegget for å jobbe med databasen ser slik ut:
MySQL
MySQL er en av de mest populære og utbredte DBMS, som brukes i mange selskaper (for eksempel Facebook, Wikipedia, Twitter, LinkedIn, Alibaba og andre). MySQL er en relasjonell DBMS som er fri programvare: den distribueres under vilkårene i GNU Public License. Vanligvis er dette databasestyringssystemet definert som et godt, raskt og fleksibelt system anbefalt for bruk i små eller mellomstore prosjekter. MySQL har mange forskjellige fordeler. For eksempel støtter den Forskjellige typer tabeller: både de velkjente MyISAM og InnoDB, og de mer eksotiske HEAP og MERGE; i tillegg vokser antallet støttede typer stadig. MySQL utfører alle kommandoer raskt - det er kanskje den raskeste DBMS som finnes akkurat nå. Et ubegrenset antall brukere kan jobbe med dette databasebehandlingssystemet samtidig, og antall rader i tabeller kan være lik 50 millioner.
Siden MySQL, sammenlignet med noen andre DBMS, støtter færre funksjoner, er det mye lettere å jobbe med det enn for eksempel med PostgreSQL, som vil bli diskutert nedenfor.
Den første versjonen av MySQL ble utgitt tilbake i 1995, og siden den gang har det vært flere påfølgende utgivelser, som hver medførte betydelige endringer.
For å jobbe med MySQL brukes ikke bare tekst, men også grafisk modus. Dette er mulig takket være phpMyAdmin-applikasjonen: du trenger ikke engang å kjenne til SQL-kommandoer for å fungere i applikasjonen, og du kan administrere databasen din direkte gjennom nettleseren din.
Generelt kan det bemerkes at MySQL er valget for de som trenger et DBMS for et lite eller mellomstort prosjekt, raskt og enkelt å bruke og uten administrasjonsvansker.
PostgreSQL
Dette fritt distribuerte databasestyringssystemet tilhører den objektrelasjonelle typen DBMS. Som med MySQL er PostgreSQL basert på SQL-språket, men i motsetning til MySQL støtter PostgreSQL SQL-2011-standarden. Dette DBMS har ingen begrensninger på maksimal størrelse på databasen, og heller ikke på maksimale poster eller indekser i tabellen.
Hvis vi snakker om fordelene med PostgreSQL, så er dette selvfølgelig påliteligheten til transaksjoner og replikasjoner, muligheten for arv og enkel utvidbarhet. PostgreSQL støtter ulike utvidelser og programmeringsspråkalternativer som PL/Perl, PL/Python og PL/Java. Det er også mulig å laste C-kompatible moduler.
Mange merker seg at i motsetning til MySQL har denne DBMS god og detaljert dokumentasjon som gir svar på nesten alle spørsmål.
At dette er et større DBMS enn MySQL indikeres også ved at PostgreSQL periodisk sammenlignes med slike kraftig system databehandling som Oracle.
Alt dette lar oss snakke om PostgreSQL som en av de mest avanserte DBMS for øyeblikket.
SQLite
For øyeblikket er dette en av de mest kompakte DBMS; den er også innebygd og relasjonell. SQLite lar deg lagre alle data i én fil, og på grunn av sin lille størrelse, utmerker seg med misunnelsesverdig ytelse. SQLite skiller seg betydelig fra MySQL og PostgreSQL i sin struktur: motoren og grensesnittet til denne DBMS er i samme bibliotek - og det er dette som lar deg utføre alle spørringer veldig raskt. Andre DBMS-er (MySQL, PostgreSQL, Oracle, etc.) bruker klient-server-paradigmet når interaksjon skjer gjennom en nettverksprotokoll.
Ulemper inkluderer mangelen på et brukersystem og muligheten for å øke produktiviteten.
SQLite kan anbefales til bruk i prosjekter hvor du raskt skal kunne migrere en applikasjon og det ikke er behov for skalerbarhet.
Oracle
Dette DBMS er av typen objektrelasjon. Navnet kommer fra navnet på selskapet som utviklet dette systemet, Oracle. Sammen med SQL bruker DBMS en prosedyreutvidelse kalt PL/SQL, samt Java-språket.
Oracle er et system som har vært stabilt i flere tiår, så det velges av store selskaper hvor pålitelighet for gjenoppretting etter feil, en strømlinjeformet sikkerhetskopiering, evnen til å skalere og andre verdifulle funksjoner er viktige. I tillegg gir dette DBMS utmerket sikkerhet og effektiv databeskyttelse.
I motsetning til andre DBMS-er, er kostnadene ved kjøp og bruk av Oracle ganske høye, og dette er ofte en betydelig hindring for bruk i små selskaper. Dette er trolig også grunnen til at Oracle kun ligger på 6. plass i 2016 DBMS-rangeringen i Russland.
MongoDB
Denne DBMS er annerledes ved at den er designet for å lagre hierarkiske strukturer data, og derfor kalles det dokumentorientert (det er en dokumentlagring uten bruk av tabeller eller skjemaer). MongoDB er åpen kildekode.
Ved å bruke en identifikator kan du utføre raske operasjoner på et objekt; Dette DBMS fungerer også godt i komplekse interaksjoner. Først av alt snakker vi om ytelse - i noen tilfeller vil en applikasjon skrevet i MongoDB kjøre raskere enn den samme applikasjonen som bruker SQL, fordi MongoDB tilhører NoSQL DBMS-klassen og bruker i stedet for SQL et objektspørringsspråk, som er mye lettere enn SQL.
Dette språket har imidlertid også sine begrensninger, og derfor bør MongoDB brukes i tilfeller der det ikke er behov for komplekse og ikke-trivielle valg.
I stedet for en konklusjon
Å velge en DBMS er viktig poeng når du oppretter ressursen din. Start fra oppgavene og evnene dine, prøv og eksperimenter for å finne akkurat det alternativet som passer best.
Bygge relasjonsdatabaser
Grunnleggende om bygging av relasjonsdatabaser
Beskrivelse av relasjonsdata
I prosessen med å bygge en relasjonsdatabase må flere problemer løses. Først er det nødvendig å beskrive databasestrukturen for DBMS. For å gjøre dette bruker utvikleren et databeskrivelsesspråk eller en tilsvarende måte å beskrive strukturen på (for eksempel grafisk visning). Da skrives databasen til et eller annet fysisk medium og fylles med data. I denne delen skal vi se på hver av disse oppgavene, men først vil vi introdusere litt relasjonsterminologi.
Terminologioversikt
Som det fremgår av kapittel 5, holdning er en tabell med visse egenskaper.
Poster i en relasjon kan bare ha enkeltverdier; flere verdier er ikke tillatt. Derfor er det bare én verdi i skjæringspunktet mellom en rad og en kolonne.
Alle oppføringer i samme kolonne er av samme type. For eksempel kan én kolonne inneholde kundenes navn og en annen kolonne kan inneholde fødselsdatoene deres. Hver kolonne har unikt navn, og rekkefølgen på kolonnene er uviktig. Relasjonskolonnene er navngitt attributter. Hvert attributt har sitt eget kuppel, som er en fysisk og logisk beskrivelse av settet med gyldige verdier.
3. Det kan ikke være to identiske rader i en relasjon, og rekkefølgen på radene er ikke viktig (fig. 8.1). Relasjonslinjer kalles også i tupler.
Tegning 8.1 er et eksempel, eller en separat forekomst, av en relasjonsstruktur som inneholder informasjon om en klinikkpasient. Generalisert format PASIENT (Navn, FødselDato, Kjønn, Kontonummer, Lege) - dette er strukturen i forholdet; dette er hva folk flest mener med begrepet holdning.(Husk fra kapittel 5, at attributtet som er nøkkelen til relasjonen er understreket.) Hvis vi legger til en begrensning på mulige dataverdier til relasjonsstrukturen, får vi relasjonsskjema(relasjonsskjema). Alle disse begrepene er gitt i tabell. 8.1.
Misforståelser om begrepet "nøkkel"
Begrep nøkkel er ofte en kilde til forvirring siden den har forskjellige betydninger under design- og implementeringsstadiene. I designprosessen er en nøkkel definert som én eller flere kolonner som unikt identifiserer en rad i et forhold. Som vi vet fra kapittelet 5, hver relasjon har minst én nøkkel, siden hver rad er unik; i det ekstreme tilfellet er nøkkelen en kombinasjon av alle kolonnene i relasjonen. Vanligvis består en nøkkel av en eller to kolonner.
På implementeringsstadiet begrepet nøkkel brukt i en annen betydning. I de fleste relasjonelle DBMS-er er en nøkkel en kolonne på grunnlag av hvilken DBMS danner en indeks og andre datastrukturer. Dette gjøres for å sikre rask tilgang til verdiene fra denne kolonnen. Disse nøklene trenger ikke å være unike, og ofte er de ikke det. De er laget kun for å forbedre ytelsen. (Se vedlegg A for informasjon om slike datastrukturer.)
Tenk for eksempel på forholdet BESTILLING (Ordrenummer, Ordredato, Kundenummer, Antall). Fra synspunkt design, nøkkelen til dette forholdet er Ordrenummer, siden utvalget med fet skrift betyr at dette attributtet unikt identifiserer relasjonsstrengen. Fra synspunkt gjennomføring, nøkkelen kan være hvilken som helst av de fire kolonnene i en gitt relasjon. Dette kan for eksempel være attributtet Bestillingsdato. I I dette tilfellet vil DBMS opprette en datastruktur som gir rask tilgang til data fra relasjonen REKKEFØLGE i henhold til bestillingsdatoen. Mest sannsynlig en spesifikk attributtverdi Bestillingsdato vil matche mange linjer. I Slik sett sier det ikke noe om dets unikhet å definere et attributt som en nøkkel.
Noen ganger for å skille mellom to betydninger av et ord nøkkel, begreper som brukes logisk nøkkel(logisk nøkkel) og fysisk nøkkel(fysisk nøkkel). En logisk nøkkel er en unik identifikator, og en fysisk nøkkel er en kolonne der en indeks eller annen datastruktur er opprettet for å forbedre ytelsen.
Indekser
Siden den fysiske nøkkelen vanligvis er en indeks, reserverer noen uttrykket nøkkel verdien av den logiske nøkkelen, og bak begrepet indeks- mening fysisk nøkkel. I Det er nettopp dette vi skal gjøre i denne boken: begrepet nøkkel vi vil bruke betydningen av "logisk nøkkel", og begrepet indeks - i betydningen "fysisk nøkkel".
I Det er tre hensyn som taler for å lage indekser. En av dem er å gi raskere tilgang til rader med verdien av det indekserte attributtet. En annen er å gjøre det enklere å sortere rader etter dette attributtet. For eksempel, V respekt REKKEFØLGE et attributt kan defineres som en nøkkel Bestillingsdato, resulterer i rapporter V hvis bestillinger er sortert etter dato, vil bli generert raskere.
Det tredje formålet med å konstruere indekser er å sikre unikhet. Indekser trenger ikke å være unike, men når en utvikler vil at en kolonne skal være unik, oppretter DBMS en indeks på den kolonnen. I de fleste relasjonelle DBMS-er kan en kolonne eller gruppe med kolonner gjøres unik ved å spesifisere nøkkelordet når du definerer kolonnen i tabellen UNIK.
Implementering av en relasjonsdatabase
Og i denne boken bruker vi relasjonsmodellen for å beskrive strukturen til databasen. Derfor, fra databasedesign kan vi gå direkte til implementeringen. Vi trenger ikke transformere strukturen på noen måte på implementeringsstadiet: alt som må gjøres er å beskrive den eksisterende relasjonsstrukturen for DBMS.
Ved implementering av databaser ved bruk av DBMS-er som ikke er basert på en relasjonsmodell, er situasjonen annerledes. For eksempel, når vi implementerer en database basert på DL/I-modellen, må vi transformere relasjonsstrukturen til en hierarkisk, og deretter beskrive den konverterte strukturen til DBMS.
Beskrivelse av databasestrukturen for DBMS
Det er flere måter en databasestruktur er beskrevet for en DBMS. Disse metodene avhenger av hvilken spesifikk DBMS som brukes. 13 Noen produkter lager en tekstfil som beskriver strukturen til databasen. Språket som brukes til å definere en slik struktur kalles noen ganger datadefinisjonsspråk(datadefinisjonsspråk, DDL). Teksten DDL-filen viser navnene på databasetabellene, angir navnene på kolonnene i disse tabellene og beskriver deres innhold, definerer indekser og beskriver også andre strukturer (begrensninger, sikkerhetstiltak). Oppføring 8.1 beskriver en enkel relasjonsdatabase for et hypotetisk DBMS som bruker et typisk datadefinisjonsspråk. Mer realistiske eksempler på bruk av en standard kalt SQL er gitt i kapittel 12 og 13.
Noen DBMS-er krever ikke at databasestrukturen defineres ved hjelp av DDL in tekstformat. Det vanligste alternativet er grafisk metode spesifisere databasestrukturen. For eksempel, i Access 2002, får utvikleren en grafisk struktur i form av en liste, på de aktuelle stedene som navnene på tabeller og kolonner må angis. Vi så et eksempel på dette i kapittel 2 (se figur 2.2).
Generelt sett, grafiske verktøy databeskrivelser er vanlige i DBMS-er designet for å kjøre på personlige datamaskiner. På servere og stormaskiner brukes både grafiske og tekstbaserte verktøy. For eksempel, i Oracle og SQL Server, kan begge metodene brukes til å definere data. I fig. 8 .2 presentert generell ordning prosessen med å beskrive data for et DBMS.
Med en hvilken som helst metode for å definere en datastruktur, må designeren navngi hver tabell, definere kolonnene for den tabellen og beskrive det fysiske formatet til dataene i hver kolonne (f.eks. TEKST 10). I tillegg, avhengig av egenskapene til DBMS som brukes, kan utvikleren spesifisere restriksjoner som må implementeres av DBMS. Kolonneverdier kan for eksempel defineres som IKKENULL(ikke tom) eller UNIK(unik). Noen produkter lar deg også sette begrensninger på mulige verdier (attributt Del kan ta verdier mindre enn 10 000, og attributtet Farge kan ta en av verdiene ["Rød"/Grønn"/Blå"]). Til slutt kan fremmednøkkelintegritetsbegrensninger introduseres. Her er et eksempel på en slik begrensning: «Attributtverdi Avdelingsnummer i bordet ANSATT må være lik attributtverdien Avdelingsnummer i bordet AVDELING".
I mange DBMS-er kan utvikleren også sette passord og bruke andre kontroller og sikkerhet. Som vil bli vist i kapittel 11, Det er mange forskjellige sikkerhetsstrategier tilgjengelig. I noen strategier er kontrollobjektene datastrukturer (for eksempel er en tabell beskyttet av et passord), i andre - brukere (eieren av passordet X kan lese og oppdatere tabeller T1 Og T2).
Fordeling av plass på fysiske medier
I tillegg til å definere databasestrukturen, må utvikleren allokere plass til databasen på fysiske medier. Igjen, de spesifikke trinnene avhenger av hvilken DBMS som brukes. Når personlig database data, alt du trenger å gjøre er å tildele databasen en katalog på disken og gi den et navn. Etter dette vil DBMS automatisk tildele plass for datalagring.
Andre DBMS-er, spesielt de som er utviklet for servere og stormaskiner, krever mer innsats. For å forbedre ytelsen og kontrollen må du nøye utforme distribusjonen av databaseinformasjon på tvers av disker og kanaler. For eksempel, avhengig av den spesifikke applikasjonsbehandlingen, kan det være bedre å plassere visse tabeller på samme disk. Motsatt kan det være viktig at enkelte tabeller ikke er på samme disk.
Tenk for eksempel på et ordreobjekt som består av tabeller BESTILL, LINE_ORDER Og PRODUKT. La oss anta at når du behandler en ordre, leser applikasjonen en rad fra tabellen REKKEFØLGE, flere rader fra tabellen ORDER_LINE og en rad fra tabellen PRODUKT for hver rad fra tabellen ORDER_LINE. Deretter rader fra tabellen ORDER_LINE, relatert til samme rekkefølge er vanligvis gruppert sammen, og radene i tabellen PRODUKT ikke gruppert på noen måte. Denne situasjonen er illustrert i fig. 8.3.
Tenk deg nå at en organisasjon behandler mange bestillinger parallelt og at den har to disker: en stor og rask, og den andre mindre og tregere. Utvikleren må finne den beste plasseringen for å lagre dataene. Ytelsen kan forbedres hvis tabellen PRODUKT vil bli lagret på en stor disk med rask tilgang, og tabellene ORDER_LINE Og REKKEFØLGE- på en disk med mindre størrelse og hastighet. Eller kanskje ytelsen blir bedre hvis du setter data fra tabeller REKKEFØLGE Og ORDER_LINE for tidligere måneder til en tregere disk, og for gjeldende måned - til en raskere.
Vi kan ikke svare på disse spørsmålene her fordi svaret avhenger av datavolumet, egenskapene til DBMS og operativsystem, størrelsen og hastigheten på disker og rør, og kravene til applikasjonene som bruker databasen. Poenget er at alle disse faktorene må tas i betraktning når man tildeler plass til en fysisk database.
I tillegg til plasseringen og mengden plass for brukerdata, kan designeren også måtte spesifisere om denne plassen skal vokse etter behov, og i så fall med hvor mye. Vanligvis er mengden av en slik økning enten angitt som en fast verdi eller som en prosentandel av den opprinnelige mengden plass.
Når du oppretter en database, må utvikleren tildele filplass for databaselogger. Du vil lære om journalføring i kapitlene 11-13; på dette stadiet trenger du bare å vite at DBMS fører en logg over endringer i databasen, som deretter om nødvendig kan brukes til å gjenopprette databasen. Filplass for logger tildeles under opprettelse av database.
Opprette en databasevedlikeholdsplan
En databasevedlikeholdsplan er en plan med prosedyrer som må utføres regelmessig. Disse prosedyrene inkluderer backup databasen, tilbakestill innholdet i databaseloggen til arkivfiler, se etter brudd på referanseintegritet, optimalisere diskplass for brukerdata og indekser, etc. Vi vil også ta opp disse problemene i kapittel 11, men husk at en databasevedlikeholdsplan bør opprettes under opprettelsesprosessen eller kort tid etter ham.
Fylle databasen med informasjon
Når databasen er beskrevet og plass på fysiske medier er tildelt for lagring, kan du begynne å fylle databasen med informasjon. Måten dette gjøres på avhenger av applikasjonskravene og egenskapene til DBMS. I beste fall er alle data allerede i et datalesbart format, og DBMS har muligheter og verktøy for å forenkle import av data fra magnetiske medier. I verste fall må alle data legges inn manuelt gjennom tastaturet ved hjelp av applikasjonsprogrammer laget av utviklere fra bunnen av. De fleste situasjoner der datakonvertering er nødvendig faller mellom disse to ytterpunktene.
Når dataene er lagt inn, er det nødvendig å kontrollere at de er korrekte. Denne sjekken er kjedelig og arbeidskrevende, men den er veldig viktig. Ofte, spesielt i store databaser, er det fornuftig å skrive spesielle programmer for å sjekke dataene. Fordelene ved å bruke disse programmene er vel verdt tiden og pengene brukt av utviklingsteamet for å lage dem. Slike programmer er engasjert i å telle antall rader i ulike kategorier, beregne sjekksummer, utføre gyldighetskontroller av dataverdier og andre kontrollprosedyrer.
Relasjonell datamanipulasjon
Vi diskuterte utformingen av relasjonsdatabaser og måtene databasestrukturen er beskrevet for DBMS. Så langt, når vi snakker om relasjonsoperasjoner, har vi snakket på en generalisert og intuitiv måte. Dette er greit så lenge vi snakker om et prosjekt, men for å implementere applikasjoner trenger vi et klart og konsistent språk som uttrykker prosesseringslogikken. Slike språk kalles Danske manipulasjonsspråk(datamanipulasjonsspråk, DML).
Til dags dato har fire strategier blitt foreslått for å manipulere relasjonsdata. Den første av strategiene relasjonsalgebra(relasjonsalgebra), definerer operatorer som virker på relasjoner (de ligner på de høyere algebraoperatorene +, -, etc.). Disse operatørene lar deg manipulere relasjoner for å oppnå ønsket resultat. Men relasjonsalgebra er vanskelig å bruke, blant annet fordi den er prosessuell. Dette betyr at ved bruk relasjonsalgebra vi må vite ikke bare Hva det gjør vi, men også Hvordan det blir gjort.
Relasjonsalgebra brukes ikke i kommersielle databasebehandlingssystemer. Selv om ingen kommersielt vellykket databasebehandlingssystem inkluderer relasjonsalgebraverktøy, vil vi diskutere det her fordi det vil hjelpe deg å forstå manipulasjon av relasjonsdata klarere og gi et grunnlag for å lære SQL.
Relasjonsregning(relasjonskalkulus) er den andre strategien for å manipulere relasjonsdata. Relasjonsregning er ikke prosedyremessig; det er et språk som uttrykker hva Hva vi ønsker å gjøre, uten å spesifisere Hvordan oppnå dette. Husk integrasjonsvariabelen i integralregning: denne variabelen tar verdier fra området som integrasjonen skjer over. I relasjonsregning er det en lignende variabel. I tuppelrelasjonell kalkulus er verdiområdet for denne variabelen relasjonstupler, og i domenerelasjonskalkulus domeneverdier. Relasjonsregning er basert på en gren av matematikken som kalles predikatregning.
Med mindre du planlegger å bli relasjonsteoretiker, trenger du sannsynligvis ikke studere relasjonsregning. Den brukes aldri i kommersielle databasesystemer, og studien er ikke nødvendig for våre formål. Derfor vil vi ikke diskutere det i denne boken.
Selv om relasjonskalkulus er vanskelig å forstå og bruke, er dens ikke-prosessuelle karakter en fordel. Derfor begynte DBMS-utviklere å søke etter andre ikke-prosedyrestrategier, noe som førte til fremveksten av den tredje og fjerde kategorien av språk for å manipulere relasjonsdata.
Transformasjonsorienterte språk er en klasse av ikke-prosessuelle språk som transformerer relasjonsinndata til en enkelt relasjonsutgang. Disse språkene har brukervennlige strukturer som lar deg spesifisere handlingene som skal utføres på de oppgitte dataene. SQUARE, SEQUEL og SQL er eksempler på transformasjonsorienterte språk. SQL-språk vil bli studert i detalj av oss i kapittel 9, 12 og 13.
Den fjerde kategorien språk for å manipulere relasjonsdata er grafiske språk. Denne kategorien inkluderer prøveforespørsel(Query-by-Example) og forespørsel fra skjema(Query-by-Form). Produkter som støtter denne kategorien inkluderer Approach (fra Lotus) og Access. Brukeren blir presentert med en grafisk representasjon av en eller flere relasjoner. Visningen kan ha form av et dataregistreringsskjema, et regneark eller en annen struktur. DBMS konverterer representasjonen til den tilsvarende relasjonen og genererer spørringer (mest sannsynlig i SQL) på vegne av brukeren. Brukere starter deretter kjøring av DML-setninger uten at de vet det. Fire kategorier av relasjonsdatamanipulasjonsspråk:
relasjonsalgebra;
relasjonsregning;
transformasjonsorienterte språk (for eksempel SQL);
forespørsel ved hjelp av en prøve, forespørsel fra et skjema.
Datamanipulasjonsspråkgrensesnitt
I denne delen skal vi se på fire typer grensesnitt som manipulerer informasjon i en database.
Manipulere data ved hjelp av skjemaer
De fleste relasjonelle DBMS-er har fasiliteter for å lage skjemaer. Noen skjemaer genereres automatisk når en tabell er definert, andre må opprettes av utvikleren. Hjelp i denne prosessen kan gis av en intelligent assistent, tilstede for eksempel i Access. Skjemaet kan være i form av en tabell (regneark) som viser flere rader i en relasjon samtidig. Det er en annen type form der hver rad i relasjonen er representert separat. I fig. 8.4 og 8.5 viser eksempler på begge typer skjemaer for PASIENT-tabellen i fig. 8.1. De fleste produktene gir en viss fleksibilitet i behandling av skjemaer og rapporter. For eksempel kan rader for behandling velges etter kolonneverdier og kan sorteres. Tabell på fig. 8.4 er sortert etter verdien i feltet Kontonummer.
Mange standardskjemaer inneholder data fra bare ett forhold. Hvis du trenger å hente data fra to eller flere relasjoner, må du som regel lage spesielle skjemaer ved hjelp av DBMS-verktøy. Slike verktøy lar deg lage både flertabells- og flerlinjeskjemaer. Siden bruken av disse verktøyene er svært avhengig av det spesifikke DBMS, vil vi ikke vurdere dem nærmere.
Spørr og oppdater språkgrensesnitt
Den andre typen grensesnitt til databasen er spørre og oppdatere språk(spørre/oppdateringsspråk), eller ganske enkelt spørrespråk(spørringsspråk). (Selv om de fleste av disse språkene lar deg både spørre og oppdatere data, blir de oftest referert til som spørringsspråk.) I dette tilfellet legger brukeren inn kommandoer som spesifiserer hvilke handlinger som må utføres på databasen. DBMS dekrypterer disse kommandoene og utfører de foreskrevne handlingene. Figur 8.6 viser hvilke programmer som er involvert i behandlingen av forespørselen.
Det viktigste av alle spørringsspråk er SQL. For å gi deg en ide om spørringsspråk, vurder følgende SQL-setning som behandler relasjonen PASIENT, vist i fig. 8.1:
VELG navn. Fødselsdato FRA PASIENT
HVOR Lege = "Levy"
Denne operatøren trekker ut fra relasjonen PASIENT alle linjer der attributtet Lege har betydningen " Levy". Attributtverdier Navn Og DatoFødsel fra disse radene plasseres den deretter i en andre tabell.
Lagrede prosedyrer
Over tid har databasebrukere og utviklere oppdaget at visse sekvenser av SQL-kommandoer må utføres regelmessig. Det eneste som endres er verdiene spesifisert i setningen HVOR. Hvis for eksempel betalinger påløper månedlig, utføres de samme SQL-setningene, men med en annen sluttdato. For å ta hensyn til dette behovet, introduserte DBMS-produsenter den såkalte lagrede prosedyrer(lagrede prosedyrer). Denne prosedyren er et sett med SQL-setninger som er lagret i en fil og kan utføres med én kommando. Parametre spesifisert i tilbudet HVOR etc., kan bestå ved innkalling av prosedyren. Et eksempel kan være følgende:
GJØR FAKTURERING LAGRET_PROSEDYRE FOR BILLEDDATO = "9/1/2000"
Denne linjen kjører en lagret prosedyre kalt FAKTURERING med parameterverdi BILLEDATO, lik "9/1/2000".
Etter hvert som utviklerne fikk erfaring, dukket det opp ett problem. SQL ble opprettet som et dataunderspråk, og det ble ikke gjort noe forsøk på å gi det alle elementene til et fullverdig programmeringsspråk. Noen av disse elementene var imidlertid nødvendige for å skrive lagrede prosedyrer, og databaseleverandører opprettet forbedrede versjoner av SQL for å inkludere ytterligere funksjoner. Ett slikt språk, PL/SQL, ble utviklet for Oracle, og et annet, kalt TRANSACT-SQL, ble utviklet for SQL Server. Du vil lære mer om disse språkene i kapittel 12 og 13.
En spesiell type lagret prosedyre - avtrekker(trigger) - DBMS kalles når en spesifisert betingelse er oppfylt. For eksempel, i en applikasjon som behandler bestillinger, vil en utvikler opprette en trigger som kjører når mengden av en vare på et lager er under en spesifisert grense (det vil si at det er på tide å bestille en vare fra en grossistleverandør). Du vil lære mer om lagrede prosedyrer i kapittel 12 og 13.
Applikasjonsprogramgrensesnitt
Den fjerde typen datatilgangsgrensesnitt er tilgang gjennom applikasjonsprogrammer skrevet på programmeringsspråk som COBOL, BASIC, Perl, Pascal og C++. I tillegg er noen applikasjonsprogrammer skrevet på språk som er innebygd i DBMS som brukes. Av disse programmeringsspråkene er dBASE det mest kjente.
Det er to grensesnittstiler mellom applikasjonsprogrammer og DBMS. Den første av dem er preget av det faktum at applikasjonsprogrammer kaller subrutiner fra funksjonsbiblioteket som følger med DBMS. For eksempel, for å lese en rad fra en tabell, kaller et applikasjonsprogram DBMS-lesefunksjonen og sender den parametere som indikerer ønsket tabell, nødvendige kolonner, radvalgskriterier, etc.
I noen tilfeller brukes objektorientert syntaks i stedet for funksjonskall. I tilgangskoden nedenfor er db-objektpekeren satt til den åpne databasen, og objektpekeren rs refererer til tabellrader PASIENT;
sett db = strømdbC)
sett rs = db.OpenRecordsetCPATIENT")
Bruker den siste pekeren du kan få tilgang til egenskapene til den åpne det settet med rekorder og løp metodene hans. For eksempel ved å bruke eiendommenrs. Tillat slettinger du kan bestemme om poster fra et postsett kan slettes PASIENT. Metode Flytt først flytter markøren til den første linjen.
For det andre, mer gammel type grensesnitt brukes noen ganger i DBMS-er beregnet på store datamaskiner og servere. Her definerer DBMS-produsenten et sett med datatilgangskommandoer på høyt nivå. Disse kommandoene, som er relatert til databasebehandling og ikke er en del av noe standardspråk, er innebygd i applikasjonsprogramkoden.
Applikasjonsprogrammet med innebygde kommandoer overføres til den foreløpige kompilatoren som er inkludert i DBMS-pakken. Den oversetter datatilgangssetninger til gyldige funksjonskall og definerer dataområder som skal deles mellom applikasjonsprogrammer og DBMS. Forkompilatoren setter også inn kode i programmet som støtter tilgang til disse dataområdene. Programmet som behandles på denne måten overføres til språkkompilatoren. I fig. 8 .7 viser interaksjonen mellom programmer i denne prosessen.
Introduksjon
Kapittel 1. Grunnleggende om databasen
1.1 Klassifisering av databaser
1.3 Databasebeskrivelsesmodeller
1.4. Grunnleggende om desktop DBMS
1.5. Krav og standarder for databaser
Kapittel 2. Arbeide med databasen Microsoft Access
2.1. Grunnleggende om desktop DBMS Microsoft Access
2.2. Arbeide med en Microsoft Access-database
Konklusjon
Liste over brukt litteratur
Introduksjon
Informasjonsstrømmene som sirkulerer i verden som omgir oss er enorme. I
over tid har de en tendens til å øke. Derfor, i enhver organisasjon, som
store og små, oppstår problemet med en slik ledelsesorganisasjon
data som ville gitt mest effektivt arbeid. Noen
organisasjoner bruker arkivskap til dette, men de fleste foretrekker det
datastyrte metoder - databaser som tillater effektiv lagring,
strukturere og systematisere store datamengder. Og i dag uten baser
data er det umulig å representere arbeidet til de fleste finansielle, industrielle,
handel og andre organisasjoner. Uten databaser ville de rett og slett druknet i
informasjonsskred.
Det er mange gode grunner til å overføre eksisterende informasjon på datagrunnlag. Nå er kostnaden for å lagre informasjon i datafiler billigere enn på papir. Databaser lar deg lagre, strukturere og hente informasjon
på en optimal måte for brukeren. Dette emnet er aktuelt for tiden, fordi bruken av klient/server-teknologier lar deg spare betydelige midler, og viktigst av alt, tid å skaffe nødvendig informasjon, og forenkler også tilgang og vedlikehold, siden de er basert på omfattende databehandling og sentralisert lagring. I tillegg lar datamaskinen deg lagre alle dataformater, tekst, tegninger, håndskrevne data, fotografier, stemmeopptak, etc.
Å bruke slike enorme mengder lagret informasjon, i tillegg til utviklingen
systemenheter, dataoverføringsmedier, minne, nødvendige midler
sikre dialog mellom mennesker og datamaskiner som lar brukeren komme inn
eller ta avgjørelser basert på lagrede data. For å gi disse funksjonene
opprettet spesialiserte midler– databasestyringssystemer (DBMS).
Hensikten med dette arbeidet er å avsløre konseptet med en database og databasestyringssystem, og også å vurdere spesifikt eksempel drift av en stasjonær DBMS.
1.1 Klassifisering av databaser
Databasen er informasjonsmodell fagområde, en samling av innbyrdes relaterte data lagret sammen med så minimal redundans at den kan brukes optimalt for en eller flere applikasjoner. Data (filer) lagres i eksternt minne og brukes som legge inn informasjonå løse problemer.
En DBMS er et program som brukes til å implementere sentralisert ledelse data lagret i databasen, tilgang til den, holde den oppdatert.
Databasestyringssystemer kan klassifiseres i henhold til metoden for å etablere forbindelser mellom data, arten av funksjonene de utfører, anvendelsesomfanget, antall støttede datamodeller, arten av språket som brukes til å kommunisere med databasen, og annet parametere.
DBMS-klassifisering:
· i henhold til funksjonene som utføres, er DBMS delt inn i operasjonelle og informative;
· i henhold til anvendelsesomfanget er DBMS delt inn i universelle og problemorienterte;
· i henhold til kommunikasjonsspråket som brukes, er DBMS delt inn i lukkede som har sine egne uavhengige språk kommunikasjon mellom brukere og databaser, og åpne, der et programmeringsspråk utvidet av datamanipuleringsspråkoperatører brukes til å kommunisere med databasen;
· i henhold til antall støttede nivåer av datamodeller, er DBMS-er delt inn i ett-, to- og trenivåsystemer;
· i henhold til metoden for å etablere forbindelser mellom data, skiller de mellom relasjonelle, hierarkiske og nettverksdatabaser data;
· Basert på måten de organiserer datalagring og utfører behandlingsfunksjoner på, er databaser delt inn i sentraliserte og distribuerte.
Sentraliserte databasesystemer med nettverkstilgang Det er to hovedarkitekturer: fil-server eller klient-server.
Filserverarkitektur. Det innebærer å velge en av nettverksmaskinene som en sentral ( hovedserver filer) hvor en delt, sentralisert database er lagret. Alle andre maskiner fungerer som arbeidsstasjoner. Databasefiler, i samsvar med brukerforespørsler, overføres til arbeidsstasjoner, hvor de hovedsakelig behandles. Med høy intensitet av tilgang til de samme dataene, ytelse informasjon System faller.
Klient-server-arkitektur. Denne modellen for datamaskininteraksjon på et nettverk har faktisk blitt en standard for moderne DBMS-er. Hver av datamaskinene som er koblet til nettverket og som utgjør denne arkitekturen, spiller sin egen rolle: serveren eier og kontrollerer informasjonsressurser systemer, har klienten mulighet til å bruke dem. I tillegg til å lagre den sentraliserte databasen, håndterer databaseserveren det meste av databehandlingen. En forespørsel om data utstedt av en klient (arbeidsstasjon) utløser et søk og henting av data på serveren. De utpakkede dataene transporteres over nettverket fra serveren til klienten. Et spesifikt trekk ved klient-server-arkitekturen er bruken av SQL-spørringsspråket.
Databaseserveren er en DBMS som behandler spørringer mottatt fra alle arbeidsstasjoner parallelt. Vanligvis er klienten og serveren geografisk atskilt fra hverandre, i så fall danner de et distribuert databehandlingssystem.
1.2. DBMS funksjonalitet
Egenskapene til DBMS er:
· produktivitet;
· sikre dataintegritet på databasenivå;
· sikre datasikkerhet;
· evne til å jobbe i flerbrukermiljøer;
· evne til å importere og eksportere data;
· gi tilgang til data ved å bruke SQL-språket;
· evne til å lage spørringer;
· Tilgjengelighet av verktøy for utvikling av applikasjonsprogrammer.
DBMS-ytelsen vurderes:
· be om utførelsestid;
· hastighet på informasjonsinnhenting;
· tidspunkt for import av databaser fra andre formater;
· hastighet på operasjoner (som oppdatering, innsetting, sletting);
· rapporter generasjonstid og andre indikatorer.
· Datasikkerhet oppnås:
· kryptering av applikasjonsprogrammer;
· datakryptering;
· databeskyttelse med et passord;
· begrensning av tilgang til databasen (til en tabell, til en ordbok osv.).
Sikre dataintegritet innebærer tilstedeværelsen av midler for å sikre at informasjonen i databasen alltid forblir korrekt og fullstendig. Dataintegritet må sikres uavhengig av hvordan dataene bringes inn i minnet (interaktivt, via import eller via spesialprogram). For tiden brukte DBMS-er har midler til å sikre dataintegritet og pålitelig sikkerhet.
Databasebehandlingssystemet administrerer data i eksternt minne, gir pålitelig datalagring og støtter passende databasespråk. En viktig funksjon til DBMS er funksjonen til å administrere RAM-buffere. Vanligvis fungerer DBMS med databaser store størrelser, ofte over størrelsen på datamaskinens RAM. Utviklede DBMS-er opprettholder sitt eget sett med RAM-buffere med sin egen disiplin for å erstatte dem.
De mest brukte databasebehandlingssystemene er Microsoft Access og Oracle.
Arbeidsstadiene i DBMS er:
· lage en databasestruktur, dvs. bestemme listen over felt som utgjør hver tabellpost, typene og størrelsene på feltene (numerisk, tekst, logisk, etc.), identifisere nøkkelfelt for å sikre de nødvendige forbindelsene mellom data og tabeller;
· legge inn og redigere data i databasetabeller ved å bruke standardskjemaet presentert som standard i form av en tabell og bruke skjermskjemaer, spesielt brukeropprettet;
· behandling av data i tabeller, basert på spørringer og basert på programmet;
· sende ut informasjon fra en datamaskin ved å bruke rapporter og uten å bruke rapporter.
De navngitte stadiene av arbeidet implementeres ved hjelp av forskjellige kommandoer.
En sentralisert database gir enkel administrasjon, forbedret bruk av data i felten når du utfører eksterne spørringer, mer høy grad samtidig behandling, lavere behandlingskostnader.
En distribuert database innebærer lagring og utførelse av databehandlingsfunksjoner på tvers av flere noder og overføring av data mellom disse nodene etter hvert som spørringene utføres. I en slik database kan ikke bare de ulike tabellene lagres på forskjellige datamaskiner, men også forskjellige fragmenter av samme tabell. Samtidig spiller det ingen rolle for brukeren hvordan datalagringen er organisert med en slik database som om den var sentralisert.
1.3.Modeller for å beskrive databaser
Det er tre typer databasebeskrivelsesmodeller - hierarkisk, nettverk og relasjonell, hovedforskjellen mellom disse er arten av beskrivelsen av relasjoner og interaksjoner mellom objekter og attributter til databasen.
Hierarkisk modell innebærer bruk av trestrukturer som består av et visst antall nivåer for å beskrive databasen. Et "tre" er et hierarki av elementer som kalles noder. Elementer betyr en liste, en samling, et sett med attributter, elementer som beskriver objekter.
En database er en samling av strukturerte og sammenkoblede data knyttet til et spesifikt fagområde.
For opprettelse, lagring, behandling og kollektiv bruk av informasjon, spesielt programvaresystemer, kalt databasestyringssystemer (DBMS).
Hovedfunksjonene til DBMS inkluderer følgende:
· fysisk plassering av data og deres beskrivelser i minnet;
· holde databaser oppdatert;
· mekanismer for å søke etter de forespurte dataene;
· tilgang til data når mange brukere ber om samme data samtidig (applikasjonsprogrammer);
· måter å sikre databeskyttelse mot feil oppdateringer og/eller uautorisert tilgang.
Hovedtrekket til en DBMS er tilstedeværelsen av prosedyrer for å legge inn og lagre ikke bare selve dataene, men også beskrivelser av strukturen.
Nøye databasedesign er den første og mest viktig skritt skape en base. Det unngår kostnadene forbundet med å gjøre korrigeringer i strukturen til de lagrede dataene. Å designe en database begynner med å analysere fagområdet og identifisere kravene til det fra individuelle brukere (ansatte i organisasjonen som databasen opprettes for). På designstadiet identifiseres informasjonsobjekter og deres egenskaper, hvilke typer data som krever regelmessig oppdatering og måter å presentere informasjon på skjerm og i rapporter fastsettes, spørsmål som må besvares jevnlig ved søk etter data formuleres. Dette bidrar til å spesifisere kravene til lagret informasjon. Du kan når som helst endre strukturen på informasjonen som er lagret i databasen ved å justere strukturen til tabeller og følgelig skjemaer og rapporter. Databaseadministratoren (DBA) er ansvarlig for å designe og vedlikeholde databasen.
DBMS bruker følgende modeller og beskrivelser:
infologisk;
· datalogisk;
· fysisk.
Tre-lags arkitektur(infologiske, datalogiske og fysiske nivåer) lar deg sikre uavhengigheten til lagrede data fra programmene som bruker dem.
I første omgang lages en generalisert uformell beskrivelse opprettet base data. Denne beskrivelsen kalles en informasjonsdatamodell og gjøres ved bruk av naturlig språk, flytskjemaer, matematiske formler, tabeller, grafer og andre midler. Informasjonsmodellen reflekterer fagområdet som databasen er utformet for og er helt uavhengig av fysiske parametere datalagringsmiljøer. De viktigste konstruktive elementene i informasjonsmodeller er enheter, forbindelser mellom dem og deres egenskaper (attributter). Informasjonsmodellen bør ikke endres før endringer i den virkelige verden medfører endringer i fagområdet og følgelig endringer i modellen.
Beskrivelsen laget av databaseutviklere ved hjelp av en infologisk datamodell kalles en datalogisk datamodell. Sluttresultatet av datavitenskapelig design er en beskrivelse logisk struktur databaser i DDL – databeskrivelsesspråket til et spesifikt DBMS. Når du oppretter en datalogisk datamodell, sikres en entydig samsvar mellom konstruksjonene til databeskrivelsesspråket og grafiske symboler informasjonsenheter og forbindelser mellom dem.
I hjertet av hver DBMS er konseptet med en datamodell, det vil si en viss abstraksjon av datarepresentasjon. I utgangspunktet var to konkurrerende modeller vellykkede - hierarkisk og nettverk. En hierarkisk database består av et ordnet sett med trær. IBM utviklet og implementerte databeskrivelsesspråket DL/I (Data Language One), som modellerte data i hierarkisk form (representasjon av data i form av trær). Denne modellen ble utviklet i samarbeid med industribedrifter og ble designet for å lagre og vedlikeholde data som er hierarkisk relatert, for eksempel materialanslag og delelister. En typisk representant for et hierarkisk DBMS er IMS (Information Styringssystem) av IBM, den første versjonen av denne dukket opp i 1968.
Figur 8.1 viser et eksempel på et hierarkisk databasediagram. FAKULTETS-posttypen er stamfaren (foreldre- eller kildeposten) til posttypene AVDELING og DEKANTKONTOR, og AVDELINGS- og DEKONTOR-postene er etterkommerne (underordnede eller underordnede poster) til FAKULTET-posten.
Alle kopier bestemt type underordnede poster som refererer til samme forekomst av den opprinnelige posten, kalles tvillinger. Den hierarkiske modellen implementerer forholdet mellom kilde- og underordnede poster i henhold til et en-til-mange-skjema, det vil si en foreldrerekord kan matche et hvilket som helst antall barn. I en hierarkisk database er det en enkelt hierarkisk bane for å få tilgang til enhver post, med start fra roten av treet, dvs. Rekkefølgen for å krysse treet er topp-til-bunn, venstre til høyre. I hovedsak er en hierarkisk modell en rettet graf.
Ris. 8.1. Opplegg hierarkisk modell Database
I IMS-terminologi ble begrepet "segment" brukt i stedet for begrepet "rekord", og begrepet "databasepost" ble forstått som hele treet av segmenter. I 1970 laget CODASYL-gruppen, som utviklet standarder for COBOL-språket, en modell kalt DBTG (Data Base Task Group). DBTG-modellen var klar til å representere både hierarkiske data og nettverksdata. Denne modellen var imidlertid veldig kompleks, så den var ikke særlig vellykket.
En typisk representant for systemer basert på nettverksmodell data er et IDMS (integrert Database ledelse System), utviklet av Cullinet Software, Inc. Nettverkstilnærmingen til dataorganisering er en utvidelse av den hierarkiske tilnærmingen. Som i den hierarkiske modellen fører relasjoner fra overordnet post til underordnet post, men denne gangen støttes det multippel arv. I nettverksmodellen er flere kildeposter tillatt for én barnepost, sammen med muligheten for å ha poster uten kildepost (fig. 8.2). Med andre ord, i en nettverksmodell kan enhver post delta i flere foreldre-barn-relasjoner. Nettverksmodellen er en urettet graf.
Ris. 8.2. Database nettverk modell diagram
De fleste databaser som brukes i dag er basert på relasjonsmodellen. Hovedideen til relasjonsmodellen er å representere en vilkårlig datastruktur i form av todimensjonale tabeller. Den vanligste relasjonsdatabasen for skrivebordet som brukes for tiden er MS Access, et eksempel på dette er omtalt i avsnitt 6.3.3.
Relasjonsmodellen ble først foreslått av E.F. Codd (E.F. Codd) i 1970. Konseptet med en datamodell, introdusert av Codd, ble deretter utviklet av Christopher Date. 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. Data lagres i tabeller. Tabellkolonnene kalles felt, og radene kalles poster. Hvert felt kan bare lagre én type informasjon. Spørringer er utformet for å manipulere data i en database.
Codd definerte reglene for relasjonsmodellen, som kalles "Codds 12 regler." Codd la senere til en "null"-regel.
1. Relasjonell DBMS må kunne administrere databasen fullt ut ved å bruke relasjoner mellom data.
2. Informasjonsregel: All informasjon i en relasjonsdatabase, inkludert tabell- og kolonnenavn, må være strengt definert som tabellverdier.
3. Garantert tilgang: Enhver databaseverdi må garanteres å være tilgjengelig gjennom en kombinasjon av tabellnavn, primærnøkkel og kolonnenavn.
4. Nullverdistøtte: DBMS må kunne fungere med null (tomme) verdier. Nullverdi er en ukjent, uavhengig, ikke-anvendbar verdi, i motsetning til standardverdier og vanlige verdier.
5. En aktiv, operativ relasjonskatalog - en beskrivelse av databasen og dens innhold - må defineres på et logisk nivå gjennom tabeller som spørringer kan brukes på ved hjelp av DML (Data Manipulation Language).
6. Uttømmende delsett av dataspråket: av i det minste, må et av de støttede språkene ha en veldefinert syntaks og være selvstendig. Den må støtte datadefinisjon og manipulering, integritetsregler, autorisasjon og transaksjoner.
7. Vis oppdateringsregel: Alle visninger som er teoretisk oppdaterbare kan oppdateres gjennom systemet.
8. Innsetting, oppdatering og sletting: DBMS støtter ikke bare dataspørring, men også innsetting, oppdatering og sletting.
9. Fysisk uavhengighet data: logikken til applikasjonsprogrammer forblir den samme ved endring fysiske metoder datatilgang og lagringsstrukturer.
10. Logisk datauavhengighet: logikken til applikasjonsprogrammer forblir den samme, innenfor rimelighetens grenser, når tabellstrukturer endres.
11. Integritetsuavhengighet: Databasespråket må kunne definere integritetsbegrensninger. De må være tilgjengelige fra live-katalogen, og det må ikke være noen måte å omgå dem.
12. Distribusjonsuavhengighet: overføring av en database fra en datamaskin til en annen datamaskin bør ikke påvirke forespørslene fra applikasjonsprogrammer. En relasjonell DBMS bør ikke avhenge av behovene til en spesifikk klient.
13. Konsistens av språk på alle nivåer: Et datatilgangsspråk på lavt nivå bør ikke ignorere sikkerhets- og integritetsreglene som støttes av et språk på høyere nivå.
Etter å ha foreslått en relasjonsdatamodell, har E.F. Codd skapte også et verktøy for praktisk arbeid med relasjoner - relasjonsalgebra - et formelt system for å manipulere relasjoner, hvis hovedoperasjoner er projeksjon, forbindelse, skjæring og forening.
Relasjonskalkulus er et annet formelt system som manipulerer relasjoner. Relasjonsregning er basert på førsteordens logikk. Akkurat som relasjonsalgebrauttrykk, er relasjonskalkulusformler definert over relasjonene til relasjonsdatabaser, og resultatet av beregningen er også en relasjon.
Relasjonsalgebra og relasjonsregning har samme uttrykkskraft; det vil si at alle spørringer som kan formuleres ved hjelp av relasjonsalgebra, også kan formuleres ved hjelp av relasjonsregning og omvendt. Dette ble først bevist av E. F. Codd i 1972. Dette beviset er basert på en algoritme som et vilkårlig relasjonskalkulusuttrykk kan reduseres til et semantisk ekvivalent relasjonsalgebrauttrykk. Algoritmen kalles Codd-reduksjonsalgoritmen.
Relasjonsdatabaser har følgende spesifikke funksjoner.
· For hvert felt i en databasetabell er det definert en datatype, så det er ikke mulig å plassere den i ett felt forskjellige poster legge inn ulike typer data.
· DBMS-er lar deg ikke bare legge inn data i tabeller, men også å kontrollere riktigheten av de angitte dataene. Dette betyr ikke bare begrensninger på datatypen, men også kontroll av akseptable verdier, antall tegn som legges inn osv. DBMS vil ikke tillate deg å lagre i en post data som ikke oppfyller de angitte reglene.
· Databasetabeller kan inneholde hundretusenvis av poster, og DBMS gir praktiske måter å trekke ut relevant informasjon fra disse mange postene.
· Alle data lagres, uavhengig av struktur og innhold, i én fil, og tilgang til disse dataene utføres side for side, uten å overskride begrensningene til dataressurser.
· Du kan etablere relasjoner mellom tabeller og deretter bruke spørringer til å dele data fra forskjellige tabeller. Dataene innhentet som et resultat av forespørselen presenteres også i form av en tabell.
· En utvalgsspørring kan brukes på én eller flere tabeller samtidig. Dataene i utvalget er dynamiske, dvs. relansering forespørsel om endrede data, endres utvalget.
· Takket være etableringen av relasjoner mellom individuelle tabeller, er det mulig å unngå unødvendig duplisering av data, spare dataminne og også øke hastigheten på informasjonsbehandlingen.
· De fleste databaser kan støtte samtidig arbeid med en database på flere brukere, mens alle brukere garantert jobber med oppdaterte data.
· Sammenlignet med andre applikasjonspakker har databaser et utviklet system for beskyttelse mot uautorisert tilgang, som gir, i tillegg til passordbeskyttelse fil, muligheten for hver bruker eller gruppe av brukere til å se og endre bare de objektene som brukere har tilgangsrettigheter til.
Når du designer en relasjonsdatabase, blir det lagt stor vekt på prosessen med tabellnormalisering. Formålet med normalisering er å lage en databasedesign hvor redundans av informasjon vil bli eliminert, dvs. hver informasjonsbit vil bli lagret på bare ett sted. Hovedformålet med normalisering er å eliminere mulige inkonsekvenser i lagrede data og spare minne. Å neglisjere normalisering gjør databasestrukturen forvirrende og selve databasen upålitelig.
Teorien om normalisering er basert på tilstedeværelsen av et eller annet forhold mellom feltene i tabellen. To typer slike avhengigheter er definert: funksjonelle og flerverdier.
Felt B i en tabell avhenger funksjonelt av felt A i samme tabell hvis og bare hvis på et gitt tidspunkt for hver av forskjellige betydninger felt A, det er nødvendigvis bare én av de forskjellige verdiene til felt B. Merk at det her antas at felt A og B kan være sammensatte.
Felt B er fullt funksjonell avhengighet fra et sammensatt felt A hvis det funksjonelt avhenger av A og ikke funksjonelt avhenger av noen delmengde av feltet A.
Felt A definerer felt B i samme tabell med flere verdier hvis det for hver verdi av felt A er et visst sett med tilsvarende verdier B.
Normaliseringsprosessen er en sekvensiell transformasjon av kildedatabasen til en normalisert database ved gradvis å redusere tabeller til normale former (NF). Dessuten inkluderer hver påfølgende NF nødvendigvis den forrige, som lar deg bryte prosessen i stadier og utføre den én gang, uten å gå tilbake til de forrige stadiene. Totalt inn relasjonell teori Det er 6 normalformer: første normalform (1NF), andre normalform (2NF), tredje normalform (3NF), Boyce-Codd normalform (BCNF), fjerde normalform (4NF) og femte normalform (5NF).
I hovedsak er en tabell i 2NF hvis den er i 1NF og også tilfredsstiller noen tilleggsbetingelser. En tabell er i 3NF hvis den er i 2NF og i tillegg tilfredsstiller andre tilleggsbetingelser osv.
En tabell er i første normalform (1NF) hvis og bare hvis ingen av radene inneholder mer enn én verdi i noen av feltene og ingen av nøkkelfeltene er tomme.
En tabell er i andre normalform (2NF) hvis den tilfredsstiller definisjonen av 1NF og alle dens felt som ikke er en del av primærnøkkelen har et fullstendig funksjonelt forhold til primærnøkkelen.
En tabell er i tredje normal form (3NF) hvis den tilfredsstiller definisjonen av 2NF og ingen av dens nonkey-felt er funksjonelt avhengig av noe annet nonkey-felt.
Codd og Boyce rettferdiggjorde og foreslo en strengere definisjon for 3NF, som tar hensyn til at en tabell kan ha flere nøkler. En tabell er i Boyce-Codd normal form (BCNF) hvis og bare hvis en funksjonell avhengighet mellom feltene reduseres til en fullstendig funksjonell avhengighet av en kandidatnøkkel.
Følgende normale former (4NF og 5NF) tar ikke bare hensyn til funksjonelle, men også multiverdiavhengige avhengigheter mellom tabellfelt.
For tiden tilbyr nesten hver DBMS-produsent sitt eget programvareprodukt datastyrt design. Disse er Oracle Designer (Oracle), Power Designer (Sybase) og andre. Demo versjoner Disse programvareproduktene kan lastes ned fra de tilsvarende nettstedene (www.oracle.com, www.sybase.com). I tillegg presenteres løsninger fra bedrifter som ikke produserer DBMS for datastøttet design. De vanligste er programvareprodukter AllFusion – AllFusion ERwin data Modeler og AllFusion Process Modeler (tidligere BPwin) (se www.interface.ru).
Relasjonsspråk gir standardoperasjoner for behandling av relasjonstabeller, lar deg formulere logiske forhold som brukes i utvalgsoperasjoner, og sjekke integriteten (konsistensen) til data fra sammenhengende tabeller. De opererer med data som sett, og bruker de grunnleggende operasjonene til settteori på dem. Inngangen til en relasjonsoperator er et sett med poster av én eller flere relasjonstabeller, og utdataene er et sett med poster av en ny relasjonstabell. Relasjonelle språk har forskjellige nivåer av prosedyre - innholdet og sekvensen av overgangen fra inngangsdata til utdata.
Følgende typer relasjonelle algebraspråk skilles:
· dBASe-lignende språk er nær strukturerte programmeringsspråk. Disse språkene gir opprettelsen av et brukergrensesnitt og typiske databehandlingsoperasjoner;
· grafiske relasjonsspråk fokusert på sluttbrukere;
· SQL-lignende spørringsspråk implementert i de fleste flerbruker- og distribuerte systemer database ledelse.
dBASe-lignende språk bruker databaser dBASe, Paradox, FoxPro, Clipper, Rbase, etc.
En typisk representant for et grafisk relasjonsspråk er QBE-språket (Query By Example), implementert i et regnearkmiljø, i forskjellige databaser, for eksempel i MS Access, i pakken Microsoft Query. Dette språket tilhører datamanipuleringsspråkene og har de enkleste syntaktiske strukturene som lett kan mestres av brukere som ikke er programmerer.
SQL (Structured Query Language) brukes når man arbeider med relasjonsdatabaser i moderne DBMS-er (ORACLE, dBASE IY, dBASE Y, Paradox, Access, etc.). Syntaksen til SQL-språkversjoner kan variere for individuelle DBMS-er.
SQL har blitt standard spørringsspråk for arbeid med fil-server og klient-server relasjonsdatabaser og for administrasjon av distribuerte databaser. Det er relasjonelt full tunge, designet for å jobbe med databaser, lage spørringer for å hente data, utføre beregninger og sikre databaseintegritet.
Database er en samling av data organisert i samsvar med visse regler og vedlikeholdt i dataminnet, som karakteriserer den nåværende tilstanden til et bestemt fagområde og brukes til å tilfredsstille informasjonsbehov brukere.
En database er en samling av data lagret i samsvar med et dataskjema, som manipuleres i samsvar med reglene for datamodelleringsverktøy.
En database er en samling av sammenhengende data som er lagret sammen i en eller flere datafiler.
Det er mange andre definisjoner som gjenspeiler den subjektive meningen til visse forfattere om hva dette begrepet betyr i deres forståelse, men det er ingen generelt akseptert enkeltformulering. De mest brukte kjennetegnene er: Databasen lagres og behandles i datasystem. Altså er informasjonslagring utenfor datamaskinen (arkiver, biblioteker, kartoteker osv.) ikke databaser.
Dataene i databasen er logisk strukturert (systematisert) for å sikre muligheten til effektivt å søke og behandle dem i et datasystem.
Strukturering innebærer eksplisitt fremheving komponenter(elementer), forbindelser mellom dem, samt typing av elementer og forbindelser, der visse semantikk og tillatte operasjoner er korrelert med typen element (relasjon).
Av de oppførte egenskapene er det kun den første som er streng, mens de andre åpner for ulike tolkninger og ulike grader av vurdering. Det er kun mulig å fastslå en viss grad av samsvar med kravene til databasen.
Mange eksperter påpeker en vanlig feil, som er feil bruk begrepet database i stedet for begrepet databasestyringssystem. Disse begrepene må derfor skilles fra hverandre.
Databaser er nødvendige for lagring og filtrering av informasjon, for behandling og utveksling av informasjon. Generelt er bruksområdet ganske bredt. Over hele verden bruker folk databaser, fra den enkle amatørbrukeren til verdens største selskaper.
En database er et depot for store mengder systematiserte data som du kan utføre visse handlinger med. Handlinger betyr å legge til, slette, endre, kopiere, arrangere osv.
Alle data i en database kan representeres som poster eller objekter.
Til vellykket arbeid Med en database trenger du noen programvareverktøy som du kan lage og administrere databasen med. Til dette formålet finnes det Database Management Systems (DBMS).
DBMS er et sett med språk og programvare, som sikrer opprettelse, bruk og vedlikehold av databasen.
Det finnes to typer DBMS: lokalt og nettverk.
Local er DBMS-er som kjører på én datamaskin. Disse inkluderer dBase, FoxPro, Microsoft Access, Paradox, etc.
Nettverks-DBMS-er er DBMS-er som lar flere datamaskiner bruke samme database ved hjelp av klient-server-teknologi. Eksempler på slike DBMS er InterBase, Oracle, Microsoft SQL Server osv. Siden vi ordner opp generelle begreper, så skal jeg fortelle deg litt om forholdet mellom dataene.
Det er 4 typer datarelasjoner:
1) En til en
2) En til mange
3) Mange til en
4) Mange til mange
En en-til-en-relasjon betyr at hver post for ett databaseobjekt vil peke til en enkelt post for et annet objekt.
En-til-mange betyr at én post av et databaseobjekt vil tilsvare flere poster av andre objekter.
Mange til én betyr at flere poster av databaseobjekter vil tilsvare en post for et annet objekt.
Mange-til-mange etableres mellom to typer databaseobjekter.
Kjennetegn ved databaser
En database er en dataimplementert informasjonsstruktur (modell) som gjenspeiler tilstanden til objekter og deres relasjoner.
Det skal bemerkes at denne definisjonen ikke er den eneste mulige. Når det gjelder definisjoner, ligner informatikk oftest ikke matematikk med sin fullstendige entydighet. Hvis vi nærmer oss konseptet "database" fra en ren brukerpunkt synspunkt, så oppstår en annen definisjon: en database er en samling av lagrede driftsdata for en bestemt virksomhet. Alt er et spørsmål om hvilket aspekt som dominerer vurderingen; i dette kapittelet er den første definisjonen mer passende.
Erfaring med bruk av databaser gjør at vi kan fremheve generelt sett deres ytelsesegenskaper:
* fullstendighet - jo mer fullstendig databasen er, jo mer sannsynlig er det at den inneholder nødvendig informasjon(det skal imidlertid ikke være overflødig informasjon);
* riktig organisering- jo bedre databasen er strukturert, jo lettere er det å finne nødvendig informasjon i den;
* relevans - enhver database kan være nøyaktig og fullstendig hvis den oppdateres kontinuerlig, dvs. det er nødvendig at databasen til enhver tid samsvarer fullstendig med tilstanden til objektet den viser;
* brukervennlighet - databasen skal være enkel og lett å bruke og ha utviklet metoder for å få tilgang til alle deler av informasjonen.
I henhold til mulighetene for å organisere relasjonelle, hierarkiske og nettverksinformasjonsstrukturer finnes det lignende typer databaser.
Hovedtyper av databaser
1) Hierarkisk
2) Nettverk
3) Relasjonell
Hierarkiske databaser
Hierarkiske databaser ble brukt på begynnelsen av 60-tallet. De er bygget i form av et vanlig tre. Data er delt inn i 2 kategorier: master og slave. Dermed er en type objekt den viktigste, og resten, som ligger på lavere nivåer i hierarkiet, er underordnede databaser organisert i henhold til dette prinsippet, som er praktiske å bruke i tilfeller der informasjon er organisert deretter.
Nettverksdatabaser
Nettverksdatabaser begynte å bli brukt nesten samtidig med hierarkiske. I disse databasene kan ethvert objekt enten være en master eller en slave.
Det er ganske vanskelig å implementere datarepresentasjon i denne formen i bruk, så denne typen ble også forlatt.
Relasjonsdatabaser
Det er relasjonsdatabaser som brukes i Hverdagen. (fra den engelske relasjonen - forhold). Denne typen database består av flere sammenkoblede rektangulære tabeller. der det er felt, nøkler, poster, attributter, etc., etc.
