hjem › Navigatører › BD bilservice. Last ned tilgangsdatabase Biltjeneste. Funksjoner utført av databasen

BD bilservice. Last ned tilgangsdatabase Biltjeneste. Funksjoner utført av databasen

Opprettingsteknologi Database "Bilservice"

For å lage en database ble målene og målene for Autoservice-databasen satt:

? sikre kundetilfredshet med både tjenesten og firmaet;
? gi beste service nær
? garantireparasjon av solgte nye og brukte biler;
? kommersielt forebyggende vedlikehold (justeringer osv.);
? kommersiell rehabiliteringstjeneste (reparasjon);
? reparasjon av brukte komponenter og sammenstillinger for lager av reproduserte reservedeler.

? Mennesker,
? materialer,
? datamaskiner,
? maskiner,
? bygning.

Den utviklede og opprettede databasen "Car Service" er et sett med sammenkoblede komponenter og viser ulike områder innen bilreparasjon.

Figur 14. Database "Bilservice"

Systemet er delt inn i to delsystemer og en utvidelse:

? Reparasjon av den tekniske delen av bilen.
? Utvidelse - reparasjon av bilinnredning.

Hovedsystemet "Reparasjon av den tekniske delen av bilen" består av fire tabeller (se fig. 15):

« Rekkefølge"- inkludert nødvendig informasjon om bestillingen for reparasjon og diagnostikk av bilen, det vil si:

? Bil.
? Eieren.
? Grunnen til å kontakte bensinstasjonen.

« Reparere"- en tabell som beskriver prosessen med å reparere de tekniske delene av bilen, nemlig delene som må repareres i nær fremtid. Denne tabellen inkluderer elementene:

? Motorreparasjon.
? Reparasjon av sjekkpunkt.
? Reparasjon av chassis.
? Reparasjon av drivstoffsystem.

Figur 15. Pålegg om reparasjon av tekniske deler

Tabell " Diagnostikk', assosiert med ' rekkefølge» og tildeler biler for diagnostikk av visse deler av bilen, dvs. motor, girkasse, chassis og drivstoffsystem.

IN " Diagnostikk» lagre informasjon om biler som trenger diagnostikk av en bestemt del.

? Motordiagnostikk.
? Sjekkpunktdiagnostikk.
? Chassisdiagnostikk.
? Drivstoffsystemdiagnostikk.

Hoved system virker på basis «Cascading modeller" Og refererer på standard GOST 21624 -76

GOST 18507 -73

Driften av systemet kommer fra innsamling av informasjon om bestillingen, deretter finner diagnostikk sted, som bestemmer behovet for reparasjon av maskinen. Hver etappe (unntatt den første) kan ikke begynne før den neste er fullført, bortsett fra hvis bilen ikke trenger reparasjoner.

Delsystemet IT-service ble opprettet for å gi garanti for reparasjon, håndtering av et garantikrav og kjøp av reservedeler for reparasjoner.

1) å sende inn et krav,
2) utstede en garanti,
3) bestilling av reservedeler, og inkluderer 11 bord, hvorav ett er felles for IT-tjenesten. (se fig. 16).

Figur 16. IT-tjeneste

IT-tjeneste - deler hele tjenesten inn i 3 deler:

? Garantikrav,
? utstede en garanti,
? reservedelsbestilling.

Data 1 og 2 - inneholder informasjon om kunder.

Kvittering 1 - tabellen inneholder data om behandlingstidspunkt og prisen på utførte tjenester.

Årsak til kontakt - en tabell som inneholder informasjon om årsaken til å kontakte servicestasjonen under garantien. Det har en sammenheng med tabellene: enighet av SRT 1 og Utfall 1, hvor data om henholdsvis SRTs samsvar med kravet og muligheten for å løse problemet noteres.

Utvidelsen representerer en slags økning i bilreparasjonstjenester. Nå har systemet karosserireparasjon og innvendig reparasjon, som også håndteres av bensinstasjonen.

Utvidelsesdelsystemet består av to tabeller og påvirker to tabeller fra hovedsystemet. (se fig. 17)

Figur 17. Tilbygg

Tabellene "karosserireparasjon og innvendig reparasjon" inneholder informasjon om typer tjenester.

Karosseri reparasjon:

? Utskifting av deler.
? Kitt.
? Maleri.
? Lakkering.
? Polering.

Innvendig reparasjon:

? Utskifting av komponenter.
? Reparasjon av komponenter.

Fra disse tabellene følger koblingene med tabellen " Pris» for å fastsette priser for tjenester.

Funksjonell:

? bestillinger av antrekk,
? arbeid,
? tjenester,
? brigade,
? normtimer.

Databaseressurser:

? Mennesker,
? utstyr,
? materialer,
? datamaskiner,
? maskiner,
? bygning.

Kaskademodellen, vist i figur 18, sørger for sekvensiell utførelse av alle stadier av prosjektet i en strengt fastsatt rekkefølge. Overgangen til neste trinn betyr fullstendig fullføring av arbeidet på forrige trinn.

Dette er representert i databasen slik:

? ta imot bestillinger på reparasjoner
? Bildiagnostikk,
? bilreparasjon,
? frigjøring av bilen fra bensinstasjonen.

Figur 18. Databasemodell

Analysefase

Her er søknaden om bilreparasjon på bensinstasjonen. Kunden fyller ut et dokument der kunden angir hvilken tjeneste han trenger.

Designfase

På dette stadiet sendes bilen til diagnostikk, som bestemmer årsaken til bilhavariet. I fremtiden, etter kundens valg, sendes maskinen til reparasjon.

Implementerings- og implementeringsfase

I denne fasen utføres det reparasjoner på de delene av bilen som i henhold til resultatet av diagnostikken må repareres eller skiftes ut. Også, uten noen kontroller, på dette stadiet, kan utsiden av bilen og interiøret repareres.

Vedlikeholdsfase

På dette stadiet utstedes en garanti for reparasjoner og en beregning av midlene som ble brukt på diagnose og reparasjon av bilen, hvoretter bilen returneres til eieren.

Egenskaper til systemet

Integrerbarhet- systemet er integrerbart, da det har mulighet til å samhandle med ulike banker (betaling for tjenester gjennom disse bankene), med et skatteselskap (salg av reservedeler utenfor regionen). Systemet er også knyttet til ulike bilforhandlere (i henhold til kontrakten) og forsikringsselskaper som forsikrer selve biltjenesten, samt selskapet der reservedeler kjøpes.

