Opprette Nye Databaser

en ny database er en beholder som inneholder alle tabellene, skjemaet, rapportene, spørringene, makroene og modulene du oppretter. I Access 2010 kan du opprette en ny database ved å klikke på» Fil » – fanen på Båndet. Klikk deretter på kommandoen» ny». Velg deretter» Blank database «- valget i Delen «Tilgjengelige Maler». I Access 2007 kan du opprette en ny tom database ved å klikke på» Tom Database «- knappen i delen» Ny Tom Database «i velkomstskjermbildet» Komme I Gang Med Microsoft Access». I Ruten » Tom Database «som vises til høyre på skjermen, kan du skrive inn et navn for databasen i tekstboksen» Filnavn:». Hvis du vil endre standardmappen der databasefilen skal lagres, kan du klikke på den lille mappeknappen til høyre i tekstboksen» Filnavn: «for å starte dialogboksen» Fil Ny Database». Bruk denne dialogboksen til å gi den nye databasefilen et navn, og velg også hvor du vil lagre filen. Når du er klar, klikker du på» OK » – knappen for å lukke dialogboksen. Klikk deretter på» Opprett » – knappen for å opprette den nye databasefilen. Når det er gjort, vises den nye tomme databasen i Hovedgrensesnittet.

Flow Oversikt Over En Database

en database bør være enkel, logisk og grei i sin utforming. Generelt bruker du skjemaer til å angi informasjon i tabeller. Dataene lagres deretter i disse tabellene, som er relatert til hverandre etter behov. Du kan bruke spørringer til å hente spesifikk informasjon fra tabellene i databasen. Spørringene danner ofte grunnlaget for rapporter, som deretter lar deg se informasjonen du ba om. Når dette systemet er på plass, kan du automatisere det ved å bruke makroer og moduler for å forenkle og strømlinjeforme prosessene som er involvert i å legge inn, lagre og hente data. Dette er hovedårsaken til at du bruker databaser: for å angi, lagre og hente data.

Flat-Fil-Metoden For Datalagring

Access er et relasjonsdatabaseprogram. Så hva betyr begrepet relasjonelt, og hvordan er dette viktig? Begrepet relasjonell beskriver metoden som brukes til å lagre data i databasetabellene. Det kan imidlertid være lettere å forstå relasjonsmodellen for datalagring ved å kontrastere den med en annen lagringsmetode som du kanskje er mer kjent med :flatfilmetoden.

Informasjon lagres ofte i store ‘ flat-filer. Anta for eksempel at du vil opprette en databasefil som lagrer firmaets kundeinformasjon. Du vil begynne med å liste opp de ulike attributtene til kunden som du ønsker å registrere. Det kan være lurt å registrere kundeinformasjon som «fornavn», «etternavn», «firmanavn» og andre relevante opplysninger. Kanskje du kan lage et bord i Et program som Microsoft Excel der du kan lage kolonner for hvert stykke informasjon du vil registrere. Du kan deretter liste hver kundes informasjon i radene under kolonnene, og opprette en grunnleggende tabell. Anta at det ser ut som følgende eksempel.

for mange typer databaser vil strukturen vist på forrige side fungere bra. Dette er en’ flat-fil ‘ liste eller tabell. Det du gjør når du bruker denne typen database, registrerer en enkelt informasjon, som «Fornavn»,» Etternavn «eller» Adresse » om en enkelt enhet-i dette eksemplet en kunde. Grunnen til at denne typen datastruktur fungerer bra i eksemplet er fordi for hver enhet (kunden), er du bare registrere informasjon som har en» 1 til 1 » forhold til enheten.

