DAV B04 - Databasteknik

1
DAV B04 - Databasteknik

• Föreläsningsmaterial

2
DAV B04 - Databasteknik

• Introduktion
• (kap 1, 2)

3
Databaser och databashanteringssystem

• En databas (DB) är en samling av relaterad data
• representerar någon aspekt av verkligheten
  minivärlden eller University of Discourse (UoD)
• Databashanteringssystem (DBHS)
• programvarusystem som används för att skapa och
  underhålla databaser
• Ett filhanteringssystem som kan hantera komplexa
  relationer mellan data och hämta och uppdatera
  data enkelt och effektivt

4
Databas-system

• Ett databas-system (DBS) består av DBHS-mjukvaran
  tillsammans med själva databasen (applikationer,
  användare)

5
Egenskaper hos databas-system

• Data är integrerad och delad
• I DBHS lagras en beskrivning av databasen
• struktur, integritetsregler mm
• Visst mått av dataoberoende

6
Datamodell

• Används för att
• gömma implementationsdetaljer
• ge användarna en konceptuell vy av databasen
• Stödjer många olika vyer av databasen

7
(Andra) fördelar med databas-system

• Redundansen kan minskas
• Säkerheten kan förbättras
• Flera olika användargränssnitt
• Integriteten kan upprätthållas
• Stöd för återhämtning av data
• Tiden för applikationsutveckling kan minskas

8
Nackdelar med databas-system

• Ofta höga kostnader för hårdvara, mjukvara och
  utbildning
• Komplexiteten hos ett DBHS kan ibland vara onödig
  eller ge för låg prestanda

9
Användare av databas-system

• Databasadministratörer (DBA)
• Applikationsprogrammerare
• Slutanvändare

10
Olika typer av databas-system

• 1965-1980
• främst hierarkiska databaser och
  nätverksdatabaser
• Från ca 1980
• de flesta nya databas-system varit
  relationsdatabaser
• Från ca 1990
• objektorienterade och objektrelationella databaser

11
Datamodeller

• En samling koncept för att beskriva databasens
  struktur
• De integritetsregler den måste följa
• Oftast också de operationer som går att göra på
  databasen

12
Högnivå-modeller

• Använder koncept som ligger nära hur användare
  förstår data.
• Används ofta vid databasdesign.
• Exempel E/R-modellen

13
Logiska modeller

• Använder koncept som kan förstås av användare
• Ligger inte alltför långt ifrån hur data
  organiseras i databasen

14
Lågnivå-modeller

• Använder koncept som beskriver i detalj hur data
  är lagrad rent fysiskt

15
Databasens schema

• Beskrivningen av databasen
• Kan visas i ett schemadiagram

16
Exempel på schemadiagram
17
Databasens gränssnitt

• Varje användare kommunicerar med databasen m h a
  ett språk
• Programmerare konventionellt programspråk (C
  eller Pascal)
• Slutanvändare något frågespråk (SQL), eller
  kommunicerar med databasen genom något
  specialdesignat menysystem

18
Språk

• Varje språk inkluderar
• ett underspråk (data sublanguage eller DSL)
• som sägs vara inbäddat i värdspråket (host
  language)

19
Dataoberoende

• Logiskt dataoberoende
• Det går att göra ändringar i det konceptuella
  schemat utan att det påverkar de externa schemana
  eller applikationsprogrammen
• Fysiskt dataoberoende
• Det går att göra ändringar i det interna schemat
  utan att det påverkar det konceptuella schemat

20
Beståndsdelar DSL

• Data Definition Language (DDL)
• den del av språket som används för att definiera
  de olika objekten som databasen består av
• Data Manipulation Language (DML)
• den del av språket som används för att manipulera
  eller utföra operationer på sådana objekt

21
Applikationer skrivna av användaren

• Skrivna i något programspråk (t ex C) med
  inbäddad SQL eller applikationer skrivna i SQL

22
Applikationer skrivna av någon leverantör (tools)

• Kompilatorer för något frågespråk,
  rapportgeneratorer, grafiska användargränssnitt,
  kalkylprogram, statistikprogram,
  4GL-kompilatorer, CASE-verktyg

23
Program som används för att administrera databasen

• Laddningsprogram, backup-program,
  reorganisationsprogram, statistik- och
  analysprogram

24
Katalogen (Data Dictionary)

• Ett DBHS måste innehålla en katalog eller ett
  data dictionary, där detaljerad information om
  systemets olika delar lagras
• information om tabeller, index, användare,
  integritets- och säkerhetsregler
• lagras också som tabeller, så att det går att
  ställa frågor till katalogen på samma sätt som
  till databasen

25
Översikt av kursen

• Genomgång av relationsmodellen
• Genomgång av SQL praktiska övningar
• Konceptuell databasdesign
• Fysisk databasdesign
• Transaktionshantering
• Databassäkerhet
• Web-databaser och distribuerade databaser
• Laborationer teori, design, implementation och
  användargränssnitt

26
DAV B04 - Databasteknik

• Relationsmodellen
• (kap 7)

27
Relationsmodellen

• En formell teori som baserar sig på (främst)
• mängdlära
• predikatlogik
• Föreslogs av E.F Codd 1970 i artikeln A
  relational model for large shared data banks i
  Communications of the ACM, juni 1970

28
Relationsmodellen

• Relation är den matematiska termen för tabell
• En databas ses som en mängd relationer
• DB R1, R2,Rn

29
Relationsmodellen

• Beskriver ett sätt att se på data från en logisk
  synvinkel
• Tre aspekter av data
• datastrukturer (eller objekt)
• huvudsakligen tabeller
• datamanipulation (eller operationer)
• operationer är bl. a SELECT, PROJECT och JOIN
• dataintegritet
• de viktigaste reglerna är de om
  entitetsintegritet och referensintegritet

30
Domäner

• En domän är en namngiven mängd av skalära värden,
  alla av samma typ
• Varje attributs värden måste tas från exakt en
  underliggande domän
• En domän är vad man i moderna programspråk kallar
  en datatyp
• De flesta av dagens relationsdatabaser stödjer
  dock bara primitiva datatyper som CHARACTER,
  INTEGER och FLOAT

31
Exempel på domäner

• typedef enumLondon, Paris, Athens, New York,
  Stockholm, Rome City
• Detta skapar en datatyp City i ett C-program.
  Alla variabler av typen City måste ha som värde
  en av de uppräknade städerna

32
Exempel på domäner

• CREATE DOMAIN City Char(9) DEFAULT ???
• CHECK (VALUE IN (London, Paris, Athens,
  New York, Stockholm, Rome, ??? ) )