Delbarhet- systemet består av mange delsystemer som utfører visse funksjoner og har mulighet til å fungere offline.

Integritet- til tross for at systemet er delbart, når det er fullt operativt, vil det ikke fungere hvis funksjonaliteten til et av undersystemene blir forstyrret.

Strukturalitet- fordeling etter nivåer og hierarkier av systemelementer, dvs. systemet vil ikke kunne fortsette å fungere hvis ett av trinnene hoppes over (uten garanti vil kunden ikke kunne sende inn et krav til bensinstasjonen).

Standarder

GOST 21624 -76 - denne standarden etablerer krav til produkter for å sikre et gitt nivå av operativ produksjonsevne (ET) og vedlikeholdbarhet (RP), samt verdiene for ET- og RP-indikatorer gitt av GOST 20334-81, for bilprodukter - firehjulsdrevne og delvis drevne kjøretøy (lastebiler, personbiler og busser), tilhengere og semitrailere (heretter - produkter).

GOST 18507 -73 - denne standarden gjelder for busser og personbiler (heretter kalt biler) og etablerer metoder for deres kontrolltester etter større reparasjoner utført av bilreparasjonsbedrifter.

Standarden gjelder ikke for biler, hvis overhaling ble utført på ordre fra individuelle eiere.

Terms of Reference

1. Lag en felles database over alle tjenester på bensinstasjonen for en bestemt bil.

Figur 19. Generelt grunnlag for alle tjenester på bensinstasjoner

2. Data om nødvendige verktøy og materialer.

Figur 20. Data om verktøy og materialer

3. Koblinger til tredjeparts systemer.

Figur 21. Tredjepartssystemer

Figur 22. Autosentrer

Figur 23. Forsikringsselskaper

Figur 24. Assurandørers felt

4. Kommentarer til kvaliteten på tjenesten.

Figur 25. Kommentarer

Figur 26. Besøksanmeldelser

Figur 27. Anmeldelser

I løpet av arbeidet ble det opprettet en database i MS Access-databasestyringssystemet. Arbeidet viser en steg-for-steg-teknologi for å lage en database. Et eksempel på databasen "Bilservice" er gitt. Denne basen ble testet på bensinstasjonen. Systemet er testet. I løpet av arbeidet ble det gjort justeringer og den endelige versjonen av Autoservice-databasen ble presentert i arbeidet.

Det er nødvendig å opprette en databasetilgang "Auto service"

Ris. 1 Hovedknappformen til den ferdige databasen "Bilservice"

Skjema "Eiere" med underskjema "Biler"

Ris. 2 Skjema "Biler"

Skjema "Ansatte"

Ris. 4 Skjema "Service"

Ris. 5 Forespørsler side

Spørsmålet "Grupper etter jobber og ansatte"

Forespørsel "ved navn på mekanikeren"

Be om "Søk etter registreringsnummer"

Ris. 6 rapporter

Rapport «Gruppering etter jobber og ansatte»

Fig.7 Rapport "Søk etter skilt"

Ris. 8 Rapporter "Med navnet på mekanikeren"

Ris. 9 Dataskjemaet til den ferdige databasen "Bilservice" viser relasjonene til tabellene: Eiere, Biler, Service, Jobbkategori, Ansatte.

Strukturen til tabellen "Biler": tilstand. nummer, merke, eier.

Strukturen til "Eiere"-tabellen: eiernummer, fullt navn, mobiltelefon, førerkortnummer.

Strukturen til "Service"-tabellen: servicenummer, bil, arbeidskategori, ordreberedskapsdato, ansatt.

Strukturen til tabellen "Ansatte": ansattnummer, mobiltelefon, adresse, fullt navn.

eller her:

Last ned databaserapport fra skjermskjemaer gratis

Omtrentlig pris 763 rubler.

Den nøyaktige prisen avhenger av betalingsmåten.

Tilgang til databasebetalingsmetoder: WebMoney, betalingsterminaler, russisk post, QIWI, Beeline, MTC, Megafon, debet- eller kredittkort, WeChat Pay, Alipay (Kina), UnionPay, Yandex.Money, gavekort og andre.

Last ned Access-databaser for lignende emner:

databasetilgang Biltjeneste 2
Utforming av fakturaer for betaling i en biltjeneste
Regnskap for biler i et transportfirma.
ATP (motortransportfirma).
ATP 2007 (motortransportfirma)
Bilverksteder
«Regnskap for drift Kjøretøy»
"Regnskap for trafikkulykker"
Registrering av bilforbrytere i trafikkpolitiet.
"Regnskap for trafikkbrudd"
"Utskifting av bildeler på bensinstasjonen"
Bytransport
"Salg av flybilletter"
"Busstasjon"
"Bilutleie"
Leiebil 2
kjøreskole
Reservedelsfirma
bilutstillingslokale
Regnskap for avskrivning av kjøretøy etter MOT og grupper av kjøretøy
Taxi
Personbilbedrift
Minibuss rutetabell
Regnskap for veitransport etter bilmerker

Nøkkelord: databasenedlasting; database program; database; kursdatabase; last ned tilgangsdatabase; adgang; klar tilgang database; databaser i tilgang; eksempel på tilgang til database; opprette en database i tilgang; eksempler på tilgangsdatabaser; opprette en database i tilgang; basetilgang; forespørsler om tilgang; tilgang til rapporter; tilgang tabeller; makroer i tilgang; tilgang til kurs; eksempler på databasetilgang; tilgangsskjemaer; Database microsoft tilgang; kjøpe en database; opprettelse av database; database eksempler; laste ned database; kursarbeid på DBMS; database eksempler; fullført semesteroppgavedatabase. Kursdatabasen "Autoservice" ble opprettet i access 2010 og konvertert til access 2003, så den vil åpne i access 2003, 2007, 2010.

