Db

Front 1

Problemen med databeroende

Back 1

-Ändring av datas definition kräver ändringar i många program – pris måste definieras som double även i andra program.

-Applikationer kan endast arbeta med sina egna filer – applikationen kan inte komma åt data i andra applikationer.

-Otydlig semantik; regler för hur data får skrivas, otydliga variebelnamn

Front 2

filbaserade synsättets 4 egenskaper.

Back 2

-Decentraliserad lagring av data,

-Data och dess lagringsstruktur definieras i programkoden,

-Organisatorisk decentralisering,

-Programspråk och utvecklingsmetod styr datastrukturen.

Front 3

4 problem decentraliserad lagring av data leder till

Back 3

Isolerad och separerad data:

-Svårt att komma åt önskade data

-Inkonsekventa definitioner av data

-Inflexibilitet

-Redundans

Front 4

3 problem, Data och dess lagringsstruktur definieras i applikationens programkod leder till

(Detta är samma som problemen av databeroende eftersom det är en av sakerna som kan leda till databeroende)

Back 4

-Ändring av datas definition kräver ändringar i många program

-Applikationen kan endast arbeta med sina egna filer

-Otydlig semantik

Front 5

kännetecken för systemutvecklingsprocess - traditionella filhanteringssystem

Back 5

-System- och programutveckling är processorienterad och fokuserar på arbetsuppgifter (processer) som utförs av systemet.

-Utvecklingen fokuseras inte på datas struktur och regler -> datadefinitioner görs i programkoden -> databeroende.

-Valet av utvecklingsmetod har betydelse för resultatet.

Front 6

5 deldefinitioner för databas

Back 6

-Gemensam samling av data (centraliserad lagring)

-Logiskt relaterade data

-Separat beskrivning av data

-Tillgodose informationsbehovet hos en organisation

-Lätt att komma åt data och ändra data

Front 7

Vilka nivåer i trenivåarkitekturen

Back 7

extern - användarnas lokala vyer

konceptuell - verksamhetens globala vy

intern - lagringsmediats vy

Front 8

Varför dela in i nivåer?

(trenivåarkitektur)

Back 8

Fysiskt dataoberoende

Logiskt dataoberoende

Front 9

Nackdel med trenivåarkitektur

Back 9

Det tar tid för DBMS att göra mappningar -> systemets prestanda försämras

Front 10

Systemutvecklingsprocess Databassynsättet

Back 10

-Utveckling av db och tillhörande applikationer utgår från datastrukturen.

-Först analyseras vilka objekt och företeelser som verksamheten vill lagra data om samt vilka samband som finns mellan dessa.

-I princip motsatsen till den processdrivna utvecklingen i filbaserade system.

Front 11

4 Fördelar med databassynsättet

-ange vilka egenskaper som ger upphov till dessa

Back 11

-Lättare att genomföra samma standarder i hela verksamheten <- centraliserad kontroll av data.

-Bättre kontroll över datas integritet <- DBMS kan utföra kontroller på data så att den är korrekt, samma data är tillgänglig för alla.

-Bättre tillgänglighet av data. <- Centraliserad data

-Förbättrad säkerhet <- DBMS sköter behörighet och kontroller på data.

Front 12

Huvudsakliga aktörer i db-miljön

Back 12

-Databasadministratör (DBA)

-Databasutvecklare

-Användare

Front 13

Vad innehåller datakatalogen

Back 13

-Information om data lagras (Metadata).

-Regler för data (ex. behörigheter).

Front 14

Vilka använder sig av datakatalogen

Back 14

DBMS,

DBA,

databasutvecklarna

Front 15

fördel med att ha en datakatalog

Back 15

Minskat databeroende (definitionen av datan lagras inte tillsammans med )

Front 16

Tre delar i en DBMS datamodell

Back 16

Strukturell del: hur data struktureras

Integritetsdel: en uppsättning regler som säkerställer att data alltid är korrekta

Manipulativ del: operationer som kan utföras på data

Front 17

3 typer av datamodeller som används vid utvecklingsarbetet av db:s design

Back 17

-Extern datamodell

* Representera varje användares vy i var sin datamodell.

-Konceptuell datamodell

* Den externa datamodellen integreras till en global datamodell.

-Intern datamodell

*Beskriver hur det lagras fysiskt

För att återspegla trenivåarkitekturen

Front 18

5 fördelar med dbsynsättet framför filbaserade system

Back 18

-minskat databeroende

-samlad data,

-bättre informationstillgång,

-minskad redundans.

-lättare att underhålla

Front 19

3 kostnader och krav vid införande db-system

Back 19

Om databasen utvecklas med defekter som blir förödande för verksamheten. Därför krävs det kompetenta DBA.,

konverteringskostnader för existerande system,

ökade kostnader förhårdvara och nätverk.

Front 20

Integritetsregler

Lista 5 stycken

Back 20

Domän

Null

Unikhet

