Mi vagyunk nézett az adatlisták tárolására szolgáló táblázatkezelő alkalmazás, például az Excel buktatóinál. Ez a megközelítés elsőre a legjobb megoldásnak tűnhet, de problémákba ütközhet az adatok több felhasználóval történő megosztása, a tartalom érvényesítése vagy akár az adatok navigálása. Miért? Mert olyan eszközt használ, amelyet nem a munka elvégzésére terveztek.
Most egy vállalkozás képzeletbeli (de tipikus) esetét vesszük figyelembe táblázatkezelő listát használva, és megvizsgáljuk, hogyan lehet ezt átalakítani adatbázis-alkalmazássá az ilyen problémák leküzdése érdekében.
Hogyan kerülnek ki a munkafüzetek a kezéből
A listánk az ügyfelek számára vállalt projektek egyszerű nyilvántartásaként kezdődött. A vállalat növekedésével az ügyfelek száma is nőtt, nevekkel és elérhetőségekkel együtt a munkafüzetbe. Szükség volt valamilyen módon annak rögzítésére is, hogy a személyzet különböző tagjai mit csináltak ezeken a projekteken, így még több adat került be ebbe a munkafüzetbe.
Ekkor a táblázatos megközelítés működésképtelenné vált: túl sokan próbálták naprakészen tartani, gyakran egyszerre. A vállalat megpróbálta bevezetni a rotációt, hogy az emberek felváltva frissítsék a munkafüzetet, de ez azt jelentette, hogy néhány feladatot elfelejtettek, mielőtt azokat rögzítették volna.
Végül az emberek saját munkafüzeteiket állítják össze, hogy nyomon kövessék feladataikat, és néha emlékeznek arra, hogy a hét végén lemásolják az adatokat a fő munkafüzetbe. Az alkalmazottak kidolgozták saját rövidítésüket ezekhez a könyvekhez, és néhányan megváltoztatták az oszlopok formátumát és sorrendjét a munkamódszerüknek megfelelően. Ezeknek az adatoknak a fő munkafüzetbe történő másolása szörnyű rendetlenséget eredményezett.
Lehet, hogy ez egy kitalált példa, de ezeket a gyakorlatokat valóban láttam a való életben. Vizsgáljuk meg közelebbről a munka ezen módszerével felvetett néhány kérdést.
Rengeteg probléma
Képzeletbeli táblázatunk első lapját láthatja. Az első oszlop részletezi annak a projektnek a nevét, amelyre az egyes bejegyzések utalnak. E nevek némelyike azonban hosszú, ezért a személyzet kísértést érezhetett a rövidítések használatával; ennek eredményeként elgépelték a hibákat. Ez megnehezíti a projektekhez tartozó feladatok lekötését. A megoldásnak nem kell nehéznek lennie: kiválaszthatja az egyes projektek rövid nevét, amelyben mindenki egyetért, vagy megadhat minden projektnek azonosító számot, és ezt automatikusan lefordíthatja a projekt nevére.
Hasonló probléma van a Started oszloppal is. Egyes cellák tartalmaznak dátumot, de mások csak egy hónapot rögzítenek - és egy vagy két rekord csak azt mondja, hogy Igen. Az Excel támogatja az adatok hitelesítését, így biztosítani lehet, hogy az egyes cellák mindig tartalmazzanak egy adott típusú adatot - de ha egy táblázatot ad hoc módon fejlesztenek, azt ritkán használják.
Ekkor a táblázatos megközelítés működésképtelenné válik: túl sokan próbálták naprakészen tartani
Ez a probléma egy adatbázis-alkalmazásban nem fog jelentkezni, mivel a mező adattípusa eleve javításra kerül. Ha nem tudja a munka megkezdésének pontos dátumát, használhatja a hónap elsőjét, vagy január 1-jét, ha csak az évet ismeri. Ha a projekt még nem kezdődött el, akkor a mezőt üresen hagyhatja - NULL adatbázisban. Ha tudta, hogy a projekt elindult, de nem tudta, mikor, használhat olyan dátumot, amely általában lehetetlen lenne az adatai számára, például 1900.01.01. Azonnal megkönnyíti a projektek rendezését és a tevékenység időrendi áttekintését.
Finomabb kihívást jelent az Ügyfél feliratú oszlop. Ennek az oszlopnak a bejegyzései nem kapcsolódnak semmi máshoz a munkafüzetben, de az 1. lapon megtalálható az Ügyfelek listája, amely valószínűleg erre utal. Összezavaró ugyanazon elemek több listája, más néven hivatkozva. Pontosítania kell az elnevezést és meg kell határoznia az entitás egyértelmű nevét: ügyfelek vagy ügyfelek?
Az Állapot oszlop egy másik, ahol nem történt érvényesítés, ezért az emberek ismét úgy döntöttek, hogy bármit írnak. Jobb lenne elkészíteni az összes megengedett érték rövid listáját.
A második lap - az 1. lap - ugyanolyan problémás. Először is, a lap neve nem leíró jellegű. Amit valójában tartalmaz, az az ügyfelek fejlécű lista, de ez nem formázva táblázatos formában az Excelben: a cím egy mezőben van, ami korlátozza az Excel beépített eszközeinek használatát a kereséshez vagy rendezéshez. Szűrheti például azokat a címeket, amelyek Cardiff-ot tartalmaznak, de az eredmények a Newport-i Cardiff Roadon találhatóakat is tartalmazzák.
A címekről a legjobb megközelítés, ha külön mezőket használ az irányítószámhoz, a megyéhez, a városhoz és az utcához (bár a megyei információk nem kötelezőek az Egyesült Királyság címeihez - lásd: Nincs megye, kérjük, mi britek vagyunk). Az utcának tartalmaznia kell mindent, ami nincs a cím többi részében.
Van egy Kapcsolat mező, amely problémákat is bemutat. Ahol több ügyfélkapcsolatunk van egy ügyfelet számláló vállalkozáson belül, a nevüket mind ebbe a mezőbe helyezték, telefonszámukat és e-mail címüket hasonlóan helyezték el a többi mezőben. Ezek elkülönítése nagy kihívást jelent - különösen, ha három név szerepel a Kapcsolat mezőben, de csak két telefonszám van.
Ennek a lapnak az utolsó oszlopa az Utolsó kapcsolatfelvétel címsor: az alkalmazottaknak ezt frissíteniük kell minden alkalommal, amikor kapcsolatba lépnek az ügyféllel. Mivel ezeket az információkat külön meg kell említeni az alkalmazott számára, és nincs garancia arra, hogy megteszik - főleg, hogy el van rejtve egy második lapon -, ezért nem megbízható. Ezt a számítógépnek automatikusan követnie kell.
Végül elérkezünk a Feladatok lapokhoz, amelyek részletesen bemutatják az egyes munkavállalók feladatait és megjegyzéseit. Ezeket nem nevezik meg következetesen, és nem tartalmazzák ugyanazokat az oszlopokat ugyanabban a sorrendben. Noha az egyes felhasználóknak van értelme adataikat a saját lapjukra bevinni, a koherencia hiánya megnehezíti az adatok összegyűjtését és elemzését. Amikor a menedzser meg akarja nézni, hogy az egyes projekteken milyen munkát végeztek, például az összes feladatot kézzel kell átmásolni az egyes lapokból egy listába, mielőtt azok rendezésre és jelentésre kerülnének.
Az adatbázis felépítése
E kérdések rendezése némi munkát, esetleg több napot is igénybe vesz. Mivel a felhasználóknak valószínűleg folytatniuk kell a régi rendszer használatát, amíg új rendszert építünk, a legjobb, ha másolatot készítünk a meglévő munkafüzetekből, amelyekből dolgozhatunk. Ez azt jelenti, hogy dokumentálni akarjuk az adatok konvertálásának minden lépését, így gyorsan meg tudjuk csinálni újra, amikor eljön az ideje az új rendszerre való áttérésnek.
Először meg kell tisztítania az Excel-munkafüzet adatait. A Keresés és csere használata segíthet, és törölnie kell minden olyan oszlopot vagy sort, amely nem tartalmaz adatokat (kivéve az oszlopfejléc sorát, amelyet meg kell őrizni). Adjon hozzá egy azonosító oszlopot az A oszlop minden egyes lapjához, és töltse fel növekményes számokkal úgy, hogy az első cellába írja be az 1-et, majd válassza az adatok aljára (Shift + End, Down), majd használja a Fill Down parancsot (Ctrl + D ). Hozzon létre egy fő listát a projektnevekről, és bárhol is legyen rögzítve egy projektnév, használja a VLookup () függvényt annak fő azonosító számának megerősítésére; ha nincs szám, következetlenség áll fenn az adataiban.
Miután az adatai tiszták, itt az ideje egy új adatbázist megtervezni a tárolásához. Az Access 2013-at fogjuk használni, mert elméleti példánkban az összes felhasználó számára elérhető az Office 365-előfizetésünkön keresztül. Új Access adatbázis létrehozásakor választhat, hogy azt Access Web App-ként vagy Access Desktop adatbázisként hozza létre. A webalkalmazásoknak egyszerűsített felülete van, és csak akkor használhatók, ha Office 365-ös SharePoint Online vagy SharePoint Server 2013 Access Services és SQL Server 2012 rendszert használunk. A hagyományos Asztali adatbázist fogjuk használni, mivel ez több lehetőséget kínál és nagyobb ellenőrzést biztosít a felhasználói tapasztalat.
Válasszon egy új asztali adatbázis létrehozásához és elnevezéséhez: Az Access létrehoz egy új táblázatot, amelynek neve 1. táblázat, és egy oszlopba, az úgynevezett ID-be helyezi a Tervező nézetet. Itt megtervezheti az adatbázisában szükséges táblákat. Minden táblának rendelkeznie kell egy ID mezővel (automatikusan növekvő egész számmal), de a félreértések elkerülése érdekében a legjobb, ha leíróbb nevet adunk neki. A Projektek táblában ez a ProjectID, az Ügyfelek táblázatban az ÜgyfélID és így tovább.
Beállíthatja az összes létrehozott oszlop adattípusát, és minden oszlopnak nevet kell adnia, és a mezőnek megfelelő egyéb tulajdonságokat és formázást kell megadnia. Az azonosító mezőhöz hasonlóan, győződjön meg arról, hogy az oszlopnevek nyilvánvalóvá teszik, milyen adatoknak kell a mezőbe kerülniük - így például a ProjektNév helyett csak a Név, az esedékesség helyett az esedékességet használja. A szalag Név és felirat gombjával létrehozhat rövidített feliratot, valamint az explicit nevet. Használhat szóközt az oszlopnevekben, de lekérdezések és jelentések írásakor szögletes zárójelekkel kell körülvennie őket.
Noha a felhasználóknak van értelme saját adataikba bevinni adataikat, a koherencia hiánya megnehezíti az elemzést
Állítsa a formázást az olyan oszlopokhoz, mint a PercentageComplete, és a dátumok legyen ShortDate, valamint a szövegmezők maximális hosszát ésszerű értékre, különben 255 karakter hosszúak lesznek. Ne feledje, hogy egyes szavak (például a Dátum) fenntartva vannak, ezért nem használhatja őket oszlopnévként: használja helyette a TaskDate vagy valami más leírást.
Ha olyan oszlopokról van szó, amelyekben egy másik táblázatban szeretne értéket keresni (például a Projekt oszlop Ügyfél oszlopában), akkor a keresési oszlop hozzáadása előtt határozza meg az Access többi tábláját. Ami az Állapotot illeti, a legegyszerűbb lehetőség az, hogy egyszerűen beírja a megjelenítendő értékeket a legördülő listába - ez azonban megnehezíti a későbbi értékek listájának hozzáadását vagy szerkesztését. Hacsak nem egy rövid listával van dolgod, ahol a lehetséges értékek valószínűleg nem változnak - például egy mező, amely valakinek a nemét rögzíti - célszerű egy másik táblázatot létrehozni az olyan bejegyzésekhez, mint a ProjectStatus. Ez lehetővé teszi, hogy a jövőben programozási változtatások nélkül egyszerűen hozzáadhasson további opciókat a listához.
Fejlesztések
Amíg az adatbázisunkat tervezzük, a régi táblázatos alapú műveletekhez képest fejlesztéseket hajthatunk végre. A felhasználók egyik panasza az Excel-munkafüzeteikkel kapcsolatban az volt, hogy minden feladat csak egy cellát tartalmazott a megjegyzésekhez, és néha több megjegyzést is kellett fűzniük egy feladathoz - vagy a felügyelőnek kellett megjegyzést fűznie egy feladathoz, majd a felhasználóhoz erre válaszoljon. Mindent egyetlen cellába tömörítve megnehezítette, hogy mikor és kik tették a megjegyzéseket. Jobban járhatunk, ha hozzászólásokhoz külön táblázatot hozunk létre, amely a Tasks táblához kapcsolódik. Ily módon az egyes feladatokhoz annyi megjegyzés fűzhető, amennyi szükséges, külön mezőkkel a dátumhoz, a felhasználónévhez és a szöveghez.
Egy másik fejlesztés, amelyet megtehetünk, az, ha olyan bejegyzéseket állítunk be, mint például a ProjectStatus, sorrendben, és nem ábécésorrendben történő megjelenítésre - például azt szeretné, ha a Befejezett a lista aljára kerülne. Ehhez adjon hozzá egy DisplayOrder oszlopot, és ezzel rendezze a keresési listát. Ne kísértjen az azonosító mező használatával; ezzel minden új rekord csak a lista végére kerülhet.
Annak biztosítása érdekében, hogy adataink tiszták maradjanak, megadhatjuk azokat a mezőket, amelyeket a felhasználónak kötelezőnek kell kitöltenie, és hozzáadhatunk egy ellenőrzést annak biztosítására, hogy a megadott adatok megfelelő formában legyenek. Megkönnyítheti az életet, ha ésszerű alapértelmezett értékeket állít be: a Megjegyzések táblázat CommentDate mezőjének alapértelmezett értéke = Date () lehet, amely automatikusan új mai megjegyzés létrehozásakor a mai dátumot állítja be. Használhatja az érvényesítést a táblázat Visszavont oszlopával (logikai értékekkel), hogy megakadályozza a felhasználók új rekordok hozzáadását meghatározott értékekkel. Ez lehetővé teszi a korábban érvényben lévő, de már nem használt történelmi értékek megőrzését. Ezek a funkciók a Table Tools | Mezők fül a szalagon vagy a Táblázattervező nézet mezőtulajdonságai között.
Adatok importálása
A táblázatok beállítása után használhatja a Külső adatok | Importálás és link | Excel gomb a szalagon az Excel-munkafüzet adatainak az Access-adatbázis tábláihoz való hozzáfűzéséhez. Mielőtt elkezdené, készítsen biztonsági másolatot az üres Access adatbázisáról, ha valami baj történne, és ha szükséges, kezdje azzal, hogy kézzel tölti fel a kis táblázatokat. Ha ez megtörtént, készítsen még egy biztonsági másolatot, így visszatérhet erre a pontra, ha a következő lépésekben bármi baj történik.
Most importálja azokat a fő táblákat, amelyek nem támaszkodnak más táblákra, például az Ügyfelekre, mielőtt befejezné azokat a táblákat, amelyek kapcsolatban vannak, például Projektek és Feladatok. Ha átrendezi és átnevezi az Excel munkafüzet oszlopait, hogy a lehető legpontosabban illeszkedjenek az Access adatbázis mezőihez, akkor nem okozhat nehézséget az adatok importálása. Ne felejtsen el jegyezni mindent, amit tesz, hogy később megismételhesse, ha újra meg kell konvertálni az adatokat.
Az adatok importálása után az Adatlap nézet tábláinak ugyanúgy kell működniük, mint az Excel munkalapoknak -, de sokkal jobb adatellenőrzéssel, kereséssel és rendezéssel. Ha kívánja, most elkezdheti új űrlapok és jelentések tervezését ezen adatok alapján: például a Projektek fő / részlet űrlapja az egyik projekt adatait megjelenítheti az űrlap tetején, és az ehhez tartozó Feladatok rácsot. projekt alján.
Beállíthat egy Saját feladatok űrlapot is, amely felsorolja az aktuális felhasználó összes kiemelkedő feladatát, és egy Lejárt feladatok jelentést, amely felsorolja az összes olyan felhasználó összes kiemelkedő feladatát, amelyek lejártak az esedékességükön.
Nincs megye, kérem, britek vagyunk
Ha címeket tárol az adatbázisában, fontos megértenie, hogy valójában milyen információkra van szüksége. Bár a megyei információk hasznosak lehetnek a marketinghez - és szükségük lehet néhány tengerentúli címre -, az Egyesült Királyság címeiben már nem használják hivatalosan.
hová menjen valamit kinyomtatni
Ennek oka, hogy az egyesült királyságbeli postacímek a postaváros fogalmára támaszkodnak, ahol az Ön számára küldött postai küldeményeket elküldik és szétválogatják, mielőtt azokat az Ön házához szállítanák. Nem minden várost vagy falut szolgálnak ki ugyanabban a megyében a postavárosok - például Melbourn (Cambridgeshire-ben) postáját Roystonon keresztül (Hertfordshire-ben) kapja meg), így a megye megadása a címben nem feltétlenül segít senkinek.
A félreértések elkerülése érdekében a Posta 1996-ban abbahagyta a megyék használatát a címekben, helyette irányítószám-információkra támaszkodva - és 2016-ig a megyei nevek eltávolítását tervezi a kiegészítő címadatok álnevének adatállományából. Tehát, ha egy megyét felvesz egy brit címbe, egyszerűen figyelmen kívül hagyja.