Det er nødvendig å opprette en databasetilgang "Autoservice". Hovedknappformen til den ferdige databasen "Bilservice". Skjemaet "Eiere" med underskjemaet "Biler". Skjema "Biler". Skjema "Kategori av arbeid". Skjema "Ansatte". Tjenesteskjema. Forespørselsside. Spørsmål "Gruppering etter jobber og ansatte". Forespørsel "Med navnet på mekanikeren." Be om "Søk etter registreringsnummer". Rapport «Gruppering etter jobber og ansatte». Rapporter "Med navnet på mekanikeren." Rapporter "Med navnet på mekanikeren." Dataskjemaet til den ferdige databasen "Bilservice" viser relasjonene til tabellene: Eiere, Biler, Service, Jobbkategori, Ansatte. Strukturen til tabellen "Biler": tilstand. nummer, merke, eier. Strukturen til "Eiere"-tabellen: eiernummer, fullt navn, mobiltelefon, førerkortnummer. Strukturen til tabellen "Kategori av arbeid": kode for arbeid, navn på arbeid, beskrivelse, kostnad for arbeid. Strukturen til "Service"-tabellen: servicenummer, bil, arbeidskategori, ordreberedskapsdato, ansatt. Strukturen til tabellen "Ansatte": ansattnummer, mobiltelefon, adresse, fullt navn. Strukturen til «Grupper etter jobber og ansatte»-spørringen i designmodus. Strukturen til spørringen "Med navnet på mekanikeren" i designmodus. Strukturen til søket "Søk etter nummerskilt" i designmodus. Makroer i designmodus.

Innledning 3
SEKSJON 1. Databaseutvikling 4

DEL 2. Modellering av datastrukturer 7
2.1. Utvikling av en konseptuell databasemodell 7
2.2. Utvikling av en logisk datamodell 9
2.3. Konvertering av en enhet-relasjonsmodell til en relasjonsmodell
datamodell 10
SEKSJON 3. Databasedesign 12
3.1. Utvikling av tabeller 12
3.2. Utforme dataregistreringsskjemaer 17
3.3. Utvikle databasespørringer 21
3.4. Rapportutvikling 27
KONKLUSJON 30
REFERANSER 31
VEDLEGG 32

INTRODUKSJON

Til dags dato har utformingen av databaser (heretter referert til som DB) blitt viktig for mange organisasjoner som bruker datateknologi for å øke produktiviteten i arbeidet sitt. Databaser har blitt grunnlaget for informasjonssystemer, og bruken av dem er i ferd med å bli en integrert del av driften til enhver bedrift.
gjenstand semesteroppgave er studiet aver.
Emnet for kursarbeidet er studiet av prinsippene for utvikling av relasjonsdatabaser på eksemplet med å designe og lage en database "Autoservice".
Formålet med databasedesign er å vise prosessen med reparasjonsaktiviteter til en liten bedrift
For å nå dette målet ble følgende oppgaver satt:

Det finnes mange forskjellige informasjonskilder angående relasjonsdatabasedesign og -applikasjon. Av alle de foreslåtte ressursene ble de valgt ut som er egnet for utforming av databaser i OpenOffice.org Base-miljøet. Så for eksempel dekker bøkene de grunnleggende teknikkene og prinsippene for å arbeide og lage databaser ved å bruke Base, som er en del av OpenOffice.org. Kildene gir grunnleggende informasjon om å lage tabeller, skjemaer, spørringer og rapporter. Bøkene beskriver retningslinjer for utforming og implementering av databaser.

SEKSJON 1. Databaseutvikling

Denne databasen er beregnet på organisasjoner som er engasjert i alle typer bilvedlikeholdstjenester.
Hovedfunksjonene til databasen er knyttet til regnskap for alle biler som noen gang har vært i en biltjeneste, lagring av fullstendig informasjon om hver bil (merke, serie og teknisk passnummer, chassisnummer og motornummer, farge, produksjonsår, etc.). ).
Databasen bør også lagre informasjon om hver eier som minst én gang benyttet tjenestene til en biltjeneste. Det skal være mulig å lagre ikke bare den grunnleggende og mest nødvendige informasjonen, men også notater, avklaringer, beskrivelser og tekniske data. egenskaper ved installerte reservedeler og mye annen nyttig informasjon.
Bilserviceadministrasjonen kan kreve følgende data:

DBMS-operatøren kan gjøre følgende endringer:

Rapportene må gi mulighet for å utstede et sertifikat for funksjonsfeil i bilen til denne eieren og en rapport om arbeidet til biltjenesten (antall biler som repareres, navnet på den ansatte som reparerte dem).

Autoservice-databasen er utviklet for administratorer og bilservicemedarbeidere som mottar og behandler bestillinger på bilreparasjoner og vedlikehold.
Fagområdet i oppgaven er data om funksjonsfeil, bileiere og bilservicearbeidere.
Det utviklede informasjonssystemet skal utføre følgende funksjoner:

Utdata i form av rapporter:

Følgende krav stilles til databasen som utvikles: dataintegritet, ingen duplisering, ingen mange-til-mange-relasjoner, ingen rekursive lenker, ingen koblinger med attributter, ingen flere attributter.
Kravene til informasjonen i databasen er:
betydning, fullstendighet, pålitelighet, forståelighet, effektivitet.
Denne representasjonen øker brukervennligheten til databasen, i dette tilfellet vil inntasting av informasjon reduseres til å velge nødvendig informasjon fra listen, der det er mulig, noe som sikkert vil øke hastigheten på å legge inn informasjon og bidra til å unngå feil inntasting av parametere.
Som et resultat av opprettelsen og implementeringen av denne databasen, er det nødvendig å skaffe følgende ytelsesindikatorer: redusere tiden når du legger inn nye data og endre gamle, og følgelig øke arbeidsproduktiviteten, samt rettidig og fullstendig mottak av informasjon nødvendig for administrasjon av en biltjeneste.

SEKSJON 2. Modellering av datastrukturer

2.1. Utvikling av en konseptuell databasemodell

Når vi bygger en konseptuell modell av databasen, vil vi bruke anbefalingene fra Karpova I.P. . Som forfatteren bemerker, er den konseptuelle databasemodellen en objektorientert modell på høyt nivå av emneområdet, som representerer objektområdet som et sett med objekter som har visse egenskaper og er i et eller annet forhold. Hovedmålet med å utvikle en datamodell på høyt nivå er å lage en modell for brukeroppfatning av data og å bli enige om et stort antall tekniske aspekter knyttet til databasedesign. Den konseptuelle datamodellen er ikke knyttet til en spesifikk fysisk implementering av databaser og er ikke avhengig av en spesifikk DBMS. Den konseptuelle modellen er laget på grunnlag av ideer om fagområdet til hver type bruker, som er et sett med data som brukeren trenger for å løse problemene sine.
Den konseptuelle modellen for "Autoservice"-basen ble designet som en "entity-relationship"-modell.
De grunnleggende konseptene i modellen inkluderer begreper som enhet (objekt), relasjon (relasjon), enhetstyper, relasjonstyper og attributter.
En enhet er en reell eller tenkt enhet som informasjon må lagres og gjøres tilgjengelig om. I ER-modelldiagrammer er en enhet representert som et rektangel som inneholder navnet på enheten. Hver enhet er definert av et sett med attributter.
Et attributt er en navngitt egenskap for en enhet. Navnet må være unikt for en bestemt enhetstype, men kan være det samme for forskjellige typer enheter. Et attributt til en enhet er enhver detalj som tjener til å klargjøre, identifisere, klassifisere, kvantifisere eller uttrykke tilstanden til en enhet. Vi vil legge inn attributtnavnene i et rektangel som angir enheten og skrive det under navnet på enheten.
Det etableres relasjoner mellom enheter.
Et forhold er en grafisk assosiasjon etablert mellom to enheter. Denne assosiasjonen er alltid binær og kan eksistere mellom to forskjellige enheter eller mellom en enhet og seg selv (rekursiv assosiasjon). Tilkoblinger - angitt med linjer.
Fra beskrivelsen av fagområdet trekker vi altså ut alle typer
enheter:
– Kunder;
- Bestillinger;
- Mestere;
- Liste over verk.
Hver av enhetene vil definere sitt eget sett med attributter.
Entitetskunden er definert av følgende sett med attributter:

