Relasjonell databasestruktur.

Databasetyper.

Hovedtrekkene til DBMS.

Konseptet med en database, DBMS.

Plan

VILKÅR: database, databasestyringssystem (DBMS),

relasjons-DB, DB-post, DB-felt, DB-nøkkelfelt, DB-tabell, DB-spørring, DB-skjema, DB-rapport, DB-makro, DB-modul.

Et av hovedområdene for databruk i det moderne informasjonssamfunnet er lagring og behandling av store mengder informasjon.

Database (DB ) er en systematisert lagring av informasjon om et bestemt fagområde, som ulike brukere kan ha tilgang til for å løse sine problemer.

Videre, ved å bruke eksempelet på et av de vanligste databasebehandlingssystemene - Microsoft Access er en del av den populære Microsoft Office-pakken - vi vil bli kjent med de grunnleggende datatypene, hvordan man lager databaser og hvordan man jobber med databaser.

Database- en organisert innsamling av data beregnet for langtidslagring i eksternt datamaskinminne og permanent bruk. For lagring av databasen kan én datamaskin brukes, samt mange sammenkoblede datamaskiner.

Hvis ulike deler av en database er lagret på mange datamaskiner koblet til et nettverk, kalles en slik database distribuert database.

Databasestyringssystem(DBMS ) Er programvare som lar deg opprette en database, oppdatere informasjonen som er lagret i den og gi den praktisk tilgang til den for visning og søking.

For tiden er de mest utbredte DBMS Microsoft Access, FoxPro, dBase... DBMS er delt med måte å organisere på databaser på nettverksbasert, hierarkisk og relasjonell DBMS.

Hovedtrekk ved DBMS:

ü Oppdatering, påfyll og utvidelse av databasen.

ü Høy pålitelighet av informasjonslagring.

ü Visning av fullstendig og pålitelig informasjon på forespørsler.

ü Midler for informasjonsbeskyttelse i databasen.

DB-er er saklig og dokumentarisk.

Faktadatabasene inneholder kort informasjon om de beskrevne objektene, presentert i et strengt definert format. Bibliotekets database lagrer bibliografisk informasjon om hver bok: utgivelsesår, forfatter, tittel osv. vil for eksempel inkludere lovtekster; Moderne musikkdatabase - tester og noter av sanger, bakgrunnsinformasjon om komponister, poeter, utøvere, lydopptak og videoklipp. Dokumentardatabasen inneholder derfor omfattende informasjon av ulike typer: tekst, lyd, multimedia.

For lagring av databasen kan én datamaskin brukes, samt mange sammenkoblede datamaskiner.

Hvis ulike deler av en database er lagret på mange datamaskiner koblet til et nettverk, kalles en slik database distribuert database.

Kjent tre hovedtyper organisere data i DB og forbindelser mellom dem:

· hierarkisk (trelignende),

· Nettverk,

· relasjonelle .

I en hierarkisk database det er en rekkefølge av elementer i posten, ett element anses som det viktigste, resten er underordnet. Å søke etter et hvilket som helst dataelement i et slikt system kan være tidkrevende på grunn av behovet for å gå sekvensielt gjennom flere hierarkiske nivåer.

Eksempel: den hierarkiske databasen danner en katalog med filer lagret på disken.

Den samme databasen er det generiske slektstreet.

Nettverk DB forskjellig i større fleksibilitet, har den evnen til å etablere, i tillegg til vertikale bånd, horisontale bånd.

Relasjonelle databaser(fra den engelske relasjonen - "relation") kalles databaser som inneholder informasjon i form av rektangulære tabeller. I denne tilnærmingen kalles en slik tabell et forhold. Hver tabellrad inneholder informasjon omtrent en separat objekt fagområdet beskrevet i databasen , og alle kolonne - visse egenskaper (egenskaper, attributter) disse gjenstandene ... Relasjonell databasen er i hovedsak en todimensjonal bord... Det er fire hovedtyper felt som brukes i en relasjonsdatabase:

Numerisk,

· Symbolsk (ord, tekster, koder osv.),

· Dato (kalenderdatoer i formen "dag / måned / år"),

· Boolsk (tar to betydninger: "ja" - "nei" eller "sant" - "usant").

Databasevinduet inneholder følgende elementer:

ü Knapper: "SKAPE", "ÅPEN", "KONSTRUKTOR" osv. Knapper åpner et objekt i et bestemt vindu eller modus.

ü Objektknapper. (Objektvalgsrygger, faner.) "Bord", "Formen" osv. Objektknappene viser en liste over objekter som kan åpnes eller lukkes.

ü Liste over objekter. Viser objekter valgt av brukeren. I vår versjon er listen fortsatt tom.

Hoveddatabaseobjekter:

· bord Er et objekt designet for å lagre data i form av poster (rader) og felt (kolonner). Vanligvis brukes hver tabell til å lagre informasjon om ett spesifikt spørsmål.

· Formen Er et Microsoft Access-objekt primært for dataregistrering. I skjemaet kan du plassere kontroller som brukes til å legge inn, vise og endre data i feltene i tabellen.

· Forespørsel - et objekt som lar deg hente de nødvendige dataene fra en eller flere tabeller.

· Rapportere - et Microsoft Access-databaseobjekt designet for å skrive ut data.

· Makroer - automatisere standardhandlinger.

· Moduler - automatisere komplekse operasjoner som ikke kan beskrives av makroer.

Med denne artikkelen starter vi en ny syklus 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 opprettelsen 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 prinsippene for datanormalisering, og datadesignverktøy. Deretter vil vi fortelle deg hva DBMS er, hvilke objekter som kan inneholdes i databaser og hvordan forespørsler gjøres til disse objektene.

Grunnleggende begreper om relasjonsdatabaser

La oss starte med de grunnleggende konseptene for DBMS og en kort introduksjon til teorien om relasjonsdatabaser - den mest populære måten å lagre data på i dag.

Relasjonsdatamodell

Relasjonsdatamodell ble foreslått av Dr. E.F. Codd, en anerkjent databaseforsker, i 1969 da han var hos IBM. De grunnleggende konseptene til 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 et slikt depot kalles relasjonsdatabasestyringssystem (RDBMS)... En RDBMS kan inneholde verktøy, applikasjoner, tjenester, biblioteker, applikasjonsopprettingsverktøy og andre komponenter.

Enhver relasjonsdatabasetabell består av strenger(også kalt poster) og kolonner(også kalt marginer). I denne syklusen vil vi bruke begge begrepsparene.

Radene i tabellen inneholder informasjon om fakta som presenteres i den (eller dokumenter, eller personer, med et ord, om gjenstander av samme type). I skjæringspunktet mellom en kolonne og en rad er det spesifikke verdier av dataene i tabellen.

Dataene i tabellene samsvarer med følgende prinsipper:

1. Hver verdi i skjæringspunktet mellom en rad og en kolonne må være atomisk(det vil si at den ikke kan deles opp i flere verdier).
2. Dataverdier i samme kolonne må være av samme type tilgjengelig for bruk i gitt DBMS.
3. Hver post i tabellen er unik, det vil si at det ikke er to poster i tabellen med et helt identisk sett med verdier for feltene.
4. Hvert felt har et unikt navn.
5. Rekkefølgen av feltene i tabellen er irrelevant.
6. Rekkefølgen av oppføringer er også irrelevant.

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 ønsker.

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

Så nå vet vi at relasjonsdatabaser består av tabeller. For å illustrere noen av de teoretiske konseptene og lage eksempler, må vi velge en slags database. For å unngå å 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 lenker

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

Siden radene i tabellen er uordnet, trenger vi en kolonne (eller et sett med flere 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 opp sammensatt primærnøkkel (sammensatt primærnøkkel).

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

KundeID-feltet i denne tabellen inneholder identifikatoren til kunden som la inn denne bestillingen. Hvis vi trenger å finne ut 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 to tabeller, Kunder og Ordrer, ved KundeID-feltet. En kolonne som peker til en post i en annen tabell knyttet til den posten kalles fremmednøkkel (fremmednøkkel). Som du kan se, i tilfellet med ordretabellen, er den fremmede nø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 primærnøkkelverdiene til en annen tabell.

Dette forholdet mellom tabeller kalles kommunikasjon (forhold). Forholdet 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 knyttet til en relasjon 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 av forholdet en-til-mange (en-til-mange forhold) eller forholdet master-detalj... Lignende relasjoner mellom tabeller brukes oftest. I dette tilfellet kalles tabellen som inneholder fremmednøkkelen detaljtabell og tabellen som inneholder primærnøkkelen som definerer mulige fremmednøkkelverdier 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ørsmål formulert på et språk som enten kan være standard for forskjellige DBMS-er eller spesifikt for en spesifikk DBMS.

Referanseintegritet

Vi har allerede sagt ovenfor at primærnøkkelen til enhver tabell må inneholde unike ikke-tomme verdier for denne tabellen. 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, vil DBMS generere en diagnosemelding som vanligvis inneholder setningen når du prøver å tilordne primærnøkkelen til en verdi som allerede er i en annen post. primærnøkkelbrudd... Denne meldingen kan deretter overføres til applikasjonen, ved hjelp av hvilken sluttbrukeren manipulerer dataene.

Hvis to tabeller er relatert av relasjonen master-detalj, ekstern nøkkel detalj- Tabeller skal bare inneholde de verdiene som allerede er tilstede 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 fra Kunder-tabellen en post som har minst én tilknyttet seg detalj- registrere i Ordretabellen, vil dette føre til at det i Ordretabellen vil være registreringer av ordre lagt inn av noen ukjent. Hvis DBMS kontrollerer riktigheten av fremmednøkkelverdier, når du prøver å tilordne en fremmednøkkel en verdi som ikke er blant verdiene til primærnøklene til hovedtabellen, eller når du sletter eller endrer poster i hovedtabellen, fører til et brudd på referensiell integritet, vil DBMS generere en diagnostisk melding, vanligvis inneholdende setningen brudd på utenlandsk nøkkel, som senere kan overføres til brukerapplikasjonen.

De fleste moderne DBMS-er, som Microsoft Access 97, Microsoft Access 2000 og Microsoft SQL Server 7.0, er i stand til å håndheve reglene for referanseintegritet, 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 reglene for referanseintegritet 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 domenet, 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 C.J.Date "Introduction to Database Systems" ("Dialectics", Kiev, 1998).

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

Normalisering er en prosess med omorganisering av data ved å eliminere repeterende grupper og andre motsetninger i datalagring for å bringe tabeller til en form som muliggjør 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 å konvertere databasen til tredje normalform.

Første normalform

La oss illustrere normaliseringsprosessen med et eksempel ved å bruke data fra NorthWind-databasen. 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 samsvare med den første normalformen, må alle feltverdiene være atomiske, 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 bestilte 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å:

• Adressen til en bestemt kunde kan kun inneholdes i databasen når kunden har bestilt minst ett produkt.
• Sletting av en post for et bestilt produkt sletter samtidig informasjon om selve bestillingen og kunden som la den.
• Hvis, gud forby, kunden har endret adressen, må du oppdatere alle postene for produktene som er bestilt av ham.

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

Andre normalform

Relasjonstabellen sies å være i 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, 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 å bytte fra den første normale formen til den andre, må du følge disse trinnene:

1. Bestem hvilke deler primærnøkkelen kan partisjoneres inn i, slik at noen av ikke-nøkkelfeltene avhenger av en av disse delene ( disse delene trenger ikke å være i én kolonne!).
2. Lag 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. Den delen av den tidligere primærnøkkelen vil da bli primærnøkkelen til den nye tabellen.
3. Fjern felt fra den opprinnelige tabellen som har blitt flyttet til andre tabeller enn de som vil bli fremmednøkler.

For å bringe OrderedProducts-tabellen til en annen normal form, flytter du for eksempel feltene CustomerID, Address og OrderDate til en ny tabell (la oss kalle det OrdersInfo), og gjør OrderID-feltet til primærnøkkelen til den nye tabellen (Figur 3) .

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

• Adressen til en spesifikk kunde kan fortsatt bare finnes i databasen når kunden har bestilt minst ett produkt.
• Sletting av en ordrepost i OrdersInfo-tabellen vil slette posten 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).

