PUCKO – databas för omexamination HT 2026

Overview / vald del

Jag tillhör Reexamination – Same as Last Year Assignment Variant. Jag behåller den tidigare lösningens inriktning på operationer, agent- och hjälpmedelsbokningar samt rapporter och uppföljningar. Gruppledare och fältagenter använder den delen. Hemligstämpling demonstreras av databasägaren; inget separat administratörsgränssnitt ingår. Detta är inte ett påstående om en ny tilldelning till grupp A–E.

Urvalets sju huvuddelar är Agent, Operation, Incident, Hjälpmedel, Rapport, Uppföljningsrapport och Rad: ungefär en fjärdedel av originalets 27 rutor. Agenttyper och vanliga rapporttyper hanteras med typattribut i den befintliga implementationen. Tekniska logg-, kod-, kopplings- och sammanställningstabeller är inte ytterligare verksamhetsentiteter. Exakt bedömning av urvalet och hur originalets subtyper räknas behöver stämmas av mot omexaminationsvarianten; filerna ändrar inte lärarens tilldelning.

Aliens, skepp, vapen, observationer, medier, personer, kampanjer och undanflykter ingår inte. Administration av hela myndighetens databas ingår inte heller. Incidentuppgifter behövs som sammanhang för operationerna, men nyregistrering av incidenter via handläggarens gränssnitt ingår inte.

Krav per entitet

Agent

• Bokstav och nummer identifierar agenten. Nummer ska vara 0–99, inte 13; noll är bara tillåtet för gruppledare.
• Förnamn, efternamn, lön och levnadsfilosofi ska lagras. Fullständigt namn härleds.
• Lön ska vara 12000–25000, eller högst 35000 för gruppledare; standardvärde är 13000. De tre förbjudna personnamnen ska avvisas.
• Fältagentens kompetenser är flervärda. Specialkompetens och region behövs för bemanning. Favorithjälpmedel är en M:N-relation.
• Fältagent får ha högst en samtidig operation, eller tre om alla ligger i samma region. Gruppledare får ha två, eller fem om alla gäller samma incident.
• Antal operationer och lyckade operationer/procent ska kunna härledas. Noll ska kunna visas som ”Inga operationer”.
• Var femte start ska en lämplig uppföljning tilldelas om agenten saknar pågående uppföljning. Egen eller tidigare uppföljd originalrapport får inte tilldelas.

Incident

• Namn och nummer identifierar incidenten. Region och plats används i operationsplaneringen.
• Flera operationer får höra till samma incident. Samma incident får inte ha motstridiga region- och platsuppgifter i denna prototyp.
• Incident utan operation ingår inte i den valda prototypen. Det är en uttrycklig avgränsning, inte ett generellt krav på PUCKO.

Operation

• Kodnamntyp, startdatum och incident identifierar en operation. Surrogatnyckeln OperationID behålls men ersätter inte UNIQUE för verksamhetsnyckeln.
• Varje operation har en gruppledare. Fältagenter och hjälpmedel tilldelas genom kopplingstabeller.
• Slutdatum krävs för bokning. Längden ska vara minst en dag; över fem veckor korrigeras till fem veckor.
• När slutdatum ändras ska bokningar och ledargränser prövas på nytt; en konflikt ska avbryta ändringen.
• Resultat är 0 eller 1. En frivillig kommentar ska kunna lagras.
• Mer än fem fältagenter ger en varning i v_Operationsvarning, inte ett förbud.

Hjälpmedel

• Namn och nummer bildar nyckeln. Kort beskrivning lagras. Ordningsnummer ska vara 1–15.
• Ett hjälpmedel får inte användas av överlappande operationer.
• Ansvarig gruppledare kan ta bort ett förlorat hjälpmedel, inklusive bokningar och favoritkopplingar. Antal hjälpmedel beräknas från aktuella bokningar.

Rapport

• Datum, titel, författare, typ och kort kommentar ska lagras. Rapporttypen är slutrapport om den inte anges. Kort kommentar får vara högst 25 tecken.
• Rapportens text, radantal och antal uppföljningar ska vara åtkomliga.
• Hela rapporten ska kunna hemligstämplas tillsammans med rader och uppföljningar och återställas med ursprungliga identiteter.
• Enstaka rader ska kunna ersättas med ”hemligstämplat” och senare återställas.
• Fältagenter får läsa egna rapporter och rapportkedjor som de tilldelats att följa upp. Gruppledare får läsa rapporterna i den valda delen.

Uppföljningsrapport