Attributtene til ordreenheten er definert som følger:

Master-enheten er dokumentert basert på følgende attributter:

Entiteten List of Works er definert av følgende sett med attributter:

I samsvar med domenemodellen presenteres følgende konseptuelle modell av "Car Service"-databasen (fig. 1).
Fig.1 Konseptuell modell av databasen "Bilservice".

2.2. Utvikling av en logisk datamodell

Konvertering av en lokal konseptuell datamodell til en lokal logisk modell består i å fjerne uønskede elementer fra de konseptuelle modellene og konvertere de resulterende modellene til lokale logiske modeller. Uønskede elementer inkluderer:
- mange-til-mange relasjoner;
– rekursive lenker;
– lenker til attributter.
I den opprettede konseptuelle modellen ble de ovennevnte uønskede elementene ikke funnet.
Logisk diagram data er vist i fig.2.

Ris. 2. Logisk skjema for data.

Konvertering av en enhetsrelasjonsmodell til en relasjonsdatamodell
utføres ved å utføre en rekke trinn sekvensielt:
- hver enhet er assosiert med relasjonen til relasjonsdatamodellen;
– hvert enhetsattributt blir et attributt for den tilsvarende relasjonen;
- Primærnøkkelen til enheten blir primærnøkkelen til den tilsvarende relasjonen. Attributter som er en del av primærnøkkelen til et forhold mottar automatisk den obligatoriske (NOT NULL) egenskapen. I hver relasjon som tilsvarer den underordnede enheten, legges et sett med attributter til hovedenheten, som er primærnøkkelen til hovedenheten. I relasjonen som tilsvarer den underordnede enheten, blir dette settet med attributter fremmednøkkelen.
Denne prosessen er omtalt nedenfor.

SEKSJON 3. Databasedesign

En tabell er et objekt designet for å lagre data i form av poster (rader) og felt (kolonner).
OpenOffice.org Base-programmet gir tre ulike måter lage en databasetabell:

I dette arbeidet ble tabellene laget ved hjelp av veiviseren.
For hver relasjonsdatabasetabell er dens struktur gitt: sammensetningen av feltene, deres navn, datatype og størrelse på hvert felt, tabellnøkler og andre feltegenskaper.
Utviklingen av databasetabeller utføres sekvensielt:

Tabellen er grunnlaget for databasen, derfor, når du utvikler tabeller, anbefales det å bli veiledet av følgende grunnleggende prinsipper:

Hver tabell inneholder informasjon om et bestemt emne, og hvert felt i tabellen inneholder et spesifikt fakta om emnet i tabellen. For hver tabell i databasen må du definere egenskapene som finnes i dem.
Autoservice-databasen inneholder fire tabeller:

Ris. 3. Tabell Kunder.

Ris. 4. Bestillingstabell.

Denne tabellen inneholder følgende attributter:

Ris. 5. Liste over verk.

Ris. 6. Mestere.

La oss definere en primærnøkkel for hver enhet, mens vi tar i betraktning at sterke enheter bare har ett nøkkelfelt, og svake enheter har så mange som lenker. Når du velger en primærnøkkel, vil vi bli veiledet av reglene:
– nøkkelen må inneholde et minimumssett med attributter;
- du bør bruke nøkkelen, sannsynligheten for å endre verdiene er minimal;
– nøkkelverdien må ha en minimumslengde.
Basert på det foregående definerer vi følgende nøkkelfelt for de eksisterende enhetene:

Etter å ha delt informasjonen inn i tabeller og definert nøkkelfeltene, må du velge hvordan DBMS skal kombinere relatert informasjon. For å gjøre dette er det nødvendig å definere relasjoner mellom databasetabeller.
OpenOffice.org BASE støtter fire typer tabellrelasjoner:
– en-til-en (hver post i en tabell tilsvarer bare én post i en annen tabell);
– en-til-mange (hver post i en tabell tilsvarer mange poster i en annen tabell);
– mange-til-en (lik en-til-mange-notasjon);
– mange-til-mange (én post fra den første tabellen kan være relatert til mer enn én post fra den andre tabellen, eller én post fra den andre tabellen kan være relatert til mer enn én post fra den første tabellen).
Forbindelsene som er opprettet i Autoservice-databasen er allerede presentert i forrige avsnitt i fig. 2.

Form - et objekt designet for å legge inn, redigere og vise tabelldata i en praktisk form.
Skjemaer inneholder såkalte kontroller som får tilgang til data i tabeller. Kontrollelementer er tekstfelt for å legge inn og redigere data, knapper, avmerkingsbokser, brytere, lister, etiketter. Å lage skjemaer som inneholder de nødvendige kontrollene forenkler dataregistreringsprosessen og bidrar til å forhindre feil.
OpenOffice.org Base-skjemaer gir funksjonalitet for å utføre mange oppgaver som ikke kan utføres på andre måter, de lar deg utføre datavalidering mens du går inn, utfører beregninger og gir tilgang til data i relaterte tabeller ved hjelp av underskjemaer.
OpenOffice.org Base tilbyr flere måter å lage skjemaer på. Den enkleste av disse er å bruke automatisk oppretting av skjemaer basert på en tabell eller spørring.
Det er fire enkle skjemaer og tre underskjemaer for Autoservice-databasen.
Eksempler på enkle former er vist i figur 7-10.

Fig.7. Kundeskjema.

Fig.8. Skjema bestillinger.

Fig.9. Liste over verk.

