Overview

UPPGIFT A (Systemadministratör)

Administration: För att kunna administrera all data i databasen krävs även ett antal administrativa funktioner i databas-systemet som sköts av myndighetens systemadministratörer.

ER model

Bild på det utvalda diagram i png. Den är uppdaterad till senaste aktuella versionen för att spegla databasen.

Databasdesignens beslut

Konceptuell Databasdesign

Fokus låg på att identifiera systemets huvudentiteter --> Agent, Operation, Incident, Region och Rapport. Deras inbördes relationer utifrån myndighetens verksamhetskrav. Administratören (Admin) modellerades konceptuellt som en subklass till Agent för att ärva grundegenskaper, men tilldelades unika attribut (UIDToken) för att spegla säkerhetsbehovet.

Logisk Databasdesign

Den konceptuella modellen översattes till relationsmodellen där primärnycklar (ex. sammansatta nycklar för Operation och Rapport) och främmande nycklar för att säkerställa hållbarheten mellan tabellerna. Subklasserna (Admin, Avslutning, Uppföljning) hanterades genom att låta dem ärva primärnycklar från sina respektive superklasser (Agent och Rapport).

Fysisk Databasdesign

I den fysiska designen prioriterades prestanda och datasäkerhet. Datatyper optimerades och CHECK-constraints applicerades för att förhindra felaktig datainmatning. Följande specifika fysiska avvikelser från den logiska modellen genomfördes:

1. Borttagna härledda attribut: Eftersom grunddata för Observation och Rapportrad avgränsades bort, kan inte *grad och *rader beräknas. Dessa har därmed raderats från logiska designen. Däremot kan *uppfölj beräknas tack vare tabellen Uppfoljning.
2. Denormalisering 1 (Merge): Entiteten Plats togs från 1:N-relation och mergades in i Incident-tabellen.
3. Denormalisering 2 (Vertikal Split): Agent_lon separerades från Agent.
4. Denormalisering 3 (Horisontell Split): Rapport har delats upp i Rapport och Rapport_hemlig.
5. Denormalisering 4 (Kodifiering 1): Satt kodifiering på SR för att lagra lyckad eller misslyckad operation (0 eller 1) istället för text.
6. Denormalisering 5 (Kodifiering 2): Gjort tabellen Terrang_kod för att hantera regioners terräng med kodifiering.

Relations

Terrang_kod(Kod_id, Beskrivning)

Region(Namn, Terrang-ID)

Incident(Namn Nr, Plats, Region_Namn)

Agent(Namn, Nr, Unamn, Agent_id, Kommentar, Behorighetsniva)

Agent_lon(Agent_Namn, Agent_Nr, Lon)

Admin(Agent_namn, Agent_nrUIDToken, Rum, Behorighetsniva)

Operation(Kodnmnt, Stdatum, Incident_namn Sldatum, SR, Kommentar, Ledare_namn, Ledare_nr, Region_namn)

Rapport(Datum, Titel Agent_Namn, Agent_Nr, Incident_Nr)

Rapport_Hemlig(Datum, Titel, Agent_Namn, Agent_Nr, Incident_Namn, Hemligstampel_Datum)

Avslutning(Rapport_datum, Rapport_titel Kommentar, Typ)

Uppföljning(Rapport_datum, Rapport_titel Kommentar, Utslag, Slutdatum, Forra_Rapport_Datum, Forra_Rapport_Titel)

Requirements

Den del av hela organisationen som berör admin på ett bra sätt har gjort att avgränsningen av kravspecifikationen ser ut som nedan.

Det ska hantera främst dataintegriteten och säkerhetsmekanismer (bl.a. behörighetsnivå) för att klargöra på ett användarvänligt (agenternas lägre tekniska kunskap och admins behov av snabbhet vid åtgärder) sätt, så att applikationen fungerar så optimalt den bara kan.

Procedurer och Triggers

Procedur: Hemligstämpla region (sp_hemligstampla_region)
Utifrån kravet att regioner ska kunna döljas av säkerhetsskäl, hanterar denna procedur flytten av data. Istället för att data går förlorad när en region raderas, ser proceduren till att alla kopplade incidenter och operationer automatiskt omplaceras till "Hemligstämplat".

Procedur: Regionsstatistik (sp_region_statistik)
För att uppfylla kravet på att kunna härleda en regions historik, ser proceduren till att antalet tidigare incidenter och operationer för en specifik region direkt anropas.