33
Relationer

• En relations schema består av en mängd attribut
• R A1, A2, An
• Varje attribut är definierat på exakt en
  underliggande domän
• Attributnamnen i en relation måste vara unika
• Flera attribut kan dock vara definierade på samma
  domän

34
Relationer

• En relations tillstånd eller värde vid en viss
  tidpunkt benämns r och består av en mängd tupler
  t (0 eller flera)
• r t1,t2,tn
• Varje tuple t består av en mängd värden v där
  varje värde är hämtat från motsvarande domän
• t v1,v2,vn

35
Relationer

• Antalet tupler i en relation kallas relationens
  kardinalitet
• Antalet attribut i en relation kallas relationens
  grad
• En eller flera attribut som unikt identifierar en
  tuple kallas för relationens primärnyckel

36
Egenskaper hos en relation

• Det finns inga duplicerade tupler
• Tuplerna är oordnade
• det finns ingen första eller sista tuple
• Attributen är oordnaded
• det finns inget första eller sista attribut
• Alla värden är atomära (skalära)
• (detta betyder att en relation alltid är i första
  normalformen)

37
Olika sorters relationer

• En namngiven relation är en relation som har
  definierats i databasen
• En basrelation är en relation som inte är en
  härledd relation, utan existerar på riktigt
• En härledd relation är en relation som är
  definierad i termer av andra relationer

38
Olika sorters relationer

• En vy är en namngiven härledd relation som är
  virtuell den existerar bara som ett uttryck
• Ett frågeresultat är en icke namngiven härledd
  relation som är resultatet av att en specifik
  fråga exekveras

39
Vyer (virtuella relationer)

• En vy är en härledd relation som är namngiven
• relationen finns bara som ett uttryck och brukar
  därför kallas en virtuell relation
• Vyer har flera användningsområden, men det
  viktigaste är att de kan användas för att skapa
  logiskt dataoberoende

40
Logiskt dataoberoende

• Ett system har logiskt dataoberoende om användare
  och applikationer inte påverkas av ändringar i
  databasens logiska struktur
• Logiskt dataoberoende kan bara uppnås om systemet
  stödjer operationer på vyer på ett korrekt sätt!

41
Logiskt dataoberoende

• Två aspekter
• Om databasen växer, d v s om t ex ett attribut
  läggs till en relation eller en relation läggs
  till databasen, kan dessa ändringar gömmas med
  hjälp av vyer
• Om databasen omstruktureras, t ex om en relation
  bryts ner i två stycken, kan vyer användas för
  skapa illusionen om att det fortfarande är en
  enda relation

42
Andra fördelar med vyer

• Vyer tillåter att samma data kan ses av olika
  användare på olika sätt samtidigt
• Vyer kan användas som "macron
• Vyer kan användas för att gömma data (av
  säkerhetsskäl)

43
Integritet

• Integritet handlar om att se till att data i
  databasen är korrekt
• Vid varje tillfälle innehåller en databas en
  mängd datavärden som skall representera en viss
  del av "verkligheten
• Vissa värden kan inte tillåtas eftersom de inte
  representerar något som finns i verkligheten (t
  ex negativa löner)
• När databasen definieras måste därför också vissa
  integritetsregler läggas till. Dessa gör det
  möjligt för DBHS att hindra att inkorrekta värden
  läggs in i databasen

44
Exempel på integritetsregler

• Integritetsregler i COMPANY-databasen
• SALARY i relationen EMPLOYEE måste vara större än
  noll
• SEX i relationen EMPLOYEE måste ha värdet M eller
  F
• SSN i relationen EMPLOYEE måste bestå av nio
  siffror

45
Integritetsregler

• Reglerna i exemplet är databas-specifika (eller
  semantiska), dvs. de gäller bara för en specifik
  databas
• Relationsmodellen innehåller också två generella
  integritetsregler, dvs. regler som gäller för
  alla databaser
• kandidatnycklar (och primärnycklar)
• främmandenycklar

46
Definition av en kandidatnyckel

• Låt R vara en relation. Då är en kandidatnyckel
  för R en delmängd av Rs mängd av attribut, säg K,
  så att
• vid varje givet tillfälle, så har två olika
  tupler i R inte samma värde på K (K är unik)
• om K är sammansatt, så kan ingen del av K tas
  bort och K fortfarande vara unik (K är ej
  reducerbar)

47
Enkla och sammansatta kandidatnycklar

• En kandidatnyckel som består av mer en ett
  attribut sägs vara sammansatt
• En kandidatnyckel som består av exakt ett
  attribut sägs vara enkel

48
Kandidatnycklar

• Kandidatnycklar definieras som mängder av
  attribut
• Skälet till att kandidatnycklar är så viktiga är
  att det enda sättet att adressera en speciell
  tuple är genom att använda ett värde på en
  kandidatnyckel

49
Exempel kandidatnycklar

• Ex i COMPANY

Employee K SSN Project K
PNUMBER Works_on K ESSN,PNO
50
Primärnycklar och alternativa nycklar

• Primärnyckel
• en nyckel som väljs från mängden kandidatnycklar
• Alternativ nyckel
• den återstående mängden kandidatnycklar när
  primärnyckeln har tagits bort

51
Sekundärnyckel

• En sekundärnyckel är en nyckel som när den
  används för sökning kan returnera en relation med
  fler än en tuple
• Ex.
• SELECT SSN from EMPLOYEE
• WHERE DNO 5
• DNO är här en sekundärnyckel

52
Nycklar och saknad information (nulls)

• Nulls är något som används i databaser för att
  handskas med saknad information
• För varje attribut i en relation kan man
  specificera NULLS ALLOWED eller NULLS NOT ALLOWED

53
Tolkningar av NULL

• Vissa logiska svårigheter
• värde okänt
• egenskapen ej relevant
• värde finns inte
• värde odefinierat

54
Regeln om entitetsintegritet

• Ingen del av primärnyckeln i en basrelation får
  vara null

I en relationsdatabas lagrar vi inte information
om någonting vi inte kan identifiera!
55
Definition av främmandenyckel (FK)

• Låt R2 vara en basrelation. Då är en
  främmandenyckel i R2 en delmängd av mängden
  attribut i R2, säg FK, så att
• det finns en basrelation R1 (R1 och R2 behöver ej
  vara olika) med en kandidatnyckel CK, och
• för varje tillfälle, så är varje värde på FK i
  relationen R2 antingen helt och hållet null eller
  identiskt med värdet på CK i någon tuple i R1

56
Främmandenycklar

