Databaskonstruktion-Assignment-1-Startup

Startup code for first assignment in Databaskonstruktion

ER Modell

Relationer

AdminAgent (entiteter Agent och Admin)

AdminAgent(Namn, Nr, Lön, Unamn, Kommentar, AdminNamn, AdminNr, UIDToken, Rum)

Operation

Operation(Kodnmnt, Stdatum, IncNamn, IncNr Sldatum, SR, Kommentar, AdminNamn, AdminNr, RegionNamn)

Incident

Incident(Namn, Nr, Grad, Plats, RegionNamn)

Region

Region(Namn, Terräng)

Rapport

Rapport(Datum, Titel, IncNamn, IncNr, AgentNamn, AgentNr)

Observation

Observation(ID, Säkerhet, Datum, Grad, IncNamn, IncNr)

Person

Person(ID, Namn, Kodnamn)

Vittnen (Många till många tabell av entiteterna Observation och Person)

Vittnen (ObservationID, PersonID)

Krav

Nedan listas de krav som identifierats för respektive entitet. Dessa görs utifrån uppgiftsversion A.

Agent

• Agenter identifieras unikt med hjälp av dess namn (en bokstav) tillsammans med en siffra.
• Agentens levnadsfilosofi lagras som en kommentar för att kunna utvärdera hur pass bra agenten lever upp till sin levnadsfilosofi.
• 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.

Admin

• Administratörerna skall kunna tilldela en person fler möjligheter när tillåtelsen givits från högre ort.
• Ha en möjlighet att skapa och underhålla de andra användarnas rättigheter.
• Det användargränssnitt som används av databasadministratören behöver inte vara lika lättanvänt som de användargränssnitt som skall användas av agenterna, då databasadministratören förstår bland annat felkoder från SQL.

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 eller Insamlingsoperation:lämmeltåg.
• 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.
• Det är tillåtet för två olika operationer för samma incident på olika datum att ha samma kodnamn och typ.
• För varje avslutad operation lagras dessutom operationens slutdatum samt operationens success rate.
• Slutdatumet måste alltid vara senare än startdatumet, samt att en operation inte får vara kortare än en dag.
• Om skillnaden mellan en operations 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.
• De attribut 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.

Incident

• Ska kunna identifieras av unikt namn eller nummer.
• För incidenten lagras dessutom platsen som den inträffade på.
• Det skall gå att beräkna ett medelvärde på incidentens alla observationers grad.
• En incident måste inträffa i någon region.
• En incident kan dessutom ha en eller flera operationer kopplade till sig.

Region

• En region identifieras unikt av dess namn.
• För en region lagras dessutom en uppskattning av regionens huvudterräng, exempelvis stadsterräng, berg eller skog.
• Dessutom skall det gå att härleda regionens antal tidigare incidenter och operationer för att kunna se om regionen är överrepresenterad.
• Det finns regioner som under en viss tidsrymd är speciellt hemliga, dessa regioner skall temporärt kunna tas bort ur databasen för att senare kunna sättas in igen. En databasadministratör skall kunna ta bort regionen och även de kopplingar som regionen har till operationer och incidenter.
• Eftersom det dock är nödvändigt att incidenter och operationer är kopplade till regioner skall en specifik region som heter “hemligstämplat“ skapas, och sedan kopplas till de påverkade operationerna och incidenterna.
• Alla regioner måste ha någon typ av terräng lagrad, om inte, är default-värdet "blandad".

Rapport

• Det finns två olika typer av rapporter, vanliga rapporter samt uppföljningsrapporter.
• En vanlig rapport lämnas in av någon agent efter varje incident som inträffat (eller efter att incidentens operation slutförts).
• För slutrapporterna lagras en kortfattad kommentar (exempelvis max 25 tecken).
• Dessutom lagras typen av rapport för slutrapporten, eftersom slutrapporten skrivits av flera olika orsaker.
• 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”. Det ska sedan gå att återställa raderna till sin ursprungliga text.
• På alla typer av rapporter så måste värden för alla attributen lagras. Om typen för en rapport inte anges skall den automatiskt sättas till slutrapport.

Observation

• 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 varje observation måste observationens datum,grad samt säkerhet anges.
• För att mäta säkerheten i en observation används anges ett värde i procent.
• För att uppskatta grad/avstånd används ett intervall på 1-4, där 4 motsvarar extrem närkontakt.
• 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. Eftersom åtkomsttiden oberoende av frågeställning behöver vara under 1 sekund, är det mycket viktigt att alla möjliga optimeringsstrategier används för att optimera åtkomsthastigheten i dessa tabeller.
• För databasadministratörerna skall det vara möjligt att ta bort observationer om det är nödvändigt med total intern mörkläggning av observationerna.
• När en observation tas bort skall motsvarande kopplingar till personer och handläggare tas bort.
• De borttagna observationerna skall dock lagras i enloggtabell eller flera loggtabeller som tillåter att datan återskapas när hemligstämpeln släppts. För denna typen av uppdatering skall därför datumet för uppdateringen samt administratörens användarnamn lagras i loggtabellen eller loggtabellerna.
• 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.

Person

• En person kan ha rapporterat flera observationer och en observation kan ha rapporterats av flera personer.
• Varje person identifieras unikt utifrån dess personnummer eller om personen i fråga vill vara anonym ett automatgenererat nummer.
• Personens namn eller alias (om han vill vara anonym) lagras som en textsträng.
• Speciellt viktiga informatörer tilldelas ett kodnamn så de kan identifieras mycket fort.
• För att kunna bedöma personens trovärdighet utifrån tidigare observationer, huruvida om operationer som inletts på grund av dessa varit framgångsrika / misslyckade (lyckade operationer kan öka trovärdigheten).
• Personer som inte har kodnamn eller lämnat falska namn (inget namn) tros vara mindre trovärdiga än kända uppgiftslämnare.