Vi har tittade vid fallgroparna med att använda ett kalkylprogram som Excel för att lagra datalistor. Detta tillvägagångssätt kan tyckas vara den bästa lösningen till en början, men du kan stöta på problem med att dela den informationen med flera användare, validera innehållet eller till och med navigera i dina data. Varför? Eftersom du använder ett verktyg som inte var utformat för att göra jobbet.
Nu överväger vi ett imaginärt (men typiskt) fall av ett företag som använder en kalkylbaserad lista och tittar på hur detta kan konverteras till en databasapplikation för att lösa sådana problem.
Hur arbetsböcker går ur hand
Vår lista började som en enkel registrering av projekt som genomförts för kunder. När företaget växte ökade också antalet kunder med namn och kontaktuppgifter till arbetsboken. Det behövdes också något sätt att registrera vad olika anställda gjorde på dessa projekt, så ännu mer data lades till i denna arbetsbok.
Vid det här tillfället blev kalkylarkmetoden obrukbar: det var alldeles för många som försökte hålla det uppdaterat, ofta samtidigt. Företaget försökte sätta in en rota, så att folk turade i tur och ordning för att uppdatera arbetsboken, men det innebar att vissa uppgifter glömdes bort innan de spelades in.
I slutändan skapade människor sina egna arbetsböcker för att hålla reda på sina uppgifter, ibland kommer de ihåg att kopiera data till huvudarboken i slutet av veckan. Anställda utvecklade sin egen stenografi för dessa böcker, och vissa ändrade kolonnernas formatering och ordning för att passa deras sätt att arbeta. Att kopiera dessa data till huvudarbetsboken resulterade i en hemsk röra.
Det här kan vara ett sminkat exempel, men jag har faktiskt sett alla dessa metoder i verkligheten. Låt oss titta närmare på några av de frågor som kastas upp av denna arbetsmetod.
Massor av problem
Du kan se det första arket i vårt imaginära kalkylblad. Den första kolumnen beskriver namnet på projektet som varje post hänvisar till. Några av dessa namn är dock långa, så personalen kan ha varit frestad att använda förkortningar; som ett resultat har skrivfel krypt in. Detta gör det svårt att knyta samman vilka uppgifter som hör till vilket projekt. Lösningen behöver inte vara svår: du kan välja ett kort namn för varje projekt som alla är överens om, eller ge varje projekt ett ID-nummer och översätta det automatiskt till projektnamnet.
Det finns ett liknande problem med kolumnen Startad. Vissa celler innehåller ett datum, men andra spelar bara in en månad - och en eller två poster säger bara Ja. Excel stöder datavalidering, så det är möjligt att säkerställa att vissa celler alltid innehåller data av en viss typ - men när ett kalkylark utvecklas på ett ad hoc-sätt används det sällan.
Vid det här tillfället blir kalkylarkmetoden obrukbar: det var alldeles för många som försökte hålla det uppdaterat
Du har inte det här problemet i en databasapplikation, eftersom datatypen för fältet kommer att fixas från början. Om du inte vet exakt när arbetet började kan du använda den första i månaden eller den 1 januari om du bara vet året. Om projektet ännu inte har startat kan du lämna fältet tomt - en NULL i databastermer. Om du visste att projektet hade startats men inte visste när kan du använda ett datum som vanligtvis skulle vara omöjligt för dina uppgifter, till exempel 1/1/1900. Omedelbart blir det enkelt att sortera projekt och få en kronologisk översikt över verksamheten.
En mer subtil utmaning presenteras av kolumnen Client. Posterna i den här kolumnen är inte länkade till något annat i arbetsboken, men det finns en lista med kunder på blad 1, vilket förmodligen är vad det hänvisar till. Det är förvirrande att lagra flera listor med samma objekt, som det hänvisas till med olika namn. Du måste klargöra namngivningen och bestämma dig för ett entydigt namn för denna enhet: är de kunder eller kunder?
Kolumnen Status är en annan där det inte har gjorts någon validering, så människor har åter valt att skriva vad de vill. Det vore bättre att upprätta en kort lista över alla tillåtna värden.
Det andra arket - Ark 1 - är lika problematiskt. Till en början är arkets namn inte beskrivande. Vad den faktiskt innehåller är en lista med rubriken Kunder, men den här formateras inte som en tabell i Excel: adressen finns i ett fält, vilket begränsar din förmåga att använda Excels inbyggda verktyg för att söka eller sortera den. Du kan till exempel filtrera efter adresser som innehåller Cardiff, men resultaten skulle också inkludera dem på Cardiff Road i Newport.
När det gäller adresser är det bästa sättet att använda separata fält för postnummer, grevskap, stad och gata (även om grevskapsinformation är frivilligt för brittiska adresser - se Inga län, snälla, vi är brittiska). Street ska innehålla allt som inte finns i de andra delarna av adressen.
Det finns ett kontaktfält som också ger problem. Där vi har flera kontakter inom ett enklientföretag har deras namn alla klumpats in i det här fältet, med deras telefonnummer och e-postadresser placerade på samma sätt i de andra fälten. Att separera dessa kommer att vara utmanande - speciellt om det finns tre namn i fältet Kontakt men bara två telefonnummer.
Den sista kolumnen i detta blad har rubriken Senast kontaktad: anställda ska uppdatera detta varje gång de kommer i kontakt med en kund. Eftersom den här informationen är en extra sak för medarbetaren att komma ihåg, och det finns ingen garanti för att de kommer att göra det - särskilt eftersom den är gömd ur vägen på ett andra ark - det är opålitligt. Detta är verkligen något som datorn borde spåra automatiskt.
Slutligen kommer vi till Uppgiftsblad, som beskriver uppgifterna och kommentarerna för varje arbetare. Dessa namnges inte konsekvent och innehåller inte samma kolumner i samma ordning. Även om det är vettigt för enskilda användare att mata in sina data på sina egna ark, gör bristen på enhetlighet det svårt att samla in och analysera data. När en chef till exempel vill se vilket arbete som har utförts på varje projekt måste alla uppgifter kopieras för hand från de enskilda arken till en lista innan de kan sorteras och rapporteras.
Bygga din databas
Att sortera ut dessa frågor kommer att ta lite arbete, eventuellt flera dagar. Eftersom användare antagligen måste fortsätta använda det gamla systemet medan vi bygger ett nytt, är det bäst att göra en kopia av de befintliga arbetsböckerna som de kan arbeta från. Det betyder att vi vill dokumentera varje steg för att konvertera data, så att vi snabbt kan göra det igen när det är dags att byta till det nya systemet.
Det första du behöver göra är att rengöra data i din Excel-arbetsbok. Med hjälp av Sök och ersätt kan det hjälpa, och du bör ta bort alla kolumner eller rader som inte innehåller data (förutom kolumnrubriken, som måste sparas). Lägg till en ID-kolumn i varje ark, i kolumn A, och fyll den med stegvisa siffror genom att skriva 1 i den första cellen, markera längst ner på data (Skift + Slut, Ner) och använd sedan kommandot Fyll ner (Ctrl + D ). Skapa en huvudlista med projektnamn och varhelst ett projektnamn spelas in använder du funktionen VLookup () för att bekräfta dess huvud-ID-nummer. om det inte finns något nummer finns det en inkonsekvens i dina data.
När dina data är rena är det dags att utforma en ny databas för att hålla den. Vi använder Access 2013, eftersom det i vårt teoretiska exempel är tillgängligt för alla våra användare via vår Office 365-prenumeration. När du skapar en ny Access-databas får du valet att skapa den som en Access-webbapp eller en Access Desktop-databas. Webappar har ett förenklat gränssnitt och kan endast användas om du har Office 365 med SharePoint Online eller SharePoint Server 2013 med Access Services och SQL Server 2012. Vi använder den traditionella skrivbordsdatabasen, eftersom den erbjuder fler alternativ och större kontroll över användarupplevelse.
Välj för att skapa en ny skrivbordsdatabas och namnge den: Access skapar en ny tabell som heter Tabell 1 och placerar dig i designvyn med en kolumn, kallad ID. Här kan du designa de tabeller du behöver i din databas. Varje tabell bör ha ett ID-fält (ett automatiskt stegvis heltal), men för att undvika förvirring är det bäst att ge det ett mer beskrivande namn. I tabellen Projekt skulle det vara ProjectID, CustomerID i tabellen Kunder och så vidare.
Du kan ställa in datatypen för varje kolumn som skapas och du måste ge varje kolumn ett namn och ange andra egenskaper och formatering som är lämpligt för fältet. Som med ID-fältet, se till att kolumnnamnen gör det uppenbart vilka data som ska finnas i fältet - så använd till exempel ProjectName snarare än bara Namn, DueDate snarare än Due. Du kan använda knappen Namn & bildtext på menyfliksområdet för att skapa en förkortad bildtext samt det explicita namnet. Du kan använda mellanslag i kolumnnamn, men du måste omge dem med hakparenteser när du skriver frågor och rapporter.
Även om det är vettigt för användare att mata in sina uppgifter på sina egna ark, gör bristen på enhetlighet det svårt att analysera
Ställ in formateringen på kolumner som PercentageComplete till Procent och datum som ShortDate, och även den maximala längden på textfält till ett förnuftigt värde, annars kommer de alla att vara 255 tecken långa. Kom ihåg att vissa ord (som Datum) är reserverade, så du kan inte använda dem som kolumnnamn: använd TaskDate eller något annat mer beskrivande istället.
När det gäller kolumner där du vill slå upp ett värde i en annan tabell (till exempel kundkolumnen i tabellen Projekt), definierar du de andra tabellerna i Access innan du lägger till uppslagskolumnen. När det gäller status är det enklaste alternativet att bara skriva in de värden som ska visas i listrutan - men det gör det svårt att lägga till eller redigera listan över möjliga värden senare. Om du inte har en kort lista där möjliga värden osannolikt ändras - till exempel ett fält som registrerar någons kön - är det en bättre idé att skapa en annan tabell för poster som ProjectStatus. Detta gör att du enkelt kan lägga till extra alternativ till listan i framtiden utan programmeringsändring.
Förbättringar
Medan vi utformar vår databas kan vi implementera förbättringar jämfört med det gamla kalkylbaserade sättet att göra saker på. Ett klagomål våra användare hade med sina Excel-arbetsböcker var att varje uppgift endast innehöll en cell för kommentarer, och ibland behövde de göra mer än en kommentar till en uppgift - eller chefen behövde kommentera en uppgift och sedan användaren svara på detta. Att klämma in allt i en enda cell gjorde det svårt att se när, och av vem, kommentarer kom. Vi kan göra det bättre genom att skapa en separat tabell för kommentarer, länkad till tabellen Uppgifter. På detta sätt kan varje uppgift ha så många kommentarer som behövs, med separata fält för datum, användarnamn och text för var och en.
En annan förbättring vi kan göra är att ställa in poster som ProjectStatus så att de visas i en viss ordning, snarare än alfabetiskt - till exempel kanske du vill att Slutfört ska gå längst ner i listan. För att göra detta, lägg till en DisplayOrder-kolumn och använd den för att sortera uppslagslistan. Frestas inte att använda ID-fältet; med detta kunde alla nya poster bara gå i slutet av listan.
För att säkerställa att våra uppgifter förblir rena kan vi markera fält som användaren måste fylla i som krävs och lägga till validering för att säkerställa att de angivna uppgifterna är i rätt form. Du kan göra livet enklare genom att ställa in förnuftiga standardvärden: i fältet Kommentardatum i kommentartabellen kan standardvärdet vara inställt på = Datum (), vilket automatiskt ställer in det till dagens datum när en ny kommentar skapas. Du kan använda validering tillsammans med en tillbakadragen kolumn i en tabell (en boolean) för att stoppa användare att lägga till nya poster med specifika värden. Detta gör att du kan behålla historiska värden som tidigare var giltiga, men som inte används längre. Dessa funktioner finns alla i Tabellverktyg | Fältfält på menyfliksområdet eller i fältegenskaperna i tabelldesignvyn.
Importera dina data
När dina tabeller har ställts in kan du använda externa data | Importera och länka | Excel-knappen på menyfliksområdet för att lägga till data från din Excel-arbetsbok till tabellerna i din Access-databas. Gör en säkerhetskopia av din tomma Access-databas innan du börjar, om något går fel, och börja med att fylla i de små tabellerna för hand om det behövs. Ta ytterligare en säkerhetskopia när detta är gjort så att du kan komma tillbaka till den här punkten om något går fel i följande steg.
Importera nu huvudtabellerna som inte är beroende av några andra tabeller, till exempel kunder, innan du avslutar med de tabeller som har relationer, till exempel projekt och uppgifter. Om du ordnar om och byter namn på kolumnerna i din Excel-arbetsbok så att de matchar fälten i din Access-databas så nära som möjligt, borde du inte ha några svårigheter att importera data. Kom ihåg att anteckna allt du gör så att du kan upprepa det senare om du behöver konvertera data igen.
När data väl har importerats bör tabellerna i databladvyn fungera mycket som Excel-kalkylbladet gjorde - men med mycket bättre datavalidering, sökning och sortering. Om du vill kan du nu börja utforma nya formulär och rapporter baserat på dessa data: till exempel kan ett Master / Detail-formulär för projekt visa data för ett projekt högst upp i formuläret och ett rutnät för uppgifterna för det projektet längst ner.
Du kan också skapa ett formulär Mina uppgifter som visar alla utestående uppgifter för den aktuella användaren och en rapport om försenade uppgifter som visar alla utestående uppgifter för alla användare som har gått efter förfallodagen.
Inga län, snälla, vi är brittiska
Om du lagrar adresser i din databas är det viktigt att förstå vilken information du faktiskt behöver. Även om landstingsinformation kan vara användbar för marknadsföring - och kan behövas för vissa utländska adresser - används den inte längre officiellt i brittiska adresser.
hur man hittar oläst e-post i gmail
Anledningen är att postadresserna i Storbritannien är beroende av konceptet med en poststad, där post för dig skickas och sorteras innan den levereras till din dörr. Inte alla städer eller byar betjänas av poststäder i samma län - till exempel får Melbourn (i Cambridgeshire) sin post via Royston (i Hertfordshire) - så att ange ett län i adressen hjälper inte nödvändigtvis någon.
För att undvika förvirring slutade postkontoret att använda län i adresser redan 1996 och förlitade sig på postnummerinformation istället - och före 2016 planerar den att ta bort lännamn från aliasdatafilen med kompletterande adressinformation. Så om du inkluderar ett län i en brittisk adress kommer det helt enkelt att ignoreras.
