10 Trin til SQL Success - dummies

Formålet med SQL er at give udviklere mulighed for at oprette nyttige og robuste databaser og databaseprogrammer. For at være vellykket på dette, skal din udviklingsindsats passere gennem en række faser, som hver bygger på det forrige, indtil du med rette kan fejre et vellykket projekt. Her er ti vigtige faser, der vil resultere i en vellykket databaseudvikling.

Definer opgaven

I starten af ​​et projekt har den person, der tildeler dig opgaven med at opbygge et system (klienten) en ide om, hvad der er nødvendigt. Denne idé kan være meget specifik, skarp og kortfattet, eller den kan være vag, nebulous og udefineret. Din første opgave er at generere og skrive en detaljeret beskrivelse af præcis, hvad slutresultatet af projektet, der hedder leverancerne , skal være. Dette er den primære opgave for definitionen.

I definitionen definerer du problemet, der skal løses af din database og tilhørende applikation, så præcist som muligt. Gør dette ved at lytte omhyggeligt til din klient, da hun beskriver, hvad hun forestiller systemet for at være. Stil spørgsmål om at klarlægge vage punkter. Ofte har kunden ikke tænkt på ting helt igennem. Hun vil have en generel ide om hvad hun vil, men ingen klar ide om detaljerne. Du skal indgå en aftale med hende om detaljerne, inden du kan fortsætte.

Bestem projektets omfang

Det næste trin i definitionfasen er at bestemme projektets omfang. Hvor stort job vil det være? Hvad vil det kræve i system analytiker tid, programmerer tid, udstyr og andre omkostninger poster? Er der en deadline?

Bestem hvad det vil tage for at gøre jobbet:

Når du har bestemt projektets omfang, er det næste spørgsmål at spørge dig selv, 'Er det muligt at gøre dette job inden for de tids- og omkostningsbegrænsninger der er lagt på af kunden? "For at besvare dette spørgsmål skal du lave en feasibility analyse. Når du har gennemført analysen, kan du bestemme, at projektet ikke er muligt som defineret i øjeblikket. Du skal enten afvise det eller overbevise klienten om at reducere omfanget til noget mere håndterbart.

Når du har fastslået, at projektet er gennemførligt, ved du, hvilken form for personale du skal udføre jobbet. På dette tidspunkt skal du beslutte, hvem der skal arbejde på projektet. Du kan muligvis kun gøre et lille job selv, men de fleste udviklingsindsatser kræver et hold af flere individer. At finde folk, der har de fornødne færdigheder (og som også er tilgængelige til at arbejde på projektet, når du har brug for dem) kan være lige så udfordrende som nogen del af den samlede udviklingsindsats.

Generer en kravkrav

Når du er nået til en aftale med din klient om, hvad der præcist skal indgå i projektet, kan du skrive en formel erklæring. Kravserklæringen er en eksplicit erklæring om databaseprogrammets display-, opdaterings- og kontrolmekanismer.

Kravene skal være så detaljerede som muligt. Det er i det væsentlige en kontrakt mellem dig og din klient. Du accepterer præcis, hvad der skal leveres, og hvornår det bliver leveret. For at forsegle arrangementet skal både dig og din klient underskrive Kravserklæringen og indgive aftale om, hvad du vil være ansvarlig for at levere. Dette trin kan virke temmelig formelt, men det beskytter begge parter. Der kan aldrig være noget spørgsmål senere om, hvad der blev aftalt.

Opret en formel databasemodel

Frem til nu har projektet primært været analyse. På dette tidspunkt kan du gå ind i designfasen og gøre overgangen fra analyse til design. Du ved mest sandsynligt alt, hvad du behøver at vide om problemet, så nu kan du begynde at designe løsningen.

Databasedesign handler om modeller. På dette tidspunkt har du brugerens datamodel, som fanger brugerens koncept for databasens struktur. Det omfatter alle hovedtyper af objekter, egenskaberne ved disse objekter, og hvordan objekterne er relateret til hinanden. Det er imidlertid ikke tilstrækkeligt struktureret til at danne grundlag for et databasedesign. For det er du nødt til at konvertere brugerens datamodel til en model, der er i overensstemmelse med et af de formelle databasemodelleringssystemer, som er blevet udviklet de sidste par årtier.