Entitetsintegritet - om idnr PN får den inte vara null

Referensintegritet - främmande nycklar

Verksamhetsregler

Front 21

kriterierna för relationsmodellen

9 st

Back 21

-Unikt relationsnamn

-Atomära värden

-Sammansatt attribut

-Flervärt attribut

-Unika attributnamn

-Alla värden för ett visst attribut måste hämtas från sammadomän

-Attributens inbördes ordning får inte ha någon betydelse

-Varje tuple måste vara unik

-Innebörden av värdena i relationen måste vara oberoende avtuplernas inbördes ordning

Front 22

Anomali

Back 22

= när det finns redundans i en tabell uppstår oönskade effekternär data ändras i databasen. = Uppdateringsanomalier.

Modifieringsanomali

För att ändra t.ex. orderdatum måste ändringen göras på alla rader där datumet finns.

Tilläggsanomali

När en ny rad ska skapas i tabellen.

T.ex. om man lägger till en ny rad för en viss order måste man säkerställa så att orderdatum och kundnummer är desamma som de övriga raderna i tabellen.

Borttagningsanomali

När en rad ska tas bort från tabellen

Att ta bort värden ur primärnyckeln, men behålla övriga attribut på raden är ej tillåtet.

Front 23

3 kriterier, som ska uppfyllas, när en relation delas upp imindre relationer

Back 23

Bibehåll alla attribut

Samtliga attribut i ursprungstabellen ska finnas i tabellerna som den delats upp i.

Förlustfri delning av tabeller

När tabellerna sammanfogas via den främmande nyckeln ska resultatet bli ursprungstabellen. Inga rader får försvinna eller tillkomma.

Upprätthålla beroendena

Målet är att determinanten och dess beroende attribut ska vara i samma tabell.

Den regel som det funktionella beroendet representerar är då inbyggd i tabellens struktur och behöver inte upprätthållas med specialskriven programkod.

Front 24

Vilka steg i utvecklingen av ett databassystem

Back 24

-Databasplanering

-Systemdefinition

-Framtagning av kravspecifikation för databassystemet

-Konceptuell design

-Logisk design

-Fysisk design

-Design och implementation av applikationerna

Front 25

3 huvudsakliga strategier för att utföra en databasdesign

Back 25

Bottom-up

Alla detaljer analyseras från början.

Succesivt sätts de samman till större enheter.

Problem: från start måste en stor mängd detaljer hanteras -> utvecklingen går i baklås.

Top-down

Startar med en handfull stora objekt som succesivt bryts ner i mer detaljerade beskrivningar.

Systemet analyseras och utformas som en helhet.

Lämplig: systemet är så pass litet att det är lätt att hålla samman under utvecklingsarbetet eller om verksamheten är välstrukturerad med en ledning som har god överblick.

Blandstrategin

Vid stora system är det bra att dela upp systemet i mindre bitar som var för sig utvecklas enligt top-down-metoden.

I slutet av den konceptuella designen eller den logiska designen sammanfogas de lokala modellerna till en global modell.

Lämpligt: stort system som gör det svårt att hålla samman utvecklingsarbetet, verksamheten är decentraliserad.

Front 26

3 viktiga egenskaper i en ER-modell är kardinalitet, delaktighet/deltagande (participation) och relationsgrad

Back 26

Kardinalitet

Hur många relationer som varje entitet maximalt får lov att ha till en annan entitetstyp.

Delaktighet/deltagande

Hur många relationer som varje entitet minimalt får lov att ha till en annan entitetstyp.

Relationsgrad

Talar om hur många entitetstyper som deltar i en relation.

Front 27

Vad är:

relationsschema

databasschema

Back 27

Relationsschema

Utgörs av relationens namn följt av dess attribut inom parentes

Databasschema

Ett schema som utgörs av databasens samtliga relationsscheman.

Det konceptuella schemat i trenivåarkitekturen.

Front 28

Vad är DDL respektive DML för något

Back 28

DDL

-Data Definition Language.

-Hur saker ska lagras.

CREATE (tabeller, rader).

DML

-Data Manipulation Language.

-Ändra/Hämta/Ta bort/Lägga till.

Queries refererar oftast till SELECT.

Ex. INSERT.

Front 29

samspelet mellan de två verksamhetsfunktionerna dataadministration och databasadministration

Back 29

Dataadministration

-På ledningsnivå i organisationen.

-Databasplanering.

-Utveckling och underhåll av standarder.

Databasadministration

-De tekniska, fysiska och praktiska aspekterna och arbetsuppgifterna rörande databasen.

-Den fysiska databasdesignen.

-Övervaka säkerhet, prestanda och dataintegritet.

-Delta vid utveckling av databasen.

-Definiera databasens scheman

Front 30

4 villkor en transaktion måste uppfylla

Back 30

(ACID)

Atomär

-Alla transaktionens operationer utförs eller ingen av dem (de kan inte delas upp).