Fig.10. Mestere.
En sammensatt form inneholder en hovedform og en underform, en underform. Et underskjema er det samme skjemaet i sitt innhold, men brukes ikke uavhengig, men alltid lastet fra et eller annet skjema når du åpner eller oppretter et dokument. Du kan gjøre nesten alt i et underskjema som du kan gjøre i et skjema, bortsett fra at du ikke kan sette inn et annet underskjema i det.
Når du oppretter felt i underskjemaer, må du huske på at navnene på alle feltene må være unike i skjemaet, sammen med alle underskjemaer som brukes samtidig i det.
Takket være sammensatte skjemaer blir det mulig å fylle ut forskjellige tabeller samtidig.
Eksempler på underskjemaer er vist i fig. 11-13.

Ris. 11. Kundeskjema med underskjema Bestillinger.
Kundeskjemaet med bestillinger-underskjemaet gir inndata av nødvendige data for å identifisere kunden og se arbeidet utført for denne bestillingen. Dette skjemaet lar deg legge inn informasjon i kunde- og ordretabellene.

Ris. 12. Skjema Bestillinger med underskjema Reparasjonsarbeid.
Dette skjemaet lar deg legge inn informasjon i tabellene for bestillinger og reparasjoner.

Ris. 13. Veiviserskjema med underskjema for bestillinger.
Foreman-skjemaet med underskjemaet Ordrer lar deg kontrollere utførelsen av arbeid av en spesifikk formann.

En spørring er et objekt som lar deg hente de nødvendige dataene fra en eller flere tabeller.
Spørringer brukes til å trekke ut data fra tabeller og gi dem til brukeren i en praktisk form. Med deres hjelp utfører de datavalg, sortering og filtrering. Du kan utføre datatransformasjon i henhold til en gitt algoritme, lage nye tabeller, automatisk fylle tabeller med data importert fra andre kilder, utføre enkle beregninger i tabeller og mye mer.
Det særegne med spørringer er at de trekker data fra basistabeller og lager på grunnlag av dem en midlertidig resulterende tabell (øyeblikksbilde) - et bilde av felt og poster valgt fra basistabeller. Arbeid med et bilde er raskere og mer effektivt enn med tabeller lagret på en harddisk.
På riktig forespørsel kan du få dataene sortert og filtrert etter behov. Forespørsler kan også brukes som postkilder for skjemaer, rapporter og datatilgangssider.
Det finnes flere typer forespørsler:

 Å studere detaljene for det valgte fagområdet.

 Utvikle en informasjonslogisk modell av databasen "Biltjeneste"

 Implementer det i MS Access DBMS.

 Lag en "forklarende notat" til kursprosjektet i henhold til følgende plan:

Formålet med databasen

Database "Bilservice" er designet for å implementere aksept og behandling av bestillinger for arbeid av en bilservicebedrift.

Selvfølgelig later han ikke til den høye rangen til ACS. På grunn av fraværet av hele blokkene som er nødvendige for et integrert automatisert kontrollsystem:

 Regnskap,

 Økonomisk blokk

 Planlagt

 Rekvisita

 Og en rekke andre blokker.

Bare en av blokkene til det automatiserte kontrollsystemet blir implementert - arbeidsplassen "Ordremottak": arbeid med kunder: motta og fikse bestillinger, organisere implementeringen av dem, rapportere om resultatene av arbeidet.

Funksjoner utført av databasen

Databasen utfører følgende funksjoner

1. Regnskap og lagring av opplysninger om bilserviceansatte. "Mekanikers»

2. Legge inn og lagre informasjon om type arbeid som utføres. "Rekkefølges»

3. Legge inn informasjon om kunder, kunders biler og data om dem. "Be oms»

4. Skjemaet "Legge inn informasjon om bestillinger" gir innspill faktisk bestilling, valg av kundens fulle navn (fra listen), valg av kundens biltype og inntasting av informasjon om denne.

Samme sted - sammensetningen av det utførte arbeidet og det fulle navnet på de bilserviceansatte som utfører dem. Og også - informasjon om sammensetning og mengde reservedeler som brukes.

5. Databasen gir også ulike rapporter som lar deg analysere tilstanden til bilservicebedriften.

Brukerkategorier

Databasen er først og fremst beregnet på bilservicemedarbeidere som mottar og behandler bestillinger på bilreparasjoner og vedlikehold.

Og rapportene som er gitt i den, er også for andre avdelinger i bedriften, så vel som for lederne.

Database design

Vi introduserer følgende begreper Og konvensjoner :

Essenser

ESSENS

Essens - ekte eller innbilt en gjenstand , informasjon om hvilke som må lagres og tilgjengelig. I ER-modelldiagrammer er en enhet representert som et rektangel som inneholder navnet på enheten.

Essenser vil bli betegnet med rektangler,

Enhetsattributter

Egenskap - navngitt essens karakteristikk . Navnet må være unikt for en bestemt enhetstype, men kan være det samme for ulike enhetstyper. Et attributt til en enhet er enhver detalj som tjener til å klargjøre, identifisere, klassifisere, kvantifisere eller uttrykke tilstanden til en enhet.

ESSENS

Attributter

Attributtnavn vi legger inn et rektangel,

angir essens, under navnet til enheten, og skriv

små bokstaver.

Forhold

Forbindelse er en grafikk assosiasjon A som er satt mellom to enheter. Denne assosiasjonen er alltid binær og kan eksistere mellom to forskjellige enheter eller mellom en enhet og seg selv (rekursiv assosiasjon).

Tilkoblinger- angi linjene som vi vil legge ned grad av tilknytning (« 1 » eller « ∞ » , som angir "mye") og dens egenskaper.

Nøkkelfelt

La oss definere konseptet hoved Og utvendig nøkler

Nøkkel - dette er minimumssettet med attributter, med verdiene som du unikt kan finne den nødvendige forekomsten av enheten. Minimalitet betyr at ekskluderingen fra settet av noen attributter ikke tillater at enheten kan identifiseres av de gjenværende. Hver enhet har minst én mulig nøkkel.

En av dem er tatt primærnøkkel .

Når du velger primærnøkkel bør foretrekkes ikke-sammensatt nøkler eller nøkler som består av et minimum antall attributter. Det er også upassende å bruke nøkler med lange tekstverdier (det er å foretrekke å bruke heltall e-attributter).

En enhets primærnøkkel (alle attributter som deltar i primærnøkkelen) er ikke tillatt å ta ubestemt betydning. Ellers vil det oppstå en motstridende situasjon: en person uten individualitet vil dukke opp, og følgelig ikke en eksisterende enhetsforekomst. Av samme grunner er det nødvendig å sikre unikhet primærnøkkel.