Du kan eliminere disse anomaliene ved å gå til tredje normalform.

Tredje normalform

Relasjonstabellen sies å være i tredje normalform hvis den er i andre normal form og alle ikke-nøkkelfeltene 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, må du følge disse trinnene:

• Definer alle felt (eller feltgrupper) som andre felt er avhengige av.
• Opprett en ny tabell for hvert slikt felt (eller gruppe av felt) og gruppen av felter som avhenger 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 inn i den. La oss slette Adresse-feltet fra den opprinnelige tabellen, og forlate KundeID-feltet - nå er det en fremmednøkkel (fig. 4).

Så, etter å ha konvertert den opprinnelige tabellen til tredje normalform, er det tre tabeller - kunder, bestillinger og ordredetaljer.

Fordelene med normalisering

Normalisering fjerner dataredundans, som lar deg redusere mengden lagrede data og kvitte seg med uregelmessighetene beskrevet ovenfor. For eksempel, etter å ha konvertert databasen diskutert ovenfor til tredje normal form, er følgende forbedringer tydelige:

• Kundens adresseinformasjon kan lagres i databasen, selv om det kun er en potensiell kunde som ennå ikke har lagt inn noen ordre.
• Du kan slette bestilt produktinformasjon uten frykt for å slette kunde- og ordredata.

Endring av kundeadresse eller ordreregistreringsdato krever nå endring av kun é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 betjener flere forskjellige DBMSer samtidig) som lar deg lage tabeller, nøkler og lenker.

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

Til slutt er det en annen metode, som blir mer og mer populær, er bruken av spesialverktøy kalt CASE-verktøy (CASE står for Computer-Aided System Engineering). Det finnes flere typer CASE-verktøy, men entitetsrelasjonsdiagrammer (E/R-diagrammer) brukes oftest for å lage databaser. 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 prototyper av tabeller entiteter, og felt kalles deres attributter. Etter å ha etablert relasjoner mellom entiteter, definert attributter og utført normalisering, kan en s.k. fysisk en databasespesifikk datamodell som definerer alle tabeller, felt og andre databaseobjekter. Etter det kan du generere enten selve databasen eller et DDL-skript for å lage den.

Liste over de mest populære CASE-verktøyene.

Tabeller og felt

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

Indekser

Tidligere har vi snakket om rollen til primær- og fremmednøkler. I de fleste relasjonelle DBMS-er implementeres nøkler ved å bruke objekter kalt indekser, som kan defineres som en liste over postnumre som indikerer i hvilken rekkefølge de skal eksponeres.

Vi vet allerede at poster i relasjonstabeller er uordnet. Likevel har enhver post på et bestemt tidspunkt en veldefinert fysisk plassering i databasefilen, selv om den kan endres under dataredigering eller som et resultat av den "interne aktiviteten" til selve DBMS.

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

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

1,6,4,2,5,3

