10 Steg till SQL-framgång - dummies

Syftet med SQL är att möjliggöra för utvecklare att skapa användbara och robusta databaser och databasapplikationer. För att lyckas med detta måste din utvecklingsinsats genomgå en rad steg, var och en som bygger på föregående, tills du rättvis kan fira ett framgångsrikt projekt. Här är tio väsentliga steg som kommer att leda till en framgångsrik databasutvecklingsinsats.

Definiera uppgiften

I början av ett projekt har personen som tilldelar dig uppgiften att bygga ett system (kunden) en aning om vad som behövs. Den tanken kan vara mycket specifik, skarp och koncis, eller den kan vara vag, nebulous och illdefinierad. Din första uppgift är att generera och skriva i en detaljerad beskrivning av exakt vad slutresultatet av projektet, som kallas leveranserna borde vara. Detta är den primära uppgiften för definitionen.

I definitionen definierar du problemet som ska lösas av din databas och tillhörande applikation så exakt som möjligt. Gör detta genom att lyssna noggrant på din klient när hon beskriver vad hon anser att systemet ska vara. Ställ frågor för att klargöra vaga poäng. Ofta har kunden inte tänkt igenom saker helt och hållet. Hon kommer att ha en allmän uppfattning om vad hon vill, men ingen klar uppfattning om detaljerna. Du måste komma överenskommelse med henne om detaljerna innan du kan fortsätta.

Bestäm projektets omfattning

Nästa steg i definitionfasen är att bestämma projektets omfattning. Hur stort jobb kommer det att vara? Vad kommer det att kräva inom systemanalytiker tid, programmerare tid, utrustning och andra kostnadsposter? Finns det en deadline?

Bestäm vad det ska ta för jobbet:

När du har bestämt projektets omfattning är nästa fråga att fråga dig själv: "Är det möjligt att göra det här jobbet inom de tids- och kostnadsbegränsningar som läggs på det av kunden? "För att svara på den här frågan måste du göra en genomförbarhetsanalys. När du har slutfört analysen kan du bestämma att projektet inte är genomförbart som för närvarande definieras. Du måste antingen avböja det eller övertyga klienten om att minska räckvidden till något mer hanterbart.

När du har bestämt att projektet är genomförbart, vet du vilken typ av personal du behöver göra jobbet. Vid denna tidpunkt måste du bestämma vem som ska arbeta för projektet. Du kanske kan göra ett litet jobb helt själv, men de flesta utvecklingsinsatser kräver ett team av flera individer. Att hitta personer som har nödvändiga färdigheter (och som också är tillgängliga för att arbeta på projektet när du behöver dem) kan vara lika utmanande som någon del av den totala utvecklingsinsatsen.

Generera en kravkrav

När du har kommit överenskommelse med din klient om vad exakt projektet ska innehålla kan du skriva en formell kravkrav. Kravsförklaringen är en tydlig redogörelse för databasprogrammets display, uppdatering och kontrollmekanismer.

Kravsförklaringen måste vara så detaljerad som möjligt. Det är i huvudsak ett avtal mellan dig och din klient. Du håller med om exakt vad som kommer att levereras och när det kommer att levereras. För att försegla arrangemanget ska både dig och din klient underteckna Kravsförklaringen, vilket innebär en överenskommelse om vad du ska ansvara för att leverera. Detta steg kan tyckas ganska formellt, men det skyddar båda parter. Det kan aldrig vara någon fråga senare om vad som överenskommits.

Skapa en formell databasmodell

Fram till nu har projektet främst analyserats. Vid denna tidpunkt kan du gå in i designfasen och göra övergången från analys till design. Du vet mest sannolikt allt du behöver veta om problemet, så nu kan du börja utforma lösningen.