• Varje attribut i en främmandenyckel måste
  definieras på samma domän som det motsvarande
  attributet i den matchande kandidatnyckeln

57
Främmandenycklar

• Främmande-till-kandidatnyckel referenser sägs
  ibland vara det "lim" som håller ihop databasen.
  Dessa sägs representera relationer mellan olika
  tupler

58
Regeln om referensintegritet

• Databasen får inte innehålla några icke matchande
  värden på främmandenycklar
• dvs. om B refererar till A, så måste A existera

59
Regler för främmandenycklar

• Vad ska då systemet göra om en operation försöker
  utföras som skulle bryta mot regeln om
  referensintegritet ?
• För varje främmandenyckel i databasen skall
  databasdesignern specificera vad som skall hända
  vid delete eller update av den matchande
  kandidatnyckeln

60
Exempel på regler för främmandenycklar

• Vad skall t ex hända om någon försöker ta bort
  eller uppdatera 123456789 i relationen
  EMPLOYEE?
• Två möjligheter (åtminstone) finns för båda
  operationerna
• RESTRICTED - operationerna är förbjudna om
  123456789 också finns i WORKS_ON
• CASCADES - operationerna utförs också på de
  tupler som innehåller 123456789 i SHIPMENT

61
Semantiska integritetsregler

• Även kallade business rules
• Gäller för en specifik databas

62
Exempel på semantiska integritetsregler

• Regler av typen Ingen kan ha en lön som är
  mindre än 10000 kan specificeras med domänregler
• Regler av typen Varje anställd måste tillhöra en
  avdelning specificeras genom att ange NOT NULL
  för attributet DNO i EMPLOYEE
• Regler av typen Ingen anställd får ha högre lön
  än sin chef kan specificeras genom triggers
  eller assertions

63
DAV B04 - Databasteknik

• Relationsalgebra
• (kap 7)

64
Relationsalgebra

• Operationer som görs på relationer för att hämta
  data från en databas
• Utdata från alla operationer är en ny relation
  (algebran är sluten). Detta gör det möjligt att
  skriva nästlade operationer

65
Operationer

• De speciella relationsoperationerna
• select, project, join och division
• De traditionella mängdoperationerna
• union, intersection, difference och cartesian
  product

66
SELECT ?

• SELECT returnerar en relation som består av alla
  tupler från en relation som uppfyller ett visst
  villkor
• SELECT-operationen benämns
• ?ltselection conditiongt (R)

67
?ltselection conditiongt (R)

• Den resulterande relationen har samma attribut
  som R
• Villkoret är av formen X ltjämförelseoperatorgt Y,
  där X är ett attributnamn och Y är ett
  attributnamn eller en konstant. Flera villkor kan
  sättas samman med hjälp av AND, OR och NOT
• SELECT är unär, dvs indata är en relation

68
PROJECT ?

• PROJECT returnerar en relation som består av alla
  tupler i en relation sedan vissa attribut har
  utelämnats
• PROJECT-operationen benämns
• ?ltattribute listgt (R)

69
?ltattribute listgt (R)

• Den resulterande relationen har bara de attribut
  som specificeras i attributlistan
• Duplicerade tupler tas bort av PROJECT
• PROJECT är unär, dvs. indata är en relation

70
Sekvenser av operationer

• Flera operationer kan kombineras för att bilda
  ett algebraiskt uttryck (en fråga)
• Exempel Hämta namn och löner för anställda som
  arbetar på avdelning 4
• P FNAME,LNAME,SALARY (s DNO4(EMPLOYEE) )

71
RENAME

• Alternativt så kan man specificera temporära
  relationer för varje steg
• DEPT4_EMPS ?s DNO4(EMPLOYEE)
• R ? P FNAME,LNAME,SALARY(DEPT4_EMPS)

72
RENAME

• Attribut i den resulterande relationen kan ges
  andra namn om man så vill
• DEPT4_EMPS ? s DNO4(EMPLOYEE)
• R(FIRSTNAME,LASTNAME,SALARY) ?
• P FNAME,LNAME,SALARY(DEPT4_EMPS)

73
Traditionella mängdoperationer

• Dessa binära operationer fungerar som motsvarande
  operationer i matematiken
• En viktig skillnad
• operanderna måste vara typkompatibla, dvs. bestå
  av samma slags tupler (gäller ej produkt)

74
UNION R1 ? R2

• Unionen av två typkompatibla relationer R1 och R2
  är
• en relation med samma huvud som både R1 och R2
• med en kropp som består av mängden av alla tupler
  t som finns i R1 eller i R2 eller i båda

75
INTERSECTION R1 ? R2

• Snittet av två typkompatibla relationer R1 och R2
  är
• en relation med samma huvud som både R1 och R2
• med en kropp som består av mängden av alla tupler
  t som finns i både R1 och R2

76
DIFFERENCE R1 R2

• Differensen mellan två typkompatibla relationer
  R1 och R2, i den ordningen, är
• en relation med samma huvud som både R1 och R2
• och med en kropp som består av mängden av alla
  tupler t som finns i R1 men inte i R2

77
CARTESIAN PRODUCT R1 X R2

• Den kartesiska produkten av två relationer R1 och
  R2 ger en relation med alla möjliga kombinationer
  av tupler från R1 och R2
• är meningslös i sig själv

78
THETA JOIN

• Är det samma som en kartesisk produkt följt av en
  SELECT-operation
• THETA JOIN benämns
• R1ltjoin conditiongtR2
• Oftast jämförs ett attribut i R1 med ett i R2 i
  villkoret

79
EQUIJOIN

• Kallas operationen om villkoret är

80
NATURAL JOIN

• är det samma som EQUIJOIN, men där
  join-attributet i R2 är borttaget i
  resultatrelationen
• NATURAL JOIN benämns
• R1 R2
• R1 ltjoin attribute1gt, ltjoin attribute2gt R2

81
DIVISION

• tar två relationer, en binär och en unär, och
  returnerar en relation som består av alla värden
  som ett av den binära relationens attribut har
  och där det andra attributet matchar alla värden
  i den unära relationen
• DIVISION benämns
• R1 ? R2

82
DAV B04 - Databasteknik

• SQL
• (kap 8)

83
SQL - frågespråk för relationsdatabaser

• 4GL, mycket kraftfullt jämfört med t ex C/C och
  FORTRAN
• SEQUEL
• SQL (Structured Query Language)
• SQL-86 SQL1 (ANSI-standard)
• SQL-92 SQL2
• SQL3
• kommer bl.a. att vara objektorienterat

84
SQL i kursen

• Olika dialekter, vi använder
• Microsoft Jet SQL (separat kompendium)
• MySQL