Hvis vi ønsker å bestille postene 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 starter med tegnene "BO", kan vi bruke indeksen til å finne plasseringen av disse postene (i dette tilfellet 2 og 5 (det er åpenbart at tallene til disse postene er i en rad i indeksen), og les deretter den andre og femte posten, i stedet for å gå gjennom hele tabellen, så bruk av indekser reduserer tiden for datahenting.

Vi har allerede snakket om det faktum at den fysiske plasseringen av poster kan endres i 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 det samtidig er tilsvarende endringer i indeksen, kalles det støttet av og slike indekser brukes i de fleste moderne DBMS-er. Implementeringen av slike indekser fører til det faktum at enhver endring i dataene i tabellen medfører en endring i de tilknyttede indeksene, og dette øker tiden som kreves av DBMS for å utføre slike operasjoner. Derfor, når du bruker et slikt DBMS, bør du bare lage de indeksene som virkelig er nødvendige, og bli veiledet av hvilke spørsmål som vil bli møtt oftest.

Begrensninger og regler

De fleste moderne DBMS-er på serversiden inneholder spesielle objekter kalt begrensninger(begrensninger), eller reglene(regler). Disse objektene inneholder informasjon om begrensningene som er pålagt de mulige verdiene til feltene. For eksempel, ved å bruke et slikt objekt, kan du angi maksimums- eller minimumsverdien for et gitt felt, og etter det vil DBMS ikke tillate lagring av en post i databasen som ikke tilfredsstiller denne betingelsen.

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

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

Representasjon

Nesten alle relasjonsdatabaser 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 en visning en lagret forespørsel.

Oppretting av visninger i de fleste moderne DBMS-er utføres med spesielle visuelle midler som lar deg vise de nødvendige tabellene på skjermen, etablere forbindelser mellom dem, velge de viste feltene, pålegge begrensninger på poster, etc.

Ofte brukes disse objektene for å sikre datasikkerhet, for eksempel ved at data kan vises med dem uten å gi direkte tilgang til tabellene. I tillegg kan noen visningsobjekter returnere forskjellige data avhengig av for eksempel brukerens navn, noe som gjør at han kun kan motta data av interesse.

Utløsere og lagrede prosedyrer

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

En lagret prosedyre er en spesiell type prosedyre som utføres av databaseserveren. 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 de kan kalles fra en klientapplikasjon som fungerer med en database.

Lagrede prosedyrer brukes ofte når du utfører vanlige oppgaver (som balansering av en balanse). De kan ta argumenter, returnere verdier, feilkoder og noen ganger sett med rader og kolonner (noen ganger referert til som datasett). Den siste typen prosedyre 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 assosiert med en spesifikk tabell og utføres når, når du redigerer denne tabellen, inntreffer en hendelse som den er knyttet til (for eksempel innsetting, sletting eller oppdatering av en post).

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

Objekter for generering av primærnøkler

Svært ofte genereres primærnøkler av DBMS selv. 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å dupliserte nøkler og få konsistente 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 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 typer felt for primærnøkler. Når du legger til poster, fylles slike felt ut automatisk med påfølgende 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

Å forhindre uautorisert tilgang til data er et stort problem som kan løses på en rekke 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 databeskyttelse mer populær - å lage en liste over brukere med navn (brukernavn) og passord (passord). I dette tilfellet tilhører ethvert databaseobjekt en spesifikk bruker, og denne brukeren gir andre brukere tillatelse til å lese eller endre data fra dette objektet, eller til å endre selve objektet. Denne metoden brukes på alle servere og enkelte stasjonære DBMS (for eksempel Microsoft Access).

Noen DBMS, hovedsakelig server-side, 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

Modifikasjon og valg av data, endring av metadata og enkelte 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 felt som skal vises i et spørringsresultat.

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

Pekere

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

De fleste moderne DBMS-er støtter de såkalte toveis-markørene, som lar deg bevege deg fremover og bakover i det resulterende datasettet. Noen DBMS-er støtter imidlertid bare ensrettede markører, som bare beveger seg fremover gjennom datasettet.

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 bransjestandarden.

Språkets ikke-prosessuelle natur betyr at du kan spesifisere i det hva som må gjøres med databasen, men du kan ikke beskrive algoritmen til 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 operatører, som kan deles inn i flere kategorier:

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

Du vil lære mer om SQL-språket i en av de neste 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, hvoretter de kan brukes i spørringer, triggere og lagrede prosedyrer.

Siden de brukerdefinerte funksjonene finnes i bibliotekene, kan de opprettes ved hjelp av et hvilket som helst utviklingsverktøy som lar deg lage biblioteker for plattformen som den gitte DBMS opererer på.

Transaksjoner

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

Fullføring (Commit) av en transaksjon betyr at alle operasjoner som er inkludert i transaksjonen er fullført, og resultatet av arbeidet deres er lagret i databasen.

Tilbakerulling av en transaksjon betyr at alle operasjoner som allerede er utført som er en del av transaksjonen, rulles tilbake og alle databaseobjekter som påvirkes av disse operasjonene blir returnert til sin opprinnelige tilstand. For å implementere muligheten til tilbakeføring av transaksjoner, støtter mange DBMS skriving til loggfiler, som lar deg gjenopprette de opprinnelige dataene under tilbakerulling.

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 en relasjonell DBMS, de grunnleggende prinsippene for datadesign, og snakket også om hvilke objekter som kan lages i databaser.

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

ComputerPress 3 "2000

Post-relasjonell DBMS. Objekt DBMS. Ulemper med relasjonell DBMS. Grunnleggende konsepter for objektorientert DBMS.

Rer begrenset. De er ideelle for tradisjonelle applikasjoner som billett- eller hotellreservasjonssystemer og banksystemer, men deres anvendelse i CAD, intelligente produksjonssystemer og andre kunnskapsbaserte systemer er ofte vanskelig. Dette skyldes først og fremst primitiviteten til datastrukturene som ligger til grunn for den relasjonsdatamodellen. Flate normaliserte relasjoner er universelle og teoretisk nok til å representere data i ethvert domene. I ukonvensjonelle applikasjoner vises imidlertid hundrevis, om ikke tusenvis av tabeller i databasen, og dyre sammenføyningsoperasjoner utføres konstant på dem for å gjenskape de komplekse datastrukturene som er iboende i domenet.

En annen alvorlig begrensning ved relasjonssystemer er deres relativt svake evner når det gjelder å representere applikasjonens semantikk ( semantikk- i programmering - et system med regler for tolkning av individuelle språkkonstruksjoner. Semantikk bestemmer den semantiske betydningen av setningene til det algoritmiske språket ...). Det mest relasjonelle DBMS gir er evnen til å formulere og vedlikeholde dataintegritetsbegrensninger. Databaseforskere erkjenner disse begrensningene og manglene ved relasjonssystemer, og gjennomfører en rekke prosjekter basert på ideer som går utover relasjonsdatamodellen.

Andre ulemper med relasjonelle DBMS-er inkluderer følgende:

Ufleksibilitet i strukturen for å utvikle databaser,

· Vanskeligheter med å bygge en konseptuell modell for objekter med flere relasjoner "mange-til-mange",

· Unaturlig tabellpresentasjon for sparsomme datamatriser.

Objekt orientert databaser er relativt nye, databaseteori har ikke et så godt matematisk grunnlag som relasjons- eller tremodeller. Dette bør imidlertid ikke nødvendigvis sees på som en iboende svakhet i denne modelleringsteknologien. Egenskapene som ser ut til å være felles for de fleste databaseimplementeringer er:

1. Abstraksjon: Hver ekte "ting" som er lagret i databasen er medlem av en klasse. En klasse er definert som en samling av egenskaper, metoder, offentlige og private datastrukturer og programmer som gjelder objekter (forekomster) av en gitt klasse. Klasser er ikke annet enn abstrakte datatyper. Metoder er prosedyrer som kalles for å utføre en slags handling på et objekt (for eksempel skrive ut deg selv eller kopiere deg selv). Egenskaper er dataverdier knyttet til hvert objekt i klassen, og karakteriserer det på en eller annen måte (for eksempel farge, alder).

2.Innkapsling: Den interne representasjonen av data og implementeringsdetaljer for offentlige og private metoder (programmer) er en del av klassedefinisjonen og er kun kjent innenfor den klassen. Tilgang til objekter i en klasse er kun tillatt gjennom egenskapene og metodene til denne klassen eller dens foreldre (se nedenfor "arv"), og ikke ved å bruke kunnskap om detaljene i den interne implementeringen.

3. Arv (enkelt eller flere): Klasser er definert som en del av et klassehierarki. Definisjonen av hver klasse på lavere nivå arver egenskapene og metodene til dens overordnede, med mindre de er eksplisitt erklært ikke-arvelige eller endret av en ny definisjon. Med enkeltarv kan en klasse bare ha én overordnet klasse (det vil si at klassehierarkiet har en trestruktur). Med multippel arv kan en klasse stamme fra flere foreldre (dvs. klassehierarkiet har en rettet, ikke-syklisk grafstruktur, ikke nødvendigvis en trestruktur).

4. Polymorfisme: Flere klasser kan ha samme metode- og egenskapsnavn, selv om de anses som forskjellige. Dette lar deg skrive tilgangsmetoder som vil fungere korrekt med objekter av helt andre klasser, så lenge de tilsvarende metodene og egenskapene er definert i disse klassene.

5. Innlegg: Interaksjon med objekter utføres ved å sende meldinger med mulighet for å motta svar.

Hvert objekt, informasjon om hvilke er lagret i OODB, anses å tilhøre en klasse, og koblingene mellom klassene etableres ved å bruke egenskapene og metodene til klassene.

OODB-modellen er på et høyere abstraksjonsnivå enn relasjons- eller trebaserte databaser, så klasser kan implementeres ved å stole enten på en av disse modellene eller på en annen. Siden utviklingssenteret ikke er datastrukturer, men prosedyrer (metoder), er det viktig at det velges en basismodell som gir tilstrekkelig styrke, fleksibilitet og prosessytelse.

Relasjonsdatabaser, med deres strenge strukturdefinisjon og begrensede sett med tillatte operasjoner, er utvilsomt ikke egnet som en basisplattform for OODB-er. M-språksystemet med sin mer fleksible datastruktur og mer prosedyremessige tilnærming til utvikling ser ut til å være mer egnet for bruk som en basisplattform for en OBSD.

En DBMS er programvare som brukere kan definere, opprette og vedlikeholde en database med og utøve kontroll over tilgangen til.

Objektrelasjonelle DBMS-er er for eksempel Oracle Database og PostgreSQL; forskjellen mellom objektrelasjonell og objekt-DBMS: førstnevnte er en overbygning over relasjonsskjemaet, mens sistnevnte i utgangspunktet er objektorientert.

Objekttilgang i relasjonelle DBMS-er 1) DBMS-en identifiserer siden i den eksterne lagringsenheten som inneholder den nødvendige posten. Bruke indeksmekanismer eller utføre full tabellskanning. DBMS leser deretter denne siden fra den eksterne lagringsenheten og kopierer den til CACHE 2, DBMS overfører sekvensielt dataene fra CACHE til applikasjonens minneplass. Hvis du gjør det, må du kanskje utføre konverteringer fra SQL-datatyper til applikasjonsdatatyper. En applikasjon kan oppdatere feltverdier i minneplassen. 3. Datafeltene modifisert av applikasjonen ved hjelp av SQL-språket overføres tilbake til DBMS CACHE, hvor det igjen kan være nødvendig å utføre en datatypekonvertering. 4. DBMS lagrer den oppdaterte siden til en ekstern lagringsenhet og overskriver den fra CACHE.

Objekttilgang i OODBMS. 1. OODBMS finn det på den eksterne lagringsenheten siden som inneholder det nødvendige objektet, bruk indeksen om nødvendig. OODBMS leser deretter den nødvendige siden fra den eksterne lagringsenheten og kopierer den inn i applikasjonens sidebuffer, som er i applikasjonens minne. 2. OODBMS m Flere konverteringer kan utføres: 1. erstatning av referanser (pekere) av ett objekt til et annet. 2. innføring i dataene til objektet med informasjon som er nødvendig for å sikre samsvar med kravene til programmeringsspråket. 3. Endring av formatet for datapresentasjon opprettet på forskjellige maskinvareplattformer eller programmeringsspråk. 3. Søknaden implementerer få tilgang til objektet og oppdater det etter behov. 4. Når applikasjonen trenger å gjøre endringene permanent eller laste ut siden fra hurtigbufferen til disken en stund, før du kopierer siden til en ekstern lagringsenhet, må OODBMS utføre de omvendte transformasjonene som ligner på de som er beskrevet ovenfor.

Billett nummer 27

Økonomisk balanse, virksomhetens virksomhet. Foretakets økonomiske balanse. Utnyttingseffekt. Gjeldsnivåanalyse. Analyse av kontantstrømmer i produksjonsaktiviteter.

Foretakets virksomhet vanligvis preget av intensiteten i bruken av investert (intern) kapital. I produksjon er kapitalen i konstant bevegelse, og går fra et trinn i sirkulasjonen til et annet: det vil si teknologien D®T®... ®P® ... T®D blir implementert. "Penger, varer

For eksempel, i det første trinnet investerer et foretak i anleggsmidler, produksjonsbeholdninger, i det andre trinnet går midler i form av varelager i produksjon, og en del brukes til å betale ansatte, betale skatter, trygdeutgifter og andre utgifter . Dette stadiet avsluttes med utgivelsen av ferdige produkter. På tredje trinn selges ferdige produkter, selskapet mottar midler. Jo raskere kapitalen gjør en krets, jo flere produkter vil selskapet motta og selge med samme mengde investert kapital. En forsinkelse i bevegelsen av midler på ethvert stadium fører til en nedgang i kapitalomsetningen, krever ytterligere investeringer og kan føre til en betydelig forverring i bruken av kapital.

Effektiviteten av å bruke den investerte kapitalen vurderes ved å beregne følgende indikatorer.

En databank forstås som et sett med databaser, samt programvare, språk og andre midler beregnet på sentralisert akkumulering av data og deres bruk ved hjelp av elektroniske datamaskiner.

Databanken inkluderer en eller flere databaser, en databasereferansebok, et databasestyringssystem (DBMS), samt et bibliotek med spørringer og applikasjoner.

Databanken er laget for å lagre store mengder informasjon, raskt finne nødvendig informasjon og dokumenter.