Så, hva er meningen med dette» 1 til 1 » forholdet mellom enheten (kunden) og dataene du registrerer («Fornavn»,» Etternavn » osv.)? Hva dette betyr er at for hver enhet eller emne (i dette tilfellet – kunden), registrerer du bare informasjon om den enheten som det bare ville være ett » svar.»For eksempel vil hver kunde bare ha ett «fornavn» og ett » etternavn.»De ville jobbe for bare ett» selskap.»Så begrepet» 1 til 1 » refererer til forholdet mellom emnet i tabellen (kunder) og dataene som samles inn om enhetene. Fordi for hver (en) kunde er det bare ett mulig stykke data å registrere i kolonnen, sier du at forholdet mellom dataene og enheten er » 1 til 1.»Hvis dette er typen database du prøver å lage, vil enkle Microsoft Excel-tabeller fungere bra.

problemet begynner å oppstå når du prøver å bruke en «flat-fil» tilnærming til å modellere en mer kompleks enhet eller emne, som » salg.»Anta for eksempel at du ønsket å utvide kundedatabasen fra den siste» flat-fil » – databasen for å inkludere salgsdata . La oss si at nå, i tillegg til informasjonen som allerede er samlet, vil du også registrere hver ordre laget av en kunde.

først vil du starte med å oppgi hvilke data om hvert salg du vil registrere. Å holde eksemplet enkelt, anta at du bestemmer deg for å registrere «salgsdato», «varer» kjøpt, «antall» av varer kjøpt » og «beløp» betalt for hvert element. Du kan velge å legge til følgende kolonner i datastrukturen ‘flat-fil’.

Dette ser ut til å fungere ved første øyekast. Du vil imidlertid umiddelbart begynne å støte på problemer når du begynner å legge inn poster i filen. Til å begynne med, hver gang en kunde foretar et kjøp, må du skrive inn alle «Fornavn»,» Etternavn » osv. informasjon igjen. Dette alene er irriterende nok.

en løsning som ofte foreslås på dette punktet, er å legge inn en annen rad (med all overflødig informasjon) en gang for hvert element som er kjøpt. Du vil imidlertid snart oppdage at denne filen vil vokse ganske raskt nedover bordet, og du må også legge inn mange overflødige kundedata for hvert element som er kjøpt. Dette er ikke en elegant løsning og vil uunngåelig kaste bort både tid og krefter på personen som utfører dataregistrering.

En annen løsning som ofte foreslås på dette punktet, er å opprette flere kolonner (som «Item1», «Item2″,» Item3″,» Quantity1″,» Quantity2″ Quantity3 » osv.) i stedet for å måtte legge inn flere rader med informasjon. Selv om dette kan virke som en god alternativ løsning, hva vil du gjøre når noen kjøper 100 elementer? Vil du virkelig lage et sett med 3 kolonner («Element»,» Antall»,» Beløp») for hvert element kjøpt, og produsere et bord over 300 kolonner på tvers? Vil du bare la dem stå tomme hvis personen bestiller bare 1 element, kaste bort verdifull lagringsplass? I denne løsningen erstatter du bare kolonnevekst (over) for vertikal vekst (ned). Dette er heller ikke en elegant løsning.

så hvorfor er det et problem nå, når det ikke var en tidligere? Svaret er at nå prøver du ikke lenger å modellere et» 1 til 1 » dataforhold i filen. Registrering av salgsinformasjon er ganske enkelt mer komplisert enn å registrere kundeinformasjon. Hva du prøver å ta opp nå er det som er referert til som en «1 til mange» forhold. I utgangspunktet, for hver enhet (kunden), prøver du nå å registrere data i kolonnene som kan oppstå mer enn en gang per kunde («Elementene» bestilt, for eksempel). Du ville være i en beklager tilstand hvis hver kunde bare kunne kjøpe en enkelt vare. Du må tillate det faktum at i et salg, kan hver kunde bestille mange elementer. Forholdet mellom kunder og varer kjøpt er en» 1 til mange » forhold. Når du finner ut at du prøver å modellere et» 1 til mange «forhold, er det da at du må forlate «flatfil» – metoden for datalagring der du prøver å plassere all informasjonen du vil registrere i et enkelt bord, og i stedet slå til relasjonsmodellen for datalagring for løsningen.