Den mest populære af de formelle modelleringssystemer er entitets-forholdsmodellen, der almindeligvis betegnes som E-R-modellen. Med denne model kan du fange, hvad brugerne har fortalt dig i en veldefineret form, som du så nemt kan oversætte til en relationsdatabase.

Når du har systemet i form af en E-R-model, er det nemt at konvertere til en relationsmodel. Relationsmodellen er noget, som din DBMS forstår, og du kan oprette databasen direkte fra den.

Design databaseprogrammet

Når du har designet databasen, er designopgaven kun halvt færdig. Du har en struktur, som du nu kan udfylde med data, men du har endnu ikke et værktøj til at fungere på disse data. Værktøjet, du skal designe nu, er databaseprogrammet.

Databaseprogrammet er den del af det samlede system, der interagerer med brugeren. Det skaber alt, hvad brugeren ser på skærmen. Det registrerer og reagerer på hver nøgle depression, som brugeren laver og hver mus handling, som brugeren udfører. Den udskriver hver rapport, der læses af brugerens medarbejdere. Fra brugerens synspunkt er databaseprogrammet systemet.

Ved udformningen af ​​databaseprogrammet skal du sørge for, at brugerne kan gøre alt, hvad Kravserklæringen lover, at de vil kunne klare.Det skal også præsentere en brugergrænseflade, som er forståelig og nem at bruge. Systemets funktioner skal vises i logiske positioner på skærmen. Brugeren skal let forstå, hvordan man udfører alle de funktioner, applikationen giver.

Byg det

Nu hvor du har et databasedesign, kan du oprette tabellerne, forholdet mellem dem og begrænsningerne på de data, der kan indtastes i dem.

Dokumentér det

Alt du har gjort, og årsagerne til alle de beslutninger, du har lavet, skal være omhyggeligt dokumenteret. Forhåbentlig har du gjort det hele tiden. På dette stadium er alt, hvad du skal gøre, lagt i dokumentationen i sin endelige form. En kompetent udvikler, der ikke er bekendt med projektet, bør kunne hente det efter at have flyttet videre til større og bedre ting.

Test alt

Når du har bygget og dokumenteret et databasesystem, kan det virke som om du er færdig, og du kan nyde en velfortjent ferie, men du er ikke helt færdig endnu - systemet skal testes stringent. Denne test skal udføres af en person, som ikke tror på samme måde som du gør. Når systemet er i gang, vil brugerne gøre ting til det, som du aldrig havde forestillet dig. De vil lave kombinationer af markeringer, som du ikke forudser, indtaste værdier i felter, der ikke giver mening, og gør tingene baglæns og på hovedet. Der er ingen at fortælle hvad de skal gøre. Uanset uventet ting, brugeren gør, vil du have systemet til at reagere på en måde, der beskytter databasen, og som leder brugeren til at foretage passende input handlinger.

Vedligeholdelse af det færdige produkt

Når du har leveret systemet til tiden og på budgettet, fejret og samlet din endelige betaling for jobbet, er dine forpligtelser ikke overstået. Selvom den uafhængige tester har gjort et fantastisk arbejde med at forsøge at få systemet til at falde, kan det efter leveringen stadig have latente fejl, der opstår uger, måneder eller endda år senere. Du kan være forpligtet til at fastsætte disse fejl uden omkostninger, afhængigt af din kontraktlige aftale med kunden.

Selvom der ikke findes nogen fejl, kan du stadig have noget løbende ansvar. Når alt kommer til alt forstår ingen systemet såvel som dig. Som tiden går, vil kundens behov ændres. Måske har hun brug for yderligere funktioner, eller vil migrere til nyere, mere kraftfuld hardware. Disse muligheder kan kræve ændringer i databaseprogrammet, og du er i den bedste position til at foretage disse ændringer, baseret på din forudgående viden. Dette ekstra arbejde kan betyde nogle gode ekstra indtægter for dig.