En databank blir opprettet i abonnentsystemet uansett kapasitet - fra en personlig datamaskin til en superdatamaskin. Men selv den største databanken er begrenset i sine muligheter. Derfor spesialiserer bankene i nettverket seg og samler informasjon innen visse områder av vitenskap, teknologi, produkter. Databaser og kunnskapsbaser er kjernen i banken. En database er en organisert struktur for lagring av informasjon. Data og informasjon er sammenhengende begreper, men ikke identiske, jeg bør merke meg avviket i denne definisjonen. I dag tillater de fleste databasestyringssystemer (DBMS) plassering i strukturene deres, ikke bare data, men også metoder (det vil si programvarekode), ved hjelp av hvilke interaksjoner med forbrukeren eller med andre programvare- og maskinvaresystemer finner sted. Dermed kan vi si at moderne databaser lagrer ikke bare data, men også informasjon.

BnD har spesialverktøy som gjør det enklere for brukere å jobbe med data (DBMS).

Sentralisert databehandling har fordeler fremfor et konvensjonelt filsystem:

- reduksjon av redundans for datalagring;

- reduksjon av arbeidsintensiteten for utvikling, drift og modernisering av IS;

Gir enkel tilgang til data som brukere

- til fagfolk innen databehandling og til sluttbrukere.

Grunnleggende krav til BnD:

- tilstrekkeligheten av visningen av fagområdet (fullstendighet, integritet og - konsistens av data, relevans av informasjon;

- evnen til å samhandle med brukere av forskjellige kategorier, høy effektivitet av datatilgang;

- vennlighet til grensesnitt, kort treningstid;

- sikre hemmelighold og differensiere tilgang til data for ulike brukere;

- pålitelighet av lagring og databeskyttelse.

Definisjonen av begrepet databank er gitt i den midlertidige forskriften om statlig regnskap og registrering av databaser og databanker, godkjent av dekret fra regjeringen i Den russiske føderasjonen av 28.02.96 nr. 226, paragraf 2 (SZ RF, 1996, nr. . 12, art. 1114)

Opprinnelig (tidlig på 60-tallet) ble et fillagringssystem brukt. For å løse primært tekniske problemer, preget av en liten mengde data og en betydelig mengde beregning, ble dataene lagret direkte i programmet. En konsekvent måte å organisere dataene på ble brukt, det var deres høye redundans, identiteten til de logiske og fysiske strukturene og den fullstendige avhengigheten av dataene. Med fremveksten av økonomiske og ledelsesmessige oppgaver (styringsinformasjonssystem - MIS), preget av store mengder data og en liten andel av beregninger, viste den spesifiserte dataorganisasjonen seg å være ineffektiv. Det var nødvendig å bestille data, som, som det viste seg, kunne utføres i henhold til to kriterier: bruk (informasjonsmatriser); lagring (databaser). Opprinnelig ble informasjonsmatriser brukt, men overlegenheten til databaser ble snart klart. Bruken av filer til kun å lagre data ble foreslått av McGree i 1959. Metoder for tilgang (inkludert vilkårlig) til slike filer ble utviklet, mens de fysiske og logiske strukturene allerede var forskjellige, og den fysiske plasseringen av dataene kunne endres uten å endre den logiske representasjonen.

I 1963 bygde S. Bachmann den første industrielle IDS-databasen med en nettverksdatamodell som fortsatt var preget av dataredundans og bruk for kun én applikasjon. Dataene ble åpnet ved hjelp av riktig programvare. I 1969 ble det dannet en gruppe som laget CODASYL-settet med standarder for nettverksdatamodellen.

Faktisk begynte moderne databasearkitektur å bli brukt. Arkitektur forstås som en type (generalisering) av en struktur der et element kan erstattes av et annet element, hvis egenskaper til inngangene og utgangene er identiske med det første elementet. Et betydelig sprang i utviklingen av databaseteknologi ble gitt av paradigmet til relasjonsdatamodellen foreslått av M. Codd i 1970. Et paradigme forstås som en vitenskapelig teori nedfelt i et system av begreper som gjenspeiler de vesentlige trekk ved virkeligheten. Nå kunne logiske strukturer hentes fra de samme fysiske dataene, dvs. de samme fysiske dataene kan nås av forskjellige applikasjoner langs forskjellige veier. Det ble mulig å sikre dataenes integritet og uavhengighet.

På slutten av 70-tallet dukket det opp moderne DBMS som gir fysisk og logisk uavhengighet, datasikkerhet og har utviklet databasespråk. Det siste tiåret har vært preget av fremveksten av distribuerte og objektorienterte databaser, hvis egenskaper bestemmes av anvendelser av designautomatiseringsverktøy og databaseintellektualisering.

Konseptet med et databasestyringssystem er nært knyttet til konseptet med en database - det er et sett med programvareverktøy designet for å lage strukturen til en ny database, fylle den med innhold, redigere innholdet og visualisere informasjon. Visualisering av databaseinformasjon betyr valg av viste data i henhold til et gitt kriterium, deres bestilling, design og påfølgende levering til en utdataenhet eller overføring via kommunikasjonskanaler.

Det finnes mange databasestyringssystemer i verden. Til tross for at de kan jobbe forskjellig med forskjellige objekter og gi brukeren forskjellige funksjoner og verktøy, er de fleste DBMS avhengige av et enkelt veletablert sett med grunnleggende konsepter. Dette gir oss muligheten til å vurdere ett system og generalisere dets konsepter, teknikker og metoder for hele klassen av DBMS.

DBMS organiserer lagring av informasjon på en slik måte at det er praktisk:

bla,

fylle opp,

endring,

se etter informasjonen du trenger,

gjøre eventuelle valg,

sortere i hvilken som helst rekkefølge.

Databaseklassifisering:

a) etter arten av den lagrede informasjonen:

Factographic (arkivskap),

Dokumentar (arkiv)

b) forresten data lagres:

Sentralisert (lagret på én datamaskin),

Distribuert (brukes i lokale og globale datanettverk).

c) i henhold til strukturen til dataorganisasjonen:

Tabellform (relasjonelt),

Hierarkisk,

Moderne DBMS gjør det mulig å inkludere ikke bare tekst og grafisk informasjon, men også lydfragmenter og til og med videoklipp.

Brukervennlighet DBMS lar deg lage nye databaser uten å måtte ty til programmering, men kun bruke innebygde funksjoner. DBMS sikrer riktigheten, fullstendigheten og konsistensen av data, samt enkel tilgang til dem.

Populær DBMS - FoxPro, Access for Windows, Paradox. For mindre komplekse applikasjoner, i stedet for en DBMS, brukes (ISS), som utfører følgende funksjoner:

lagring av en stor mengde informasjon;

raskt søk etter nødvendig informasjon;

legge til, slette og endre lagret informasjon;

utgangen i en form som er praktisk for en person.

Informasjon i databaser er strukturert i separate poster, som kalles en gruppe relaterte dataelementer. Arten av forholdet mellom poster bestemmer to hovedtyper av databaseorganisering: hierarkisk og relasjonell.

Hvis det ikke er data i databasen (tom database), så er det fortsatt en fullverdig database. Dette faktum har metodisk betydning. Selv om det ikke er data i databasen, er det fortsatt informasjon i den - dette er strukturen til databasen. Den definerer metodene for å legge inn data og lagre dem i databasen. Den enkleste "ikke-datamaskin"-versjonen av databasen er en forretningsdagbok, der en side er tildelt for hver kalenderdag. Selv om det ikke er skrevet en eneste linje i den, slutter den ikke å være en daglig planlegger, siden den har en struktur som tydelig skiller den fra notatbøker, arbeidsbøker og annet skrivemateriell.

Databaser kan inneholde forskjellige objekter, men hovedobjektene i enhver database er tabellene. Den enkleste databasen har minst én tabell. Følgelig er strukturen til den enkleste databasen identisk lik strukturen til tabellen.

For tiden er det en rask vekst i antall e-handelssystemer (ECS). E-handel har en rekke særtrekk som skiller den skarpt fra alle tidligere kjente metoder for klassisk handel på grunn av de eksepsjonelle kommunikative egenskapene til Internett.

E-handelssystemer må være i stand til å koordinere forretningstransaksjoner på tvers av flere forretningsapplikasjoner, kunne trekke ut deler av informasjon fra flere kilder og levere informasjonen de trenger på en rettidig og sømløs måte – alt på en enkelt nettbrukerforespørsel.

SEC har et sett med spesifikke egenskaper som skiller dem fra klassiske handelssystemer (vanlige butikker, supermarkeder, børser, etc.). Samtidig må disse egenskapene tas i betraktning når man konstruerer og analyserer modeller av prosesser i SEC, siden den klassiske formuleringen av optimaliseringsproblemet med optimal kontroll av et diskret system ikke er egnet. Så, egenskapene til SEC: Driftstiden er ubegrenset, i motsetning til klassiske systemer, der det er en strengt regulert arbeidsplan. Vi kan si at strømmen av besøkende er jevnt fordelt over tid. I motsetning til klassiske systemer i SEC (dette er spesielt typisk for B2C-systemer), kommer besøkende ikke bare for kjøp, men også for litt informasjon: for å bli kjent med sortiment, priser, betalingsbetingelser og levering av varer.

Samtidig er klassiske systemer preget av en slik funksjon at besøkende med stor sannsynlighet blir kjøpere. Derfor er det mulig å vurdere ulike modeller og metoder for å vurdere effektiviteten av funksjonen til SEC: forholdet mellom antall kjøpere og antall besøkende, virkningen av SEC og tilbakemelding på inndataflyten til applikasjoner.

Det er typisk for SEK at mange besøkende kommer dit flere ganger for å få litt informasjon, og først etter at de er fornøyd med alle betingelsene, foretar de et kjøp.

SEC kan betjene et tilstrekkelig stort antall besøkende samtidig. Denne egenskapen er kun begrenset av programvare- og maskinvarefunksjonene til SEC. Det vil si at i tilfellet med SEC, fra brukerens synspunkt, er det ingen ventekøer. Dette gjelder spesielt for helt eller delvis automatisert SEC.

I SEC er et tilfelle mulig når en besøkende som har skrevet inn produkter i en virtuell kurv forlater systemet uten å foreta et kjøp (det er naturlig at alle produkter forblir i systemet, siden det rett og slett er umulig å stjele dem). Ved å tegne en analogi med klassiske handelssystemer, er det igjen vanskelig å forestille seg en situasjon når en besøkende, som kommer inn i en butikk, først laster en full vogn med varer, og deretter losser alt og forlater butikken. I SEC er dette tilfellet mulig hvis settet med kontrollfaktorer ikke er optimalt (eller suboptimalt)

