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ås 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.

• 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).

• Det skall vara möjligt att ta bort (hemligstämpla) hela rapporter Borttagningen skall loggas så det är möjligt att återskapa rapporten i sin helhet när hemligstämpeln släppts.

• Slutligen skall det vara möjligt att hemligstämpla vissa rader i en rapport, rapporten 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 kampanj identifieras av dess nummer.

• Till en viss incident kan flera olika kampanjer ha 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 kampanj. Modifikationen i sig behöver inte loggas.

KAMPANJINCIDENT

• En tabell skapad eftersom kampanj och incident är en många till många relation.

• Tilldelad uppgift A, databasen har utformats efter att hantera agenter, operationer, incidenter, rapporter, regioner och kampanjer.

Databasdesign

Konceptuell Databasdesign

• Den konceptuella databasdesignen skapades efter admin och blev utvald efter vad som jag tyckte krävdes för att få en databas som fungerar. inga relationer ändrades utan jag enbart plockade ut tabeller.

Logisk Databasdesign

• vid skapandet av den logiska databasdesignen utgick jag ifrån den befintliga ER modellen, det jag ändrade var att slå ihop admin och agent eftersom admin är ett agent arv, samt att de har en till många koppling. Annars kopplade jag ihop allting enligt Er modellen och skapade nycklar för varje tabell och även kolumner till varje tabell.

Fysisk Databasdesign

• I den fysiska databasdesignen genomförde jag flera ändringar för att anpassa strukturen och för att förbättra prestandan. jag använde merging för att slå ihop region och incident, horisontell genom en uppdeling av operation och vertikal uppdelning av rapport. jag kodifierade regionterrang och incidentplats samt skapade index för att effektivisera sökning på incidentnr. jag skapade även användare med olika rättigheter för att begräna åtkomsten till databasen.

Procedur/Trigger

Procedur AgentLön

• Denna procedur skapades för att kontrollera samt sätta en agentlön genom en call. När call utförs kontrolleras den angivna lönen så att den inte är för låg eller för hög, ifall den är inom rimlig gräns kommer lönen att uppdateras.

Procedur Regionhemlig

• Denna procedur gör om ett regionnamn till hemligstämplad, genom att använda en call och skriva in regionnamnet som ska bli hemligt ersätts det gamla namnet med det nya.

Trigger namnkoll

• Denna trigger kontrollerar att vissa namn inte får anges i inserts, alltså ifall något namn är angett men inte får vara angett kommer triggern inte tillåta inserten.