Databasadministratör Databas

Här kommer databasen för databasadministratörer att skapas!

Relationer

Agent(Bokstav, Nummer, Typ, Lön, Namn, Kommentar)
Admin(AgentBokstav, AgentNummer, UIDToken, Rum)
Gruppledare(AgentBokstav, AgentNummer)
Region(Namn, Terräng)
Incident(Nummer, Namn, RegionNamn)
Operation(Kodnamn, Startdatum, IncidentNummer, Slutdatum, Lyckad, Kommentar) \

Krav

Agent

En agent identifieras med en bokstav tillsammans med en siffra. Alla agenter måste ha ett nummer mellan 1 och 99 (inklusive start och slut) förutom 13. Om agenten är en gruppledare får agenten även ha numret 0. Vissa personer får inte bli agenter, detta gäller Leif Lokey Olsson, Greger Puckowitz och Greve Dracula. Typen av agent ska också sparas. Agentens lön, ursprungliga namn, samt levnadsfilosofi i form av en kommanter ska också sparas. Lönenes tak är 25,000 om de inte är gruppledare, och golvet är 12,000. Automatiska lönen som sätts är 13,000. Ett användargränssnitt ska vara lämpad för varje agents arbetsuppgifter.

Databasadministratör

Administratörer har en UIDToken som är ett tal med 8 siffror. Administratörer har ett rum som de sitter i lagrat i databasen. Rummets namn är uppbyggt av en bokstav följt av 3 siffror. Databasadministratören ska kunna ta bort regioner, samt de kopplingar regionen har till operationer samt incidenter. Databasadministratören har tillgång att ta bort regioner. Användargränsnittet som används av administratören behöver inte vara lika lättanvänt, då administratören förstår SQL felkoder. Användargränsnittet får dock inte vara för svåranvänt så att det hindrar effektiviteten av arbetet. Administratören skall ha möjligheter att med ett grafiskt gränssnitt lagra nya tuppler enligt i tidigare delar av kravspecifikationen fastställda normer samt ha en möjlighet att skapa och underhålla de andra användarnas rättigheter. Administratören har samma rättigheter som alla andra användargrupper tillsammans plus ytterligare rättigheter till vissa specialoperationer. Administratörerna har endast rättigheter att ta bort eller modifiera data i tabeller om den rättigheten tilldelats i detta dokument. Administratören skall ha rättigheter att skapa tuppler i tabellerna gällande regioner och agenter. Om en användare gör någon form av förbjuden åtgärd (exempelvis försöker uppdatera en tabell med restriktioner fler gånger än tillåtet)skall den automatiskt hamna i en lista med förbjudna åtgärder.

Gruppledare

Gruppledare har endast de härledda attributer: Operations, Rate, Lyckade, ORate Alla operationer ska vara sorterade på slutdatum, och en gruppledare kan styra 2 operationer om de inte tillhör samma incident, annars 5. Gruppledarens lön kan stiga upp till 35,000. Gruppledare får även ha numret 0. Operationens namn, datum och plats ska tydligt visas på gränssnittet. Det ska finnas en lista med pågående operationer där gruppledaren kan ändra slutdatum (samt om operationen var lyckad eller ej antar jag?). När en ny incident tilldelas till en gruppledare ska detta automatiskt visas vid start av applikationen eller direkt när händelsen inträffar. Gruppledaren skall kunna starta en ny operation för den tilldelade incidenten. Gruppledaren har rättigheter att läsa all information i alla tabeller utom i tabellerna andra gruppledare annat än deras namn och härledda attribut. Gruppledaren har rättigheter att skapa nya oeprationer för en viss incident. Gruppledaren har inte rättigheter att skapa nya incidenter

Operation

Varje operation identifieras av dess kodnamnstyp, tillsammans med startdatum och incidenten. Kodnamntypen anger både operationens kodnamn samt dess typ. Flera operationer kan skapas med samma kodnamn kring samma incident ifall startdatumet är annorlunda. En kommentar kan lagras om operationen, där agenter kan lagra viktig information utöver informationen i operationens förbestämda fält. En operation måste styras av en gruppledare. När operationen är avslutad, sparas även dess slutdatum samt ifall operationen var lyckad, där 1 är lyckad or 0 är olyckad. Vid bokning av agenter måste ett preliminärt slutdatum vara satt. Slutdatumet måste vara efter startdatumet, samt så måste operationen vara mellan 1 dag och 5 veckor. När gruppledaren ändrar slutdatumet måste allt omevalueras (gruppledare). Ifall det sker en dubbelbokning av en gruppledare så får gruppledaren ett felmeddelande och ändringen avbryts.