Databasestyringssystemer lar deg kombinere store mengder informasjon og behandle dem, sortere dem, foreta valg etter bestemte kriterier osv.

Moderne DBMS gjør det mulig å inkludere ikke bare tekst og grafisk informasjon, men også lydfragmenter og til og med videoklipp. Brukervennlighet DBMS lar deg lage nye databaser uten å måtte ty til programmering, men kun bruke innebygde funksjoner. DBMS sikrer korrekthet, fullstendighet og konsistens av data.

1.2 Relasjonelle databaser

Relational DBMS (RDBMS; ellers Relational Database Management System, RDBMS) er en DBMS som administrerer relasjonsdatabaser.

Konseptet relasjonell (engelsk relasjon - relasjon) er assosiert med utviklingen av den berømte engelske spesialisten innen databasesystemer Edgar Codd (Edgar Codd).

Disse modellene er preget av enkel datastruktur, brukervennlig tabellpresentasjon og evnen til å bruke det formelle apparatet til algebra av relasjoner og relasjonskalkulus for databehandling.

Relasjonsmodellen fokuserer på å organisere data i form av todimensjonale tabeller. Hver relasjonstabell er en todimensjonal matrise og har følgende egenskaper:

- hvert element i tabellen er ett dataelement;

- alle kolonnene i tabellen er homogene, det vil si at alle elementene i en kolonne er av samme type (numerisk, symbolsk, etc.);

- hver kolonne har et unikt navn;

- det er ingen identiske linjer i tabellen;

- rekkefølgen på rader og kolonner kan være vilkårlig.

De grunnleggende konseptene for relasjonell DBMS er: 1) attributt; 2) relasjoner; 3) en tuppel.

En database er altså ikke annet enn en samling tabeller. RDBS og rekordorienterte systemer er organisert rundt B-Tree-standarden eller Indexed Sequential Access Method (ISAM) og er standardsystemene som brukes i de fleste moderne programvareprodukter. Språk som SQL (IBM), Quel (Ingres) og RDO (Digital Equipment) brukes til å gi en kombinasjon av tabeller for å definere relasjoner mellom data, som er nesten helt fraværende i de fleste programvareimplementeringer av B-Tree og ISAM, og industristandarden er nå blitt SQL-språket, støttet av alle produsenter avr.

Den originale versjonen av SQL er et tolket språk for å utføre operasjoner på databaser. SQL-språket ble opprettet på begynnelsen av 70-tallet som et grensesnitt for interaksjon med databaser basert på relasjonsteorien, som var ny for den tiden. Ekte applikasjoner er vanligvis skrevet på andre språk som genererer SQL-kode og sender dem til DBMS som ASCII-tekst. Det bør også bemerkes at nesten alle reelle relasjonssystemer (og ikke bare relasjonssystemer), i tillegg til implementeringen av ANSI SQL-standarden, nå kjent i den siste utgaven under navnet SQL2 (eller SQL-92), inkluderer tilleggsutvidelser, for eksempel støtte for klient-server-arkitektur eller applikasjonsutviklingsverktøy.

Radene i tabellen består av felt som er kjent på forhånd for databasen. De fleste systemer kan ikke legge til nye datatyper. Hver rad i tabellen tilsvarer én post. Plasseringen til denne linjen kan endres sammen med sletting eller innsetting av nye linjer.

For å identifisere et element unikt, må det knyttes til et felt eller sett med felt som garanterer unikheten til elementet i tabellen. Slike felt eller felt kalles primærnøkkelen til tabellen og er ofte tall. Hvis en tabell inneholder primærnøkkelen til en annen, lar dette deg organisere forholdet mellom elementene i forskjellige tabeller. Dette feltet kalles en fremmednøkkel.

Siden alle felt i en tabell må inneholde et konstant antall felt av forhåndsbestemte typer, er det nødvendig å lage ytterligere tabeller, med tanke på de individuelle egenskapene til elementene, ved å bruke fremmednøkler. Denne tilnærmingen kompliserer i stor grad opprettelsen av komplekse relasjoner i databasen. En annen stor ulempe med relasjonsdatabaser er den høye kompleksiteten ved å manipulere informasjon og endre relasjoner.

Til tross for de vurderte ulempene med relasjonsdatabaser, har de en rekke fordeler:

deling av tabeller etter forskjellige programmer;

utvidet "returkode" for feil;

høy hastighet på spørringsbehandling (SQL-kommando SELECT; resultatet av valget er en tabell som inneholder felt som oppfyller det angitte kriteriet);

selve konseptet med objektdatabaser er ganske komplekst og krever seriøs og langvarig opplæring fra programmerere;

relativt høy hastighet ved arbeid med store datamengder.

I tillegg er det allerede investert betydelige midler i relasjonelle DBMS rundt om i verden. Mange organisasjoner er ikke overbevist om at kostnadene ved å migrere til objektdatabaser vil lønne seg.

Derfor er mange brukere interessert i en kombinert tilnærming som lar dem dra nytte av fordelene med objektdatabaser uten å helt forlate relasjonsdatabasene sine. Slike løsninger finnes. Hvis overgangen fra en relasjonsdatabase til en objektdatabase er for dyr, er det ofte et mer kostnadseffektivt alternativ å bruke sistnevnte som en utvidelse og tillegg til relasjonsdatabaser. Avveininger lar deg finne en balanse mellom objekter og relasjonstabeller.

Objektrelasjonelle adaptere - eh Denne metoden innebærer bruk av en såkalt objektrelasjonsadapter, som automatisk allokerer programvareobjekter og lagrer dem i relasjonsdatabaser. En objektorientert applikasjon fungerer som en vanlig DBMS-bruker. Til tross for en viss ytelsesforringelse, lar dette alternativet programmerere konsentrere seg helt om objektorientert utvikling. I tillegg kan alle applikasjoner i bedriften fortsatt få tilgang til data som er lagret i relasjonsform.

Noen objekt-DBMS-er, for eksempel GemStone fra GemStone Systems, kan selv fungere som en kraftig objektrelasjonsadapter, som lar objektorienterte applikasjoner få tilgang til relasjonsdatabaser.

Objektrelasjonelle adaptere som Hewlett-Packards Odapter for Oracle Database kan brukes med suksess på mange områder, for eksempel mellomvare som integrerer objektorienterte applikasjoner med relasjonsdatabaser.

Objektrelasjonelle gatewayer - s Når du bruker denne metoden, samhandler brukeren med databasen ved å bruke OODBMS-språket, og gatewayen erstatter alle objektorienterte elementer i dette språket med deres relasjonskomponenter. Dette kommer igjen på bekostning av ytelse. For eksempel må en gateway konvertere objekter til et sett med lenker, generere de originale identifikatorene (OID-ene) til objektene og sende dette til relasjonsdatabasen. Gatewayen må da, hver gang RDBMS-grensesnittet brukes, oversette OID som finnes i databasen til det tilsvarende objektet som er lagret i RDBMS.

Ytelsen til de to tilnærmingene diskutert ovenfor avhenger av hvordan relasjonsdatabasen er tilgjengelig. Hver RDBMS består av to lag: databehandlerlaget og lagringsbehandlingslaget. Den første behandler setninger i SQL-språket, og den andre tilordner dataene til databasen. En gateway eller adapter kan samhandle med både datalaget (det vil si tilgang til RDBMS ved hjelp av SQL) og medielaget (prosedyrekall på lavt nivå). Ytelsen i det første tilfellet er mye lavere (for eksempel, OpenODB-systemet fra Hewlett-Packard, som kan fungere som en gateway, støtter det bare på et høyt nivå).

Hybrid DBMS - f.eks En annen løsning er å lage hybride objektrelasjonelle DBMS-er som kan lagre både tradisjonelle tabelldata og objekter. Mange analytikere mener at fremtiden tilhører slike hybriddatabaser. Ledende relasjonsdatabaseleverandører begynner (eller planlegger å) legge til objektorienterte verktøy til produktene sine. Spesielt kommer Sybase og Informix til å introdusere støtte for objekter i de neste versjonene av DBMS. Uavhengige firmaer har til hensikt å gjennomføre lignende utviklinger. For eksempel forbereder selskapet Shores seg på å utstyre Oracle8 med objektorienterte verktøy, som er planlagt utgitt i slutten av 1996.

På den annen side, gjenkjenner objektdatabaseleverandører som Object Design at objektorienterte databaser ikke vil erstatte relasjonsdatabaser i overskuelig fremtid. Dette tvinger dem til å lage gatewayer for å støtte relasjonelle og hierarkiske databaser eller ulike typer grensesnitt, et typisk eksempel på dette er Ontos' Ontos Integration Server objektrelasjonelt grensesnitt brukt i forbindelse med Ontos / DB OODB.

1.3 Flerdimensjonale databaser

En kraftig database med en spesiell lagringsorganisasjon - kuber, som lar brukere analysere store mengder data. En flerdimensjonal database lar deg utføre høyhastighetsarbeid med data lagret som en samling av fakta, dimensjoner og forhåndsberegnet aggregater.

I spesialiserte DBMS-er basert på flerdimensjonal datarepresentasjon, organiseres data ikke i form av relasjonstabeller, men i form av ordnede flerdimensjonale matriser:

Hyperkuber - alle celler som er lagret i databasen må ha samme dimensjon, det vil si være i det mest komplette grunnlaget for målinger

Polykuber - hver variabel lagres med sitt eget sett med dimensjoner, og all tilhørende prosesseringskompleksitet overføres til de interne mekanismene i systemet.

Bruken av flerdimensjonale databaser i online analytiske prosesseringssystemer har følgende fordeler:

