Databaskonstruktion-Assignment-1-Startup

Requirements

Kraven följer krav specifikationerna som gäller för dem entiteter som har valts ut för handläggaren i systemet.

Agent

• Namnet och numret identifierar tillsammans agenten
• Agenter får inte ha nummer som är mindre än 0
• Agentnummer som överstiger 99 är ej tillåtet
• Om en Agent är en gruppledare får agenten ha numret 0 annars får ingen agent ha det
• Ingen agent får ha en lön mindre än 12000
• Agenter får inte ha lön över 25000 om dem inte är gruppledare
• Om ingen lön har delats ut ska lönen automatiskt sättas till 13000

Incident

• Incident identifieras med antingen dess unika namn eller unika nummer
• Platsen där en incident skett lagras
• En incident måste hända i någon region
• Medelgraden för en incidents observationer ska kunna beräknas

Observation

• Datum, säkerhet och grad måste anges vid varje observation
• Graden anger vad närkontakt har för nivå och värdena som är tillåtna är ett till fyra
• Säkerheten ska anges som en procentsats, det lägsta är en och det högsta är hundrafjorton procent
• Alla observationer ska ha lagrats av en handläggare och måste tillhöra en incident
• Åtkomsttider som är under en sekund är nödvändiga när det är frågor mot observationer
• Databasadministratörer ska kunna ta bort observationer. Dessa borttagningar ska skrivas in med datum och användarnamn så att man kan återskapa data. Kopplingar till personer och media tas bort

Media

• Inspelning identifieras av observationen som den gjort samt namnet på mediat
• Inspelningens kvalitet uppskattas och lagras som dålig, god, medelgod eller bra
• Om kvalitet inte har angetts så ska ett antagande göras av att kvaliteten är medelgod
• En kommentar om innehållet på en inspelning lagras som ska ha högst åttio tecken
• En medieinspelning får inte finnas som inte tillhör en observation

Person

• Varje person identifieras unikt utav personnummer, eller ett autogenererat nummer för anonyma personer
• Namnet eller alias på personen lagras som en textsträng
• Personer som har ett eventuellt kodnamn ska lagras så att informatörer som är viktiga kan fort identifieras
• En person kan rapportera flera observationer och en observation kan ha rapporterats av flera personer
• Man ska kunna ha en snabb åtkomst som är nödvändig för att arbete mot tabellen sker i realtid

Region

• En region identifieras utav sitt namn
• För regioner lagras en uppskattning av huvudterrängen i regionen
• Alla regioner ska ha en terräng lagrad
• Om det inte finns ett värde ska det automatiskt sättas "blandad" på terrängen
• Databasadministratörer ska kunna ta bort en region

Rättigheter

• Handläggare har rättighet till att läsa och skapa tuppler i tabeller med observationer, media, incidenter och personer
• Handläggare har rättighet till att läsa all information om gruppledare samt desinformationsspridare men ingen annan agenttyp
• Databasadministratörer har bara rättighet till att ta bort eller modifiera data i tabeller om dem har fått den rättigheten tilldelad

Relationer

Agent(Namn, Nr, Lon, Unamn) Region(Namn, Terrang) Incident(Nr, Namn, Plats, RegionNamn) Observation(ID, Säkerhet, Datum, Grad, IncidentNr, AgentNamn, AgentNr) Media(Namn, ObservationID, Kvalite, Komm) Person(ID, Namn, Kodnamn) ObservationPerson(ObservationID, PersonID)

Aktör

• Jag blev tilldelad variant E som är handläggare

Konceptuell databasdesign

• Jag valde incident för att det är en entitet som är relevant för handläggaren då han ska kunna söka upp varten incident har skett
• Observation valdes för att handläggaren även där ska kunna se vilka observationer som är direkt kopplade med incidenterna
• Media som är en svag entitet valdes för att det ska kunna finnas med vilken typ av media som användes vid en observation
• Person för att det är dessa som rapporterar sina observationer
• Region för att handläggaren ska kunna se inom vilken region en incident har skett

Logisk databasdesign

Relationer: I denna databasen så finns det 8 tabeller med 2 olika kodifieringstabeller. Media som var en egen tabell blev mergad med observation. observationperson tabellen blev till genom en många till många relation mellan observation och person där primärnyckeln har en sammansatt nyckel av främmande nycklar

Fysisk databasdesign

I min databasdesign gjordes en merge mellan observation och media där medianamn och kvalite blev egna kolumner. Detta på grund av att media var en svag entitet och namn är inget unikt värde, samma namn för mediat kan finnas till flera observationer och antagandet gjordes att media alltid tillhör observationer.

Den vertikala delningen kom från observation och gjordes till observationkomm tabellen samt personnamn ur person tabellen. Kommentar valdes pga att det var en varchar(80) alltså många karaktärer som inte används ofta. Samma med namn för persontabellen.

Två index skapades en för incidentnr i observationstabellen samt en för kodnamn i person tabellen. Detta för att kunna göra snabba sökningar mot incidentnr i observation samt snabbt kunna identifiera kodnamn.

Två användare har grants, en är databasadmin som har rättighet till SELECT, DELETE, UPDATE på observation och handläggaren som har rättighet till SELECT på incident och observation samt execute på proceduren VISAKODNAMN. Handläggaren kan använda sig utav proceduren utan att komma åt persontabellen med en SELECT.

Kodifiering gjordes för kvalite och terräng. Kvalite för att den innehåller många karaktärer som gör det smidigare att göra till nummer istället. Terräng blir även samma där då den inte behöver upprepas och kan skrivas ut som ett nummer istället.

Procedur och Trigger

GETMEDELGRAD(Incnr): Denna proceduren gör att man kan beräkna medelvärdet av graden i observationer inom en incident. Detta uppfyller kravet för att medelgraden i en incidents observation ska kunna beräknas. VISAKODNAMN(Inid): Denna proceduren hämtar personens kodnamn så att en informatör snabbt kan identifieras. CHECKSAKERHET: Denna trigger avbryter inserts som har en säkerhet som inte är 1-114. KOLLAGRAD: Denna trigger avbryter inserts för en grad som är utanför 1-4.