Williams databassystem för PUCKO

Översikt

Projektet innehåller en prototyp av PUCKOs databassystem med databasadministratör som tilldelad användartyp.

Den valda delen av modellen lägger sitt fokus på administrativ hantering av agenter, operationer, incidenter, observationer och regioner. Prototypen kommer särskilt att behandla databasadministratörens möjligheter att hantera, hemligstämpla och återställa känslig information.

ER modell

ER-modellen visar avgränsningen som gjorts av den konceptuella modellen som planeras att implementeras för databasadministratören.

Krav

Kraven som listas nedan är relevanta för de entiteter som jag valde att ha med i den avgränsade modellen för min tilldelade agent databasadministratören. Kraven utgår från uppgiftsspecifikationen och kan uppdateras om modellens avgräsnings förändras under projektets gång.

Agent

• Det finns fem olika typer av agenter, där databasadministratören är en av dem.
• Varje agent identifieras unikt genom kombinationen av ett agentnamn och ett agentnummer
• Agentnummret måste vara under 100, samt får det inte vara negativt och inte heller 0 eller 13.
• Agentens levnadsfilosofi ska lagras som en kommentar.
• Agentens lön får normalt sätt inte överstiga 25000 och aldrig vara mindre än 12000. Om ingen lön anges så ska den automatiskt sättas till 13000.

Admin

• Admin är en undertyp av Agent och ärver därför entiteten agents gemensamma attribut och identifierare.
• Databasadministratören ska kunna lagra nya tuppler genom ett grafiskt användargränssnitt.
• Applikationen och dess gränssnitt ska vara användarvänligt och lättanvändligt.
• Varje databasadmin ska ha ett unikt UID-token.

Operation

• Varje operation identifieras genom kombinationen av kodnamntyp, startdatum och incidenten som genererade operationen.
• Slutdatumet för en operation måste vara senare än startdatumet.
• En operation måste vara i minst en dag.
• Operation får inte vara i mer än 5 veckor, isåfall ska slutdatumet automatiskt justeras till 5 veckor.
• Slutresultat för operationen ska lagras som heltalet 1 för lyckad, eller 0 för misslyckad operation.

Incident

• En incident kan identifieras antingen genom sitt unika namn eller sitt unika nummer.
• Platsen där incidenten inträffade ska lagras.
• Varje incident måste vara kopplad till en region.
• En incident kan ha en eller flera operationer kopplade till sig.
• En incident kan ha flera observationer kopplade till sig.
• Incidentetns genomsnittliga grad ska kunna beräknas utifrån graden för incidentens observationer.

Observation

• Varje observation ska ha ett unikt ID.
• Datum, grad och säkerhet måste anges för varje observation.
• Graden ska vara ett värde mellan ett och fyra, där fyra innebär extrem närkontakt.
• Säkerheten ska anges som en procentsats, säkerheten får inte vara lägre än en procent eller högre än 114 procent.
• Varje observation måste tillhöra en incident.
• Åtkomsttiden för frågor om observationer ska vara kortare än en sekund.
• Databasadministratören ska kunna ta bort observationer när total intern mörkläggning är nödvändig.
• När en observation tas bort för mörkläggning ska tillhörande kopplingar till personer och handläggare samt tillhörande medieinofmration tas bort.
• Borttagna observationer ska sparas i en eller flera loggtabeller så att informationen senare kan återställas.
• Datumet för mörkläggningen och administratörens användarnamn ska lagras i logtabellen.

Region

• Varje region identifieras unikt genom sitt namn.
• Regionens huvudsakliga terräng ska lagras.
• Varje region ska hah en anvigen terräng.
• Om ingen terräng anges ska värdet automatiskt sättas till blandad.
• Antalet tidigare operationer och incidenter i regionen ska kunna härledas.
• Databasadministratören ska tillfälligt kunna ta brot en hemligstämplat region så att den vid senare tid kan återsätllas.
• När en region hemligstämplas ska dess kopplingar till incidenter och operationer hanteras.
• En region med namnet hemligstämplat ska skapas om den inte redan finns.
• Berörda incidenter och operationer ska kopplas till regionen hemligstämplat under den tid som den ursprungliga regionen är he,igstämplad.

Relationer

Relationerna har skapats utifrån den avgränsade ER-modellen.

Agent(Namn, Nr, Lon, Unamn, Kommentar)

Admin(AgentNamn, AgentNr, UIDToken, Rum)

Region(Namn, Terrang)

Incident(Nr, Namn, Plats, RegionNamn)

Operation(Kodnamnt, Startdatum, IncidentNr, Slutdatum, SR, Kommentar, AdminNamn, AdminNr, RegionNamn)

Observation(ID, Säkerhet, Datum, Grad, IncidentNr)