Federal Agency for Education
Statens utdanningsinstitusjon for høyere profesjonsutdanning
"CHELYABINSK STATE UNIVERSITY"
Kursarbeid
Database applikasjonsutvikling
Domeneanalyse
Beskrivelse av fagområdet og funksjoner til oppgavene som skal løses
I kursarbeidet, i samsvar med oppgaven, automatiseres aktivitetene til salgsavdelingen til bedriften "Russian Food".
Emnet automatisering er noen av jobbfunksjonene til salgsavdelingen. Salgsavdelingen har en plan for utgivelse av ferdige produkter utarbeidet i tre måneder. I samsvar med denne planen produserer verkstedene produkter, men den faktiske produksjonen avhenger av mange faktorer og kan avvike fra den planlagte. Salgsavdelingen mottar også butikkfakturaer, som reflekterer faktisk produksjon og levering av produkter til enkelte varehus.
Salgsavdelingens oppgave er å analysere gjennomføringen av planen for levering av produkter til lager. For å gjøre dette må du velge de planlagte og faktiske dataene for en viss periode for et bestemt lager og analysere faktaavviket fra planen.
Bedriften har 3 verksteder hvor produktene produseres. Utvalget av produkter er vist i tabellen.
Tabell 1.
Butikknr Butikknavn Produktnavn Minimum produksjonsenhet Pris pr enhet melk 3,5 % boks 50 stk 650,00 gni 1 melk melk 4,0 % kartong 50 stk 700,00 rub. kremboks 50 stykker1 200,00 gni. kokt pølsepakning 50 stk2 500,00 gni 2 pølse røkt pølsepakning 50 stk3 400,00 rub. pølsepakke med 50 stykker1 200,00 gni. hermetisert gjeddeboks med 50 bokser 670,00 gni 3 fisk kaviar svart boks 50 bokser 5 400,00 gni. rød boks kaviar 50 bokser 5 370,00 gni. Produkter utgitt av verksteder leveres til lager Tabell 2. Lagernummer Lagernavn 1 Lagernummer 12 Lagernummer 23 Lagernummer 3 Liste over input (primær) dokumenter. Følgende brukes som primære dokumenter for å løse dette problemet: produksjonsplan for verksteder liste over butikkfakturaer Verkstednummer Verkstedfakturanummer Innleveringsdato verksted faktura spesifikasjon Verkstednummer Verkstedfakturanummer Produktkode Antall Fagområdebegrensning. Når du utvikler et kursprosjekt, er følgende begrensninger tillatt: det ferdige produktet er tilordnet ett ferdigvarelager og kan produseres av flere verksteder. det ferdige produktet har kun én måleenhet. ett verksted kan produsere flere typer produkter. flere varer av ferdige produkter kan lagres i ett lager. produksjonen av ferdige produkter ved verkstedet er planlagt månedlig. det samme elementet kan planlegges for utgivelse i forskjellige måneder. En butikkfaktura for levering av ferdige produkter til lageret kan inneholde flere produktnavn, nummeret er unikt kun for én butikk. Formulering av problemet Organisatorisk og økonomisk essens av komplekset av oppgaver. Et av hovedproblemene ved bedriften er avviket mellom den planlagte produksjonsmengden, som dannes i samsvar med forespørsler fra kjøpere og den faktiske mengden produkter som sendes av butikkene til varehusene. For å løse dette problemet er det nødvendig å motta informasjon om tilgjengelighet, mangel på eller overskudd av produkter i varehus i forhold til planen i tide (umiddelbart). Overskudd forblir på lageret, holdbarheten kan overskrides, og illikvide eiendeler skapes. Beskrivelse av utdatainformasjonen Utdatainformasjonen vil bli presentert i form av et rapporteringsskjema. Analyse av gjennomføringen av planen for levering av produkter til lageret _________________ Måned Produktnavn Måleenhet Mengde Overskuddsplan Fakta For å få dette skjemaet brukes dataene til primærdokumentene: produktliste; liste over varehus; liste over verksteder; en plan for produksjon av produkter ved verksteder; liste over butikkfakturaer; Beskrivelse av inndatainformasjonen. Inndatainformasjon er delt inn i betinget konstant (referansebøker), beholder verdiene i lang tid, og endrer stadig, det vil si operasjonell regnskapsinformasjon. Betinget permanent informasjon inkluderer: liste over produserte produkter; liste over produksjonsverksteder; liste over varehus; referansemåleenheter. Operasjonell regnskapsinformasjon inkluderer: en plan for produksjon av produkter ved verksteder; liste over butikkfakturaer; spesifikasjon av butikkfakturaen. La oss presentere hoveddokumentene med detaljene i tabell 3: Antall p / p Dokumentnavn Detaljer 1 Liste over produserte produkter 1. Produktkode 2. Produktnavn. 3. Enhetskode. 4.Pris. 5. Lagernummer 3 Liste over varehus 1. Lagerkode. 2.Navn på lageret 2 Liste over verksteder 1. Kode for verkstedet. 2. Navn på verkstedet 4 Referansemåleenheter 1. Kode for måleenheten. 2. Navnet på måleenheten 5 Planen for butikkens produksjon av produkter 1. Butikkens nummer. 2. Utgivelsesmåned. 3. Produktkode. 4.Antall 6 Liste over butikkfakturaer 1. Butikknummer. 2. Nummer på butikkfakturaen. 3. Leveringsdato 7 Spesifikasjon av butikkfaktura 1. Nummer på butikk. 2. Nummer på butikkfakturaen. 3. Produktkode. 4. Mengde. Database design Tildeling av informasjonsobjekter En av de vanskeligste stadiene i databasedesignprosessen er utviklingen av tabeller, siden resultatene som databasen skal produsere (rapporter, utdataskjemaer osv.) ikke alltid gir et fullstendig bilde av strukturen til tabellen. Informasjonen i tabellen skal ikke dupliseres. Det skal ikke være repetisjoner mellom bordene. Når viss informasjon er lagret i bare én tabell, vil den bare måtte endres på ett sted. Dette gjør arbeidet mer effektivt, og eliminerer også muligheten for informasjonsmismatch i ulike tabeller. Hver tabell skal inneholde informasjon om kun ett emne. Informasjon om hvert emne er mye lettere å behandle hvis den finnes i tabeller uavhengig av hverandre. Hver tabell inneholder informasjon om et annet emne, og hvert felt i tabellen inneholder separat informasjon om emnet i tabellen For å implementere datatilkoblinger fra forskjellige tabeller, må hver tabell inneholde et felt eller et sett med felt som vil angi en individuell verdi for hver post i tabellen. Et slikt felt eller sett med felt kalles en primærnøkkel. Etter å ha distribuert dataene på tvers av tabellene og definert nøkkelfeltene, må du definere relasjonene mellom tabellene. Tabell 4 Informasjonsobjekter Informasjon obektSootvetstvuyuschy dokumentRekvizityKlyuchIzdeliyaSpisok produsert izdeliyKod izdeliyaDa Navn izdeliyaKod enhet izmereniyaTsena antall skladaTsehaSpisok tsehovNomer tsehaDa Navn tsehaSkladySpisok skladovNomer skladDaNaimenovanie skladaEdinitsa izmereniyaSpravochnik enhet izmereniyaKod enheter Unit izmereniyaDa Navn izmereniyaPlan vypuskaPlan utgivelsen produkter tsehamiNomer tsehaDaNomer mesyatsaDa kode izdeliyaDa KolichestvoTsehovye nakladnyeSpisok butikk nakladnyhNomer tsehaDa antall klan nakladnoyDa Dato sdachiSpetsifikatsii Spesifikasjon laug nakladnoyNomer tsehaDaNomer butikk fakturaJa ProduktkodeJa Antall MånedFor "Release plan"-objekt MånedsnummerJaMånedsnavn Informasjonslogisk modellering og bestemmelse av koblinger mellom informasjonsobjekter En informasjonslogisk modell er en datamodell som viser et emneområde i form av et sett med informasjonsobjekter og strukturelle koblinger mellom dem. Vår informasjonslogiske modell vil se slik ut: Figur 1. Infologisk modell Som følge av utviklingen av databasen ble det innhentet 8 informasjonsobjekter. La oss definere typen tilkobling i hvert par av disse inf. gjenstander. Måleenhet - Produkt Koblingstypen er 1-til-mange, siden flere elementer kan måles med én måleenhet, men hver gjenstand måles for øyeblikket med én måleenhet. Forbindelsen mellom disse objektene er i henhold til Unit code-attributtet. Lager - Produkt Koblingstypen er 1-til-mange, siden flere varer med ferdige produkter kan lagres på ett lager. Kommunikasjon - etter attributt Lagernummer. Produkter - Utgivelsesplan Relasjonstypen er 1-til-mange, ettersom én vare kan planlegges for utgivelse i forskjellige måneder, men hvert planlagt antall refererer til kun én vare i en gitt måned. Kommunikasjon via nødvendig produktkode. Måned - Utgivelsesplan Lenketypen er 1-til-mange, hver måned lages det en produksjonsplan. Kommunikasjon etter nødvendig nummer på måneden. Workshop - Utgivelsesplan Kommunikasjonstype 1 - for mange er ett verksted planlagt å bli utgitt i forskjellige måneder. Kommunikasjon via nødvendig butikknummer. Verksteder - Verkstedfakturaer Verksted - Spesifikasjoner Tilkoblingstypen er 1-til-mange, én butikk utsteder mange fakturaer. Kommunikasjon via nødvendig butikknummer. Verkstedfakturaer - Spesifikasjoner Lenketypen er 1-til-mange, én butikkfaktura kan inneholde flere stykklister. Kommunikasjon etter behov - Butikkfakturanummer og butikknummer. Produkt - Spesifikasjoner Lenketype 1 - for mange utstedes ett produkt mer enn én gang, men denne utstedte mengden refererer til kun ett produkt. Kommunikasjon via nødvendig produktkode. Logisk databasestruktur Den logiske strukturen til en relasjonsdatabase er en adekvat refleksjon av den innhentede informasjonslogiske modellen for fagområdet. Ingen ekstra transformasjoner er nødvendig for den kanoniske modellen. Hvert datamodellinformasjonsobjekt er kartlagt til en tilsvarende relasjonstabell. Strukturen til en relasjonstabell bestemmes av attributtene til det tilsvarende informasjonsobjektet, hvor hver kolonne (felt) tilsvarer en av attributtene. Nøkkelattributter danner en unik nøkkel for en relasjonstabell. For hver kolonne i tabellen er typen, datastørrelsen og andre egenskaper spesifisert. Topologien til dataskjemadesignet sammenfaller praktisk talt med topologien til den informasjonslogiske modellen. Som en del av dette kursarbeidet vil den logiske strukturen til databasen se slik ut (fig. 2.): Fig. 2. Logisk databasestruktur Databaseimplementering i Microsoft Access-miljø For å implementere den utformede databasen vil vi bruke et av de mest populære databasebehandlingssystemene for Windows Microsoft Access-operativsystemet. Denne DBMS er inkludert i den utbredte integrerte pakken til Microsoft Office og er fullt kompatibel med programmene i denne pakken. En stor fordel med MS Access er tilgjengeligheten av utviklingsverktøy for informasjonssystemer for brukere med ulike kvalifikasjoner: fra nybegynnere til profesjonelle. MS Access DBMS er fokusert på å jobbe med følgende objekter: Tabeller er hovedelementet i enhver relasjonsdatabase, de er designet for å definere og lagre data; Spørringer fungerer som kilder for å bygge andre spørringer, skjemaer og rapporter. Spørringer lar deg endre og analysere data. Den vanligste typen spørring, en utvalgsspørring, er et sett med regler som brukes til å velge data fra én eller flere relaterte tabeller. Resultatene av kjøringen av spørringen presenteres i form av en virtuell tabell. Skjemaer er et objekt primært designet for å legge inn data, vise dem på skjermen eller kontrollere driften av en applikasjon. Det er mulig å bruke skjemaer for å oppfylle brukerens krav til presentasjon av data fra spørringer eller tabeller, skjemaene kan også skrives ut. Rapporter er et middel til å organisere produksjonen av data for utskrift. Ved hjelp av rapporten er det mulig å vise nødvendig informasjon i ønsket form. Du kan forhåndsvise rapporten før utskrift. Datakilder for rapporter er tabeller og spørringer; Makroer - et objekt som er en strukturert beskrivelse av en eller flere handlinger som skal utføres av MS Access som svar på en spesifikk hendelse. Moduler er objekter som inneholder programmer skrevet i Visual Basic for Applications-språket (VBA). Som en del av oppgaven er det ikke nødvendig å lage makroer og moduler i den utformede databasen. Alle MS Access-objekter er plassert i én fil på disken. MS Access har et grensesnitt med flere vinduer, men det kan bare behandle én database om gangen. For å opprette en ny database, må du starte MS Access, velge "Ny database"-modus, skriv inn navnet på databasen og velg plasseringen på disken. Tabellene i den utformede databasen er informasjonsobjekter, feltene i tabellene er detaljene til informasjonsobjekter. For å fylle ut inndatainformasjonen, vil det være nødvendig å designe et brukergrensesnitt - skjemaer: skjemaet "Produkter" - for redigering av tabellen "Produkter"; Skjema "Utgivelsesplan" - for å korrigere planen for antall produserte produkter; "Verkstedfraktsedler"-skjemaet som kobler sammen "Verkstedfraktsedler"-tabellen og tabellen "Verkstedfraktsedler" avhengig av "Verkstedfraktsedler". For å implementere rapporten "Analyse av implementeringen av planen for levering av produkter til lageret", vil det være nok å utføre en forespørsel om valg av måneden (tabell "måned"), produktnavn (tabell "Produkter" ), måleenheter (tabell "Måleenhet"), mengder i henhold til planen (tabell "Produksjonsplan"), faktiske mengder (tabell "Spesifikasjoner"), med tillegg av en "overskudd"-kolonne med en fradragsformel. Opprette tabeller og dataskjema salg av applikasjonsdatabaser Det er flere moduser for å lage tabeller (tabellmodus, designer, tabellveiviser, importtabeller, lenke til tabeller fra andre databaser). Den mest allsidige måten å lage et bord på er å bruke designmodus. For å lage en tabell i denne modusen, må du definere tabellfeltene. Hvert felt er preget av et navn, datatype og egenskaper. Feltnavnet må ikke inneholde spesialtegn. Microsoft Access kan bruke følgende datatyper: Tekst - tjener til å lagre alfanumerisk informasjon. Feltlengden må ikke overstige 255 tegn; MEMO-felt - beregnet for lagring av alfanumerisk informasjon på opptil 65535 tegn; Numerisk - brukes for numeriske data involvert i beregninger; Dato / tid - dato og (eller) klokkeslett i området fra 100 til 9999; Monetær - brukes for pengeverdier og numeriske data brukt i matematiske beregninger, utført med en nøyaktighet på 15 sifre i hele og opptil 4 sifre i brøkdelen; Teller - tjener til å generere unike sekvensielt økende eller tilfeldige tall som automatisk legges inn i feltet når hver ny post legges til i tabellen. Verdiene til felt av typen teller kan ikke endres; Boolsk - beregnet på boolske verdier (Ja / Nei, Sant / Falskt). Den logiske feltlengden er 1 bit; OLE-objektfelt - ethvert objekt i binært format (Word-dokument, Excel-tabell, bilde, lydopptak) koblet til eller innebygd i en MS Access-tabell. Størrelsen på et slikt felt må ikke overstige 1 GB; Oppslagsveiviser - Oppretter et felt som ber deg velge verdier fra en liste, eller fra en kombinasjonsboks som inneholder et sett med konstante verdier eller verdier fra en annen tabell. Ved å velge dette alternativet fra en listeboks i en celle starter oppslagsveiviseren, som bestemmer feltets type. Feltegenskaper angis nederst i tabelldesignvinduet på fanen Generelt. Listen over egenskaper er forskjellig for hver datatype. La oss vurdere noen av dem: Feltstørrelse - begrenser feltlengden til det angitte antallet tegn; Format - angir formatet for datoer og tall; Antall desimaler - for monetære og numeriske felt, setter antall desimaler; Inndatamaske - for tekst- og datofelt, definerer malen i henhold til hvilke data skal legges inn i feltet; Indeksert felt - lar deg lage en indeks som vil tjene til å fremskynde søket og sorteringen av tabellen etter dette feltet. En indeks er en intern tjenestetabell som består av to kolonner: verdien av det indekserte feltet og tabellnummeret. Du kan angi følgende egenskaper for indekser: a) "Ja (treff er tillatt)" - det opprettes en indeks som inkluderer samsvarende feltverdier, b) "Ja (ingen samsvar er tillatt)" - en indeks opprettes basert på den unike verdi av feltet, c) "Nei" - ingen indeks er opprettet En tabell i MS Access inneholder vanligvis en primærnøkkel. For å lage en nøkkel, må du velge et felt i konstruktøren og tilordne det en nøkkel gjennom kontekstmenyen. Felt Datatype Feltstørrelse Primærnøkkel Enhet Kode Numerisk Langt heltall Ja Enhet Navn Tekst 50 Tabell "Produkter". Felt Datatype Feltstørrelse Primærnøkkel Varekode Numerisk langt heltall Ja Varenavn Tekst100 Enhetskode Numerisk langt heltall Pris Valuta-lagernummerNumerisk byte Lagerbord Felt Datatype Feltstørrelse Primærnøkkel Lagernummer Numerisk byte Ja Lagernavn Tekst 20 Månedstabell Felt Datatype Feltstørrelse Primærnøkkel Månedsnummer Numerisk heltall Ja (ingen samsvar tillatt) Månedsnavn Tekst 20 Verkstedbord Felt Datatype Feltstørrelse Primærnøkkel Butikknummer Numerisk byte Ja Butikknavn Tekst 30 Utgivelsesplan-tabell Feltdatatype FeltstørrelsePrimærnøkkelbutikknummerNumerisk ByteJa MånedNumberNumeriskHeltallJaProduktkodeNumerisk Langt heltallJaNumberNumeriskReelt (16) Verkstedfakturatabell Felt Datatype Feltstørrelse Primærnøkkel Butikknummer Numerisk byte Ja Butikkfakturanummer NumeriskLangt heltall Ja LeveringsdatoDato \ Tid- Tabell "Spesifikasjoner" Felt Datatype Feltstørrelse Primærnøkkel Butikknummer Numerisk byte Ja Butikkfakturanummer Numerisk Langt heltallJa VarekodeNumerisk Langt heltallJaNumberNumeriskGyldig (16) La oss lage et dataskjema i Microsoft Access: Fig. 3. Dataskjema Opprette et brukergrensesnitt Skjemaer er det primære middelet for å lage et brukergrensesnitt som gir den mest praktiske måten å presentere, vise, redigere data på og kontrollere fremdriften til en applikasjon. Hovedfunksjonene til skjemaer er datainndata, informasjonsutgang og redigering, programfremdriftskontroll, meldingsutgang, informasjonsutskrift. Det finnes følgende typer skjemaer: Normal - viser én oppføring av datakilden; Multi-side - designet for å fungere med en datakilde som har et stort antall felt; Bånd - viser flere poster av datakilden, praktisk for et lite antall felt; Popup - vises i forgrunnen på skjermen og lar deg jobbe med andre former; Eksklusiv - tillater ikke bytte til andre former før den er lukket; En slave er en god måte å representere data på "mange"-siden av et en-til-mange forhold, er innebygd i masterskjemaet og er alltid avhengig av det. Strukturelt består skjemaet av tre seksjoner – overskrift, notater og dataområder. Delene i skjemaet inneholder kontroller. Enhver kontroll kan plasseres på et skjema ved hjelp av verktøykassen, som vises i skjemaets designer. De mest brukte elementene: (inskripsjon) - tjener til å lage permanente inskripsjoner i skjemaet; (felt) - et element som viser verdien fra datakilden; (kombiboks) - designet for å lage rullegardinlister i skjemaet; (knapp) - designet for å lage kommandoknapper i form som utfører visse handlinger; (avmerkingsboks) - et element som lar deg aktivere eller deaktivere verdien til en parameter; (underskjema) - tjener til å bygge inn et underskjema i hovedskjemaet. Det er mer praktisk å lage et skjema ved hjelp av en veiviser. Det første trinnet er å velge datakilden og feltene for skjemaet. På det andre trinnet bør du spesifisere utseendet til det projiserte skjemaet. Det tredje trinnet er å velge stilen til skjemaet (bakgrunnsbilde for skjemaet, formatet på fonter og farger). På det siste trinnet, skriv inn navnet på skjemaet, der det vil bli lagret i databasen. Skjemaet som er opprettet ved hjelp av veiviseren, må fullføres i designmodus. Legg til de nødvendige etikettene, knappene, underskjemaene. Som en del av kursarbeidet ble følgende skjemaer laget: Ris. 4. Produkter. Fig. 5. Utgivelsesplan. Skjemaet "butikkfakturaer" inneholder underskjemaet "Spesifikasjoner" Fig. 6. Verkstedsfakturaer. Rapportimplementering Før du genererer en rapport, må du opprette en spørring. Spørringer er et viktig verktøy i ethvert databasestyringssystem. Hensikten med forespørsler er i beskrivelsen av forespørselstyper. Spørringer kan opprettes både i Query Wizard-modus (da må du velge type spørring), og i Query Designer. Det er fire typer spørringer i Microsoft Access: enkle utvalgsspørringer viser data fra én eller flere tabeller i en tabell; legge til en parameter (seleksjonsbetingelse) er tillatt; Kryssreferansespørringer samler inn data fra én eller flere tabeller i et regnearklignende format og brukes til å analysere dataene; legge til en parameter (seleksjonsbetingelse) er tillatt; Endringsforespørsler brukes til å lage nye tabeller fra søkeresultater og for å gjøre endringer (legge til, slette) i dataene til eksisterende tabeller; legge til en parameter (seleksjonsbetingelse) er tillatt; en spørring for å finne poster som ikke samsvarer med noen post i den underordnede tabellen. Ved hjelp av spørringer i spørringsveivisermodus (ved å velge den endelige rapporten for spørringen), er det mulig å utføre en beregning (sum, gjennomsnitt, minimum, maksimum) ved å bruke de valgte dataene. For å implementere rapporten "Analyse av implementeringen av planen for levering av produkter til lager nr. ___", vil det være nok å utføre en forespørsel for et utvalg av måneden (tabell "måned"), produktnavn (tabell " Produkter"), måleenheter (tabell "Måleenhet"), mengder etter plan (tabell "Utgivelsesplan"), faktiske mengder (tabell "Spesifikasjoner"), med tillegg av en kolonne "overskudd" med en subtraksjonsformel, samt med et utvalg av lagernummeret (tabell "lager") med en utvalgstilstand uten å vise dette lageret i den resulterende tabellen. For denne rapporten ble det opprettet en spørring ved å bruke konstruktøren: Fig. 8. Resultatet av spørringen. I henhold til forskjellig varemengde fra spesifikasjonen kan det ses at hermetikkgjedde ble levert til lageret både i juli og i september to ganger. Rapportgenerering Rapporter er den beste måten å presentere informasjon fra en database på som en papirkopi. De gir kraftige alternativer for gruppering og beregning av delsummer og delsummer for store datasett. Rapportene kan brukes til å generere vakkert utformede fakturaer, innkjøpsordrer, postetiketter, presentasjonsmateriell og andre dokumenter du kanskje trenger for å drive virksomheten din med suksess. Rapporten inneholder følgende områder: tittel - vises bare én gang i begynnelsen av rapporten; topptekst og bunntekst - gjentas på hvert ark i rapporten, brukes til å vise permanent eller periodisk informasjon (rapportdato, sidetall osv.); overskrifter og merknader for grupper - vises når gruppering utføres i rapporten i henholdsvis begynnelsen og slutten av hver gruppe. Opptil ti nivåer av gruppering kan opprettes i rapporten; dataområde - brukes til å legge inn informative rapportlinjer; rapportnotat - designet for å vise sammendragsinformasjon om rapporten som helhet, skrevet ut én gang på slutten av rapporten. Det er mer praktisk å lage en rapport, som et skjema, ved hjelp av en veiviser. Etter å ha opprettet en rapport, kan du endre strukturen i designmodus (korrigere og formatere kolonneoverskriftene til rapporten, legge til eller fjerne felt, osv.). Som et resultat av rapportens utførelse ble dens trykte form innhentet. Analyse av gjennomføringen av planen for levering av produkter til lager nr. 1, 2, 3 - Fig. 10-12. Feltet "butikkfakturanummer" ble lagt til for å vise at produktet kunne overleveres til lageret to ganger i måneden på to forskjellige fakturaer. Fig. 9. Rapportdesigner Fig. 10. Analyse av gjennomføring av plan for levering av produkter til lager nr. 1 Fig. 11. Analyse av gjennomføring av plan for levering av produkter til lager nr. 2 Fig. 12. Analyse av gjennomføring av plan for levering av produkter til lager nr. 3 Bibliografi Tarasov V.L. Arbeide med databaser i Access-miljøet, Tutorial / Nizhny State University, Nizhny Novgorod, 2005. Shekhtman V.E. Databaser, SQL Lærebok om fagene "Databaser", "Databaser og ekspertsystemer", "Moderne SQL programmeringsteknologi". / - NPI KemSU, Novokuznetsk, 2006. Andreev V.A., Tupikina E.N., Databasestyringssystemer (Microsoft Access), retningslinjer / FESAEU, Vladivostok, 2003. Veiskas D., Effektivt arbeid med TILGANG, studieveileder / SPb, 1996. Khomonenko A.F., Tsygankov V.M., Maltsev M.G. Databaser, lærebok for universiteter / Ed. prof. A.D. Khomonenko. - SPb .: KORONA-trykk, 2002.
Som nevnt ovenfor, setter riktig bruk av spesialiserte komponenter dem på samme ytelsesnivå som API-kallene til det valgte DBMS. Etter min mening er bruk av API berettiget i det sjeldne tilfellet når egenskapene til selv spesifikke komponenter for utvikling ikke er nok, selv om dette er ekstremt usannsynlig, eller hvis slike komponenter ikke er tilgjengelige for plattformen som utviklingen utføres for ( Sun Solaris). Oppretting av spørringer til databasen. Etter å ha valgt en strategi for tilgang til data og etter å ha bestemt oss for arkitekturen til applikasjonen, kan vi ta hensyn til hvordan vi skal bruke den. Den generelle tommelfingerregelen er at jo mindre data du ber om fra serveren, desto raskere kjører applikasjonen din. Selvfølgelig er det ikke rasjonelt å be serveren om mindre data enn brukeren ønsker å se om gangen, så det første spørsmålet bør være "hvilke data er nødvendig for hver modul i systemet?" Utviklere som flytter fra skrivebordsdatabaser må overvinne en tabelldrevet visning av databaser. InterBase inneholder utvilsomt tabeller. Men når du designer et program, ser du dem ikke, du ser bare resultatet av å utføre en SQL-spørring. Du kan selvfølgelig skrive en spørring som returnerer alle poster fra tabellen (i det minste synlig for en gitt transaksjon):
VELG * FRA SOME_TABLE
Men i de fleste tilfeller vil en slik spørring returnere betydelig mer data enn det som kreves for optimalt brukergrensesnitt og prosessering av forretningsprosesser. Forresten, en slik spørring bruker ikke så nyttige funksjoner i InterBase / Firebird som muligheten til å bli med (BLI MED) og sortere (ORDER BY) det resulterende datasettet.
Ber du om mindre data, får du mer fart. Du trenger kanskje ikke alle kolonnene i en tabell for å utføre visse oppgaver i et program. Faktisk bør du ikke bruke "*"-tegnet i utvalgte spørringer, det er bedre å bruke en direkte oppregning av felt. Denne tilnærmingen er basert på at selv om jeg trenger alle kolonnene i tabellen, trenger jeg ikke kolonnene i tabellen som vil bli lagt til i fremtiden når jeg fullfører denne delen av programmet. Å definere spesifikke kolonner i spørringen sikrer at jeg kun får de kolonnene jeg oppga i spørringen, selv om tabellstrukturen utvikler seg videre. På samme måte, selv om brukeren virkelig trenger alle postene fra tabellen uten unntak, trenger han ikke å se dem alle samtidig. Det kan være ekstremt upraktisk for en bruker å søke etter felt i midten av et datanett i en tabell med et over gjennomsnittet antall poster. For eksempel, hvis du har mer enn 100 poster i regnearket ditt, bør du allerede ha tenkt grundig på utformingen av søknaden din.
Hva koker det hele ned til? Her er tingen: jo mindre data du ber om og overfører, desto raskere kjører applikasjonen din, selv på tregere nettverk. Her er noen applikasjonsteknikker du kan bruke for å redusere SELECT-data.
Gi brukeren gode verktøy for å finne postene de er interessert i. Hvis listen er for lang til å vises i en enkelt sammenhengende form, kan du dele den opp i logiske sider, med faner med de første bokstavene fra A til Å. Hvis listene fortsatt er for lange i dette tilfellet, gi brukeren kraftige datafiltreringsverktøy for å begrense det resulterende settet med poster. For å implementere datainnhenting i applikasjonen din kan du bruke metodene du bruker for å finne nettsider. Når brukeren får presentert et sett med poster, selv om det er relativt lite, er det nok å bruke ett eller to nøkkelfelt for å danne et spørringsfilter. La applikasjonen ha et eget vindu eller en del av et vindu der brukeren kan se alle data på posten hvis han fant det han lette etter. Prøv også å bruke tabellsammenføyninger (JOINs) i spørringer i stedet for oppslagsfelt på skjemaer der det er mulig. Selv om det er mulig å optimalisere utførelsen av TDataset-metoden. Oppslag, selv denne forbedrede metoden vil ikke fungere raskere enn å slå sammen tabeller (JOIN) - det er ikke nødvendig å nevne arbeidet med den umodifiserte metoden i det hele tatt.
La oss lage en enkel databaseapplikasjon som viser informasjon fra "Turists"-tabellen og en registrering av "Turist Information"-tabellen fra en Microsoft Access-database knyttet til den gjeldende posten for Tourists-tabellen.
For å gjøre dette, la oss lage et tomt Windows-program. Miljø utseende
utviklingen er vist i figur 39.
Ris. 39. Tom søknad
I figur 39 er "Data"-komponentgruppen uthevet, som inneholder komponenter for tilgang til og manipulering av data.
Bindingen av databasedataene til skjemaet utføres av "Binding Source"-komponenten. La oss overføre det til skjemaet. Etter å ha plassert det på skjemaet, tar utviklingsmiljøet følgende form (fig. 40).
Ris. 40. Komponentbindende kilde på skjemaet
Komponenten er ikke visuell, så den vises i et ekstra panel. Hovedegenskapen til komponenten er DataSource-egenskapen, som peker til datakilden. Som standard er egenskapen tom, så du må angi verdien. Når denne egenskapen er valgt, vises følgende vindu i egenskapsvinduet (fig. 41).
Ris. 41. Liste over datakilder
Listen er for øyeblikket tom, så du må opprette en ny datakilde ved å velge kommandoen Legg til prosjektdatakilde for å opprette en ny datakilde og koble til den. Følgende dialogboks vises (fig. 42).
Ris. 42. Liste over datakilder
Denne dialogboksen gir følgende utvalg av datakilder:
Database - Database;
Tjeneste - En tjeneste er en slags tjeneste som gir data. Oftest er det en webtjeneste;
Objekt - Et objekt for å velge et objekt som skal generere data og objekter å jobbe med.
I vårt tilfelle må du velge elementet "Database". Et vindu for valg av datatilkobling vises (fig. 43).
Ris. 43. Velge en datatilkobling
Hensikten med denne dialogboksen er å lage en tilkoblingsstreng som vil beskrive tilkoblingsparametrene for ADO-motoren, for eksempel typen database, dens plassering, brukernavn, sikkerhetsfunksjoner, etc.
Rullegardinlisten i dialogboksen inneholder alle tidligere opprettede tilkoblinger. Hvis den nødvendige tilkoblingen ikke er på listen, bør du bruke knappen "Ny tilkobling". Ved å trykke på knappen vises følgende dialogboks (fig. 44).
I denne dialogen velger du type datakilde (i dette tilfellet Microsoft Access), navnet på databasen (i dette tilfellet navnet og plasseringen til databasefilen), brukernavnet og passordet som brukes for å koble til databasen. "Avansert"-knappen lar deg stille inn et stort antall parametere relatert til ulike detaljer om ADO-mekanismen. Ved å bruke "Test tilkobling"-knappen vil du sørge for at de angitte parameterne er riktige og at tilkoblingen fungerer.
Ris. 44. Opprette en ny tilkobling
Det siste trinnet i dialogboksen er å velge de tabellene eller andre databaseobjekter som kreves i denne datakilden. Valgvinduet er vist i figur 45.
Ris. 45. Velge de nødvendige tabellene
I dette vinduet er tabellene "Turister" og "Turistinformasjon" valgt. Siden det ikke ble opprettet andre objekter enn tabeller i databasen, vises kun tabeller i figur 45. Dette fullfører opprettelsen av datakilden. Når du klikker Fullfør, vises et datasett ved siden av BindingSource på skjemaet.
Nå må dataene som er koblet ovenfor vises på skjemaet. Den enkleste måten å vise data på er å bruke DataGridView-komponenten fra Data-komponentgruppen. Komponenten er visuell og ser slik ut på skjemaet (fig. 46).
Ris. 46. Komponent DataGridView
Komponentinnstillingsvinduet vises umiddelbart, som bestemmer dens evne til å redigere data: "Aktiver legge til", "Aktiver redigering", "Aktiver sletting"; muligheten til å endre rekkefølgen av kolonner: "Aktiver kolonneombestilling"; og også muligheten til å dokke i overordnet container.
For at komponenten skal vise data, må du velge en datakilde i nedtrekkslisten. Hvis du velger nedtrekkslisten, vises følgende dialogboks (fig. 47).
Ris. 47. Velge en datakilde for DataGridView
I dette tilfellet har vi valgt "Turister"-tabellen som datakilde. Dette valget endrer visningen som følger (fig. 48).
Ris. 48. Komponent DataGridView viser strukturen til tabellen
På figuren kan du se at det er en annen BindingSource-komponent og en TableAdapter-komponent som fungerer med turisttabellen. Vær oppmerksom på at ved design eller under utvikling, vises ikke data fra tabellen.
Nå må du vise dataene fra den tilknyttede turistinformasjonstabellen. For å gjøre dette, plasser en annen DataGridView-komponent på skjemaet og velg følgende som datakilde (fig. 49).
Ris. 49. Velge en datakilde for den andre DataGridView
Her er ikke datakilden "Turistinformasjon"-tabellen i seg selv, men den bindende kilden mellom "Turister" og "Turistinformasjon"-tabellene. Dette valget sikrer at bare de radene velges fra turistinformasjonstabellen som er knyttet til gjeldende rad i turisttabellen. Dette valget sikrer også at tilhørende data oppdateres og slettes riktig. Driften av den resulterende applikasjonen er vist i figur 50.
Ris. 50. Databaseapplikasjon på jobb
Det er upraktisk å navigere gjennom dataene ved hjelp av piltastene. Det er en BindingNavigator-komponent for å forenkle navigering gjennom dataene. Legg den på skjemaet (fig. 51).
Ris. 51. BindingNavigator-komponenten på skjemaet
Denne komponenten lar deg navigere mellom tabellposter, legge til og slette tabellrader. Funksjonaliteten og utseendet til komponenten kan tilpasses ettersom det er en ToolStripContainer-menylinje.
Egenskapen som definerer tabellen som skal navigeres gjennom, er BindingSource-egenskapen. Sett verdien av denne egenskapen til TouristBindingSource. I drift ser komponenten slik ut (fig. 52).
Ris. 52. BindingNavigator-komponenten på jobb
Redigering av data i cellene til DataGridView-komponenten med passende innstillinger er mulig, men upraktisk og ikke rasjonelt. Spesielt er det vanskelig å kontrollere angitte verdier for feil. Derfor, for "Turister"-tabellen, vil vi lage et skjermskjema som gjør det mulig å vise data i TextBox-komponentene og redigere dem. For å gjøre dette, plasser en panel-type beholder på skjemaet, og på den tre TextBox-komponenter som følger (fig. 53).
Ris. 53. Skjermpanel for redigering av poster i tabellen "Turister"
Nå er det nødvendig å binde TextBox-komponentene til de tilsvarende feltene i "Turister"-tabellen. For å gjøre dette, bruk egenskapen fra DataBindings-gruppen - Avansert, vist i figur 54.
Ris. 54. Egenskapen "Databindinger - avansert"
Hvis du velger denne egenskapen, vises dialogen vist i figur 55. Denne dialogboksen lar deg utføre ikke bare databinding, men også å angi en hendelse der dataene skal oppdateres, samt formatere dataene når de vises .
For den øverste TextBox-komponenten i rullegardinlisten Binding, velg datakilden "touristsBmdmgSource" og kildefeltet - "Etternavn". For de midtre og nederste tekstbokskomponentene, velg den samme datakilden og henholdsvis "Navn" og "Patronym"-feltene.
Den utviklede applikasjonen i drift ser ut som følger (fig. 56).
Ris. 55. Dialogboks for egenskapen "DataBindings - Advanced".
Ris. 56. Binding av data til visuelle komponenter
Men når endringer gjøres, forblir alle nye data bare på skjemaet. De er ikke lagret i databasen, og de vil selvsagt ikke være tilstede når applikasjonen kalles opp igjen. Dette er fordi dataene har blitt lastet inn i et DataSet, som er en kopi av tabellen i minnet. Alle handlinger utføres med denne kopien. For at endringene skal gjenspeiles i databasen, må du utføre oppdateringsmetoden for TableAdapter-klassen. I den utviklede applikasjonen er det derfor nødvendig å plassere Oppdater-knappen og skrive følgende programkode til Click-hendelsesbehandleren:
touristsTableAdapteгUpdate (bDTur_firmDataSet); info_about_touristsTableAdapter.Update (bDTur_firmDataSet);
Denne koden oppdaterer informasjonen i tabellene "Turister" og "Turistinformasjon" levert av datakilden. Merk at denne metoden er overbelastet, og dens varianter lar deg oppdatere både en enkelt rad i en tabell og en gruppe med rader.
30.04.2009 Alexey Kovyazin
Relasjonsdatabaser har penetrert nesten alle informasjonssystemer, og det ser ut til å ha blitt det mest etablerte IT-området, hvor lite kan oppfinnes, men virkeligheten er langt fra ideell.
Relasjonsdatabaser brukes i dag i nesten alle applikasjoner, fra innebygd i mobile og spesielle enheter, nettbaserte applikasjoner og slutter med bedriftsstyringssystemer. Inntrengningen av databaser i alle typer applikasjoner øker, og utviklere får stadig mer brukervennlige verktøy og tilnærminger. Man kan få inntrykk av at utviklerne av databaseapplikasjoner er det mest "velstilte" laget av programmerere som har verktøy for alle anledninger, men dette er langt fra tilfelle. Embarcadero Technologies kjøpte Borlands CodeGear-avdeling for utviklingsverktøy i 2008 for å kombinere profesjonell applikasjonsutvikling og designverktøy, utviklings- og databaseadministrasjonsverktøy for å løse både applikasjons- og databaseproblemer.
Kaotisk databasedesign
I den moderne programvareutviklingsindustrien er det en vanlig oppfatning at det er umulig å definere produktkrav før man starter et prosjekt, og derfor må utviklingen tilpasses deres konstante endring. Som et resultat har iterative prosesser dukket opp for å imøtekomme endrede krav, og refaktorisering av kildekode har blitt en integrert del av programvareutvikling. Hva skjer med databaser under iterativ utvikling? Endre krav tvinger deg til å justere databaseskjemaet, og som oftest skjer dette på en ugjennomsiktig måte, uten å analysere helhetsbildet og avhengighetene. Tabeller, felt, fremmednøkler og begrensninger opprettes og endres kaotisk, ingen overvåker referanseintegritet, og ingen kan si sikkert hvordan databasen ved iterasjon N skiller seg fra sin tilstand ved iterasjon N-1.
Faktisk utføres utviklingen av databaser i dag ved "patch"-metoden, som i dagene da "fossen"-prosessen dominerte - i begynnelsen av prosjektet er en viss modell av databasen "tegnet" basert på delkravene som er kjent for øyeblikket, så genereres en fysisk database, og deretter glemmes om modellen ved å gjøre endringer direkte i databasen. Ulempene med denne tilnærmingen er åpenbare: utveksling av kunnskap og forståelse av det store bildet er vanskelig, og endringer er ugjennomsiktige, de kan generere motsetninger i logikken og skjemaet til databasen, som vil forbli ukjent til det øyeblikket programvaresystemet settes i drift, noe som fører til svært store tap. Moderne databaseapplikasjonsutviklere trenger verktøy som er rettet mot iterativ databaseutvikling.
Den første og viktigste betingelsen for slik tilpasningsevne er tilstedeværelsen av fullverdige muligheter reverse engineering(omvendt utvikling, opprettelse av en databasemodell basert på analysen av dens fysiske skjema) og direkte engineering(forward engineering; opprettelse og modifikasjon av det fysiske databaseskjemaet basert på modellen). I praksis betyr dette at du ved hjelp av et designverktøy kan analysere skjemaet til en eksisterende database, lage en databasemodell basert på den, endre modellen og umiddelbart bruke endringene, noe som egentlig burde endre databaseskjemaet riktig og konsekvent, og ikke ødelegge eller forvirre det.
Den iterative tilnærmingen presser oss også til å lage undermodeller assosiert med en bestemt iterasjon. Å fremheve eventuelle enheter og deres attributter i en undermodell bidrar til å skille ansvarsområder både mellom ulike utviklere og mellom ulike iterasjoner, samtidig som man sikrer modellens generelle integritet. Naturligvis trenger du også muligheten til å sammenligne de to modellene, og ikke i form av SQL-skript, men på entitets- og attributtnivå, for å se og fullt ut forstå endringene som er gjort under iterasjonen og deres innvirkning på hele modellen.
Applikasjonsutviklere jobber sjelden alene, så de trenger samarbeidsverktøy, men hvis det er greit på applikasjonsutviklingssiden, støttes vanligvis ikke databasesamarbeid på verktøynivå på noen måte. Samarbeid innebærer nødvendigvis et versjonskontrollsystem: alle versjoner av modellene og det fysiske databaseskjemaet må lagres i ett enkelt depot, noe som gir muligheten til å rulle tilbake og sammenligne skjemaer helt fra begynnelsen av utviklingsprosessen.
Databaseutvikling er ikke mindre viktig enn applikasjonsutvikling, derfor er den strategiske utviklingsretningen å gi databaseutviklingsprosessen versjonskontroll og kravhåndtering, samt eksplisitt koble stadiene for modellering og modifisering av databaser til iterasjoner og endrede krav til en programvareprosjekt. For å løse de ovennevnte problemene og støtte den moderne iterative prosessen med databaseutvikling, tilbyr Embarcadero ER/Studio - et design-, analyse-, revers- og forward-engineeringsverktøy som lar deg kontrollere modellversjoner basert på sitt eget depot. Change Manager-verktøyet kan brukes til å kontrollere metadataendringer i fysiske databaser.
Disaggregert kode
Det mest kjente problemet som i stor grad bremser prosessen med å utvikle databaseapplikasjoner er behovet for å bruke forskjellige verktøy for å feilsøke applikasjonskode og SQL-kode i databasen.
La oss ta en titt på et enkelt eksempel. Anta at du utvikler en applikasjon i Delphi som kaller opp en lagret prosedyre i en Oracle DBMS. Ved å bruke Delphi-verktøy kan applikasjonsutvikleren trinn for trinn i feilsøkingsmodus frem til øyeblikket de kaller opp SQL-spørringen, se parameterne som er sendt til den lagrede prosedyren og resultatet som prosedyren vil returnere. Men hva skjer i prosedyren når den kjøres på databaseserveren? Det er umulig å bestemme dette fra utviklingsmiljøet til applikasjonen vår - for dette må du laste ned en applikasjon for SQL-utvikling, som har muligheten til å feilsøke lagrede prosedyrer, og som også viser planer for SQL-spørringer, statistikk over utførelse av dem, lar deg for å vise og endre databaseskjemaet. Du kan imidlertid ikke overføre parametere fra applikasjonsutviklingsmiljøet til SQL-utviklingsmiljøet, og du må kopiere dem manuelt ved å bytte fra ett vindu til et annet. Det er heller ikke mulig å se de detaljerte resultatene av å utføre SQL-kode i applikasjonsbyggeren, for eksempel spørringsplan, utførelsesstatistikk og så videre. Fremkomsten av tverrspråklig feilsøkingsteknologi har løst disse problemene.
Det første Embarcadero-produktet som støtter feilsøking på tvers av språk er RapidSQL Developer (tidligere PowerSQL), hvor den visuelle delen er basert på Eclipse-teknologi og lar deg derfor integrere i et hvilket som helst utviklingsmiljø basert på den (inkludert, selvfølgelig, JBuilder) og dynamisk tverrspråklig feilsøking. Nå, når den lagrede prosedyren kjøres på serveren, bytter utvikleren automatisk til et fullverdig SQL-feilsøkingsmiljø innenfor rammen av det samme verktøyet, som er i stand til å feilsøke både vanlige SQL-spørringer og lagrede prosedyrer. Utvikleren kan se de faktiske inngangsparametrene for spørringer og lagrede prosedyrer, og får muligheten til trinnvis feilsøking av SQL-koden. Å integrere RapidSQL Developer i Eclipse-kompatible utviklingsverktøy er det første trinnet i integrering av applikasjons- og databaseutvikling, og neste trinn er å gi lignende muligheter for Delphi, C ++ Builder og andre applikasjonsutviklingsverktøy fra Embarcadero.
Multi-plattform databaseapplikasjoner
En spesiell utfordring for utviklere er utviklingen av databaseapplikasjoner som må fungere med flere DBMS-er. For eksempel har banker og forsikringsselskaper vanligvis flere store kontorer og mange små filialer. De fleste forretningsprosessene knyttet til inntasting av driftsinformasjon og daglig arbeidsflyt er de samme på hovedkontoret og i filialene, men skalaene er forskjellige. Det naturlige ønsket om å spare på kostnadene for industrielle DBMS-lisenser for bruk i filialer fører til ideen om at det ville være greit å velge et annet DBMS uten å endre applikasjonen.
Erfarne databaseutviklere forstår godt essensen av problemene som oppstår her: forskjellen i datatyper og SQL-dialekter, fraværet av migrerings- og replikeringsmekanismer mellom forskjellige DBMS-er, kompleksiteten til migreringsverifisering gjør skriving og drift av applikasjoner for forskjellige DBMS-er til et mareritt. Fra siden av applikasjonsutviklingsverktøy prøver de å løse dette problemet ved å lage datatilgangsbiblioteker (dbExpress i Delphi og C ++ Builder, ADO og ADO.Net fra Microsoft), bygget på enhetlige arkitekturprinsipper og tilgangsmetoder, også som ved å bruke en rekke objektrelasjonelle "Wrappere" (Object Relation Mapping, ORM) over relasjonslogikken og strukturen til databasen, generere kildekode for arbeid med data basert på analysen av databaseskjemaet og bruke mekanismen til "adaptere" " for å implementere protokollen til et spesifikt DBMS. Blant de mest populære ORMene er Hibernate for Java og ActiveRecord i RubyOnRails, som gir et objektorientert grensesnitt til dataene som er lagret i DBMS. For Delphi er det et lignende prosjekt tiOPF, for C # - NHibernate.
Selvfølgelig kan bruken av slike universelle biblioteker og sett med komponenter betydelig redusere antall rutineoperasjoner i prosessen med multi-plattform databaseutvikling. Dette er imidlertid ikke nok når det gjelder applikasjoner som bruker mer komplekse databaser, der logikken som ligger i lagrede prosedyrer og triggere brukes aktivt - for implementering, feilsøking og testing kreves det separate verktøy, noen ganger helt forskjellige for forskjellige DBMS-er. For utvikling av databaseapplikasjoner på tvers av plattformer tilbyr Embarcadero RapidSQL-verktøyet.
Alle Embarcadero-databaseprodukter støtter flere plattformer og er basert på Thunderbolts skjemaanalyse- og databasestatistikkmotor. Hver støttet DBMS og hver spesifikke versjon av DBMS har tilsvarende kodegrener i Thunderbolt-kjernen, som lar deg kartlegge databaseskjemaet til den interne representasjonen i denne kjernen så nøyaktig som mulig og, viktigst av alt, for å utføre korrekte konverteringer mellom representasjonen og reelle databaser. Det er takket være Thunderbolt-kjernen at RapidSQL lar deg utvikle høykvalitets SQL-kode for alle støttede plattformer (Oracle, MS SQL, Sybase og ulike varianter av IBM DB2), og ER/Studio kan utføre nøyaktig reverse- og forward engineering av databasen skjemaer.
Hvis du utvikler en applikasjon for to eller flere plattformer eller migrerer en eksisterende applikasjon fra en plattform til en annen, vil RapidSQL gi alle nødvendige verktøy for å migrere skjema, brukere og tillatelser mellom forskjellige DBMS. Selvfølgelig konverterer RapidSQL ikke automatisk PL / SQL-prosedyrer til T-SQL - dette krever fortsatt en programmerer - men verktøyet gir et enkelt vindu for multiplattformutvikling, enhetlige redaktører for skjemaobjekter, brukere og deres rettigheter, og SQL feilsøking på alle støttede plattformer. ... I følge RapidSQL-brukere sparer dette opptil 70 % av tiden brukt på å migrere mellom forskjellige DBMS-er.
Endringer i data og diagrammer
Migrering fra ett DBMS til et annet er umulig uten bekreftelse. Hvem og hvordan kan garantere at dataene som overføres fra ett DBMS til et annet virkelig er identiske? Ulike klientbiblioteker, forskjellige datatyper og forskjellige kodinger gjør prosessen med å sammenligne data til en ikke-triviell oppgave.
I den virkelige verden slutter ikke arbeidet med utrullingen av applikasjonen og databasen - det er vedlikehold, nye versjoner av applikasjonens kjørbare filer og patcher til databasen vises. Hvordan kan du få garantier for at alle nødvendige oppdateringer er tatt i bruk i databasen og at hele programvarepakken vil fungere korrekt?
Embarcadero har utviklet Change Manager-verktøyet for å sammenligne data, skjemaer og databasekonfigurasjoner. Sammenligningen skjer innenfor rammen av en eller flere DBMS, med automatisk kontroll av samsvaret mellom datatyper og dannelsen av SQL-skript av forskjeller, som umiddelbart kan brukes for å bringe databasene i identisk tilstand. Metadatasammenligningsmodulen gir sammenligning av databaseskjemaer både mellom levende databaser og mellom database og SQL-skript og genererer et skript for metadataforskjeller. Denne funksjonaliteten kan brukes ikke bare til å sjekke databaser for samsvar med referansen, men også til å organisere en vanlig databaseoppdateringsprosess, samt for å se etter uautoriserte endringer, for eksempel i eksterne grener av en stor organisasjon. Situasjonen er lik med konfigurasjonsfiler - Change Manager sammenligner konfigurasjonsfiler og lar deg sikre at konfigurasjonen av distribuerte applikasjoner oppfyller kravene til denne programvaren.
Databaseapplikasjonsytelse
Hvor ofte ser vi applikasjoner som fungerer bra på små testvolumer med data, men som blir uakseptabelt trege på reelle volumer. Feilberegninger i krav, mangelfull testing i tidlige stadier, hastverk med å levere et prosjekt er alle kjente årsaker til dårlig applikasjonsutvikling. I dette tilfellet foreslår å engasjere seg i selvforbedring og fundamentalt forbedre kvaliteten på programmene, men alle utøvere vet at det noen ganger er umulig å omskrive et prosjekt, enten økonomisk eller, i noen tilfeller, politisk, og oppgaven å optimalisere ytelsen må løses på noen måte.
Hovedårsaken til ytelsesproblemer i databaseapplikasjoner ligger i uoptimaliserte SQL-spørringer og lagrede prosedyrer. Moderne databaseoptimalisatorer er kraftige nok, men de har også visse grenser for evner, og for å oppnå god ytelse, må du komponere SQL-spørringer korrekt, opprette (eller slette) ytterligere indekser, i visse tilfeller denormalisere databasen, overføre noen av logikken til triggere og lagrede prosedyrer.
Under utvikling kan spørringsoptimalisering utføres ved hjelp av RapidSQL, som inkluderer en SQL Profiler-modul som kan analysere planer og generere hint for å forbedre ytelsen til SQL-spørringer. Men hva hvis problemet oppstår under produksjon og ikke er lokalisert i en spesifikk SQL-spørring? Hvis ytelsen faller på et bestemt tidspunkt på dagen, eller, enda mer irriterende, problemet oppstår på en ekstern kopi av systemet, mens alt er bra på hovedserveren? Det er her DBOptimizer, et databaseprofileringsverktøy for Oracle, Microsoft SQL Server, Sybase og IBM DB2, er utviklet.
Når profileringsmodusen startes, samler DBOptimizer inn informasjon om databasen og kjøretiden, inkludert informasjon om CPU-belastningen og andre parametere til operativsystemet, og skriver den til profileringsøkten. Resultatet er en liste over spørringer utført ved et gitt tidsintervall, sortert etter forbrukte ressurser. For hver problematiske forespørsel kan du se planen, utførelsesstatistikken og andre detaljer. Dessuten viser DBOptimizer også hint og anbefalinger for å forbedre spørringen i forhold til spesifikke DBMS.
Verktøykasse
Alle de nevnte verktøyene brukes, mens de løser problemer, på forskjellige stadier i databaseutviklingens livssyklus. Det er ganske upraktisk og kostbart å beholde et dusin applikasjoner for alle anledninger som kanskje eller ikke er nødvendig under design, utvikling, migrering, optimalisering og drift av databaser.
Utgitt i februar 2009, det allsidige Emdacadero All-Access-verktøysettet inkluderer de essensielle verktøyene for alle stadier av databaseapplikasjonsutvikling, fra ER / Studio til DBOptimizer, fra Delphi og C ++ Builder til DBArtisan. Den beste måten å beskrive All-Access på er sammenligningen med verktøykassen som enhver ivrig eier har hjemme. Kanskje ikke alt verktøy brukes hver dag, men en justerbar skiftenøkkel bør alltid være tilgjengelig i tilfelle en lekkasje.
All-Access pålegger ikke databaseprogrammerere eller arkitekter andre roller, men gir et universelt verktøysett som passer for alle roller iosessen, fra arkitekt til tester; tilbyr alle medlemmer av utviklingsteamet verktøy for alle stadier av databaseutvikling, samt et sett med høyt spesialiserte verktøy for å optimalisere databaser (DBOptimizer) og applikasjoner (JOptimizer) for å "utvide" flaskehalser. Pakken støtter flere DBMS, noe som gir kostnadsbesparelser.
De tekniske forskjellene mellom objektorienterte og relasjonelle databaseteknologier har resultert i kulturelle forskjeller som fortsatt skiller datahåndteringsfellesskapet fra utviklingsfellesskapet. Hva skal man gjøre videre med dette?