høy ytelse. Produkter som tilhører denne klassen har vanligvis en flerdimensjonal databaseserver. I prosessen med analyse velges data utelukkende fra en flerdimensjonal struktur, og i dette tilfellet er søk og utvelgelse av data mye raskere enn med en flerdimensjonal konseptuell visning av en relasjonsdatabase, siden den flerdimensjonale databasen er denormalisert, inneholder pre- aggregerte indikatorer og gir optimal tilgang til de forespurte cellene

datainnhenting og gjenfinning er mye raskere enn med en flerdimensjonal konseptuell visning av en relasjonsdatabase - den gjennomsnittlige responstiden på et ad hoc-spørring ved bruk av en flerdimensjonal DBMS er vanligvis en til to størrelsesordener mindre enn i tilfellet med en relasjons-DBMS med et normalisert dataskjema

struktur og grensesnitt samsvarer best med strukturen til analytiske spørringer. Denne metoden er mer relatert til den mentale modellen til en person, siden analytikeren er vant til å operere med flate bord. Ved å lage en seksjon av en kube med et todimensjonalt plan i en eller annen retning, er det lett å oppnå den gjensidige avhengigheten av et hvilket som helst par av mengder med hensyn til det valgte målet. For eksempel, hvordan har kostnadene ved å produsere et produkt (mål) endret seg over tid (måling) i sammenheng med seksjoner, verksteder og produksjonsanlegg (en annen dimensjon)

flerdimensjonale DBMS takler enkelt oppgavene med å inkludere ulike innebygde funksjoner i informasjonsmodellen, mens de objektivt eksisterende begrensningene til SQL-språket gjør utførelsen av disse oppgavene på grunnlag av relasjonelle DBMS ganske vanskelig og noen ganger umulig.

MOLAP kan kun fungere med sine egne flerdimensjonale databaser og er basert på proprietære teknologier for flerdimensjonale DBMS, derfor er de de dyreste. Disse systemene gir en full syklus med OLAP-behandling og inkluderer enten, i tillegg til serverkomponenten, deres eget integrerte klientgrensesnitt, eller bruker eksterne regnearkprogrammer for å kommunisere med brukeren. For å vedlikeholde slike systemer kreves det en spesiell stab av ansatte for å installere, vedlikeholde systemet og danne datarepresentasjoner for sluttbrukere.

En annen ulempe med MOLAP-modeller er:

ikke tillat arbeid med store databaser. I dag er deres reelle grense 10-20 gigabyte. I tillegg, på grunn av denormalisering og tidligere utført aggregering, tilsvarer 20 gigabyte i en flerdimensjonal database som regel (ifølge Codd) 2,5-100 ganger mindre volum av de originale detaljerte dataene, det vil i beste fall flere gigabyte.

sammenlignet med relasjonelle, bruker de eksternt minne veldig ineffektivt. Cellene til hyperkuben er lagret i dem i form av logisk ordnede arrays (blokker med fast lengde), og det er en slik blokk som er den minste indekserte enheten. Selv om flerdimensjonale DBMS-er ikke lagrer blokker som ikke inneholder noen spesifikk verdi, løser dette bare delvis problemet. Fordi dataene er lagret i en ordnet form, slettes ikke alltid udefinerte verdier fullstendig, og selv da bare hvis dataene kan organiseres i størst mulig sammenhengende grupper ved å velge sorteringsrekkefølge. Imidlertid kan det hende at sorteringsrekkefølgen som oftest brukes i spørringer ikke samsvarer med rekkefølgen de skal sorteres i for å eliminere ikke-eksisterende verdier så mye som mulig. Når man designer en flerdimensjonal database, må man derfor ofte ofre enten ytelse (og dette er en av de første fordelene og hovedgrunnen til å velge en flerdimensjonal DBMS), eller eksternt minne (selv om, som nevnt, maksimal størrelse på en flerdimensjonal database). databasen er begrenset)

det er ingen enhetlige standarder for grensesnitt, beskrivelsesspråk og datamanipulering

støtter ikke datareplikering, som ofte brukes som en oppstartsmekanisme. Derfor er bruk av flerdimensjonal DBMS bare berettiget under følgende forhold:

volumet av innledende data for analyse er ikke for stort (ikke mer enn flere gigabyte), det vil si at nivået på dataaggregering er ganske høyt.

settet med informasjonsdimensjoner er stabilt (siden enhver endring i strukturen deres nesten alltid krever en fullstendig omstrukturering av hyperkuben).

systemets responstid på ad hoc-forespørsler er den mest kritiske parameteren.

krever omfattende bruk av komplekse innebygde funksjoner for å utføre kryssdimensjonale beregninger på celler i hyperkuben, inkludert muligheten til å skrive egendefinerte formler og funksjoner.

2. Praktisk del

2.1 Redegjørelse av problemet

2.1.1 Hensikten med å løse problemet

Ledelsen av Stroy-design LLC, som utfører aktiviteter knyttet til reparasjon av lokaler, ønsker å automatisere beregningene for å beregne kostnadene for arbeidet som utføres for raskt å kunne levere en faktura til kunden. Dette vil bidra til å redusere oppgjørstiden, unngå menneskelige feil og øke kundetilfredsheten med tjenestene som tilbys. Derfor ble det besluttet å beregne kostnadene for det utførte arbeidet og lage en faktura for betalingen, som skulle inneholde navnet på arbeidet, mengden utført arbeid, prisen per produksjonsenhet og kostnaden for arbeidet. Oppgaven som skal løses i MS Excel-programvaremiljøet på månedlig basis heter «Beregning av kostnad for utført arbeid».

Hensikten med å løse dette problemet er aktualiteten til beregninger av kostnadene for arbeid for rask levering av en detaljert faktura til klienter.

2.1.2 Problemtilstand

Legg inn driftsinformasjon fungerer som dokumentet "Beregning av kostnadene for utført arbeid", som inneholder detaljene: navnet på arbeidet, mengden utført arbeid, prisen per produksjonsenhet (rubler), kostnaden for arbeidet (rubler), de to siste detaljene må beregnes og beregnes. Basert på det opprettes følgende skjermskjema:

Navn arbeid	Enheter målinger	Volum utført virker		Pris fungerer, gni.
		Q i	C i	S i

Betinget permanent informasjon (referanse) fungerer som en prisliste for organisasjonen, som inneholder følgende detaljer (betinget form): navnet på arbeidet, prisen per produksjonsenhet (rubler). Basert på det opprettes følgende skjermskjema:

Pris liste

Jobbtittel	Enhetspris, gni.

Latinske bokstaver i tabellen indikerer elementene i de tilsvarende beregningsformlene.

Som et resultat du bør motta en faktura med følgende detaljer: navn på arbeid, pris per produksjonsenhet (rubler), volum utført arbeid, kostnad for arbeid (rubler), kontonummer (utfylles automatisk). Klientens fulle navn og dato legges inn manuelt. Informasjon er gitt i følgende dokumenter:

Strukturen til det resulterende dokumentet "Faktura"

	LLC "Stroyservice"
	KONTONR.
				Dato		20__
			Fullt navn på klienten
	№ p / s		Navn arbeid		Enheter målinger	Volum utført virker		Enhetspris, gni.	Pris fungerer, gni.
			Batteribytte		PCS.
			Bakgrunnsklistremerke		m 2
			Bytte ut rør
			Parkett på gulv		m 2
	TOTAL:								ΣS i
	mva:								N
	VERDI MED MVA:								SN
		Ch. regnskapsfører

I tillegg må informasjonen i tabellene for analyse presenteres i form av diagrammer.

Innen teknologi, organiser koblinger mellom tabeller for automatisk generering av fakturadokumentet ved å bruke funksjonene VLOOKUP eller LOOKUP.

2.2. Datamaskinmodell for å løse problemet

2.2.1. Informasjonsmodell for å løse problemet

Informasjonsmodellen som gjenspeiler forholdet mellom kilden og resulterende dokumenter er vist i fig. 2.

2.2.2. Analytisk modell for å løse problemet

For å få tak i dokumentet " Beregning av kostnad for utført
virker »Det er nødvendig å beregne følgende indikatorer:

kostnader for arbeid, rubler;


moms, gni .;


beløp inkludert mva, gni ..


Beregninger utføres i henhold til følgende formler:


S i = C i ∙ Q i ,


N = ΣS i ∙ 0,18 ,


SN = ΣS i + N,


hvor S i
- pris Jeg arbeidet; C i
- pris pr Jeg produksjonsenhet; Q jeg - begge utførte Jeg arbeidet; N- MVA;SN- Verdi med mva.


2.2.3. MS Excel problemløsningsteknologi


Løse problemet ved hjelp av MS Excel


Ring Excel:


trykk på "Start"-knappen;


velg kommandoen "Programmer" i hovedmenyen;


fra Microsoft Office-menyen velg MS Excel.

Gi nytt navn til "Ark 1" til "Prisliste":

velg kommandoen "Gi nytt navn" fra kontekstmenyen og trykk på venstre museknapp;


trykk på "Enter"-tasten.

Skriv inn overskriften til tabellen "Prisliste":

skriv "Prisliste" på tastaturet;


4. Formater tittelen:





Ris. 2. Et eksempel på valg av en gruppe celler


på verktøylinjen, i fanen "Hjem", velg delen "Justering" og klikk på knappen.


5. Formater cellene A2: B2 for lange overskrifter:


velg cellene A2: B2;


utfør "Juster"-kommandoen i "Formater celler"-delen av "Hjem"-menyen på verktøylinjen;


velg fanen "Alignment";


i gruppen med alternativer "Vis" setter du avkrysningsboksen for alternativet "pakke med ord" (fig. 3);





Ris. 3. Innstilling av orddeling av ord når du går inn i en celle med lange


overskrifter


klikk på "OK"-knappen.


6. Skriv inn i celle A2: B2 informasjonen vist i fig. 4.





Ris. 4. Navn på felt i tabellen "Prisliste".


7. Formater cellene A3: A8 for å skrive inn teksttegn:


velg cellene A3: A8;


på verktøylinjen, i "Hjem"-menyen, velg "Celler", hvor i "Format"-elementet, utfør kommandoen "Format celler";


