Introduktion / Överblick

Jag har fått variant E vilket är handläggare och har därefter valt att göra mina avgränsning av systemet för att fokusera på det som beskrivs vara viktigt för varianten handläggaren.

Konceptuell databasdesign

För den konceptuella databasdesignen så valde jag att göra en avgränsning för dem entiteter som jag ansåg vara viktiga för min uppgiftsvariant handläggare.

För att hantera arven för tabellen observation och agent använde jag alternativ D, med andra ord att slå ihop alla entiteter till en egen tabell med ett typ-attribut för att på så sätt undvika joins och öka prestanda när jag vill hämta dess sammanhängande data.

M:M relationen mellan handläggare och observation hanterade jag genom att skapa en egen tabell (HANDLAGGAROBSERVATION) med bägge deras primärnycklar.

Logisk datbasdesign

Den logiska databasdesignen inleddes med att först välja ut relevanta krav från uppgiftsbeskrivningen baserat på min tidigare avgränsning inom den konceptuella databasdesignen.

Därefter överförde jag jag mina relationer baserat på min avgränsning och bestämde passande datatyper utifrån dem insamlade kraven och det som ansågs rimligt baserat på attributet, exempelvis blev kolumner med datum datatypen DATE. Dessutom implmenterades constraints utifrån dem insamlade kraven.

Fysisk databasdesign

För den fysiska databasdesignen så utgick jag ifrån den logiska och konceptuella databasdesignen för att på så sätt använda mig av denormaliseringstekniker såsom kodifiering och vertikal split för att optimera databasen. Besluten som låg bakom var som följande:

Kodifiering användes på tabellen för Observation på färg-fältet vilket flyttades till en egen tabell eftersom antagandet gjordes att det finns ett bestämt antal färger för både Alien och Skepp och på så sätt öka hämtningstiden för tabellen.

Därefter användes vertikal split på fritext kommentars-fältet för tabellerna Operation och Agent för att slippa hämta dessa varje gång data ska hämtas från tabellerna och på så sätt optimera hämtningstiden för tabellerna.

En merge utfördes på tabellerna Incident och rapport för att på så sätt undvika att göra joins då både incident och rapport har en relation där bägges data ofta hämtas tillsammans.

ER Modell

Relationer

Agent(Namn, NR,Lön, Unamn, Kommentar, ÄrHandläggare)

HandläggarObservation(Namn, Nr, ID)

Observation(ID, Säkerhet, Datum, Grad, AlienFärg, AlienKläder, AlienStorlek, AlienTyp, SkeppForm, SkeppFärg, SkeppLamptyp, SkeppRörelse, Typ, IncNamn, IncNr)

Incident(Namn, Nr,Plats)

Rapport(Datum,Titel,IncNamn, InrNr,AgtNamn, AgtNr)

Operation(Kodnmt,Stdatum,IncNamn, IncNr, Sldatum, SR, Kommentar)

Egna antaganden och beslut kring design

För entiteten observation valde jag att använda alternativ D för att hantera arvet, dvs att skapa en enda stor tabell för att undvika joins mellan tre olika tabeller. Därav att uppnå prestanda kravet som nämndes i uppgiftsbeskrivningen för observation entiteten.

Arvet för tabellen Agent hanterades genom att skapa ett typ-attribut som identifierar om en agent är eller inte är handläggaren

För att uppfylla kravet om att incident skall identifieras antingen av dess unika nummmer eller namn, så valdes nummer att användas, vilket innebar att Incident tabellens primärnyckel ändrades till att vara enbart nummret (nr)

Eget antagande gjordes om att det finns ett bestämt antal färger som en observation av typen Alien eller Skepp kan vara (Röd, grön, orange, lila)

Krav

Dessa är dem krav som samlades in från dokumentet och har därefter utvärderats för att sedan kunna implementeras in i databasmodellen.

Agent

• Varje agent identifieras unikt med hjälp av dess namn (namnet är endast en bokstav exempelvis K), tillsammans med en siffra exempelvis J 2.

• Agentens levnadsfilosofi lagras som en kommentar för att kunna gå tillbaka och utvärdera hur pass bra agenten lever upp till sin levnadsfilosofi vid ett senare tillfälle.

• Ingen agent får ha nummer som är mindre än noll. Talet 13 är av naturliga skäl inte tillåtet som agentnamn. Agentnummer över 99 är inte heller tillåtna.