• Uppföljningen har egen författare, titel, startdatum, slutdatum, kommentar och utslag. Kommentar får vara högst 80 tecken; standardutslag är 0.
• NULL slutdatum betecknar en pågående uppföljning. När den avslutas måste slutdatum ligga efter startdatum; ingen femveckorsgräns används.
• Underlaget är en fältrapport för misslyckad operation eller en misslyckad uppföljning. Två år ska ha gått sedan den aktuella delen avslutades.
• Uppföljningarna ordnas efter UppfID inom samma originalrapport, som i den tidigare lösningen. Återställning av arkiverade data är skild från tilldelning av en ny uppföljning.

Rad

• En rapport kan ha noll eller flera rader. Varje rad har högst 80 tecken och ett nummer i följd från 1.
• Numret och kopplingen får inte ändras för en befintlig rad. Enskild borttagning får bara ske från slutet.
• Rad innehåller både vanliga rapporters och uppföljningars rader. RapportDel är 0 för originalrapporten och uppföljningens ID för dess rader.

Antaganden och otydligheter

1. Bokningsdatum är inkluderande: samma slut- och startdag räknas som överlapp. Minst en dag betyder slutdatum > startdatum.
2. AgentKod är bokstav direkt följd av AgentNr, exempelvis F1. Textens formulering om ”13 som agentnamn” tolkas som agentnummer 13.
3. Hjälpmedlets Nummer och OrdningsNr representerar samma nummer. Båda kolumnerna behålls för kompatibilitet men måste överensstämma.
4. Kodnamn innehåller både operationens kodnamn och typ, enligt specifikationens sammansatta kodnamntyp.
5. Varje originalrapport har en sekventiell uppföljningskedja och högst en pågående uppföljning. En ny uppföljning granskar kedjans senaste misslyckade del.
6. Kommentarens maximum för levnadsfilosofi sätts till 255 tecken eftersom specifikationen inte anger någon längd.
7. Uppföljningens StartDatum används som dess rapportdatum. Titel genereras vid tilldelningen. Datum/titel är unikt inom respektive rapporttabell.
8. Hemligstämpling och återställning utförs av databasägaren i denna prototyp eftersom texten inte entydigt pekar ut en roll. Vanliga agentkonton får inte läsa arkiv eller hemliga originaltexter.
9. Databasägaren får utföra installation, test och återställning. De två exempelkontona kopplas till var sin agent; de är inte delade konton för flera verkliga personer.
10. Avvisade proceduranrop och utvalda triggerkontroller loggas i MyISAM-tabellen Logg_Felbokning så att en rollback inte raderar felloggen. Arkiv och övriga verksamhetsdata använder InnoDB. Klienten i del 2 måste fånga nekade direkta SQL-anrop (inklusive constraint- och behörighetsfel) och anropa LoggaForbjudenAtgard. Det krävs för att även de felen ska loggas; en tabelltrigger kan inte fånga ett nekat GRANT-tillstånd.
11. Funktionen för att hemligstämpla en rapport är återställbar arkivering. Arkivloggen behålls efter återställning. En ny hemligstämpling skapar en ny loggpost.
12. Databasägaren sköter underhåll. Agentkonton får göra vissa direkta INSERT/DELETE/UPDATE med triggerkontroller. Rapporttext skrivs genom SkrivRapportText för att textlagring och radnummer ska stämma.

Konceptuell databasdesign

Diagrammet visar urvalet och sambanden mellan verksamhetsobjekten, inte samtliga fysiska hjälptabeller. En operation har en incident, en ledare, flera fältagenter och flera hjälpmedel. Rapporten knyts till operationen; uppföljningarna bildar en kedja. Agenternas roller behålls som typattribut i den tidigare lösningen.

Logisk databasdesign

Följande relationsöversikt beskriver utgångsläget före denormalisering. Den ska bevaras när den fysiska modellen ändras. PK står för primärnyckel och FK för främmande nyckel.

Relation	Nycklar och centrala attribut
Agent	PK AgentKod; AgentNr, Typ, Förnamn, Efternamn, Lön, Kommentar, Region, Specialkompetens
AgentKompetens	PK/FK AgentKod + PK Kompetens; flervärt attribut
Incident	PK Namn + Nr; Region, Plats
Operation	PK OperationID; FK IncidentNamn + IncidentNr; FK Gruppledare; Kodnamn, StartDatum, SlutDatum, SuccessRate, Kommentar
OperationFaltagent	PK/FK OperationID + AgentKod
Hjälpmedel	PK Namn + Nummer; OrdningsNr, Beskrivning
OperationHjalpmedel	PK/FK OperationID + Namn + Nummer
FavoritHjalpmedel	PK/FK AgentKod + Namn + Nummer
Rapport	PK RapportID; UNIQUE Datum + Titel; FK OperationID, Författare; Typ, KortKommentar, Text
Uppföljningsrapport	PK UppfID; FK RapportID, Författare; StartDatum, Titel, SlutDatum, Utslag, Kommentar
Rad	PK RadID; UNIQUE RapportID + RapportDel + Nr; FK RapportID och eventuell UppfID; Text