Consistent

-Databasen var konsistent vid starten av T och ska vara det efter T avslutas.

Isolated

-Ändringar som görs av transaktionen ska inte bli synliga förrns transaktionen är avslutad.

-När transaktioner exekveras samtidigt ska respektive transaktion effekter vara desamma som om de exekverades ensamma (= T isoleras från varandra).

Durability (varaktighet)

-När transaktionen fullbordats ska dess ändringar av databasens innehåll vara permanenta.

Front 31

Vad menas med before image respektive afterimage?

Back 31

Before image

-Innan en transaktion utförs tas kopior över utgångsläget, dessa kan sedan användas i en rollback och återställa databasen till utgångsläget.

After image

-En journal över utförda transaktioner.

-Användbar för att uppdatera DBMS vid databasproblem.

Front 32

Rollback och roll forward

Back 32

Rollback

-Om en transaktion inte kan slutföras används rollback för att gå tillbaka till utgångsläget, med omanipulerad data.

-Man avbryter transaktionen.

Roll forward

-En journal över genomförda transaktioner som kan användas vid databasproblem för att ”bring it up to date”.

Front 33

Vad menas med commit?

Back 33

Commit

-När en transaktion anses vara färdig används commit för att alla ändringar ska sparas och att databasen är konsistent.

Front 34

Cascading rollback

Back 34

Cascading rollback = En transaktion tvingas göra rollback pga att en annan transaktion har gjort rollback.

Front 35

Vilka är de två vanliga sätten att eliminera den negativa effekten av cascading rollback?

Back 35

Rigorous

-Varje transaktion håller alla sina lås tills den är färdig.

Strict

-Varje transaktion håller endast X-låsen.

Front 36

Vadmenas med att en transaktion är serializeable?

Back 36

Serializeable = Transaktioner är helt isolerade från varandra. Uppfylls med tvåfaslåsning. (En transaktion i taget).

Front 37

Vad är deadlock och hur kan det åtgärdas?

Back 37

Deadlock = två eller flera transaktioner står still ochväntar på varandra.

Wait-for-graph: gör rollback på en av transaktionerna och låt den andra transaktionen fortsätta.

Time-out: när en transaktion har stått och väntat på ett lås tillräckligt länge antas den ha råkat ut för deadlock och avbryts.

Front 38

Vilka åtgärder bör DBMS ha utfört för att det ska vara möjligt att återställa databasen (recovery) efter att en krasch har inträffat?

Back 38

-Loggfil (journal)

-Checkpoint

-Backup

-Omedelbar och fördröjd uppdatering

Front 39

Varför är det viktigt att tillämpa write-ahead log protocol?

Back 39

För att kunna titta i loggfilen efter en krasch för att se vad som behöver ändras. Skriver till loggfilen innan transaktionen utförs(-before image).

Front 40

Hur utförs Roll forward av DBMS? För vilka transaktioner utförs detta?

Back 40

Roll forward: Användning av after image på en commit för att göra om allting och säkerställa consistency. Gör om alla ändringarna (transaktionen) igen.

Front 41

Hur utförs Rollback av DBMS? För vilka transaktioner utförs detta?

Back 41

Roll-back: användningar av logg för att hitta before image, utförs mha before image; rullar tillbaka databasen till ett tidigare stadie. Utförs för transaktioner som inte ännu är sparade i databasen.

Front 42

Teknikerna/metoderna för concurrency control delas in i kategorierna pessimistiska (eller konservativa) och optimistiska.

Back 42

OCC känneteckas av att man antar att transaktionerna oftast inte kommer vilja utföra saker samtidigt på samma objekt. Använder därför inte lås och

Först påbörjar man transaktionen, modify, validate (ser om det blev som man ville?), commit

PCC låser alla transaktioner tills det finns noll risk för regelbrott (mot ACID). Passar bäst inom bankindustrin.

Front 43

Kravspecifikationens 7 kategorier av regler

Back 43

1. Attribut som kan fungera som identifikator

2. Obligatoriskt eller frivilligt värde?

3. Unikt eller duplikat?

4. Domänen

5. Dynamiska regler för värden

vad som ska göras när ett värde ändras

6. Återanvändning

7. Ordningsföljder

Front 44

Vilka är de olika typerna av verksamhetstransaktioner?

Back 44

MUL

-Manuella transaktioner – använder inte datasystemet, är därför ointressanta för analysen av datastrukturen, men är det som brukar binda ihop de transaktioner som gör det.

-Uppdateringstransaktioner – ändrar lagrade data. Analysen av dem ger informationen om hur datas struktur ser ut. (kallas även skrivtransaktion)

-Lästransaktioner – Gör inga ändringar av lagrad data, utgörs av sammanställningar, presentationer och rapporter. (kallas även beslutsstödstransaktion)

-Blandade transaktioner – En blandning av ovanstående. Omfattar ett helt ärende.