* Agentens lön och ursprungliga namn (inklusive separata förnamn och efternamn och ett härlett attribut som sätter samman förnamn och efternamn) skall dessutom lagras för alla agenter.

* Vissa personer får av olika orsaker inte bli agenter. Det gäller personer som heter Leif Loket Olsson, Greger Puckowitz och Greve Dracula.

* De härledda värden som skall beräkna ett antal, exempelvis antalet genomgångna operationer för en viss agent, skall värdet “Inga operationer“ visas i applikationen.

* När en rapport skrivs så skall det vara möjligt att se sidantalet som rapporten har samt antalet ord rapporten täcker.

(Agent) -> Handläggare

• handläggaren skall kunna sitta uppkopplad mot databas-systemet och direkt kunna mata in relevant informationen från telefonsamtalet

• För handläggaren skall det vara möjligt att beräkna antalet incidenter som handläggaren rapporterat samt antalet observationer som rapporterats

• Beräkna antalet operationer som startats beroende på incidenter rapporterade av handläggaren

• Det är viktigt att handläggaren visas en komplett bild innehållande incidentens information

• En handläggare har rättigheter att läsa och skapa tuppler i tabellerna med observationer, media, incidenter och personer enligt de regler som skapats för informationssystemet.

• Eftersom handläggaren har i uppgift att tilldela desinformationsspridare och gruppledare till en viss incident så måste han ha rättigheter att läsa all information som finns tillgänglig om dessa båda typer av agenter (men inga andra).

Observation

* Det finns två olika typer av observationer. En observation kan antingen gälla rymdskepp eller rymdvarelser, om flera olika typer av rymdvarelser siktats eller om både rymdskepp och rymdvarelser siktats skall separata observationer skapas för denna incident

• För observationerna så skall en procentsats anges för observationens säkerhet, säkerheten får inte vara mindre än en procent och inte högre än hundrafjorton procent.

• Graden anger vilken grad av närkontakt som personen som gjort observationen hade med rymdvarelserna. Tillåtna värden är ett till fyra där fyra innebär extrem närkontakt.

• Säkerheten talar om hur säker observationen är, uttryckt som en procentsats.

• Eftersom åtkomsttider på under en sekund för alla frågor som ställs om denna data är nödvändiga för verksamheten är det mycket viktigt att alla möjliga optimeringsstrategier används för att optimera åtkomsthastigheten i dessa tabeller.

• Prestanda är av högsta vikt när det gäller åtkomst av observationer av rymdvarelser eller rymdskepp och av datan om rymdvarelserna och rymdskeppen.

• För varje observation måste observationens datum,grad samt säkerhet anges

• Observationen måste även tillhöra någon incident som inträffat.

• Varje observation måste ha lagrats av någon handläggare

• När en ny observation kommer till handläggarens kännedom som saknar en motsvarande incident skall en ny incident direkt skapas.

• Om flera observationer hör till samma incident skall inte någon ny incident skapas utan de skall kopplas direkt till incidenten. Handläggaren får sedan fatta ett beslut om en ny observation skall tilldelas för incidenten.

(Observation med arvtyp:) -> Alien

• För en observation av en rymdvarelse anges rymdvarelsens färg, kläder, typ och storlek.

• Typen anger vilken typ av varelse som rymdvarelsen tillhör, exempelvis humanoid.

• Storleken anger den uppskattade storleken på rymdvarelsen uttryckt i meter.

• Kläder anger ett par ord om klädedräktens utseende endast generellt omdömme om kläderna skall anges.

(Observation med arv-typ:) -> Skepp

• För en observation av ett rymdskepp anges formen på rymdskeppet, typen av lampor rymdskeppet hade, rymdskeppets färg samt en uppskattning av rymdskeppets rörelse

Incident

• En incidient kan identifieras antingen av dess unika namn eller dess unika nummer.

• För incidenten lagras dessutom platsen som den inträffade på.

• En incident kan dessutom ha en eller flera operationer eller desinformationskampanjer kopplade till sig.

• Dessutom skall det gå att beräkna ett medelvärde på incidentens alla observationers grad.

Operation

• Varje operation identifieras av dess kodnamntyp samt operationens startdatum tillsammans med incidenten som genererade operationen. Kodnamntypen anger både operationens kodnamn samt dess typ, exempelvis uppstädningsoperation: Gregers Bodega

