| database.sql | ||
| ER_Diagram.svg | ||
| LICENSE | ||
| README.md | ||
Databaskonstruktion-Assignment-1-Startup
Startup code for first assignment in Databaskonstruktion
Översikt
För den här uppgiften blev jag tilldelad uppgift C Jag har valt att ta med mig det följande i från diagramet: Agent, FältAgent, Hjälpmedel, Operation, Incident, Region, Alien, Skepp, Rapport och Uppföljning
Konceptuell Databasdesign
Jag tog endast med mig de delar av databasen som verkade relevant och/eller nödvändigt för en Fält Agent att kunna fungera inom databasen. Som exempel så måste det finnas hjälpmedel eftersom en fält agent ska kunna ha en favorit. Dock så krävs inte de andra agenterna för att fältagenten ska kunna finnas. Jag började med att modifiera ER diagramet och började ta fram de möjliga relationer jag skulle kunna tänka mig skulle krävas (Så som AgentsHjälpmedel eller AgentOperation)
ER model
Relationer
Agent(Namn, Nr, Lön, Unamn, Kommentar)
FältAgent((Kompetens), SpecialKompetens, *SuccessRate, *Uppdrag, FavoritHjälpmedelNamn, FavoritHjälpmedelNummer)
Hjälpmedel(Namn, Nr, Beskrivning)
AgentsHjälpmedel (AgentNamn, AgentNr, HjälpmedelNamn, HjälpmedelNr)
Operation(Kodnamntyp, IncidentNamn, IncidentNummer, IncidentPlats, Startdatum, Slutdatum, SuccessRate, Kommentar)
AgentOperation (AgentNamn, AgentNr, Kodnamntyp, IncidentNamn, IncidentNummer, Startdatum)
Incident(Namn, Nummer, *Grad, Plats)
Region(Namn, Terräng, *Incidenter, *Operationer)
Alien(IDKod, (Kännetecken), Farlighet)
Skepp(ID, (Kännetecken), Sittplatser, Tillverkat)
Rapport(Datum, Titel, IncidentNamn, IncidentNummer, AgentNamn, AgentNr Uppfölj, Rader)
Rad(Nr, RaportDatum, RaportTitel, Text)
Avslutningsrapport(Kommentar, Typ RapportDatum, RapportTitel)
Krav
Här så listas alla krav på de olika entiteter inom databasen och hur de ska funka i slutändan:
Agent
- Namnet är en bokstav tillsammans med en siffra.
- Deras "levnadsfilosofi" ska lagras som en kommentar.
- Nummret det tilldelas får inte vara: Negativt, 0, 13 eller över 99.
- Deras lön för inte vara över 25,000 men aldrig mindre än 12,000. Default lön är 13,000.
FältAgent
- Kan ha flera hjälpemdel men endast ett favorit-hjälpmedel.
- Fältagenter har flera kompetenser men endast en "Specialkompetens".
- Det ska gå att berkäkna agentens totala antal operationer och lyckade operationer.
- De får inte arbeta på fler än en operation samtidigt, om inte de är i samma region. I det fallet så får de jobba på upp till tre operationer åt gången.
Hjälpmedel
- Samma hjälpmedel får inte tilldelas till olika operationer samtidigt
- Ordningsnummeret får aldrig vara högre än femton eller än ett.
Incident
- En incident måste ha en region
Region
- Regioner ska kunnas temporärt tas bort (samt kopplingar till operationer) och bytas ut med "Hemligtstämplat"
- Om ingen terräng ges så är terrängen "blanded" av default
Operation
- Kodnamntypen är operationens kodnamn och dens typ i ett och samma värde
- Två olika operationer för samma incident på olika datum får ha samma kodnamn och typ
- Slutdatumet måste vara efter startdatumet
- Operationen får inte vara kortare än en dag eller längre än fem veckor.
Alien
- Olika farlighets grader: Harmlös, Halvt harmlös, Ofarlig, Neutral, Svagt farlig, Farlig, Extremt farlig, Spring för livet.
Skepp
- Alla skepp måste ha ettt tillverkningsplanet
Rapport
- Vanlig rapport skappas av en agent efter varje incident
- Man ska kunna ta bort/hemligstämpla rapporter och alla dens rader, det ska loggas så att det är möjligt att återskapa raporten när den inte längre är hemligstämplad.
- Det ska också vara möjligt att ta bort vissa rader, i de fallen så byts de ut med "Hemligstämplat" och senare när det släpps så ska de återskapas.
- Om det finns ingen typ så defaultas det till "Slutrapport"
Avslutningsrapport
- Max 25 tecken på kommentar
- Skappas när en operation är klar
- Får inte vara kortare än en dag i längd.
Logisk Databasdesign
Den logiska databasdesignen ändrades mycket under uppgiftens gång. Med introduktion av merges, koder och annan normalizering. Till slut så blev det ett flertal till tabeller som funkar som relationer mellan andra tabeller (Som mellan Hjälpmedel - Operation. Hjälpmedel - FältAgent samt Hjälpmedel(Favorit) - FältAgent). Det var svårt att veta vad man kunde/skulle splita inom en tabell, och efter man hade splittat en tabell (Vertikalt eller Horizontelt) om man fick sedan merga de igen, jag själv gjorde inte det för säkerhetens skull.
Vi har fyra procedurer inom databasen: Först så har vi en AgentLogg tabell med en trigger. När en agent blir inserted till Agent tabellen så aktiveras en procedur som insertar samma värden in till "AgentLogg" tabellen.
En annan vi har är på Lön raden inom Anställd tabellen(Som var splittad ifrån Agent) där vi har en constraint för att se till att Löne värdet inte är större eller mindre än några värden.
De två andra procedurer har samma funktion men på olika tabeller:
"HÄMTAIDENTIFIERING" Selectar allt från "Identifering"s tabellen
Och "HÄMTAOPERATIONPLATSMÄNGD" mer eller mindre hämtar hur många incidenter en särskild plats har
Fysisk
Operationstabellen är en bra start, det är en merge mellan Operation, Incident och Region, detta är bägge bra och dåligt. Bra: Det är enklare att inserta och modifiera data inom en endaste tabell instället för att behöva gå till två olika tabeller. Dåligt: Det är väldigt svårt att hålla reda på endast incidenterna/Region i sig själva och det blir bökigt med allt annan data som man inte är intresserad i (Om man är endast ute efter Incident eller Region relaterad data)
Anställd tabellen är en Vertikal split i från Agent, där vi istället har all data för de som är anställda inom PUCKO, man kan vara Anställd där utan att vara en Agent, men en Agent (Och Fält Agent) är alltid anställd där.
Men Alien och Skepp så gjorde jag en mix av Kodefiering och en split. Bägge Alien och Skepp använder en Vertikal splittad tabel "Identifiering" för att identifera de inom databasen, det betyder att en ID inom Alien har ett annan resultat inom Skepp. Med skepp då så kodifierade jag ut Tillverkningsplaneten och gjorde då tabellen "Planet"