Incident

En incident kan identifieras med dess unika namn eller unika nummer. Platsen där incidenten skedde ska lagras. En incident måste inträffa i en region. En incident kan ha flera operationer kopplade till sig.

Region

Varje region identfieras unikt av dess namn. För en region lagras dessutom en uppskattning av regionens huvudterräng. Det ska kunna gå att härleda regionens antal tidigare incidenter och operationer för att kunna se om regionen är överrepresenterad. Vissa regioner är under en viss tidsrymd hemliga och ska kunnas ta bort från databasen för att sedan lägga till dem igen. Om en region tas bort måste en specific 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 en terräng lagrad, om ingen terräng anges ska den atuomatiskt sättas till "blandad".

Inför muntlig redovisning

1.

Jag blev tilldelad grupp A, vilket var databasadministratör.

2.

Konceptuell Design

För att avgränsa databasen så valde jag att utgå ifrån databasadministratör tabellen, och sedan grena utåt. Jag grenade först ut till Operation tabellen, vilket hade flera relationer som behövde finnas med i databasen. Operation tabellen behövde: Gruppledare, Incident och Region. Eftersom gruppledare och databasadministratör fanns med i databasen så var det bara naturligt att även lägga till Agent tabellen.

Logisk Databasdesign

Det första steget av logiska databasdesignen var bara att översätta ER modellens tabeller till relationer i tabellform, vilket inte var några problem. I andra steget skapade jag SQL kod samt bestämde datatyper för de alla olika attributer i tabellerna, jag skulle kanske kunnat vara lite mer sträng på dataanvändningen med varchar men det var inte super viktigt. För att testa alla tabeller lade jag sedan in massa inserts med relevant data (steg 3), och allt funkade bra. För att hålla datan konsekvent så används constraints, vilket jag lade till som stämmer överens med kravspecifikationerna. Eftersom constraintsen kräver mer specifik data behövde jag ändra på mina tidigare inserts så att de fungerade med constraintsen.

Fysisk Databasdesign

Jag råkade läsa fel i uppgiften, så råkade göra en merge på arvrelationer (vilket jag märkte efter jag gjort steg 13), men jag fixade detta och återuppfyllda krav 9. Denormaliseringsdelen känns intuitivt och hade inte problem med den delen. Att fixa insertsen som redan fanns i koden gick bra och hade inte några problem med det. Vart man skulle sätta sina indexes var lite klurigt, men jag är nöjd med de valen jag gjorde och det fungerar bra. Att skapa rättigheter för användare gick också bra, det var bara att gå igenom kravspecifikationerna och hitta de saker dem skulle ha tillgång till. Procedures och triggers var lite svårt att förstå först, men efter ett tag så hajade jag det. Det var även lite svårt att skriva alla procedures och triggers men det löste sig till slut.

3.

LoggaNyOperation

"LoggaNyOperation" skapar en trigger på tabellen "Operation" som körs efter en insert på tabellen. Den skapar sedan en ny rad i tabellen "OperationsLogg" där den lagrar typen av action på Operation tabellen, vilken användare som genomförde det, hela primary nyckeln för operations raden, samt den aktuella tidspunkten.

KollaAgentTyp

"KollaAgentTyp" skapar en trigger på Operation som körs innan en insert på tabellen. Den triggern säkerställer att bokstaven och nummret kopplat till operationens gruppledare existerar i gruppledare tabellen, samt kollar den också samma ska för admin bokstaven och numret och kollar de mot DBAdmin tabellen. Ifall något av dessa inte är fel så skickas ett felmeddellande tillbaka och SQLSTATE sätts till "45000" vilket avbryter inserten.

AvslutaOperation

"AvslutaOperation" proceduren tar in 4 värden som parametrar, 3 av dessa är en operations primary nyckel, och den sista är ifall den operationen lyckades eller inte. Först skapar proceduren en rad i AvklaradOperation, och sätter in alla värden i den som finns i den existerade raden i Operation tabellen, efter det så tar proceduren bort den originella operationen i Operation. Detta gör så att de avklarade operationer inte behöver blue queryade varje gång man vill hämta de aktiva operationerna.

AntalOperationer

"AntalOperationer" proceduren tar in en gruppledares bokstav och nummer och gör en select som visar hur många operationer en viss gruppledare är ansvarig för med hjälp av COUNT funktionen i en select sats.