Vi har kiggede ved faldgruberne ved at bruge et regnearksapplikation såsom Excel til at gemme lister med data. Denne tilgang kan virke som den bedste løsning i starten, men du kan løbe ind i problemer med at dele disse data med flere brugere, validere indholdet eller endda navigere i dine data. Hvorfor? Fordi du bruger et værktøj, der ikke var designet til at udføre jobbet.
Nu overvejer vi et imaginært (men typisk) tilfælde af en virksomhed, der bruger en regnearkbaseret liste, og ser på, hvordan dette kan konverteres til en databaseapplikation for at løse sådanne problemer.
Hvordan arbejdsbøger kommer ud af hånden
Vores liste startede som en simpel oversigt over projekter, der blev gennemført for kunder. Efterhånden som virksomheden voksede, steg antallet af kunder også med navne og kontaktoplysninger tilføjet til projektmappen. Der var også behov for en eller anden måde at registrere, hvad forskellige medarbejdere gjorde på disse projekter, så endnu flere data blev tilføjet i denne projektmappe.
På dette tidspunkt blev regnearkmetoden ubrugelig: der var alt for mange mennesker, der forsøgte at holde den opdateret, ofte på samme tid. Virksomheden forsøgte at indføre en rota, så folk skiftede til at opdatere projektmappen, men det betød, at nogle opgaver blev glemt, før de blev registreret.
I sidste ende oprettede folk deres egne projektmapper for at holde styr på deres opgaver og huskede nogle gange at kopiere dataene til hovedarbejdsmappen i slutningen af ugen. Medarbejdere udviklede deres egen stenografi til disse bøger, og nogle ændrede formateringen og rækkefølgen af kolonnerne, så de passer til deres måde at arbejde på. Kopiering af disse data til hovedarbejdsbogen resulterede i et forfærdeligt rod.
Dette kan være et sammensat eksempel, men jeg har faktisk set alle disse fremgangsmåder i det virkelige liv. Lad os se nærmere på nogle af de problemer, der er kastet op af denne arbejdsmetode.
Masser af problemer
Du kan se det første ark i vores imaginære regneark. Den første kolonne beskriver navnet på det projekt, som hver post refererer til. Nogle af disse navne er imidlertid lange, så personalet kan have været fristet til at bruge forkortelser; som et resultat er der indtastet typografier. Dette gør det vanskeligt at binde hvilke opgaver, der hører til hvilket projekt. Løsningen behøver ikke at være vanskelig: du kan vælge et kort navn til hvert projekt, som alle er enige om, eller give hvert projekt et ID-nummer og automatisk oversætte dette til projektnavnet.
Der er et lignende problem med kolonnen Startet. Nogle celler indeholder en dato, men andre registrerer kun en måned - og en eller to poster siger bare Ja. Excel understøtter datavalidering, så det er muligt at sikre, at bestemte celler altid indeholder data af en bestemt type - men når et regneark udvikles ad hoc-måde, bruges det sjældent.
På dette tidspunkt bliver regnearksmetoden ubrugelig: der var alt for mange mennesker, der prøvede at holde det opdateret
Du har ikke dette problem i en databaseapplikation, da datatypen for feltet vil blive rettet fra starten. Hvis du ikke ved den nøjagtige dato, hvor arbejdet startede, kan du bruge den første i måneden eller 1. januar, hvis du kun kender året. Hvis projektet endnu ikke er startet, kan du lade feltet være tomt - en NULL i databasetermer. Hvis du vidste, at projektet var startet, men ikke vidste hvornår, kan du bruge en dato, der normalt ville være umulig for dine data, såsom 1/1/1900. Straks bliver det let at sortere projekter og få et kronologisk overblik over aktivitet.
En mere subtil udfordring præsenteres af kolonnen mærket Client. Posterne i denne kolonne er ikke knyttet til noget andet i projektmappen, men der er en liste over kunder på ark 1, hvilket sandsynligvis er det, det henviser til. Det er forvirrende at gemme flere lister over de samme emner, der henvises til med forskellige navne. Du er nødt til at afklare navngivningen og sætte dig ind i et entydigt navn for denne enhed: er det kunder eller kunder?
Statuskolonnen er en anden, hvor der ikke har været nogen validering, så folk har igen valgt at skrive, hvad de vil. Det ville være bedre at oprette en kort liste over alle de tilladte værdier.
Det andet ark - ark 1 - er lige så problematisk. Til at begynde med er arknavnet ikke beskrivende. Hvad den faktisk indeholder er en liste med overskriften Kunder, men dette er ikke formateret som en tabel i Excel: Adressen er i et felt, hvilket begrænser din evne til at bruge Excels indbyggede værktøjer til at søge eller sortere den. Du kan for eksempel filtrere efter adresser, der indeholder Cardiff, men resultaterne vil også omfatte dem på Cardiff Road i Newport.
Når det kommer til adresser, er den bedste tilgang at bruge separate felter til postnummer, amt, by og gade (selvom amtoplysninger er valgfri for britiske adresser - se Ingen amter, vi er britiske). Street skal indeholde alt, hvad der ikke findes i de andre dele af adressen.
Der er et kontaktfelt, der også giver problemer. Hvor vi har flere kontakter inden for en enkeltklientvirksomhed, er deres navne alle blevet klumpet ind i dette felt med deres telefonnumre og e-mail-adresser på samme måde placeret i de andre felter. At adskille disse ud vil være udfordrende - især hvis der er tre navne i kontaktfeltet, men kun to telefonnumre.
Den sidste kolonne i dette ark har overskriften Sidste kontakt: medarbejdere formodes at opdatere dette hver gang de kontakter en kunde. Da disse oplysninger er en ekstra ting for medarbejderen at huske, og der ikke er nogen garanti for, at de vil - især da de er skjult ud af vejen på et andet ark - de er upålidelige. Dette er virkelig noget, som computeren automatisk skal spore.
Endelig kommer vi til opgavearkene, der beskriver opgaverne og kommentarerne for hver arbejdstager. Disse navngives ikke konsekvent og indeholder ikke de samme kolonner i samme rækkefølge. Mens det giver mening for individuelle brugere at indtaste deres data på deres egne ark, gør manglen på sammenhæng det vanskeligt at samle og analysere dataene. Når en leder f.eks. Ønsker at se, hvad der er udført på hvert projekt, skal alle opgaver kopieres manuelt fra de enkelte ark til en liste, før de kan sorteres og rapporteres om.
Opbygning af din database
At sortere disse problemer vil tage noget arbejde, muligvis flere dage. Da brugerne sandsynligvis bliver nødt til at fortsætte med at bruge det gamle system, mens vi bygger et nyt, er det bedst at lave en kopi af de eksisterende projektmapper, hvorfra de kan arbejde. Dette betyder, at vi vil dokumentere hvert trin i konvertering af data, så vi hurtigt kan gøre det igen, når tiden er inde til at skifte til det nye system.
Den første ting, du skal gøre, er at rense dataene i din Excel-projektmappe. Brug af Find & erstat kan hjælpe, og du skal slette enhver kolonne eller række, der ikke indeholder data (undtagen kolonneoverskriftsrækken, som skal holdes). Føj en ID-kolonne til hvert ark i kolonne A, og udfyld det med trinvise tal ved at skrive 1 i den første celle, vælge nederst i dataene (Skift + Slut, Ned) og derefter bruge kommandoen Udfyld (Ctrl + D ). Opret en masterliste med projektnavne, og hvor et projektnavn der er registreret, skal du bruge VLookup () -funktionen til at bekræfte dets master-ID-nummer; hvis der ikke er noget tal, er der en inkonsekvens i dine data.
Når dine data er rene, er det tid til at designe en ny database, der indeholder dem. Vi bruger Access 2013, fordi det i vores teoretiske eksempel er tilgængeligt for alle vores brugere via vores Office 365-abonnement. Når du opretter en ny Access-database, får du valget mellem at oprette den som en Access Web-app eller en Access Desktop-database. Webapps har en forenklet grænseflade og kan kun bruges, hvis du har Office 365 med SharePoint Online eller SharePoint Server 2013 med Access Services og SQL Server 2012. Vi bruger den traditionelle Desktop Database, da den giver flere muligheder og større kontrol over brugererfaring.
Vælg for at oprette en ny Desktop-database og navngive den: Access opretter en ny tabel kaldet tabel 1 og placerer dig i designvisningen med en kolonne, kaldet ID. Her kan du designe de tabeller, du har brug for i din database. Hver tabel skal have et ID-felt (et automatisk inkrementelt heltal), men for at undgå forvirring er det bedst at give det et mere beskrivende navn. I tabellen Projekter ville det være ProjectID, CustomerID i tabellen Kunder osv.
Du kan indstille datatypen for hver kolonne, der oprettes, og du skal give hver kolonne et navn og indstille andre egenskaber og formatering efter behov. Som med ID-feltet skal du sørge for, at kolonnenavnene gør det indlysende, hvilke data der skal være i feltet - så brug f.eks. ProjectName snarere end bare Navn, DueDate i stedet for Due. Du kan bruge knappen Navn og billedtekst på båndet til at oprette en forkortet billedtekst samt det eksplicitte navn. Du kan bruge mellemrum i kolonnenavne, men du bliver nødt til at omgive dem med firkantede parenteser, når du skriver forespørgsler og rapporter.
Mens det giver mening for brugerne at indtaste deres data på deres egne ark, gør manglen på sammenhæng det vanskeligt at analysere
Indstil formateringen på kolonner som PercentageComplete til at være Procent og datoer, der skal være ShortDate, og også den maksimale længde af tekstfelter til en fornuftig værdi, ellers vil de alle være 255 tegn lange. Husk, at nogle ord (f.eks. Dato) er reserveret, så du kan ikke bruge dem som kolonnenavne: brug TaskDate eller noget andet mere beskrivende i stedet.
Når det kommer til kolonner, hvor du vil slå en værdi op i en anden tabel (f.eks. Kolonnen Kund i tabellen Projekter), skal du definere de andre tabeller i Access, før du tilføjer opslagskolonnen. Når det kommer til status, er den enkleste mulighed bare at skrive de værdier, der skal vises i rullelisten - men det gør det vanskeligt at tilføje eller redigere listen over mulige værdier senere. Medmindre du har at gøre med en kort liste, hvor mulige værdier sandsynligvis ikke ændres - såsom et felt, der optager en persons køn - er det en bedre idé at oprette en anden tabel til poster som ProjectStatus. Dette giver dig mulighed for nemt at tilføje ekstra muligheder til listen i fremtiden uden en programmeringsændring.
Forbedringer
Mens vi designer vores database, kan vi implementere forbedringer i forhold til den gamle regnearksbaserede måde at gøre tingene på. En klage, som vores brugere havde over deres Excel-projektmapper, var, at hver opgave kun indeholdt en celle til kommentarer, og nogle gange var de nødt til at komme med mere end en kommentar til en opgave - eller supervisoren havde brug for at kommentere en opgave, og derefter brugeren svar på dette. At klemme alt sammen i en enkelt celle gjorde det vanskeligt at se, hvornår og af hvem der blev fremsat kommentarer. Vi kan gøre det bedre ved at oprette en separat tabel til kommentarer, der er knyttet til tabellen Tasks. På denne måde kan hver opgave have så mange kommentarer som nødvendigt med separate felter til dato, brugernavn og tekst for hver enkelt.
En anden forbedring, vi kan foretage, er at indstille poster som ProjectStatus til at blive vist i en bestemt rækkefølge i stedet for alfabetisk - for eksempel vil du muligvis have Fuldført til at gå nederst på listen. For at gøre dette skal du tilføje en DisplayOrder-kolonne og bruge den til at sortere opslagslisten. Vær ikke fristet til at bruge ID-feltet; med dette kunne nye poster kun gå i slutningen af listen.
For at sikre, at vores data forbliver rene, kan vi markere felter, som brugeren skal udfylde som krævet, og tilføje validering for at sikre, at de indtastede data er i den korrekte form. Du kan gøre livet lettere ved at indstille fornuftige standardværdier: feltet Kommentar dato i tabellen Kommentarer kan have sin standardværdi sat til = Dato (), som automatisk indstiller det til dagens dato, hver gang en ny kommentar oprettes. Du kan bruge validering sammen med en trukket kolonne i en tabel (en boolsk) for at stoppe brugere med at tilføje nye poster med specifikke værdier. Dette giver dig mulighed for at beholde historiske værdier, der tidligere var gyldige, men som ikke bruges mere. Disse funktioner kan alle findes i Tabelværktøjer | Fanen Felter på båndet eller i feltegenskaberne i tabeldesignvisning.
Importerer dine data
Når dine tabeller er oprettet, kan du bruge de eksterne data | Import & link | Excel-knappen på båndet for at tilføje dataene fra din Excel-projektmappe til tabellerne i din Access-database. Lav en sikkerhedskopi af din tomme Access-database, før du starter, hvis noget går galt, og start med at udfylde de små tabeller i hånden, hvis det er nødvendigt. Tag en anden sikkerhedskopi, når dette er gjort, så du kan komme tilbage til dette punkt, hvis noget går galt i de følgende trin.
Importer nu hovedtabellerne, der ikke er afhængige af andre tabeller, f.eks. Kunder, inden du afslutter med de tabeller, der har forhold, såsom projekter og opgaver. Hvis du omarrangerer og omdøber kolonnerne i din Excel-projektmappe for at matche felterne i din Access-database så tæt som muligt, skal du ikke have problemer med at importere dataene. Husk at notere alt, hvad du laver, så du kan gentage det senere, hvis du har brug for at konvertere dataene igen.
Når dataene først er importeret, skal tabellerne i databladvisning fungere meget som Excel-regnearkene gjorde - men med meget bedre datavalidering, søgning og sortering. Hvis du ønsker det, kan du nu begynde at designe nye formularer og rapporter baseret på disse data: for eksempel kan en Master / Detail-formular til Projekter muligvis vise dataene for et projekt øverst i formularen og et gitter med opgaverne til det projektet i bunden.
Du kan også oprette en formular Mine opgaver, der viser alle de udestående opgaver for den aktuelle bruger og en rapport om forsinkede opgaver, der viser alle de udestående opgaver for alle brugere, der har forfaldsdato.
Ingen amter, tak, vi er britiske
Hvis du gemmer adresser i din database, er det vigtigt at forstå, hvilke oplysninger du faktisk har brug for. Selvom amtsoplysninger kan være nyttige til markedsføring - og det kan være nødvendigt for nogle udenlandske adresser - bruges de ikke længere officielt i britiske adresser.
hvordan du ændrer dit navn i lol
Årsagen er, at britiske postadresser er afhængige af konceptet med en postby, hvor post til dig sendes og sorteres, inden den leveres til din dør. Ikke alle byer eller landsbyer betjenes af postbyer i samme amt - for eksempel modtager Melbourn (i Cambridgeshire) sin mail gennem Royston (i Hertfordshire) - så det at specificere et amt i adressen hjælper ikke nødvendigvis nogen.
For at undgå forvirring stoppede postvæsenet at bruge amter i adresser tilbage i 1996 og stole på postnummeroplysninger i stedet - og i 2016 planlægger det at fjerne amtsnavne fra aliasdatafilen med supplerende adresseoplysninger. Så hvis du inkluderer et amt i en britisk adresse, bliver det simpelthen ignoreret.