85
Beståndsdelar SQL

• Data Definition Language (DDL)
• med hjälp av kommandon i DDL skapar man och kan
  modifiera scheman, tabeller, villkor och vyer
• Manipulation Language (DML)
• kommandona i DML möjliggör läsning, skrivning,
  insättning, radering och förändring av
  tabellinnehåll

86
SQL uttryck

• Tabell relation
• Rad tuple
• Kolumn attribut

87
DDL-operationer

• CREATE
• Skapa tabell, schema, vy, domän
• DROP
• Radera tabell eller
• ALTER
• Lägg till eller ta bort i tabell

88
DML-operationer

• SELECT
• Välj ut data ur tabell(er)
• INSERT
• Skriv in rad(er)
• DELETE
• Radera rad(er)
• UPDATE
• Modifiera kolumner i rad(er)

89
DAV B04 - Databasteknik

• ER-diagram
• (kap 3)

90
Datamodellering
91
ER (Entity Relationship) - diagram

• Konceptuell datamodellering
• ER modellen beskriver data utifrån
• entiteter
• attribut
• relationer

92
Entiteter

• Sak i verkliga världen
• existerar fysiskt, ex bil, student
• existerar konceptuellt, ex univ.kurs, jobb

93
Entiteter och attribut

• Varje entitet har attribut, dvs. egenskaper som
  beskriver entiteten
• Student namn, ålder, adress...

94
Attributens värde

• En existerande entitet har värden på sina
  attribut
• student s1 Kalle, 47, Karlstad
• Denna typ av data utgör majoriteten av
  information sparad i en databas!

95
Sammansatta attribut

• Kan delas ned i mindre delar som har oberoende
  betydelse

96
Mångvärdes attribut

• Vanligtvis har ett attribut bara ett värde,
  men...
• Vad händer om ex. en bil har tre olika färger?

97
Härledda attribut

• Exempelvis kan man härleda en persons ålder från
  personnummer och nuvarande år

98
Entitetstyper

• Definierar en mängd av entiteter som har samma
  attribut (varje entitet i mängden har dock egna
  värden på attributen)
• En entitetstyp beskrivs därmed med hjälp av
  entitetens namn och dess attribut
• STUDENT Namn, ålder, adress

99
Entitetsmängder

• Samlingen/mängden av alla entiteter av en viss
  entitetstyp i databasen vid någon given tid

100
Nyckelattribut

• Varje entitetstyp skall ha ett attribut vars
  värde skall vara unikt för varje enskild entitet
  i entitetsmängden
• Student Personnummer, namn, ålder

101
Relationer mellan entiteter

• Som i samband mellan entiteter

102
Relationer och attribut

• En relation kan också ha attribut
• Exempelvis en student på en kurs har ett betyg...

103
Kardinalitet på relationer11 förhållande
104
Kardinalitet på relationer1N förhållande
105
Kardinalitet på relationerNM förhållande
106
DAV B04 - Databasteknik

• Mappning mellan ER-diagram och relationsmodellen
• (kap 9)

107
Mappning ER-diagram / relationsmodellen

• Används för att skapa den logiska databasdesignen
  som baseras på den konceptuella designen

108
Algoritm

• Finns en algoritm för att stegvis utföra
  mappningen
• denna finns mer detaljerat beskriven i kapitel 9.1

109
Starka entiteter

• Steg 1
• varje stark entitetet blir en basrelation där
  primärnyckeln i relationen motsvarar
  nyckelattributet(en) i entiteten

110
Svaga entiteter

• Steg 2
• bildar sin primärnyckel genom att ta
• primärnyckeln från ägande relationen (som
  främmandenyckel) och egen partiell nyckel
  tillsammans
• Reglerna för främmandenycklar i en relation
  mellan en svag och en stark entitet måste vara
• DELETE CASCADES
• UPDATE CASCADES
• Visar på beroendeförhållandet mellan entiteterna

111
11 förhållanden

• Steg 3
• välj en av entiterna och lägg in primärnyckeln i
  den ena som främmandenyckel i den andra
• eventuella attribut till relationen mellan dessa
  bör hamna på samma sida

112
1N förhållanden

• Steg 4
• introducera primärnyckeln från en relationen
  som främmandenyckel i relationen på många sidan
• eventuella attribut till relationen (sambandet)
  mellan dessa två entiteter migreras till många
  sidan

113
NM förhållanden

• Steg 5
• varje många-till-många relation (samband) blir en
  basrelation
• varje sådan basrelation måste innehålla minst en
  främmandenyckel från varje deltagare i relationen
• primärnyckeln kan skapas genom kombinationen av
  främmandenycklarna eller genom att introducera
  ett nytt attribut

114
Attribut

• Steg 6
• Varje egenskap i för en entitet blir ett attribut
  i den relation den tillhör.
• Undantaget är om attributet för entiteten är ett
  mångvärdes attribut, i så fall skapas en ny
  relation

115
Värdedomäner

• Skapas för alla attributens värdemängder

116
DAV B04 - Databasteknik

• Praktisk databasdesign
• (kap 16)

117
Sammanhang

• Informationssystem (IS)
• Livscykel Makro
• Databassystem (DBS)
• Livscykel Mikro

118
Informationssystems livscykel(Makro livscykel)

1. Analys av möjliga krav (Feasibility analysis)
2. Kravanalys och insamling av krav
3. Design
4. Implementation
5. Testing/kontroll och acceptanstest
6. Utplacering, drift och underhåll

119
Databassystems livscykel(Mikro livscykel)

1. Definition av systemet
2. Databasdesign
3. Databas implementation
4. Inladdning av data eller konvertering
5. Konvertering av applikationer
6. Testing och kontroll
7. Drift
8. Övervakning och underhåll

120
Steg 2 databasdesign

• Mål
• klara av användarnas och applikationernas krav på
  informationsinnehåll
• naturlig och lättförstådd struktur på
  informationen
• klara av ställda krav på prestanda, ex svarstid
• Består av sex olika faser...

121
Faser i databasdesignen
122
Faser i databasdesignen

• Insamling och analys av krav
• Konceptuell databasdesign
• Exempel ER-modellen
• Val av DBHS
• Mappning av datamodeller (logisk databasdesign)
• exempel, mappning från ER modellen till
  relationsmodellen
• Fysisk databasdesign
• lagringsstrukturer, index
• Implementering av databassystemet
• impl. av databas och applikationer, trimning
  (tuning)

123
Fas 1 Insamling och analys av krav

• Identifikation av applikationsområden och
  användargrupper
• Studier av existerande dokumentation
• Studier av nuvarande operativsystem och planerad
  användning av informationen