velg fanen "Nummer";


velg "Tekst"-formatet (fig. 5);


klikk på "OK"-knappen.





Ris. 5. Valg av celleformat


8. Gjenta trinn 9 for celleområdet B3: B8, velg "Numerisk" format.


9. Angi de første dataene (fig. 6).





Ris. 6. Visning av "Prisliste"-tabellen


10. Gi et navn til cellegruppen:


velg cellene A3: B8;


velg kommandoen "Tildel navn" i "Definerte navn"-delen av "Formler"-menyen (fig. 7);





Ris. 7. Visning av "Opprett navn"-vinduet


klikk på "OK"-knappen.


11. Gi nytt navn til "Ark 2" til "Beregning av kostnadene for arbeid" (i likhet med trinnene på s. 2).


12. Lag en tabell "Beregning av kostnadene for utført arbeid" (ligner handlingene i paragrafene 3 - 7, 8) (fig. 8).





Ris. 8. Visning av tabellen "Beregning av kostnaden for arbeid"


13. Fyll ut kolonnene "Navn på arbeid" og "Pris per produksjonsenhet, gni.":


gjør celle A3 aktiv;


i "Data"-menyen, velg kommandoen "Datavalidering", i feltet "Datatype" som velger "Liste";


skriv inn en verdi i "Kilde"-feltet, uthev området A3: A8 i "Prisliste" (fig. 9);





Ris. 9. Sette opp listen over betalere


klikk på "OK"-knappen;


for å skrive inn navnet på en jobb fra listen i hver celle i kolonne A ("Jobbnavn"), gjør du celle A3 aktiv og, plasserer markøren på markøren i nedre høyre hjørne, venstreklikker og drar den til celle A6 (fig. 10);





Ris. 10. Visning av arket "Beregning av arbeidskostnad" ved oppsett av liste


i feltet "Velg en funksjon" trykk "VLOOKUP" (fig. 11);





Ris. 11. Visning av det første vinduet i funksjonsveiviseren


klikk på "OK"-knappen;


skriv inn navnet på jobben i "Search_value"-feltet ved å klikke på celle A3;


trykk enter";


skriv inn informasjon i "Tabell"-feltet;


bruk kommandoen "Bruk i formel" i "Formler"-menyen ved å velge "Sett inn navn";


velg "Navn:" "Prisliste" (fig. 12);





Ris. 12. Angi et matrisenavn som argument for en formel


klikk på "OK"-knappen;


trykk enter";


skriv inn informasjon - nummer 2 i "Column_number"-feltet;


skriv inn informasjonen - tallet 0 i feltet "Interval_view" (fig. 13);





Ris. 13. Visning av det andre vinduet i funksjonsveiviseren


Klikk på "OK"-knappen;


14. Fyll ut kolonnen "Omfang av utført arbeid".


15. Skriv inn navnene på jobbene i cellene A4: A6:


Gjør celle A4 aktiv;


Klikk på knappen ved siden av celle A4 og fra den foreslåtte listen velg navnet på arbeidet - Batteribytte, stk. Cell С4 - "Pris per produksjonsenhet, rubler." vil fylles ut automatisk (fig. 14);





Ris. 14. Automatisk fylling av prisen per produksjonsenhet etter navnet


fyll ut cellene A5: A6 på samme måte, cellene C5: C6 vil også fylles ut automatisk.


16. Fyll ut kolonnen "Arbeidskostnader, rubler"
tabeller "Beregning av kostnad for utført arbeid".
For dette:


skriv inn formelen = B3 * C3 i celle D3;


multipliser formelen som er angitt i celle D3 for de gjenværende cellene D4: D6 i denne kolonnen (ved hjelp av autofullføringsfunksjonen).


Dermed vil sløyfen bli utført, hvis kontrollparameter er linjenummeret.


17. Den ferdige tabellen ser slik ut (fig. 15).





Ris. 15. Resultat av utfylling av tabellen "Beregninger av arbeidskostnadene"


18. Gi nytt navn til "ark 3" til " Kryss av ”(I likhet med trinnene i punkt 2).


19. På "Konto"-regnearket oppretter du den nødvendige tabellen ved å følge de foregående avsnittene.


20. Bruk OPSLAKK-funksjonen () for å lage krysstabellkoblinger. Men før det, sorter verdiene i tabellen "Beregninger av kostnadene for utført arbeid" i stigende rekkefølge etter kolonnen "Navn på arbeidet". For dette:


velg celleområdet A2: D6;


velg elementet "Sortering og filtrering" på hovedsiden, og der "Egendefinert sortering";


i rullegardinvinduet velg "Sorter etter" "Navn på verk";


klikk på "OK"-knappen.


bruk kommandoen "Sett inn funksjon" i "Formler"-menyen;


i feltet "Velg en funksjon" trykk "VIS";


klikk på "OK"-knappen;


skriv inn navnet på jobben i feltet "Se etter_verdi" ved å klikke på celle C9;


trykk enter";


skriv inn informasjonen i Vector to View-feltet, nemlig ‘Beregn kostnaden for arbeid’!$ A $ 3: $ A $ 6;


trykk enter";


skriv inn informasjonen i feltet "Søkt vektor", nemlig 'Beregning av kostnaden for arbeid'!$ C $ 3: $ C $ 6;


trykk "Enter" (fig. 16);





Ris. 16. Visning av det andre vinduet i veiviseren for VIS-funksjonen


klikk på "OK"-knappen;


22. Gjenta trinnene som ligner på punkt 22 for cellene D9: D12, E9: E12.


23. Fyll ut "TOTAL"-kolonnen i tabellen som følger:


skriv inn i celle F13 formelen = SUM (F9: F12).


24. Fyll ut "MVA"-kolonnen. For å gjøre dette, skriv inn formelen = F13 * 0,18 i celle F14.


25. Fyll ut kolonnen "BELØP MED MVA". For å gjøre dette, skriv inn formelen = F13 + F14 i celle F15.


26. Som et resultat bør du få tabellen vist i fig. 17.





Ris. 17. Form for faktura for betaling av utført arbeid


27. For å analysere informasjon om kostnadene for hver type arbeid på den mottatte ordren:


gjør "Konto"-arket aktivt;


velg området C9: F12;


velg "Histogram"-kommandoen i "Charts"-delen av "Sett inn"-menyen;


velg ønsket type histogram;


gi nytt navn til histogrammet til "Kostnader for hver type arbeid" (fig. 18).





Ris. 18. Histogram "Kostnadene for hver type arbeid"


2.3. Resultater av et dataeksperiment og deres analyse


2.3.1. Resultater av et dataeksperiment


For å teste riktigheten av å løse problemet, vil vi fylle ut inngangsdokumentene, og deretter beregne resultatene.


Pris liste
Jobbtittel	Enhetspris, gni.
Baderstatning, stk.
Utskifting av rør, m
Tapetklistremerke, m2
Parkett på gulv, m2
Takkalking, m2

Beregning av kostnaden for utført arbeid
Jobbtittel	Omfang av utført arbeid	Enhetspris, gni.	Kostnader for arbeid, gni.
Utskifting av batterier, stk.			1000
Utskifting av rør, m
Tapetklistremerke, m2			1400
Parkett på gulv, m2			1200

	LLC "Stroy-design"
	KONTONR.
		Dato		. .20
		Fullt navn på klienten
	P / p nr.	Jobbtittel	Omfang av utført arbeid	Enhetspris, gni.		Kostnader for arbeid, gni.
		Utskifting av batterier, stk.				1000
		Tapetklistremerke, m2				1400
		Utskifting av rør, m
		Parkett på gulv, m2				1200
	TOTAL:					4560
	mva:					820,8
	VERDI MED MVA:					5380,8

Som et resultat av å løse problemet, faller listene som er oppnådd ved hjelp av datamaskinen sammen med testene.


2.3.2. Analyse av de oppnådde resultatene


Dermed lar dannelsen av det resulterende dokumentet (tabell) "Faktura" deg løse problemet - for å redusere tiden for å utføre beregninger av arbeidskostnadene, eliminere feil forårsaket av den menneskelige faktoren og øke graden av kundetilfredshet. Opprettelsen av forskjellige diagrammer (histogrammer, grafer) basert på disse tabellene ved hjelp av MS Excel gjør det ikke bare mulig å visuelt presentere resultatene av informasjonsbehandling for analyse for å ta beslutninger, men også for å raskt utføre manipulasjoner på området konstruksjonen deres til fordel for den mest praktiske presentasjonen av visualiseringsresultatene i henhold til de spesifiserte brukerparameterne (analytiker).


Hovedideene til moderne informasjonsteknologi er basert på konseptet om at data skal organiseres i databaser for å reflektere den virkelige verden i endring og møte brukernes informasjonsbehov. Disse databasene er opprettet og opererer under kontroll av spesielle programvaresystemer kalt databasestyringssystemer (DBMS).


Økningen i volumet og den strukturelle kompleksiteten til de lagrede dataene, utvidelsen av brukerkretsen av informasjonssystemer har ført til utbredt bruk av den mest praktiske og relativt lettfattelige relasjonelle (tabellformede) DBMS. For å gi samtidig tilgang til dataene til flere brukere, ofte plassert langt nok fra hverandre og fra lagringsstedet til databasene, er det opprettet nettverksflerbrukerversjoner av databasen basert på relasjonsstrukturen. I dem løses på en eller annen måte spesifikke problemer med parallelle prosesser, dataintegritet (riktighet) og sikkerhet, samt tilgangsautorisasjon.


DBMS skal gi tilgang til data til alle brukere, inkludert de som praktisk talt ikke har og (eller) ikke ønsker å vite om: den fysiske plasseringen av data og deres beskrivelser i minnet; søkemekanismer for de forespurte dataene; problemer som oppstår fra samtidig forespørsel om samme data fra mange brukere (applikasjonsprogrammer); måter å sikre databeskyttelse mot feil oppdateringer og (eller) uautorisert tilgang; holde databaser oppdatert og mange andre funksjoner i DBMS.