AgentKod och de ursprungliga surrogatnycklarna behålls för att undvika onödiga ändringar inför del 2. Typkodtabellerna är den fysiska kodifieringen av texttyperna ovan. RapportText är en separat lagring av originalrapportens hela text; Rad upprätthåller radreglerna och den hela texten synkroniseras av skrivproceduren.

Fysisk databasdesign

Datatyper och constraints

INT används för identiteter och antal, TINYINT för koder/resultat, VARCHAR för korta texter, DATE/DATETIME för datum, LONGTEXT/TEXT för rapporttext och JSON för återställningsunderlag. PK, FK, UNIQUE och NOT NULL används tillsammans med namngivna och befintliga CHECK-villkor. Regler över flera rader, datumkorrigering och behörighetskontroller ligger i procedurer/triggers.

Denormalisering

Teknik	Konkret utförande	Motiv och konsekvens
Merge 1:N	Incident skapas och får data, Operation kopplas med FK; Region/Plats förs över med UPDATE JOIN, FK tas bort och Incident tas bort.	Operationslistan behöver incidentens plats utan extra JOIN. Incidentuppgifter dupliceras och kontrolleras för överensstämmelse. Incidenter utan operation stöds inte i denna avgränsning.
Kodifiering 1	Agent.TypCode refererar till AgentTypCodes.	Den lagrade typen är ett litet tal. Typ är en virtuell läskolumn som behåller befintliga strängvärden.
Kodifiering 2	Rapport.TypCode refererar till RapportTypCodes.	Samma princip för rapporternas typer; standardkod 1 motsvarar slutrapport.
Vertikal 1	Operation.Kommentar flyttas till OperationKommentar.	Valfri längre text hålls utanför de ofta lästa bokningsraderna. Två exempelkommentarer flyttas i scriptet.
Vertikal 2	Rapport.Text flyttas till RapportText.	Rapportlistor kan läsas utan hela texten. Den befintliga v_RapportFull återförenar delarna.

Detta är en merge + två kodifieringar samt två vertikala uppdelningar. Ingen av dessa är en merge eller split av en arvsrelation. Extra operationskopior och regionspeglingar har tagits bort. OpAgentCount och OpToolCount är vyer som beräknar antal direkt från bokningarna, utan separata tabeller eller uppdateringstriggers.

Indexering

Två extra index används: Agent(Typ, AgentKod) för typurval och Operation(Region, StartDatum) för sökning per region och startdatum.

Rättigheter

DatabasAgent kopplar användarnamn till agent. Gruppledaren får tilldela/avboka fältagenter, avboka hjälpmedel, ändra slutdatum och skapa rapporter direkt med befintliga triggerkontroller. BokaHjalpmedel och SkapaOperation behålls som procedurer. Fältagenten skriver egna rapporter och avslutar egna uppföljningar. Vyer begränsar läsåtkomsten. Endast databasägaren har åtkomst till sekretessprocedurer och arkiv; inga sådana rättigheter ges till applikationskontona.

Procedurer och triggers inför muntlig redovisning

Tabellen beskriver kraven och varför funktionerna behövs. SQL-kommentarerna beskriver den konkreta kodåtgärden. Dubblerade kontroller, extra operationskopior och det separata demonstrationssystemet för lösenord har tagits bort. Behörigheterna använder MySQL-konton och DatabasAgent.