Fremmednøkler

Hvis enhet MED binder enheter EN Og I, så må den inkludere fremmednøkler som tilsvarer primærnøklene til enhetene A og B.

Hvis enhet I betegner en enhet EN, så må den inkludere en fremmednøkkel som tilsvarer primærnøkkelen til enheten EN.

Merk:

1. Siden utviklerne av MS Access DBMS i utgangspunktet ta hensyn til problemene med hoved Og fremmednøkler, ble en spesiell felttype introdusert i Access - KEY FIELD. Dens type er COUNTER.

Adgang krever ikke dens obligatoriske inkludering i tabellen. Men sterkt tilbud.

Funksjonene til denne typen felt er som følger:

Når du går inn Ny inngang– i dette feltet dannes en ny AUTOMATISK, unik, ikke-repeterende numerisk verdi.

Feltet kan ikke godta ubestemt betydning.

Felt - automatisk indeksert.

Manuell endring av verdien til dette feltet umulig.

Derfor problemet nøkkelfelt Og fremmednøkler I Access er løsningen enkel:

I hovedtabellen(enheter) opprette spesiell nøkkel felt. Det blir vår primærnøkkel .

I de underordnede tabellene legger vi inn kopien (med samme navn). Det blir deres ekstern nøkkel .

Vi kobler sammen hoved- og underordnede tabeller ved disse feltene. Det er alt. Kommunikasjon ferdig!

2. Utviklere introduserte i Access et verktøy kalt « Dataskjema »

som tillater ikke bare å knytte tabeller, men spesifiser også for hver lenke:

henne type("en-til-en", "en-til-mange", etc.)

og henne kjennetegn: Sikre integritet og gjennomgripende oppdateringer og slettinger fra relaterte tabeller og felt.

Hva må spesifiseres ved bygging ER– modeller Database.

Spesielt, det er hvorfor Access er ideelt egnet som et programmeringssystem for implementering av ER-modeller.

Ved implementering av vårER– modeller iAdgangVi vil utnytte alle disse mulighetene.

Send ditt gode arbeid i kunnskapsbasen er enkelt. Bruk skjemaet nedenfor

Studenter, hovedfagsstudenter, unge forskere som bruker kunnskapsbasen i studiene og arbeidet vil være deg veldig takknemlig.

Vert på http://www.allbest.ru/

DEN FØRSTE HØYERE TEKNISKE INSTITUTIONEN I RUSSLAND

UDDANNELSES- OG VITENSKAPSMINISTERIET I DEN RUSSISKE FØDERASJON

Federal State Budgetary Educational Institute of Higher Professional Education

"NATIONAL MINERAL UNIVERSITY "GRUVEBYGGING"

Kursarbeid

"Database - biltjeneste"

Etter disiplin: Anvendt programmering

Fullført av: Stepanova K.A.

Sjekket av: Matyukhin S.A.

St. Petersburg 2013

Introduksjon

1. Beskrivelse av fagområdet

2. Beskrivelse av databasestrukturen

3. Tabeller

4. Mandat

5. Beskrivelse av programmet

6. Komponenter

7. Opplegg for brukeren

8. Grensesnitt

Konklusjon

Bibliografi

applikasjon

Introduksjon

I vår tid, den digitale teknologiens tidsalder, spiller datamaskiner en viktig rolle. Nå i enhver organisasjon - det være seg offentlige etater eller private firmaer, er alt datastyrt, og dette skyldes svært høy datakraft. Beregning av selv de mest komplekse prosesser og oppgaver utføres på kortest mulig tid, og tidsfaktoren spiller ofte en stor rolle i de fleste oppgavene. Datakraften og minnekapasiteten til datamaskiner de siste årene har blitt utrolig stor, og prisene deres har falt betydelig, noe som har bidratt til massedatabehandling av absolutt alle grener av menneskelig aktivitet. Nå er det vanskelig å forestille seg livet uten en smart maskin som forenkler og fremskynder et stort antall oppgaver. Nytten til en datamaskin reduseres til ingenting i fravær av spesialisert programvare, uten hvilken "jernassistenten" blir ubrukelig. I dette arbeidet vil bli diskutert om opprettelsen av et så viktig, og i de fleste organisasjoner og hovedprogrammet, hvis navn er en database. I dette spesielle tilfellet, bilservicedatabasen.

1. Beskrivelse av fagområdet

Målet med oppgaven er å oppnå programvareprodukt, som lar deg lagre informasjon om kundene til tjenesten, feil i bilene deres, noe som sikrer effektiviteten og påliteligheten til databehandlingen.

Bilservicedatabasen er beregnet på bilserviceoperatører og gir tilgang til informasjon om bilmerke, besøksdato, funksjonsfeil, vinnummer på bilen, samt kundeinformasjon: telefonnummer osv.

Effektiviteten til programmet ligger i å redusere tiden for behandling, søke etter nødvendig informasjon.

Behovet for å automatisere denne oppgaven skyldes det faktum at valget av nødvendige data for rapporter og regnskap for arbeidet til ingeniører vanligvis gjøres manuelt eller ved hjelp av Excel, og bruker en betydelig mengde tid på dette. Dette programmet gir også søke-, filtrerings- og sorteringsmuligheter.

Det kreves ingen spesielle kunnskaper for å jobbe med programmet innen programmering.

2. Beskrivelse av databasestrukturen

Tabelllenker:

Kundetabellen er koblet til mastertabellen ved å bruke et 1:N-forhold i vin_nummer-feltet

Kundetabellen er knyttet til beregningstabellen med et 1:1 forhold på vin_nummer-feltet

3. tabeller

Tabell 1: Klienter (hovedtabell)

Tabell 2: Mestere (slave)

Tabell 3: Mestere (slave)

programvare for biltjenestebaseredigering

4. Teknisk oppgave

Grunnlag for utvikling:

Lærerens oppgave for å gjennomføre praktiske klasser og fullføre kurs.

Formål med utvikling:

Programmet er designet for å automatisere arbeidet til biltjenesteoperatører.

Programkrav:

Bør automatisere arbeidet til en bilserviceoperatør

Informasjon må lagres permanent på harddisken til datamaskinen

· Det skal være mulig å se databasen med mulighet for å slette spesifisert informasjon fra den.

Krav til pålitelighet:

· Programmet skal behandle feilhandlinger fra brukeren og informere ham om det.