• Skriftliga svar på frågor från databasens
  potentiella användare

124
Fas 2 Konceptuell databasdesign

• 2 parallella aktiviteter
• datamodellering
• transaktionsdesign
• Datamodellering
• centraliserad vs. vy integration
• Transaktionsdesign
• Specar funktionella krav på applikationerna
• Hämtnings-/uppdaterings/blandade transaktioner

125
Fas 3 Val av DBHS

• Exempel på faktorer som spelar in
• relationsdatabas, objektdatabas?
• utvecklingsverktyg?
• vad kostar det att
• införskaffa all mjukvara?
• underhålla mjukvaran?
• införskaffa eventuell ny hårdvara?
• skapa databasen alt. konvertera från gammal?
• skaffa eventuell ny personal?
• träna personalen så att de kan använda DBHS?
• ha databassystemet i drift?

126
Fas 4 Mappning mellan datamodeller

• Kan ske i två steg
• system-o-beroende mappning
• ER-modell -gt relationsmodellen
• systemberoende mappning
• DBHS har olika kännetecken och restriktioner som
  man behöver anpassa sig till
• Resultatet blir DDL uttryck i det språk som
  utvald DBHS hanterar

127
Fas 5 Fysisk databasdesign

• Utifrån vad DBHS kan erbjuda väljs lämpliga
• lagringsstrukturer, åtkomstvägar, organisation av
  filer, indexering
• Kriterier som påverkar
• svarstid
• utrymme
• transaktionsgenomströmming (medelvärde
  transaktioner/minut)

128
Fas 6 implementation och trimning

• DDL och SDL uttrycken kompileras och används för
  att skapa databasens scheman och (tomma)
  databasfiler. Eventuellt sker laddning/konverterin
  g av data
• görs av DBA databasdesigner
• Transaktioner implementeras genom att utgå från
  de konceptuella beskrivningarna av
  transaktionerna
• görs av applikationsprogrammerare

129
Fysisk databasdesign i relationsdatabaser

• Brukar börja med att man tar fram de viktigaste
  faktorerna och den information man har om dem och
  analyserar dessa...
• Frågor, transaktioner, applikationer

130
Fysisk databasdesign i relationsdatabaser

• Analys av
• frågor och transaktioner
• frekvens på anrop av frågor och transaktioner
• tidskrav på frågor och transaktioner
• frekvens på uppdateringsoperationer
• indexering (accessvägar)

131
Databastrimning i relationsdatabaser

• Görs för att applikationer ska köra snabbare, få
  ned svarstider, förbättra genomströmning av
  transaktioner
• Fixas genom att trimma
• index
• databasdesignen
• frågor

132
DAV B04 - Databasteknik

• Normalisering och funktionella beroenden
• (kap 14)

133
Riktlinjer när man vill skapa en databas

1. Designa så att det är lätt att förstå innebörden.
   Kombinera inte attribut från olika entitetstyper
   i samma tabell
2. Designa så att inte problem uppstår vid
   insättning, borttagning eller modifiering
3. Undvik värden i basrelationer som ofta blir NULL.
   Skapa istället en ny relation

134
Normalisering

• Uppdelning i flera relationer
• Innebär att redundansen i databasen är minskad
  (eliminerad?)
• Ingen information försvinner vid normaliseringen
• Inga falska samband skapas om man gör NATURAL
  JOIN på tabellerna

135
Funktionellt beroende (FD)

• Functional Dependency
• Är en många-till-en relation från en mängd
  attribut till en annan i en given relation

136
Definition av FD

• Givet en relation R, så är attributet Y i R
  funktionellt beroende av attributet X i R omm
  varje X-värde i R är associerat med precis ett
  Y-värde i R (vid varje tillfälle). Attributen X
  och Y kan vara sammansatta
• R.X ? R.Y

137
Exempel på funktionellt beroende

• Relationen EMP_PROJ (i Fig. 14.3b, sida 470) har
  följande FD

SSN ? ENAME PNUMBER ? PNAME, PLOCATION SSN,
PNUMBER ? HOURS
138
Exempel på funktionellt beroende

• Andra raden skulle också kunna delas upp i
• Även den triviala relationen finns

PNUMBER ? PNAME PNUMBER ? PLOCATION
PNUMBER -gt PNUMBER osv.
139
Determinant

• Vänstra sidan av FD
• Determinanten kan vara primärnyckel och därmed
  också kandidatnyckel men måste inte vara det
  (BCNF 3NF)

140
Dependent

• Den högra sidan av ett FD
• Alla attribut i en relation är funktionellt
  beroende av primärnyckeln

141
Definition av fullständigt funktionellt beroende

• Attributet Y i relationen R är fullständigt
  funktionellt beroende av attributet X i R om det
  är funktionellt beroende av X och det inte finns
  någon äkta delmängd Z av X sådan att Y är
  funktionellt beroende av Z

142
Exempel på fullständigt funktionellt beroende

• Relationen EMP_PROJ (i fig. 14.3b, sida 470)
• Här är SSN, PNUMBER primärnyckel (PK), vilket
  gör att alla attribut kan bestämmas när man vet
  PKs värde. Attributen ENAME, PNAME och PLOCATION
  är alltså funktionellt beroende av PK men inte
  fullständigt funktionellt beroende eftersom
  följande gäller

SSN ? ENAME PNUMBER ? PNAME PNUMBER ? PLOCATION
143
1a normalformen (1NF)

• En relation är i första normalformen (1NF) omm de
  underliggande enkla domänerna innehåller endast
  skalära värden
• figur 14.8 och 14.9

144
2a normalformen (2NF)

• En relation är i andra normalformen (2NF) omm
  relationen är i 1NF och varje attribut som inte
  ingår i primärnyckeln är fullständigt
  funktionellt beroende av den
• figur 14.10 (a)

145
3e normalformen (3NF)

• En relation är i tredje normalformen (3NF) omm
  relationen är i 2NF och varje attribut som inte
  ingår i primärnyckeln är icke-transitivt beroende
  av primärnyckeln
• figur 14.10 (b)

146
Boyce-Codd normalform (BCNF)

• En relation är i Boyce-Codd normalform (BCNF) omm
  varje determinant är en kandidatnyckel (dvs.
  skulle kunna vara primärnyckel)
• figur 14.13

147
Transitivt beroende

• I EMP_DEPT (i fig. 14.10b) är SSN primärnyckel
  och det innebär att alla attribut inklusive DNAME
  och DMGRSSN är funktionellt beroende (FD) av SSN
