| .DS_Store | ||
| database.sql | ||
| ER_Diagram.png | ||
| LICENSE | ||
| README.md | ||
Databaskonstruktion-Assignment-1-Startup Martin Löf
Startup code for first assignment in Databaskonstruktion
ER MODELL
RELATIONER
Agent(AgentNamn, AgentNr, AgentLön, AgentUnamn, AgentKommentar, AdminUIDtoken, AdminRum,AdminNamn, AdminNr)
Operation(OperationKodnmt, OperationStdatum, OperationSldatum, OperationSR, OperationKommentar,IncidentNamn, IncidentNr Regionnamn,AdminNamn, AdminNr)
Region(RegionNamn, RegionTerräng)
Incident(IncidentNamn, IncidentNr, IncidentPlats, RegionNamn)
Rapport(RapportDatum, RapportTitel, IncidentNamn, IncidentNr, AdminNamn, AdminNr)
Kampanj(KampanjNr, KampanjSdatum, KampanjSldatum, KampanjKommentar, KampanjSR)
KampanjIncident(KIncidentNamn, KIncidentNr KKampanjNr)
KRAV
- Kraven för alla entiter och dess attribut.
AGENT
-
Varje agent identifieras unikt med hjälp av dess namn (namnet är endast en bokstav exempelvis K), tillsammans med en siffra exempelvis J 2. Agentens levnadsfilosofi lagras som en kommentar för att kunna gå tillbaka och utvärdera hur pass bra agenten lever upp till sin levnadsfilosofi vid ett senare tillfälle. 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.
-
Vissa personer får av olika orsaker inte bli agenter. Det gäller personer som heter Leif Loket Olsson, Greger Puckowitz och Greve Dracula. Agenter skall inte tilldelas löner över 25000. Om ingen lön tilldelas så skall lönen automatiskt sättas till 13000.
-
Det nummer som tilldelas en viss agent får inte vara noll om inte personen är en gruppledare, i det fallet är numret tillåtet. Ingen agent får ha nummer som är mindre än noll. Talet 13 är av naturliga skäl inte tillåtet som agentnamn. Agentnummer över 99 är inte heller tillåtna. De härledda värden som skall beräkna ett antal, exempelvis antalet genomgångna operationer för en viss agent, skall värdet “Inga operationer“ visas i applikationen.
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.
-
För att bokning av olika agenter skall fungera så är det nödvändigt att operationens slutdatum anges, slutdatumet kan senare ändras för att passa det verkliga slutdatumet.
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 om den inte redan existerar och sedan kopplas till de påverkade operationerna och incidenterna. Alla regioner måste ha någon typ av terräng lagrad. Om inget värde tilldelas så skall det automatiskt sättas till “blandad”.
INCIDENT
-
En incidient kan identifieras antingen av dess unika namn eller dess unika nummer. För incidenten lagras dessutom platsen som den inträffade på.
-
En incident måste inträffa i någon region.
-
En incident kan dessutom ha en eller flera operationer kopplade till sig.
RAPPORT
-
En rapportlämnas in av någon agent efter varje incident som inträffat (eller efter att incidentens operation slutförts).
-
om något speciellt som borde rapporteras uppkommit, samt kampanjrapporter som gäller desinformationskampanjer, samt en övrigt typ som anger övriga rapporter. Slutligen skall det finnas två härledda attribut, ett som anger rapportens radantal, och ett som anger rapportens antal uppföljningar. 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”. När hemligstämpeln släppts skall det vara möjligt att återställa rapporten till sitt tidigare utseende. På alla typer av rapporter så måste värden för alla attributen lagras.
KAMPANJ
-
Varje unik desinformationskampanj identifieras av dess nummer.
-
Till en viss incident kan flera olika desinformationskampanjer kopplas och en viss kampanj kan gälla flera olika incidenter. För varje unik kampanj lagras dessutom dess success rate som talar om om kampanjen lyckades eller misslyckades. Kampanjens startdatum och slutdatum talar om när kampanjen påbörjades samt avslutades, en kampanj kan vara pågående (null på slutdatum) men den måste ha en början. Dessutom lagras en kommentar (högst 80 tecken) om kampanjen och dess uppgift.
-
Det skall med hjälp av ett specialkommando för de agenter som arbetat med kampanjen vara möjligt att ta bort eller uppdatera en desinformationskampanj. Modifikationen i sig behöver inte loggas.
KAMPANJINCIDENT
- En tabell skapad eftersom kampanj och incident är en många till många relation.