I dag er relasjonsdatabaser fortsatt de vanligste, på grunn av deres enkelhet og synlighet både i prosessen med opprettelse og på brukernivå.


Hovedfordelen med relasjonsdatabaser er kompatibilitet med det mest populære spørringsspråket SQL. Med en enkelt spørring på dette språket kan du slå sammen flere tabeller til en midlertidig tabell og kutte ut de nødvendige radene og kolonnene fra den (utvalg og projeksjon). Fordi tabellstrukturen til en relasjonsdatabase er intuitiv for brukere, er SQL enkel og lett å lære. Relasjonsmodellen har et solid teoretisk fundament som utviklingen og implementeringen av relasjonsdatabaser har vært basert på. I kjølvannet av populariteten forårsaket av suksessen til relasjonsmodellen, har SQL blitt det primære språket for relasjonsdatabaser.


I prosessen med å analysere informasjonen ovenfor, ble følgende mangler ved den vurderte databasemodellen avslørt: siden alle feltene i en tabell må inneholde et konstant antall felt av forhåndsbestemte typer, er det nødvendig å lage ytterligere tabeller som tar hensyn til den enkelte egenskapene til elementene ved hjelp av fremmednøkler. Denne tilnærmingen gjør det svært vanskelig å lage komplekse relasjoner i databasen; høy kompleksitet ved å manipulere informasjon og endre forbindelser.


I den praktiske delen ble MS Excel 2010-verktøy løst, oppgaven ble satt i forhold til den betingede virksomheten - selskapet Stroy-design LLC, som utfører aktiviteter knyttet til gjennomføring av arbeid med reparasjon av lokaler. Tabeller ble bygget etter gitte data i oppgaven. Beregningen av kostnadene for arbeid på den mottatte ordren er utført, beregningsdataene skal legges inn i tabellen. Linker mellom tabeller er organisert ved å bruke funksjonene VLOOKUP eller LOOKUP for automatisk å generere en faktura utstedt til klienten for å betale for utført arbeid. Utformet og fylt ut dokumentet "Faktura for utført arbeid." Resultatene av å beregne kostnadene for hver type arbeid på den mottatte ordren presenteres i en grafisk form.


Dataopplæringsprogram for faget informatikk "/ A.N. Romanov, V.S. Toroptsov, D.B. Grigorovich, L.A. Galkina, A. Yu. Artemiev, N.I. Lobova, K.E. Mikhailov, G.A. Zhukov, O.E. Krichevskaya, S.V. Yasenovsky, L.A. Vdovenko, B.E. Odintsov, G.A. Titorenko, G.D. Savichev og V.I. Gusev, S.E. Smirnov, V.I. Suvorov, G.V. Fedorova, G.B. Konyashin. - M .: VZFEI, 2000. Oppdatert 24.11.2010. - Tilgang med innlogging og passord.


Dataopplæringsprogram i faget "Informasjonssystemer i økonomi" / A.N. Romanov, V.S. Toroptsov, D.B. Grigorovich, L.A. Galkina, A.V. Mortvichev, B.E. Odintsov, G.A. Titorenko, L.A. Vdovenko, V.V. Braga, G.D. Savichev og V.I. Suvorov. - M .: VZFEI, 2005. Oppdatert 15.10.2010. - URL:. Tilgang med innlogging og passord.


DBMS KONSEPT OG TYPER DATABASEMODELLER INNSAMLING AV SOSIOLOGISKE DATA VED HJELP AV DATABASETEKNOLOGIER. OPPRETTELSE AV TABELLER OG DB-SKJEMAER 2013-11-05

I dette kapittelet fremhever og karakteriserer vi hovedklassene i DBMS.

Hovedklassifiseringen av DBMS er basert på databasemodellen som brukes. I henhold til dette kriteriet skilles flere klasser av DBMS: hierarkisk, nettverk, relasjonell, objekt og andre. Noen DBMS-er kan støtte flere datamodeller samtidig.

Tidligere DBMS-er, for eksempel hierarkiske og nettverksbaserte, har en trestruktur og er bygget på "Ancestor - Child"-prinsippet. Men slike systemer har allerede overlevd deres og brukes mindre og mindre.

Relasjonelle DBMS-er har erstattet hierarkiske og nettverksbaserte.

Kjennetegn ved relasjonell DBMS

De første teoretiske utviklingene innen relasjonell DBMS ble hentet tilbake på 70-tallet, samtidig dukket de første prototypene av relasjonell DBMS opp. I lang tid ble det ansett som umulig å oppnå effektiv implementering av slike systemer. Den gradvise akkumuleringen av metoder og algoritmer for å organisere og administrere relasjonsdatabaser førte imidlertid til at relasjonssystemer på midten av 80-tallet praktisk talt fjernet tidlige DBMS-er fra verdensmarkedet.

Den relasjonelle tilnærmingen til å organisere en DBMS forutsetter tilstedeværelsen av et sett med relasjoner (todimensjonale tabeller) sammenkoblet. En kobling i dette tilfellet er en assosiasjon av to eller flere relasjoner (tabeller). En database som ikke har koblinger mellom relasjoner har en svært begrenset struktur og kan ikke kalles relasjonell. Spørringer mot slike databaser returnerer en tabell som kan delta på nytt i neste spørring. Data i noen tabeller er, som vi sa, relatert til data i andre tabeller, derav navnet "relasjonell".

Den relasjonelle tilnærmingen til å bygge et DBMS har en rekke fordeler: A. Ya. Baidak, A. A. Bulgakov. Moderne DBMS og deres applikasjon innen kraftteknikk [Elektronisk ressurs]. - Tilgangsmodus: http:// masters. donntu.edu.ua/2010/etf/baydak/library/article2. htm. - Tittel fra skjermen:

Tilstedeværelsen av et lite sett med abstraksjoner som gjør det relativt enkelt å modellere de fleste vanlige fagområdene og tillater presise formelle definisjoner, samtidig som de forblir intuitive;

Tilstedeværelsen av et enkelt og samtidig kraftig matematisk apparat, hovedsakelig basert på settteori og matematisk logikk og gir et teoretisk grunnlag for en relasjonell tilnærming til organisering av databaser;

Mulighet for ikke-navigasjonsdatamanipulering uten behov for å kjenne den spesifikke fysiske organiseringen av databaser i eksternt minne.

Relasjonsmodellen har et strengt teoretisk fundament. Denne teorien bidro til opprettelsen av det deklarative SQL-språket, som nå har blitt standarden for å definere og manipulere relasjonsdatabaser. Andre styrker ved relasjonsmodellen er enkelhet, egnethet for online transaksjonsbehandlingssystemer (OLTP) og datauavhengighet. Imidlertid har spesielt relasjonsdatamodellen og relasjons-DBMS visse ulemper.

Den største ulempen med relasjonelle DBMS-er anses å være iboende begrenset bruk av disse systemene på områder som krever ganske komplekse datastrukturer. Et av hovedaspektene ved den tradisjonelle relasjonsdatamodellen er atomiteten (unikhet og udelelighet) til data som er lagret i skjæringspunktet mellom tabellrader og -kolonner. Denne regelen ble lagt i grunnlaget for relasjonsalgebra da den ble utviklet som en matematisk datamodell. I tillegg tillater ikke spesifisiteten til implementeringen av relasjonsmodellen å reflektere de reelle forbindelsene mellom objekter i det beskrevne fagområdet tilstrekkelig. Disse begrensningene hindrer i betydelig grad effektiv implementering av moderne applikasjoner, som allerede krever noe forskjellige tilnærminger til organisering av data.

Grunnprinsippet i relasjonsmodellen er å eliminere dupliserte felt og grupper gjennom en prosess som kalles normalisering. Flate normaliserte tabeller er allsidige, enkle å forstå og teoretisk nok til å representere data i ethvert fagområde. De er godt egnet for lagrings- og visningsapplikasjoner i tradisjonelle bransjer som bank- eller regnskapssystemer, men deres anvendelse i systemer basert på mer komplekse datastrukturer er ofte vanskelig. I utgangspunktet skyldes dette primitiviteten til datalagringsmekanismene som ligger til grunn for relasjonsmodellen Nikitin M. Er epoken med relasjonell DBMS over? [Elektronisk ressurs]. - Tilgangsmodus: http://www.cnews.ru/reviews/free/marketBD/articles/articles2. shtml. - Tittel fra skjermen.

I dag er velkjente produsenter av relasjonelle DBMS-er følgende - ORACLE, Informix, IBM (DB2), Sybase, Microsoft (MS SQL Server), Progress og andre. I sine produkter fokuserer DBMS-produsenter på å jobbe med ulike typer datamaskiner (fra stormaskiner til bærbare) og på ulike operativsystemer (OS). Produsenter av DBMS ignorerte heller ikke produkter som kjører på stasjonære datamaskiner, som dBase, FoxPro, Access og lignende. Disse DBMSene er designet for å fungere på en PC og løse lokale problemer på én PC eller en liten gruppe PC-er. Ofte brukes DBMS-data som et speilbilde av en liten del av et felles DBMS for å minimere de nødvendige maskinvare- og ressurskostnadene for å løse små oppgaver.

Ulike DBMS kjører på forskjellige operativsystemer og maskinvare. De mest kjente blant slike operativsystemer er UNIX, VAX, Solaris, Windows. Avhengig av mengden datalagring, antall brukere som får tilgang til dataene samtidig, kompleksiteten til oppgavene, brukes forskjellige DBMS-er på forskjellige plattformer. For eksempel lar Oracle DBMS på Unix installert på en multiprosessorserver løse problemer med å levere data til hundretusenvis av brukere. Ponomareva I.S. Databasestyringssystemer [Elektronisk ressurs]. - Tilgangsmodus: http:// mathmod. aspu.ru/images/File/Ponomareva/TM10_About%20BD. pdf. - S. 2.

For øyeblikket er de mest interessante DBMS-orientert til Windows-operativsystemet ved å bruke Intel-plattformen.