Databasdesign handlar om modeller. Vid denna tidpunkt har du användarnas datamodell, som fångar användarnas koncept för databasens struktur. Den innehåller alla huvudtyper av objekt, egenskaperna hos dessa objekt och hur objekten är relaterade till varandra. Det är emellertid inte tillräckligt strukturerat för att ligga till grund för en databasdesign. Därför måste du konvertera användarnas datamodell till en modell som överensstämmer med ett av de formella databasmodelleringssystemen som har utvecklats under de senaste decennierna.

Den mest populära av de formella modelleringssystemen är enhetsrelationsmodellen, som vanligtvis kallas E-R-modellen. Med den här modellen kan du fånga vad användarna har sagt till dig i en väldefinierad form som du enkelt kan översätta till en relationsdatabas.

När du har systemet i form av en E-R-modell är det enkelt att konvertera till en relationsmodell. Relationsmodellen är något som DBMS förstår, och du kan skapa databasen direkt från den.

Design databasprogrammet

När du har designat databasen är designuppgiften bara halv klar. Du har en struktur som du nu kan fylla i med data, men du har inget verktyg för att fungera på den data. Det verktyg du måste designa nu är databasprogrammet.

Databasapplikationen är den del av det totala systemet som interagerar med användaren. Det skapar allt som användaren ser på skärmen. Det känner och reagerar på varje nyckeldepression som användaren gör och varje musaktivitet som användaren utför. Den skriver ut varje rapport som läses av användarens medarbetare. Från användarens synvinkel är databasprogrammet det systemet.

När du utformar databasprogrammet måste du se till att det gör det möjligt för användarna att göra allt som Kravsförklaringen lovar att de kommer att kunna göra.Det måste också presentera ett användargränssnitt som är förståeligt och lätt att använda. Systemets funktioner måste visas i logiska positioner på skärmen. Användaren måste enkelt förstå hur man utför alla funktioner som applikationen tillhandahåller.

Bygg det

Nu när du har en databasdesign kan du skapa tabellerna, relationerna mellan dem och begränsningarna på den data som kan skrivas in i dem.

Dokumentera det

Allt du har gjort och orsakerna till alla de beslut du har gjort måste dokumenteras noggrant. Förhoppningsvis har du gjort det här hela tiden. I detta skede behöver du bara lägga dokumentationen i sin slutliga form. En kompetent utvecklare som inte känner till projektet bör kunna hämta det efter att du har flyttat till större och bättre saker.

Testa allt

När du har byggt och dokumenterat ett databassystem kan det verka som om du är klar och du kan njuta av en välförtjänt semester, men du är inte helt klar ännu - systemet behöver testas noggrant. Den testningen måste göras av någon som inte tror på samma sätt som du gör. När systemet börjar fungera, kommer användarna att göra saker för det som du aldrig föreställde dig. De kommer att göra kombinationer av val som du inte förutsåg, ange värden i fält som inte menar och gör saker bakåt och upp och ner. Det är ingen som säger vad de ska göra. Oavsett oväntad sak som användaren gör, vill du att systemet ska svara på ett sätt som skyddar databasen och som leder användaren till att göra lämpliga inmatningsåtgärder.

Behåll den färdiga produkten

När du har levererat systemet i tid och på budget, firat och samlat in din slutbetalning för jobbet är ditt ansvar inte över. Även om den oberoende testeren har gjort ett fantastiskt jobb med att försöka få systemet att misslyckas, kan det efter leveransen fortfarande ha latenta buggar som visas veckor, månader eller till och med år senare. Du kan vara skyldig att fixa dessa buggar utan kostnad, beroende på ditt avtal med kunden.

Även om inga fel upptäcks kan du fortfarande ha något pågående ansvar. Trots allt förstår ingen systemet såväl som dig. När tiden går, kommer din kunds behov att förändras. Kanske behöver hon ytterligare funktioner, eller vill migrera till nyare, kraftfullare hårdvara. Dessa möjligheter kan kräva ändringar av databasprogrammet, och du är i bästa position att göra de ändringar som baseras på din förkunskapskunskap. Det här extra arbetet kan innebära några trevliga extra intäkter för dig.