• Det finns ytterligare beroenden i tabellen Om
  man vet DNUMBER vet man också DNAME och DMGRSSN

148
Transitivt beroende

• Vi har ett transitivt beroende från SSN via
  DNUMBER till DNAME och DMGRSSN
• Transitiva beroenden elimineras genom att
  splittra tabellen (PROJECT).
• fig. 14.10

SSN ? DNUMBER ? DNAME, DMGRSSN
149
Vandra mellan normalformerna

• Allmänt gäller att varje steg till högre
  normalform görs med PROJECT (splittring av
  tabell) och tabellen kan återskapas via NATURAL
  JOIN. Inga informationsförluster uppstår vid
  dessa operationer
• ex. finns i figur 14.2 och 14.4

150
Varning!

• Vid olämplig design kan falska tupler uppstå vid
  NATURAL JOIN
• ex. figur 14.3, 14.5 och 14.6

151
DAV B04 - Databasteknik

• Indexering
• (kap 6)

152
Lagring av databaser på sekundärminne

• Att läsa/skriva på sekundärminne (hårddisk) är en
  långsam process jämfört med operationer i
  primärminnet
• Antalet diskaccesser (I/O) bör därför minimeras

153
Skrivning och läsning från sekundärminne

• Skrivning och läsning sker i form av sidor (
  page/block) med standardstorlek, t ex 1024 bytes
• Databasposterna är ofta mindre än sidorna, t ex
  100 bytes, vilket gör att man läser/skriver flera
  poster (i detta fall 10) på samma gång
• Önskvärt är att relaterade poster lagras nära
  varandra för att minska antalet accesser

154
Hämta en post från databasen

1. DBHS bestämmer vilken lagrad post som behöver
   hämtas och ber filhanteraren att hämta posten
2. Filhanteraren bestämmer vilken sida (block) som
   posten finns på och ber diskhanteraren att hämta
   den sidan
3. Diskhanteraren bestämmer fysisk adress och ber om
   data från denna adress
4. Data läses av diskhanteraren
5. Den lagrade sidan returneras till filhanteraren
6. Den lagrade posten returneras till DBHS

155
Exempel på lagringsstrukturer

• Sekventiell lagring, osorterad/sorterad
• Indexering
• Hashing
• B-träd, B-träd

156
Sekventiell lagring

• Osorterat
• plus insättning av nya poster enkelt, sist eller
  första lediga
• minus leta upp en post är besvärligt,
  sekventiell sökning
• Sorterat
• plus binärsökning ger mycket snabbare access
• minus insättning av nya poster medför att poster
  måste flyttas

157
Hashing

• Hashing innebär att adressen till en post
  bestämmes med hjälp av en hash-funktion vars
  indata är något av fälten i posten
• plus direktaccess
• plus minskat adressintervall
• minus kan ge kollisioner som måste
  specialbehandlas

158
Indexering

• Indexering innebär att man bestämmer en viss
  ordningsföljd på posterna i datafilen. Index kan
  knytas till vilket fält som helst eller en
  kombination av fält
• Primary indexes
• Clustering indexes
• Secondary indexes
• Multilevel indexes
• Dynamic multilevel indexes, B-trees, B-trees

159
Primary indexes

• Index knutet till primärnyckel
• dense index ( index till varje post)
• nondense ( ej index till varje post).
• Indexfil och datafil
• fig. 6.1 och exampel 1, sida 159

160
Clustering indexes

• Index knutet till ett icke-nyckelfält som har
  dubbletter
• En pekare från indexfilen för varje distinkt
  värde (första blocket) på clustering-fältet
• fig. 6.2 och 6.3

161
Secondary indexes

• Indexfil med två värden, indexfält och pekare
  till post/block
• En datafil kan ha många sekundärindex, ett för
  varje attribut
• Fig. 6.4 och exempel 2, sida 162. Index till
  osorterad fil men på ett fält med unika värden
• Fig. 6.5 visar indexfil till fält med ej unika
  värden

162
Multilevel indexes

• Index med flera nivåer
• fig. 6.6 och exempel 3, sida 167
• Mycket snabb access men i likhet med alla
  ovanstående varianter är det problem med
  insättning av nya poster och borttagning av
  befintliga poster

163
Dynamic Multilevel Indexes using B-trees and
B-trees

• B-träd som finns i olika varianter möjliggör att
  dynamiskt lägga till och ta bort poster utan att
  slösa med minnesutrymme
• Träden är balanserade, dvs. alla löv ligger på
  samma nivå
• Nyckelvärdena är upphängda i sorteringsordning
  i trädet

164
Skillnaden mellan B-träd och B-träd

• I ett B-träd kan datapekare finnas i alla inre
  noder och i löven medan B-träd endast har
  datapekare i löven
• Dessutom finns pekare mellan löven i B-träd
  vilket möjliggör sekventiell sökning

165
B-träd av ordningen p

• Varje inre nod i trädet (fig. 6.10a) är på formen
  ltP1, ltK1, Pr1gt, P2, , ltK2, Pr2gt, , , ltKq-1,
  Prq-1gt, Pqgt där q lt p
• Varje Pi är en trädpekare och varje Pri är en
  datapekare till den post (eller block som
  innehåller) vars nyckelvärde är Ki

166
B-träd av ordningen p

• Inom varje nod gäller K1 lt K2 lt lt Kq-1
• För alla sökvärden X i det subträd som utpekas av
  Pi gäller
• Ki-1 lt X lt Ki, för 1 lt i lt q
• X lt Ki, för i 1
• Ki-1 lt X för i q

167
B-träd av ordningen p

• Varje nod har högst p trädpekare
• Varje nod, förutom roten och löven, har
  åtminstone (p/2) trädpekare. Roten har minst 2
  trädpekare såvida den inte är ensam nod i trädet

168
B-träd av ordningen p

• En nod med q trädpekare, q lt p, har q-1
  söknyckelvärden och därmed också q-1 datapekare
• Alla löv ligger på samma nivå. Löven har samma
  struktur som inre noder men deras trädpekare är
  NULL

169
B-träd av ordningen p

• Inre noder definieras enligt
• varje inre nod i trädet är på formen
  ltP1, K1, P2, K2, , Pq-1, Kq-1 , Pqgt där q
  lt p
• varje Pi är en trädpekare
• Inom varje nod gäller K1 lt K2 lt lt Kq-1

170
B-träd av ordningen p

• För alla sökvärden X i det subträd som utpekas av
  Pi gäller
• Ki-1 lt X lt Ki, för 1 lt i lt q
• X lt Ki, för i 1
• Ki-1 lt X för i q
• Varje inre nod har högst p trädpekare

