Vi har så ved fallgruvene ved å bruke et regnearkprogram som Excel til å lagre lister med data. Denne tilnærmingen kan virke som den beste løsningen til å begynne med, men du kan støte på problemer med å dele dataene med flere brukere, validere innholdet eller til og med navigere i dataene dine. Hvorfor? Fordi du bruker et verktøy som ikke var designet for å gjøre jobben.
Nå vil vi vurdere et tenkt (men typisk) tilfelle av en virksomhet som bruker en regnearkbasert liste, og se på hvordan dette kan konverteres til et databaseapplikasjon for å løse slike problemer.
Hvordan arbeidsbøker kommer ut av hånden
Vår liste begynte som en enkel oversikt over prosjekter som ble gjennomført for kunder. Etter hvert som selskapet vokste, økte også antall kunder med navn og kontaktdetaljer lagt til arbeidsboken. Det var også behov for en eller annen måte å registrere hva forskjellige ansatte gjorde på disse prosjektene, så enda mer data ble lagt til i denne arbeidsboken.
På dette tidspunktet ble regnearktilnærmingen lite anvendelig: det var altfor mange som prøvde å holde den oppdatert, ofte samtidig. Selskapet prøvde å innføre en rota, slik at folk svingte på å oppdatere arbeidsboken, men dette betydde at noen oppgaver ble glemt før de ble spilt inn.
Til slutt satte folk opp egne arbeidsbøker for å holde rede på oppgavene sine, noen ganger husket å kopiere dataene til hovedarbeidsboken på slutten av uken. Ansatte utviklet sin egen stenografi for disse bøkene, og noen endret formateringen og rekkefølgen på kolonnene for å passe deres måte å jobbe på. Å kopiere disse dataene til hovedarbeidsboken resulterte i et forferdelig rot.
Dette kan være et sammensatt eksempel, men jeg har faktisk sett alle disse praksisene i det virkelige liv. La oss se nærmere på noen av problemene som kastes opp av denne arbeidsmetoden.
Mange problemer
Du kan se det første arket i vårt imaginære regneark. Den første kolonnen beskriver navnet på prosjektet som hver oppføring refererer til. Noen av disse navnene er imidlertid lange, så ansatte kan ha blitt fristet til å bruke forkortelser; som et resultat har det kommet inn skrivefeil. Dette gjør det vanskelig å binde opp hvilke oppgaver som hører til hvilket prosjekt. Løsningen trenger ikke å være vanskelig: du kan velge et kort navn for hvert prosjekt som alle er enige om, eller gi hvert prosjekt et ID-nummer og oversette dette automatisk til prosjektnavnet.
Det er et lignende problem med Startet-kolonnen. Noen celler inneholder en dato, men andre registrerer bare en måned - og en eller to poster sier bare Ja. Excel støtter datavalidering, så det er mulig å sikre at bestemte celler alltid inneholder data av en bestemt type - men når et regneark er utviklet på en ad hoc-måte, blir det sjelden brukt.
På dette tidspunktet blir regnearkstilnærmingen lite brukbar: det var altfor mange som prøvde å holde den oppdatert
Du har ikke dette problemet i et databaseapplikasjon, siden datatypen til feltet vil bli løst fra begynnelsen. Hvis du ikke vet nøyaktig datoen da arbeidet begynte, kan du bruke den første i måneden, eller 1. januar hvis du bare vet året. Hvis prosjektet ennå ikke er startet, kan du la feltet være tomt - en NULL i databasetermer. Hvis du visste at prosjektet var startet, men ikke visste når, kan du bruke en dato som vanligvis ville være umulig for dataene dine, for eksempel 1/1/1900. Umiddelbart blir det enkelt å sortere prosjekter og få en kronologisk oversikt over aktiviteten.
En mer subtil utfordring presenteres av kolonnen merket Client. Oppføringene i denne kolonnen er ikke knyttet til noe annet i arbeidsboken, men det er en liste over kunder på ark 1, som sannsynligvis er det den refererer til. Å lagre flere lister med de samme elementene, referert til med forskjellige navn, er forvirrende. Du må avklare navngivningen og avgjøre et entydig navn for denne enheten: er de kunder eller kunder?
Status-kolonnen er en annen der det ikke har vært noen validering, så folk har igjen valgt å skrive hva de vil. Det ville være bedre å lage en kort liste over alle tillatte verdier.
Det andre arket - Ark 1 - er like problematisk. Til å begynne med er arknavnet ikke beskrivende. Det den faktisk inneholder er en liste over kunder, men dette er ikke formatert som en tabell i Excel: adressen er i ett felt, noe som begrenser muligheten din til å bruke Excels innebygde verktøy for å søke eller sortere den. Du kan for eksempel filtrere etter adresser som inneholder Cardiff, men resultatene vil også inkludere de på Cardiff Road i Newport.
Når det gjelder adresser, er den beste tilnærmingen å bruke separate felt for postnummer, fylke, by og gate (selv om fylkesinformasjon er valgfri for britiske adresser - se Ingen fylker, vi er britiske). Street skal inneholde alt som ikke er i de andre delene av adressen.
Det er et kontaktfelt, som også gir problemer. Der vi har flere kontakter innen en enkeltklientvirksomhet, har navnene deres blitt samlet inn i dette feltet, med telefonnummer og e-postadresser på samme måte plassert i de andre feltene. Å skille disse ut vil være utfordrende - spesielt hvis det er tre navn i kontaktfeltet, men bare to telefonnumre.
Den siste kolonnen i dette arket har overskriften Sist kontaktet: ansatte skal oppdatere dette hver gang de tar kontakt med en kunde. Siden denne informasjonen er en ekstra ting for den ansatte å huske, og det ikke er noen garanti for at de vil - spesielt siden den er skjult ut av veien på et nytt ark - den er upålitelig. Dette er virkelig noe datamaskinen bør spore automatisk.
Til slutt kommer vi til oppgavearkene, som beskriver oppgavene og kommentarene til hver arbeider. Disse blir ikke navngitt konsekvent, og inneholder ikke de samme kolonnene i samme rekkefølge. Selv om det er fornuftig for individuelle brukere å legge inn dataene sine på sine egne ark, gjør mangelen på sammenheng det vanskelig å samle og analysere dataene. Når en leder for eksempel vil se hva som er gjort på hvert prosjekt, må alle oppgavene kopieres for hånd fra de enkelte arkene til en liste før de kan sorteres og rapporteres om.
Bygg databasen din
Å sortere ut disse problemene vil ta litt arbeid, muligens flere dager. Siden brukere sannsynligvis må fortsette å bruke det gamle systemet mens vi bygger et nytt, er det best å lage en kopi av de eksisterende arbeidsbøkene man kan jobbe fra. Dette betyr at vi vil dokumentere hvert trinn i konvertering av data, slik at vi raskt kan gjøre det igjen når tiden kommer til å bytte til det nye systemet.
Det første du må gjøre er å rense dataene i Excel-arbeidsboken. Det kan hjelpe å bruke Finn og erstatt, og du bør slette en kolonne eller rad som ikke inneholder data (bortsett fra kolonneoverskriftsraden, som må oppbevares). Legg til en ID-kolonne til hvert ark, i kolonne A, og fyll den ut med inkrementelle tall ved å skrive 1 i den første cellen, velg til bunnen av dataene (Skift + Slutt, Ned) og bruk deretter kommandoen Fyll ned (Ctrl + D ). Lag en hovedliste med prosjektnavn, og uansett hvor et prosjektnavn er registrert, bruk VLookup () -funksjonen for å bekrefte hoved-ID-nummeret; Hvis det ikke er noe, er det en inkonsekvens i dataene dine.
Når dataene dine er rene, er det på tide å utforme en ny database for å holde den. Vi bruker Access 2013, fordi det i vårt teoretiske eksempel er tilgjengelig for alle brukerne våre gjennom vårt Office 365-abonnement. Når du oppretter en ny Access-database, får du valget mellom å opprette den som en Access Web App eller en Access Desktop Database. Web-apper har et forenklet grensesnitt og kan bare brukes hvis du har Office 365 med SharePoint Online eller SharePoint Server 2013 med Access Services og SQL Server 2012. Vi bruker den tradisjonelle skrivebordsdatabasen, siden den gir flere alternativer og større kontroll over Brukererfaring.
Velg for å opprette en ny skrivebordsdatabase og gi den navnet: Access oppretter en ny tabell som heter Tabell 1, og plasserer deg i designvisningen med en kolonne, kalt ID. Her kan du designe tabellene du trenger i databasen din. Hver tabell skal ha et ID-felt (et automatisk trinnvis heltall), men for å unngå forvirring er det best å gi det et mer beskrivende navn. I prosjekt-tabellen ville det være ProjectID, CustomerID i kundetabellen og så videre.
Du kan angi datatypen for hver kolonne som er opprettet, og du må gi hver kolonne et navn og angi andre egenskaper og formatering som passer for feltet. Som med ID-feltet, sørg for at kolonnenavnene gjør det tydelig hvilke data som skal gå i feltet - så bruk for eksempel ProjectName i stedet for bare Name, DueDate i stedet for Due. Du kan bruke Navn og bildetekst på båndet for å lage en forkortet billedtekst så vel som det eksplisitte navnet. Du kan bruke mellomrom i kolonnenavn, men du må omgi dem med firkantede parenteser når du skriver spørsmål og rapporter.
Selv om det er fornuftig for brukerne å legge inn dataene på sine egne ark, gjør mangelen på sammenheng det vanskelig å analysere
Sett formateringen på kolonner som PercentageComplete til å være Percent og datoer som ShortDate, og også maksimal lengde på tekstfelt til en fornuftig verdi, ellers vil de alle være 255 tegn lange. Husk at noen ord (som Dato) er reservert, så du kan ikke bruke dem som kolonnenavn: bruk TaskDate eller noe mer beskrivende i stedet.
Når det gjelder kolonner der du vil slå opp en verdi i en annen tabell (for eksempel Kundekolonne i Prosjekt-tabellen), definerer du de andre tabellene i Access før du legger til oppslagskolonnen. Når det gjelder status, er det enkleste alternativet å bare skrive inn verdiene som skal vises i rullegardinlisten - men dette gjør det vanskelig å legge til eller redigere listen over mulige verdier senere. Med mindre du har å gjøre med en kort liste der mulige verdier neppe vil endre seg - for eksempel et felt som registrerer noens kjønn - er det en bedre idé å lage en annen tabell for oppføringer som ProjectStatus. Dette lar deg enkelt legge til ekstra alternativer til listen i fremtiden uten en programmeringsendring.
Forbedringer
Mens vi designer databasen vår, kan vi implementere forbedringer i forhold til den gamle regnearkbaserte måten å gjøre ting på. En klage brukerne hadde med Excel-arbeidsbøkene deres, var at hver oppgave bare inneholdt en celle for kommentarer, og noen ganger trengte de å gi mer enn en kommentar til en oppgave - eller at veilederen trengte å kommentere en oppgave, og deretter svare på dette. Å klemme alt inn i en enkelt celle gjorde det vanskelig å se når og av hvem det kom kommentarer. Vi kan gjøre det bedre ved å lage en egen tabell for kommentarer, knyttet til oppgavetabellen. På denne måten kan hver oppgave ha så mange kommentarer som nødvendig, med separate felt for dato, brukernavn og tekst til hver enkelt.
En annen forbedring vi kan gjøre er å sette oppføringer som ProjectStatus til å vises i en bestemt rekkefølge, i stedet for alfabetisk - for eksempel vil du kanskje at Fullført skal gå nederst på listen. For å gjøre dette, legg til en DisplayOrder-kolonne og bruk den til å sortere oppslagslisten. Ikke bli fristet til å bruke ID-feltet; med dette kunne nye poster bare komme på slutten av listen.
For å sikre at dataene våre forblir rene, kan vi merke felt som brukeren må fylle ut som Påkrevd, og legge til validering for å sikre at de oppgitte dataene er i riktig form. Du kan gjøre livet lettere ved å sette fornuftige standardverdier: Kommentarfeltfeltet i kommentartabellen kan ha standardverdien satt til = Dato (), som automatisk setter den til dagens dato når en ny kommentar opprettes. Du kan bruke validering sammen med en tilbaketrukket kolonne i en tabell (en boolsk) for å stoppe brukere å legge til nye poster med spesifikke verdier. Dette lar deg beholde historiske verdier som tidligere var gyldige, men som ikke brukes lenger. Disse funksjonene finner du i Tabellverktøy | Felt-fanen på båndet eller i feltegenskapene i tabelldesignvisning.
Importerer dataene dine
Når tabellene er satt opp, kan du bruke Eksterne data | Importer & lenke | Excel-knappen på båndet for å legge til dataene fra Excel-arbeidsboken til tabellene i Access-databasen. Ta en sikkerhetskopi av den tomme Access-databasen før du begynner, i tilfelle noe går galt, og start med å fylle ut de små tabellene for hånd hvis nødvendig. Ta en annen sikkerhetskopi når dette er gjort, slik at du kan komme tilbake til dette punktet hvis noe går galt i følgende trinn.
Importer nå hovedtabellene som ikke er avhengige av andre tabeller, for eksempel kunder, før du avslutter med tabellene som har relasjoner, for eksempel prosjekter og oppgaver. Hvis du omorganiserer og omdøper kolonnene i Excel-arbeidsboken for å matche feltene i Access-databasen så tett som mulig, bør du ikke ha noen problemer med å importere dataene. Husk å notere alt du gjør, slik at du kan gjenta det senere hvis du trenger å konvertere dataene igjen.
Når dataene er importert, bør tabellene i Dataarkvisning fungere mye som Excel-regnearkene gjorde - men med mye bedre datavalidering, søk og sortering. Hvis du ønsker det, kan du nå begynne å designe nye skjemaer og rapporter basert på disse dataene: for eksempel kan et hoved- / detaljskjema for prosjekter vise dataene til ett prosjekt øverst i skjemaet og et rutenett med oppgavene for det prosjekt nederst.
Du kan også sette opp skjemaet Mine oppgaver som viser alle utestående oppgaver for den nåværende brukeren, og en rapport om forsinkede oppgaver som viser alle utestående oppgaver for alle brukere som har gått forfallsdato.
Ingen fylker, vær så snill, vi er britiske
Hvis du lagrer adresser i databasen din, er det viktig å forstå hvilken informasjon du faktisk trenger. Selv om fylkesinformasjon kan være nyttig for markedsføring - og kan være nødvendig for noen utenlandske adresser - brukes den ikke lenger offisielt i britiske adresser.
hvordan du forhindrer at krom åpnes ved oppstart
Årsaken er at britiske postadresser er avhengige av konseptet med en postby, der posten for deg blir sendt og sortert før den blir levert på døren. Ikke alle byer eller landsbyer betjenes av postbyer i samme fylke - for eksempel får Melbourn (i Cambridgeshire) posten sin via Royston (i Hertfordshire) - så å spesifisere et fylke i adressen hjelper ikke nødvendigvis noen.
For å unngå forvirring sluttet postkontoret å bruke fylker i adresser tilbake i 1996, og stole på postnummerinformasjon i stedet - og innen 2016 planlegger det å fjerne fylkesnavn fra aliasdatafilen med tilleggsadresseinformasjon. Så hvis du inkluderer et fylke i en britisk adresse, vil det ganske enkelt bli ignorert.