Trigger: Validering av Agentlön (trg_agent_lon_check)
Denna trigger agerar som ett automatiserat skyddsnät för lönerna på P.U.C.K.O. Den utvärderar inkommande löner och blockerar databastransaktionen om lönen är under minikrav eller överstiger maxgränsen. Den säkerställer även att agenter automatiskt tilldelas ingångslönen om inget belopp anges.

Trigger: Maxlängd för Operation (trg_operation_max_tid)
Baserat på den strikta tidsramen att operationer får pågå i maximalt 5 veckor, övervakar triggern inmatningen av operationsdatum. Om en operation planeras att pågå längre än 35 dagar, ingriper triggern och korrigerar automatiskt slutdatumet för att garantera att regeln följs.

Agent

• 1 En agent identifieras av en sammansatt nyckel bestående av första bokstaven i namnet (namn) och ett unikt nummer (nr).
• 2 Det finns ett härlett attribut agent_id som anger agentens fullständiga agentnamn (första bokstav unamn och nr).
• 3 Agentnummer 00-09 är reserverade för gruppledare. Agentnummer 10-99 används för övriga agenter (nr 13 får ej förekomma).
• 4 Agentens lön skall ha ett minvärde på 12000kr, ett maxvärde på 35000kr och om ingen lön sätts, ska den automatiskt sättas till 13000kr.
• 5 Agenter som inte är gruppledare får ej ha lön över 25000kr.
• 6 Leif Loket Olsson, Greger puckowitz och Greve Dracula får ej vara agenter.
• 7 Härlett attribut ska visas i applikationen.
• 8 Agenter har olika behörigheter.

Admin (Systemadministratör)

• 1 Systemadministratör identiferas unikt av ett säkert UIDTOKEN.
• 2 Admin har särskilda behörigheter för att ex. hantera och hemligstämpla data.
• 3 Admin är en subklass till Agent och ärver därmed agentens primärnyckel (Namn, Nr) samt dess grundegenskaper, vilket implementeras som en identifierande 1:1-relation.

Operation

• 1 Operation identifieras unikt av kombinationen kodnamnstyp, startdatum och incident.
• 2 Operationen succes rate (SR) lagras som sant eller falskt (0 eller 1).
• 3 En incident måste inträffa i någon region (tvingande koppling).
• 4 En operation måste ledas av en gruppledare agentnummer (00-09).
• 5 Operationens start- och slutdatum måste skilja sig åt med minst 1 dag och får pågå i max 5 veckor.

Region

• 1 En region identifieras unikt av dess namn.
• 2 Måste finnas en uppskattning av dess huvudterräng lagrad. Om inget värde tilldelas, ska det automatiskt sättas till 'blandad'.
• 3 Det ska gå att härleda regionens antal tidigare incidenter och operationer.
• 4 Regioner ska kunna hemligstämplas (tas bort temporärt). När detta görs ska regionens befintliga kopplingar till incidenter och operationer automatiskt flyttas till en specifik region som heter 'hemligstämplat'.

Incident

• 1 Kan identifieras antingen av dess unika namn eller dess unika nummer.
• 2 Incidentens plats ska lagras.
• 3 Incidenten måste inträffa i någon region (tvingande koppling).
• 4 Kan ha flera operationer kopplade till sig.

Rapport (superklass)

• 1 Identifieras av sitt datum och titel.
• 2 En rapport lämnas in av en agent och kopplas till en specifik incident.
• 3 Alla attribut måste ha värden (not null).
• 4 Ska finnas ett härlett attribut - antal uppföljningar.

Avslutning (subklass till Rapport)

• 1 Ärver primärnyckel från Rapport-tabellen.
• 2 En kortfattad kommentar lagras (max 25 tecken).
• 3 Typ av rapport lagras (fältrapport, ledningsrapport, kampanjrapport, övrigt och slutrapport).
• 4 Sätts automatiskt till 'slutrapport' om inget annat anges.

Uppföljning (subklass till Rapport)

• 1 Ärver primärnyckeln från Rapport-tabellen.
• 2 Endast fältrapporter på misslyckade operationer och misslyckade uppföljningsrapporter kan tilldelas uppföljningar.
• 3 Misslyckad operation KAN tilldelas ny uppföljning på uppdraget efter 2 år.
• 4 En längre kommentar lagras (max 80 tecken).
• 5 Om inget utslag anges ska det automatiskt tilldelas värdet som motsvarar misslyckande.