171
B-träd av ordningen p

• Varje inre nod, förutom roten, har åtminstone
  (p/2) trädpekare. Roten har minst 2 trädpekare
  såvida den inte är ensam nod i trädet
• En nod med q trädpekare, q lt p, har q-1
  söknyckelvärden

172
B-träd av ordningen p

• Lövnoder definieras enligt
• Varje löv har utseendet
  ltltK1, Pr1gt, ltK2, Pr2gt, , , ltKq-1,
  Prq-1gt, Pnextgt där q lt p
• Pri är en datapekare och Pnext pekar på nästa
  lövnod i trädet

173
B-träd av ordningen p

• Inom varje nod gäller K1 lt K2 lt lt Kq-1, q lt
  p
• Varje Pri är en datapekare som pekar på den post
  (eller block) vars söknyckelvärde är Ki
• Varje lövnod har åtminstone (p/2) trädpekare
• Alla lövnoder är på samma nivå

174
DAV B04 - Databasteknik

• Transaktionshantering
• (kap 19)

175
Transaktion

• Logisk enhet i databasbearbetning
• Har en början och ett slut
• Kan innehålla flera delar, t ex read(x),
  modify(x) och write(x)

176
read(x)

• Kan ses som 3 steg
• hitta (beräkna) adress till den sida (block) där
  x finns
• kopiera sidan till buffert i PM
• kopiera x från buffert till programvariabel x

177
write(x)

• Kan ses som 4 steg
• hitta adress till den sida (block) där x finns
• kopiera sidan till buffert i PM
• kopiera programvariabel x till buffert
• lagra den uppdaterade sidan på sekundärminne

178
Concurrency

• Innebär samtidig/jämlöpande körning av flera
  transaktioner
• kan ställa till problem om de jobbar mot samma
  datamängd

179
Förlorade uppdateringar/ Lost Update Problem

• X är initialt lika med 80
• Transaktion T1 vill flytta 5 ( N) bokningar från
  X till Y
• Transaktion T2 vill öka X med 4 ( M) bokningar
• X borde bli 79 men värdet blir 84

180
Tillfälliga uppdateringar / Temporary Update
Problem

• X minskas av T1
• T2 läser x och uppdaterar X
• Men sedan misslyckas T1 och minskningen görs
  ogjord
• Därmed har T2 använt ett felaktigt värde (dirty
  read)

181
Felaktiga summeringar / Incorrect Summary
Problem

• T3 summerar variablerna A, B, ,Y
• Samtidigt ska T1 föra över N enheter från X till
  Y
• T3 summerar förändrat X-värde men oförändrat
  Y-värde
• Summan är ej korrekt

182
Fel som kan inträffa under transaktioner

• Datorfel - hårdvaru-, mjukvaru-, nätverksfel
• Transaktionsfel
• t ex division med noll
• Exceptions
• t ex data för transaktion saknas, underskott
• Concurrency control
• visar att transaktionen ej kan utföras på ett
  korrekt sätt eller deadlock inträffar
• Diskfel
• read/write, headcrash
• Katastrof
• brand, fel tape

183
Tillståndsdiagram

• 5 olika tillstånd
• ACTIVE
• PARTIALLY COMMITTED
• COMMITTED
• FAILED
• TERMINATED

184
Loggning

• Allt som händer lagras på en loggfil som skrivs
  till disk
• Varje transaktion har ett transaktions-ID, T

185
Operationer

• Hur mycket behöver lagras för varje typ?
• start_transaction, T
• write_item, T, X, old_value, new_value
• read_item, T, X
• commit, T
• abort, T

186
Varför logga systemet?

• Eftersom alla permanenta operationer loggats kan
  ett korrekt tillstånd erhållas med hjälp av
  loggen om man vet läget vid en tidigare tidpunkt
  (check-point)
• Vi kan göra undo på de transaktioner som inte
  fullföljdes genom att backa i loggen
• Vi kan göra redo på transaktioner som inte gjorts
  commit på genom att gå framåt i loggen

187
Önskvärda egenskaper hos transaktioner

• ACID-egenskaper
• Atomicity
• en transaktion skall utföras helt eller inte alls
  
• Consistency preservation
• transaktionen gör att databaser växlar mellan
  konsistenta tillstånd
• Isolation
• transaktionen skall inte påverkas av andra
  transaktioner
• Durability or permanency
• ändringar är permanenta

188
Transaktionsscheman

• Med schema (schedule eller history) avses en
  beskrivning av ordningsföljden mellan de
  operationer (read/write) som görs för att antal
  transaktioner som använder gemensamma data

189
Seriella och icke-seriella scheman

• Seriellt schema (serial)
• en transaktion i taget aktiv och först när den
  avslutats (commit/abort) kan nästa börja
• Icke-seriellt (nonserial)
• dvs. inte en transaktion i taget
• Automatiskt seriellt
• om transaktionerna är oberoende av varandra

190
Hur kan man avgöra om ett schema är seriellt
eller inte?

• För varje transaktion Ti som ingår i schemat S
• Skapa en nod som heter Ti i en precedensgraf
• För varje fall i S där Tj
• utför en read_item(X) efter att Ti utfört en
  write_item(X)
• skapa en kant (Ti ? Tj ) i precedensgrafen

191
Hur kan man avgöra om ett schema är seriellt
eller inte?

• För varje fall i S, där Tj
• utför en write_item(X) efter att Ti utfört en
  read_item(X)
• skapa en kant (Ti ? Tj ) i precedensgrafen
• För varje fall i S, där Tj
• utför en write_item(X) efter att Ti utfört en
  write_item(X)
• skapa en kant (Ti ? Tj) i precedensgrafen

192
Hur kan man avgöra om ett schema är seriellt
eller inte?

• Schemat S är serialliserbart omm precedensgrafen
  saknar cykler

193
DAV B04 - Databasteknik

• Concurrency Control
• (kap 20)

194
Tekniker för concurrency control

• Olika slags lås (locks)
• Tidsstämpling (timestamps)

195
Binära lås

• 2 tillstånd, låst (locked) och olåst (unlocked)
• Ett lås till varje databasvariabel (post, item) X
• Växlar tillstånd med lock_item(X) och
  unlock_item(X)
• Viktigt att det är atomära (odelbara) operationer
  
• Om låset redan är låst läggs man i väntekö

196
Regler för lås

• En transaktion T måste utföra operationen
  lock_item(X) innan någon read_item(X) eller
  write_item(X) utförs i T
• En transaktion T måste utföra operationen
  unlock_item(X) efter att alla read_item(X) eller
  write_item(X) utförts i T