· Programmet skal gi kontroll over inndatainformasjonen.

5. Programbeskrivelse

privat void Form1_Load(objektsender, EventArgs e) () // last inn hovedkomponenter

privat void b_add_Click(objektsender, EventArgs e) () // legger til en ny post

privat void b_replace_Click(objektsender, EventArgs e) () // rediger oppføring

privat void b_cancel1_Click(objektsender, EventArgs e) () // avbryt handling

private void b_save_Click(objektsender, EventArgs e) () // lagre endringer

privat void b_record1_Click(objektsender, EventArgs e) () // skriv data

privat void b_delete_Click(objektavsender, EventArgs e) () // slett data

privat void b_exit_Click(objektsender, EventArgs e) () // programavslutning

6. Komponenter

7. Opplegg forbruker

Tabell 1 "Klienter" og tabell 2 "Mestre" er forbundet med en en-til-mange-relasjon med vin_nummer-feltet.

Tabell 1 "Kunder" og tabell 3 "Kostnad" er koblet i en en-til-en-relasjon av vin_nummer-feltet.

8. Grensesnitt

Legger til en ny oppføring

Redigerer et gammelt innlegg

Sletter en oppføring

Sorter etter besøksdato

Signerte bord

Hovedtabellen til programmet "Bilservice" inkluderer:

1. Kundebilliste

2. Dato for kontakt med bileieren

3. Feil

4. Kundetelefon

5. Vin-nummer

6. Administrasjon av listen over klienter utføres med knapper (Legg til/Erstatt/Slett)

7. Vis og ta opp salongklienter

8. Sortering

10. Valg av mestere

11. Navn på tabeller

12. Avslutt programmet

Konklusjon

Resultatet av arbeidet var skapelsen programvare betjener arbeidsplassen til biltjenesteoperatøren.

I prosessen med å fullføre kursarbeidet ble det tilegnet ferdigheter innen bygging og programmering av databaser i programmeringsspråket C #.

Bibliografi

1. Matyukhin S.A. "Programmering i C # objektorientert tilnærming" - pedagogisk og metodisk kompleks 2013

2. A. Hejlsberg, M. Torgersen, S. Wiltamuth, P. Gold C# programmeringsspråk. Klassisk informatikk. 4. utgave = C# programmeringsspråk (dekker C# 4.0), 4. utgave. - St. Petersburg: "Piter", 2012. - 784 s. -- ISBN 978-5-459-00283-6

3. E. Stillman, J. Green Learning C#. 2nd Edition = Head First C#, 2ed. - St. Petersburg: "Piter", 2012. - 704 s. -- ISBN 978-5-4461-0105-4

4. Andrew Troelsen C# 5.0 Programmeringsspråk og .NET 4.5 Framework, 6. utgave = Pro C# 5.0 og .NET 4.5 Framework, 6. utgave. - M.: "Williams", 2013. - 1312 s. -- ISBN 978-5-8459-1814-7

5. Joseph Albahari, Ben Albahari C# 5.0. Katalog. Full språkbeskrivelse = C# 5.0 i et nøtteskall: The Definitive Reference. - M.: "Williams", 2013. - 1008 s. -- ISBN 978-5-8459-1819-2

6. Herbert Schildt. C# 4.0: komplett guide= C# 4.0 Den komplette referansen. - M.: "Williams", 2010. - S. 1056. - ISBN 978-5-8459-1684-6

applikasjon. Kodeprogrammer

bruker System.Collections.Generic;

bruker System.ComponentModel;

bruker System.Data;

ved hjelp av System.Drawing;

bruker System.Linq;

bruker System.Text;

bruke System.Threading.Tasks;

bruker System.Windows.Forms;

offentlig delklasse Skjema1: Skjema

InitializeComponent();

groupBox1.Visible = usant;

groupBox2.Visible = usant;

private void-kunderBindingNavigatorSaveItem_Click_1(objektavsender, EventArgs e)

dette.Valider();

this.customersBindingSource.EndEdit();

this.tableAdapterManager.UpdateAll(this.db_autoDataSet);

privat void Form1_Load(objektavsender, EventArgs e)

// TODO: Denne kodelinjen laster data inn i tabellen "db_autoDataSet.masters". Du kan flytte eller fjerne den etter behov.

this.mastersTableAdapter.Fill(this.db_autoDataSet.masters);

// TODO: Denne linjen med kode laster data inn i tabellen "db_autoDataSet.calculation". Du kan flytte eller fjerne den etter behov.

this.calculationTableAdapter.Fill(this.db_autoDataSet.calculation);

// TODO: Denne kodelinjen laster data inn i tabellen "db_autoDataSet.customers". Du kan flytte eller fjerne den etter behov.

this.customersTableAdapter.Fill(this.db_autoDataSet.customers);

privat void b_exit_Click(objektsender, EventArgs e)

privat void button5_Click_1(objektavsender, EventArgs e)

privat void b_add_Click(objektsender, EventArgs e)

groupBox1.Visible = sant;

b_replace.Visible = usann;

b_delete.Visible = usann;

b_exit.Visible = usann;

b_add.Visible = usann;

b_exit2.Synlig = usann;

b_save.Visible = usann;

textBox1.Text = "";

textBox2.Text = "";

textBox3.Text = "";

textBox4.Text = "";

textBox5.Text = "";

privat void b_replace_Click(objektsender, EventArgs e)

textBox10.Text = kunder DataGridView.CurrentRow.Cells.Value.ToString();

textBox9.Text = kunder DataGridView.CurrentRow.Cells.Value.ToString();

textBox8.Text = kunder DataGridView.CurrentRow.Cells.Value.ToString();

textBox7.Text = kunder DataGridView.CurrentRow.Cells.Value.ToString();

textBox6.Text = kunder DataGridView.CurrentRow.Cells.Value.ToString();

textBox6.ReadOnly = sant;

groupBox2.Visible = sant;

b_add.Visible = usann;

b_delete.Visible = usann;

b_exit.Visible = usann;

b_exit2.Synlig = usann;

b_replace.Visible = usann;

b_save.Visible = usann;

privat void b_cancel1_Click(objektavsender, EventArgs e)

b_add.Visible = sant;

b_delete.Visible = sant;

b_exit.Visible = sant;

b_exit2.Visible = sant;

b_replace.Visible = sant;

b_save.Visible = sant;

groupBox1.Visible = usant;

privat void b_cancel2_Click(objektavsender, EventArgs e)

b_add.Visible = sant;

b_delete.Visible = sant;

b_exit.Visible = sant;