Procedur/trigger	Krav eller beslut som motiverar den
VerifieraGruppledare	Bokningar och ändrad operationslängd tillhör den ansvariga ledaren. Ett annat agentkonto får inte ändra någon annans operation.
KontrolleraGruppledarbokning	Ledarkapaciteten beror på om samtidiga uppdrag avser samma incident. Gränsen måste kontrolleras för hela det föreslagna intervallet.
KontrolleraFaltbokning	Bemanning i olika regioner ska inte krocka; undantaget för tre uppdrag gäller bara en och samma region.
trg_oh_before_ins	Verksamhetens giltighets- och bokningsregler ska gälla även när tabellerna nås utan de vanliga procedurerna.
trg_op_before_ins	Verksamhetens giltighets- och bokningsregler ska gälla även när tabellerna nås utan de vanliga procedurerna.
trg_op_before_upd	Verksamhetens giltighets- och bokningsregler ska gälla även när tabellerna nås utan de vanliga procedurerna.
trg_ofa_before_upd	Verksamhetens giltighets- och bokningsregler ska gälla även när tabellerna nås utan de vanliga procedurerna.
trg_oh_before_upd	Verksamhetens giltighets- och bokningsregler ska gälla även när tabellerna nås utan de vanliga procedurerna.
TilldelaUppfoljning	Tvåårsregeln, misslyckat resultat och oberoende granskare ska uppfyllas innan en uppföljning skapas.
BokaHjalpmedel	En fysisk resurs kan inte användas på två platser under samma tid. Befintligt procedurnamn behålls för del 2.
trg_ofa_before_ins	Verksamhetens giltighets- och bokningsregler ska gälla även när tabellerna nås utan de vanliga procedurerna.
GETOPTOOLCOUNT	Fältagenten behöver kunna se utrustning för sitt eget uppdrag utan insyn i andra operationers utrustning.
trg_oh_before_del	Verksamhetens giltighets- och bokningsregler ska gälla även när tabellerna nås utan de vanliga procedurerna.
trg_rapport_before_ins	Rapporthanteringen behöver spårbarhet och skydd mot felaktig författaridentitet.
StartaFaltagent	Tilldelning ska ske vid var femte applikationsstart, inte vid varje sidvisning. Befintlig pågående uppföljning ska respekteras.
trg_rad_ins	Rapportens rader måste förbli identifierbara och sammanhängande även om en ändring görs direkt i databasen.
trg_rad_upd	Rapportens rader måste förbli identifierbara och sammanhängande även om en ändring görs direkt i databasen.
trg_rad_del	Rapportens rader måste förbli identifierbara och sammanhängande även om en ändring görs direkt i databasen.
VerifieraRapportskrivare	Agenten får inte skriva i en annan agents rapport eller uppföljning.
SynkroniseraRapportText	Det gamla textgränssnittet ska kunna användas efter att rapporternas radregler införts.
SkrivRapportText	Alla textinmatningar ska uppfylla 80-teckensgränsen och kunna ersättas atomärt utan luckor i radnumren.
HemligstamplaRad	Uppgiften kräver maskering utan att ursprungstexten går förlorad.
AterstallRad	En släppt hemligstämpel ska återge exakt den text som doldes.
HemligstamplaRapport	Sekretessen omfattar hela rapportkedjan; dess data måste kunna återföras efter borttagningen.
AterstallRapport	Återställning ska bevara rapport-, uppföljnings- och radidentiteter samt länkar.
SkapaOperation	Ledaren får skapa deloperationer till den incident som redan tilldelats ledaren.
AvslutaUppfoljning	Den tilldelade granskaren måste kunna ange slutsats och en giltig avslutningstid.
TaBortHjalpmedel	Förlorad utrustning ska kunna avregistreras med sina kopplingar, men bara av ansvarig ledare.
trg_kompetens_ins	Kompetenser och favorithjälpmedel tillhör fältagentrollen i den valda delen av verksamheten.
trg_favorit_ins	Kompetenser och favorithjälpmedel tillhör fältagentrollen i den valda delen av verksamheten.
LoggaForbjudenAtgard	Klienten behöver registrera nekade SQL-rättigheter som stoppats före en procedurs körning.

Körning och verifiering

Kör database.sql i en separat testinstallation som databasägare med rätt att skapa databas, användare, procedurer, triggers och rättigheter. Scriptet riktar sig till MySQL 8.0.21 eller senare, inte MariaDB. Det återskapar pucko_ludwig och de tre namngivna demonstrationskontona. Befintliga data i den databasen försvinner.

Den tidigare versionen innehöll automatiska SQL-tester för constraints, bokningar, denormalisering, sekretess, återställning och beräknade antal. Testerna har lyfts ut ur installationsfilen och ingår inte i denna inlämning. Testning av G-kraven ska ändå kunna redovisas.

Behörighetskontroll inför del 2

• Prova som gruppledarkontot: skapa operation via SkapaOperation, tilldela fältagent med INSERT och ändra SlutDatum.
• Prova som fältagentkontot: läs v_MinaHjalpmedel/v_MinaRader och skriv egen rapport. Skrivning i någon annans rapport ska avvisas.
• Fältagentkontot ska nekas direkt läsning av sekretessarkiv och skrivning i Operation/Rad.
• Koppla klientens felhantering till LoggaForbjudenAtgard för nekade direkta SQL-anrop.

Datatäckning