• Operationen har även en frivillig kommentar som bör fyllas i där agenterna specificerar viktiga detaljer om operationen som är utöver den information som lagras i operationens förbestämda fält.

• De attibut som anges som “success rate” skall lagras i form av ett heltal som är ett om operationen eller kampanjen lyckades och noll om operationen eller kampanjen misslyckades Inga andra värden är tillåtna.

• För att bokning av olika agenter och hjälpmedel skall fungera så är det nödvändigt att operationens slutdatum anges, slutdatumet kan senare ändras för att passa det verkliga slutdatumet.

• Det är tillåtet för två olika operationer för samma incident på olika datum att ha samma kodnamn och typ

• För kampanjer och operationer så måste alltid slutdatumet för operationen eller kampanjen vara senare än startdatumet.

* En operation eller en kampanj får inte vara kortare än en dag.

* Om skillnaden mellan en operations eller kampanjs startdatum och slutdatum är större än fem veckor så antas slutdatumet vara felinmatat, längden till operationen skall då automatiskt sättas till fem veckor.

Rapport

• På alla typer av rapporter så måste värden för alla attributen lagras.

• En vanlig rapport eller slutrapport som den också kallas lämnas in av någon agent efter varje incident som inträffat (eller efter att incidentens operation slutförts).

* Slutligen skall det finnas två härledda attribut, ett som anger rapportens radantal, och ett som anger rapportens antal uppföljningar.

* Det skall vara möjligt att ta bort (hemligstämpla) hela rapporter inklusive alla rapportens rader och uppföljningar. Borttagningen skall loggas så det är möjligt att återskapa rapporten i sin helhet när hemligstämpeln släppts.

* När en rapport tas bort skall automatiskt alla associerade rapportrader och uppföljningar tas bort.

* Slutligen skall det vara möjligt att hemligstämpla vissa rader i en rapport, rapportraden ersätts då med texten “hemligstämplat”. När hemligstämpeln släppts skall det vara möjligt att återställa rapporten till sitt tidigare utseende.

Procedurer / triggers

Under detta kapitel förklarar jag kort kring hur jag tänkt med mina skapade procedurer och triggers samt hur dem fungerar och vilka krav som löses av dem.

Trigger: OBSERVATIONSLOGGNING

Denna trigger skapades för att logga när en handläggare registrerar en ny observation, där både id, användare och tidsstämpel loggas i en ny tabell OBSERVATIONSLOGGNING innan en insert görs i observationstabellen. Detta för att säkerställa vem som faktiskt har registrerat en observation vilket bidrar med möjligheten att kunna gå tillbaka och kontrollera vilken handläggare och när dem registrerat en observation.

Trigger: KONTROLLERA_DATUM

Triggern KONTROLLERA_DATUM implementerades för att lösa kravet om att slutdatumet måste vara efter startdatumet för operationer. Därav gjordes en trigger som kontrollerar att startdatumet är innan slutdatumet, innan en insert görs i tabellen för Operation. Om inte så visas ett felmeddelande inne i databasen.

Procedur: GRADMEDELVARDE()

Proceduren GRADMEDELVARDE() implementerades för att kunna lösa kravet från uppgiftsbeskrivningen om att det skall gå att beräkna medelvärdet på incidentens alla observationerns grad och på så sätt hämtas medelvärdet av graden från alla observationer som har en relation med en incident inom proceduren med hjälp av frågespråk.

Procedur: HAMTA_INCIDENT()

Proceduren HAMTA_INCIDENT() skapades för att kunna lösa kravet från uppgiftsbeskrivningen om att det ska gå att beräkna hur många incidenter som en viss handläggare har rapporterat in. Därav skapades en procedur med två parametrar, agentens namn och nr, där count(*) sedan används för att beräkna alla incidenter som har rapporterats in av en viss agent eller handläggare med det inlagda namnet och numret.

Extra procedur som skapades utöver uppgiftskraven för PHP / C# applikationen

Procedur: LAS_OPERATION()

Proceduren LAS_OPERATION() används för att kunna hämta och visa alla databasens operationer som har blivit skapade och på så sätt kunna ge handläggaren en helhetsbild över vilka operationer som finns registrerade inom C# och PHP applikationen. Procedur säkerställer även att vi ej behöver ta emot SQL input från användaren, vilket gör applikationen säkrare.