b_exit2.Visible = sant;

b_replace.Visible = sant;

b_save.Visible = sant;

groupBox2.Visible = usant;

privat void b_save_Click(objektavsender, EventArgs e)

kunderBindingNavigatorSaveItem_Click_1(sender, e);

privat void b_record1_Click(objektavsender, EventArgs e)

DataTable table = db_autoDataSet.Tables;

DataRow row = table.NewRow();

rad = tekstBoks1.Tekst;

rad = Convert.ToDateTime(tekstBox2.Text);

rad = tekstBox3.Tekst;

rad = tekstBox4.Tekst;

rad = tekstBox5.Text;

table.Rows.Add(row);

gruppeBox1.Skjul();

b_replace.Visible = sant;

b_delete.Visible = sant;

b_exit.Visible = sant;

b_add.Visible = sant;

b_exit2.Visible = sant;

b_save.Visible = sant;

privat void b_record2_Click(objektsender, EventArgs e)

DataTable table = db_autoDataSet.Tables;//12 bundet dynamisk. fanen. tabell med den første filen fra databasen

vinRab = Convert.ToInt64 (customersDataGridView.CurrentRow.Cells.Value.ToString());//13 fikk vinen til gjeldende rekord

DataRow row = table.Rows.Find(vinRab);//14 kombinert dynamikk. radraden med filoppføringen vin c shifrRab og sett datasettet i "redigerings"-tilstanden, der det lar deg endre feltverdiene

rad = textBox10.Text;//15 skrevet til det andre feltet i raden gitt fra vinduet

rad = Convert.ToDateTime(textBox9.Text);// 15 skrives til det tredje feltet i radraden

rad = tekstBox8.Tekst; //15 ble skrevet til det fjerde feltet i rad rad rad = textBox7.Text;

rad = tekstBox6.Tekst;

table.AcceptChanges();//15 AcceptChanges-kommandoen lar deg godta endrede feltverdier

groupBox2.Hide();//16

b_replace.Visible = sant;

b_delete.Visible = sant;

b_exit.Visible = sant;

b_add.Visible = sant;

b_exit2.Visible = sant;

b_save.Visible = sant;

privat void b_delete_Click(objektavsender, EventArgs e)

// sletter linjen under markøren

// først bygger vi en advarsel for ikke å gjøre en feilaktig sletting

streng s1, s2, s3, s4, s5, melding;

DialogResult resultat;// 18

int ind = customersDataGridView.CurrentRow.Index;

s1 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s2 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s3 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s4 = customersDataGridView.CurrentRow.Cells.Value.ToString();

s5 = customersDataGridView.CurrentRow.Cells.Value.ToString();

melding = "Bilmerke= " + s1 + "\nDato for besøk= " + s2 + "\n Feil= " + s3 + "\n Kundetelefon= " + s4 + "\n vinnummer" + s5;

// resultatvariabel kan ta enten DialogResult.Yes eller DialogResult.No

result = MessageBox.Show(melding, "Slette neste oppføring? ",

MessageBoxButtons.YesNo, MessageBoxIcon.Question);

hvis (resultat == DialogResult.Yes)//Linje er slettet

(// 20 Den gjeldende tabellen fra customersDataGridView av DataGrid-typen skrives til buffertabellen

CurrencyManager CurMng = (CurrencyManager)customersDataGridView.BindingContext;

if (CurMng.Count > 0) // hvis tabellen ikke er tom

CurMng.RemoveAt(CurMng.Position);// sletter den merkede posisjonen

// her resultat == DialogResult.No og sletting avvises

// avslutte prosedyre

Vert på Allbest.ru

Lignende dokumenter

Database opprettelse. Søk, endre og slett poster. Databehandling og utveksling. Database design. Definisjon av formler for den beregnede delen av basen. Redigering av felt og poster. Former for presentasjon av informasjon i databasen.

semesteroppgave, lagt til 23.02.2009

Utvikling av et programvareprodukt - database "Excursion" i det integrerte programmeringsmiljøet C ++ Builder 6. Bestemme rekkefølgen på visning av databasedata, redigere og slette dem. Funksjoner i brukerhåndboken og det generelle grensesnittet til programmet.

semesteroppgave, lagt til 11.03.2013

Begrunnelse av behovet for databasestyringssystemer i virksomheter. Funksjoner ved utviklingen av dasom gir visning, redigering, innsetting av databaseposter, generering av spørringer og rapporter.

semesteroppgave, lagt til 23.01.2010

Oppretting av en database og beskrivelse av "Studiedatabase"-programmet designet for å gruppere informasjon om studenter. Karakteristisk funksjonalitet programmer: legge til poster i databasen, redigere, slette poster og sortere data.

semesteroppgave, lagt til 25.04.2011

Utvikling av programmet "Database over sportsutstyr". Beskrivelse av operasjonsalgoritmen til moduler og blokker. Strukturdiagram av prosjektrepresentasjonen. Prosessen med å finne riktig informasjon. Automatisk datasortering. Legge til og redigere poster.

semesteroppgave, lagt til 15.08.2013

Oppretting av enkle referanseskjemaer. Redigere skjemaegenskaper i designmodus. Legge til og redigere egenskaper for kontroller. Utforme rapporter for databasen. Ta med bordet til normal form og bygge et dataskjema.

abstrakt, lagt til 23.11.2008

Prosedyren for å designe og utvikle en database og programvare. Informasjon om strukturen til databasen, opprettede tabeller, skjemaer, rapporter, spørringer, lagret informasjon. Logiske og konseptuelle datamodeller; valg av programvare.

semesteroppgave, lagt til 20.01.2010

Begrensningstyper som opprettholder integritet i relasjonsdatamodellen. Bestemme verdien av et primærnøkkelfelt ved hjelp av en generator. Legge til, endre og slette poster i databasetabellen "Library" i SQL-programmeringsspråket.

laboratoriearbeid, lagt til 10.10.2012

Domeneanalyse. Krav for å sette sammen en hotelldatabase. Gjennomføring av prosessen med å søke etter nødvendig informasjon. Utforming av tabeller, forespørsler, rapporter og deres utskrift. Redigere, legge til og lagre data.

semesteroppgave, lagt til 02.07.2016

Begrunnelse for valg av applikasjonsutviklingsverktøy. Legge til, slette, redigere informasjon. Refleksjon av informasjon fra databasen. Søk etter informasjon på den valgte tabellen. Prosjektdata, enhet, logikk, firma. Samhandlingsskjema mellom prosjektene i programmet.

Populær i kategorien: