Databaskonstruktion-Assignment-1-Startup

Länk till diagrammet:Klicka här för att se ER-diagrammet

Requirements

Kravspecifikation utvald för Gruppledarens perspektiv på databasen.

Agent

• Varje agent identifieras unikt av sitt namn (en bokstav) och ett nummer
• Agentnummer över 99 är inte tillåtna, och de får inte heller vara mindre än noll
• Agentnamnet "13" är inte tillåtet
• Vissa personer får inte bli agenter (Leif Loket Olsson, Greger Puckowitz och Greve Dracula)
• Ingen agent oavsett typ får tjäna mindre än 12000
• Om ingen lön tilldelas vid registrering ska lönen automatiskt sättas till 13000
• Ursprungligt namn och levnadsfilosofi (kommentar) ska lagras

Gruppledare

• Lönetaket för gruppledare är 35000
• Gruppledare är de enda som får ha agentnummer 0
• Får leda högst två operationer samtidigt om de tillhör olika incidenter
• Får leda upp till fem operationer samtidigt om alla tillhör samma incident

Fältagent

• Får inte ha lön över 25000
• Får normalt inte arbeta på mer än en operation samtidigt
• Om operationerna är i samma region får fältagenten arbeta på upp till tre operationer samtidigt
• Fältagentens kompetenser och viktigaste specialkompetens ska lagras

Incident

• Identifieras unikt antingen via sitt unika namn eller sitt unika nummer
• Platsen där incidenten inträffade ska lagras

Operation

• Operation identifieras av kodnamn, typ, startdatum samt den incident som genererade operationen
• En operation måste ha en gruppledare, men en gruppledare kan ha flera operationer
• Slutdatum måste vara senare än startdatum
• En operation får inte vara kortare än 1 dag
• Om skillnaden mellan start- och slutdatum är större än 5 veckor ska slutdatumet automatiskt justeras så att operationen blir exakt 5 veckor lång
• Resultatet (Success rate) lagras enbart som heltalet 1 (lyckad) eller 0 (misslyckad)

Hjälpmedel

• Identifieras genom en kombination av namn och ordningsnummer
• Ordningsnumret måste vara mellan 1 och 15
• Samma hjälpmedel får inte vara tilldelat flera operationer samtidigt
• Ska ha en mycket kortfattad beskrivning (ett par ord)

Logisk Databasdesign (Relationer)

Incident(IncidentNr, IncidentNamn, Plats)

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

Gruppledare(AgentNamn, AgentNr)

Falt(AgentNamn, AgentNr, Specialkompetens)

Falt_Kompetens(AgentNamn, AgentNr, Kompetens)

Operation(Kodnamn, Startdatum, IncidentNr, IncidentNamn, Typ, Slutdatum, SR, Kommentar, GBokstav, GSiffra)

Falt_Operation(AgentNamn, AgentNr, OpKodnamn, OpStartdatum, OpIncidentNamn, OpIncidentNr)

Hjalpmedel(HjalpNamn, HjalpNr, Beskrivning)

Falt_Hjalpmedel(AgentNamn, AgentNr, HjalpNamn, HjalpNr)

Operation_Hjalpmedel(HjalpNamn, HjalpNr, OpKodnamn, OpStartdatum, OpIncidentNamn, OpIncidentNr)

Tilldelad uppgift

Jag har tilldelats uppgift D som handlar om att hantera gruppledare

Konceptuell Databasdesign

I den konceptuella fasen identifierades de centrala entiteterna i systemet, såsom Agent, Incident, Operation och Hjälpmedel, samt deras inbördes relationer. Fokus låg på att förstå verksamhetens krav och rita upp ett ER-diagram som tydligt visar kardinaliteter (exempelvis att en fältagent kan ha flera kompetenser, att hjälpmedel och fältagenter har en M:N-relation, och att en operation leds av en gruppledare).

Logisk Databasdesign

Under den logiska fasen översattes den konceptuella modellen (ER-diagrammet) till en relationsmodell. Primärnycklar och främmande nycklar definierades för att binda ihop datan korrekt. Tabellerna normaliserades för att undvika dataredundans och uppdateringsanomalier, vilket bland annat innebar att flervärda attribut (som kompetenser) och M:N-relationer (som favorithjälpmedel) bröts ut till egna kopplingstabeller.

Fysisk Databasdesign

I den fysiska designen optimerades databasen för prestanda och säkerhet. Följande huvudsakliga beslut togs:

• Denormalisering (Merge): Den svaga entiteten Incident slogs ihop med Operation för att minska antalet tabellkopplingar vid sökningar.
• Denormalisering (Horisontell): Operationstabellen delades upp i aktiva och arkiverade operationer för att snabba upp sökningar på pågående uppdrag. För att bevara dataintegriteten för refererande tabeller (exempelvis Hjälpmedel) skapades supertypen Operation_Bas som enbart hanterar primärnycklarna.
• Denormalisering (Vertikal): Stora kommentarstexter för agenter bröts ut till en egen tabell (Agent_Info) så att kärndatan i Agent-tabellen blir snabbare att läsa in.
• Kodifiering: Strängar för operationstyper och kompetenser ersattes med kodtabeller (OperationTyp och KompetensKod) och siffer-ID:n för att spara lagringsutrymme och undvika stavfel.
• Indexering & Säkerhet: Index skapades på kolumner som ofta används i sökningar (ex. lön och incidentplats). Dessutom implementerades användarrättigheter (GRANT) där fältagenter endast får läsrättigheter medan gruppledare fick rätt att manipulera data i aktiva operationer.

Procedurer och Triggers

Nedan beskrivs de procedurer och triggers som har implementerats i databasen för att uppfylla verksamhetens krav på loggning, säkerhet och affärsregler.

Trigger: LOGGAGENT

Denna trigger lyssnar på tabellen Agent. Dess syfte är att av säkerhetsskäl spara en händelselogg i en separat tabell (AgentLog) varje gång en ny agent anställs och registreras i databasen, inklusive vem som gjorde registreringen och när.

Trigger: SALARYCHECK

Denna trigger agerar som en affärsregel (constraint) inför uppdateringar i Agent-tabellen. Den kontrollerar det nya lönevärdet mot det gamla och avbryter processen med ett felmeddelande om någon försöker sänka en agents lön, vilket garanterar att löner enbart kan höjas.

Procedur: UPDSALARY

Denna procedur används som ett säkert gränssnitt för att uppdatera en agents lön. Den utvärderar en inbyggd constraint som säkerställer att ingen lön kan sättas lägre än minimikravet på 12 000. Om lönen är godkänd genomförs uppdateringen.

Procedur: GETAGENTS

Denna procedur fungerar som ett förenklat gränssnitt för applikationslagret. Den hämtar och returnerar all relevant kärndata om agenter utan att användaren behöver skriva komplexa SQL-frågor direkt mot de underliggande tabellerna.