197
Regler för lås

• En transaktion T får inte utföra operationen
  lock_item(X) om den redan har ett lås på X
• En transaktion T får inte utföra operationen
  unlock_item(X) om den inte har ett lås på X

198
Regler för lås

• Reglerna garanterar att högst en transaktion i
  taget kan låsa en variabel!
• I databashanteraren finns en tabell där man för
  varje lås anger
• lt data item, LOCK, transaktion som håller låset gt

199
Delade/exklusiva lås

• Shared/Exclusive (or Read/Write) Locks
• Läsning av samma datapost kan tillåtas för flera
  transaktioner, låset kan delas, en räknare vet
  hur många transaktioner som låst (läser) samma
  post
• 3 tillstånd, read-locked, write-locked och
  unlocked

200
Regler för delade/exklusiva lås

• En transaktion T måste utföra operationen
  read_lock(X) eller write_lock(X) innan någon
  read_item(X) utförs i T
• En transaktion T måste utföra operationen
  write_lock(X) innan någon write_item(X) utförs i
  T
• En transaktion T måste utföra operationen
  unlock(X) efter att alla read_item(X) och
  write_item(X) är utförda

201
Regler för delade/exklusiva lås

• En transaktion T får inte utföra operationen
  read_lock(X) om den redan har ett lås på X
• En transaktion T får inte utföra operationen
  write_lock(X) om den redan har ett lås på X
• En transaktion T får inte utföra operationen
  unlock(X) om den inte har ett lås på X

202
Two-phase locking protocol

• Alla låsningar (read_lock och write_lock) föregår
  första unlock i transaktionen
• Garanterar serialiserbarhet
• Dock kan deadlock inträffa

203
Deadlock Prevention Protocols

• Varje transaktion förses med tidstämpel TS(T)
• Antag att Ti försöker låsa X som redan är låst av
  Tj
• Nu finns två varianter, i båda dessa varianter
  undviks deadlock
• wait-die
• wound-wait

204
wait-die

• Om TS(Ti) lt TS(Tj), (dvs. Ti är äldre än Tj)
• så får Ti vänta
• annars (dvs. Ti är yngre än Tj) avbryts Ti
  (abort) och återstartas senare med samma
  tidstämpel

205
wound-wait

• Om TS(Ti) lt TS(Tj), (dvs. Ti är äldre än Tj)
• så avbryt Tj (Ti wounds Tj ) och återstarta
  senare med samma tidstämpel
• annars (dvs. Ti är yngre än Tj) låt Ti vänta

206
Utan tidstämpel

• No waiting
• Om transactionen inte kan få ett lås avbryts den
  omedelbart och återstartas efter viss fördröjning
  utan att kontrollera om deadlock kommer att
  uppstå
• Cautious waiting
• Antag att Ti försöker låsa X men att X redan är
  låst av Tj
• Om Tj inte är blockerad (inte väntar på någon
  annan låst variabel) så blockeras Ti och får
  vänta annars avbryts Ti

207
Deadlock Detection and Timeouts

• Upptäck deadlock genom att konstruera wait-for
  graph
• Deadlock omm det finns cykler i grafen
• Lösningar
• victim selection
• timeouts

208
Victim selection

• Någon måste offras
• Undvik transaktionen som gått länge och gjort
  många uppdateringar

209
Timeouts

• Avbryt transaktionen om den väntat för länge

210
Starvation

• En transaktion får vänta orimligt länge på grund
  av låg prioritet eller annat
• Lösningar
• FCFS first-come-first-serve i väntekö
• Prioritet ge högre prioritet åt den som väntat
  länge

211
DAV B04 - Databasteknik

• MySQL
• (-)

212
Vad behöver du?

• Ett SSH-program som ex.Tera Term Pro (Programs-gt
  Misc-gtTera Term-gt Tera Term Pro (SSH) )
• Ett program för att kopiera över filer från ditt
  vanliga konto till kontot på enterprise, ex
  WinSCP (Programs-gt Net-gt WinSCP)
• Följande data
• enterprise.cse.kau.se
• användarkonto (ex. picard, data)
• lösenord

213
Logga in på enterprise

• Från SSH-programmet med hjälp av
• användarkonto
• lösenord

214
Logga in på databaskontot

• Därifrån loggar du in på MySQL
• mysql h lthostnamegt -u ltusergt -p
• (-h lthostnamegt kan du bortse från)
• Ex. mysql u picard -p

215
Välj databas

• Tala om vilken databas du kommer att använda
  (lab3_XX)
• mysqlgt use lab3_XX

216
Andra nyttiga kommandon

• Visa alla tabeller i databasen
• mysqlgt show tables
• Beskriv en specifik tabell
• mysqlgt describe lttabellens namngt

217
MySQL vs. Access

• Inga sub-selects (går inte att nästla)
• Information om främmandenycklar sparas inte
  (kommer i senare version...), så
  referensintegritet kontrolleras inte (upp till
  er)
• Inga vyer (senare version...)

218
MySQL vs. Access

• I MySQL är det möjligt att göra COUNT(DISTINCT
  ltkolumn-namngt)
• Wildcards
• Access (substräng), ? (ett tecken)
• MySQL (substräng), _ (ett tecken)
• Kommentarer skrivs efter ett -tecken eller inom
  / / enligt C-stil

219
Exempel skapa tabeller

• CREATE TABLE suppliers
• (s_num varchar(5) NOT NULL PRIMARY KEY
• name varchar(50) NOT NULL
• )
• CREATE TABLE shipments
• (s_num varchar(5) NOT NULL,
• p_nu, varchar(5) NOT NULL,
• PRIMARY KEY (s_num, p_num),
• FOREIGN KEY (s_num) REFERENCES suppliers (s_num)
• FOREIGN KEY (s_num) REFERENCES parts (p_num)
• )

220
Information om att skapa tabeller

• Alla alternativ för CREATE TABLE finns på
• http//www.mysql.com/doc/C/R/CREATE_TABLE.html
• Ytterligare exempel finns på
• http//www.mysql.com/doc/C/r/Creating_tables.html
• De viktigaste typerna
• TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT, REAL,
  DOUBLE, FLOAT, DECIMAL(length,decimals),
  NUMERIC(length,decimals), CHAR(length),
  VARCHAR(length), DATE, TIME, TIMESTAMP, DATETIME,
  TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT,
  ENUM(value1,value2,value3,...)

221
Ta bort tabeller

• (Efter allt arbete man lagt ned för att skapa
  tabellen...))
• drop table lttabell-namngt
• Tar bort både definitionen av tabellen och alla
  data så var försiktig!!!