Det finns äldre och pågående operationer, flera agenter och resurser, flera rapporter och uppföljningar, samt återställda sekretessloggar och verkliga avvisade testanrop. Flera operationer saknar frivillig kommentar, vilket visar tillåtna frånvarande kopplingar. Resursantal beräknas av vyer.

Del 2 – gränssnitt mot databasen

• De centrala namnen Agent, Operation, OperationFaltagent, Hjalpmedel, OperationHjalpmedel, Rapport, RapportText och Uppfoljningsrapport behålls.
• Gruppledaren använder INSERT/DELETE i OperationFaltagent, DELETE i OperationHjalpmedel och UPDATE av Operation.SlutDatum. Befintliga triggers kontrollerar reglerna. BokaHjalpmedel och SkapaOperation anropas för nya bokningar/operationer.
• Rapporter skapas med INSERT i Rapport; TypCode används vid skrivning och Typ är läsbar. SkrivRapportText tar rapport-ID, eventuell uppföljnings-ID och texten.
• StartaFaltagent anropas en gång per faktisk applikationsstart. AvslutaUppfoljning avslutar den egna uppföljningen.
• Beräkna radantal, sidantal (48 rader/sida), ordantal och antal uppföljningar vid läsning i klienten. Visa varning under 25 ord för originalrapporter. Import/export hör till klienten.
• Sortera hjälpmedel på Namn, Nummer; agentlistan på regionförtur, agentbokstav och AgentNr; operationshistoriken på SlutDatum. AgentKompetens och FavoritHjalpmedel innehåller underlaget för detaljvisningen.
• Fånga nekade direkta SQL-anrop och anropa LoggaForbjudenAtgard. Detta återstår att ansluta i del 2.
• Exempelkontona motsvarar G1 och F2. Prova dem vid separata behörighetstester. PHP-applikationens anslutning behöver kontrolleras innan den kan beskrivas som rollbegränsad. Den tidigare separata AppUser-demonstrationen har tagits bort.

Vad som ändrats jämfört med database(2).sql

• Merge av Incident och Operation görs uttryckligen med testdata. Två kodifieringar och två vertikala uppdelningar uppfyller återstående antal.
• Extra operationskopior, regionspeglingar, överflödiga räknartabeller och dubblerade agentkontroller tas bort. Antal beräknas med vyer.
• Rapporternas rader, hemligstämpling och återställning kompletteras enligt uppgiftstexten. JSON används endast som återställningsunderlag.
• Rättigheter kompletteras för funktionerna i den valda delen. Direkta skrivningar behålls där befintliga triggers räcker.
• Kompetenser, specialkompetens och favorithjälpmedel ger det underlag som agent- och bokningsdelen kräver.
• Tidigare testfall kontrollerade bland annat constraints, bokning, femte starten, merge, rader och återställning. Testhjälparna ingår inte i den nuvarande installationsfilen.

Verifiering av denna version

Den tidigare SQL-versionen uppges ha körts med MySQL 8.0.44. Den nuvarande database.sql innehåller samma databasobjekt och exempeldata, men de automatiska testerna har tagits bort ur installationsfilen. Studenten har uppgett att den nya koden fungerar. Alla constraints, procedurer och behörigheter har dock inte verifierats oberoende här. Rollkontona behöver testas separat i kursmiljön.

Git och muntlig redovisning

Filerna behöver läggas i kursens fork tillsammans med det befintliga arbetet. Ingen fjärrfork eller commit har gjorts genom denna leverans. Befintlig verklig historik ska bevaras; skapa inte påhittade tidigare arbetssteg.

Kontrollera att den verkliga historiken uppfyller uppgiftens krav på commits för diagram, krav/requirements, relationer, datatyper, Insert och Datatyper, constraints, Insert och Constraint, respektive denormalisering, Insert och Denormalisering, respektive indexering, rättigheter samt procedur/trigger. Kontrollera ändringarna på git.webug.se. En enda slutlig SQL-fil ersätter inte dessa kursmoment.

Inför redovisningen: förklara urvalet, hur M:N och flervärda attribut överförts, varför merge/split/koder valts, varför radnummer skyddas samt hur behörighet och återställning fungerar. Läraren avgör slutligt godkännande; testresultat och dokumentation är underlaget.

Inlämnade filer

• database.sql skapar databasen, objekten, rättigheterna och exempeldata. Filen börjar med DROP DATABASE; kör den inte mot data som ska sparas.
• README.md beskriver design, G-tekniker och verifiering.
• Den separata testfilen ingår inte i inlämningen. Testerna behöver ändå kunna redovisas.
• Tabell-, vy- och procedurnamn som PHP använder har inte ändrats.