Databaser Design och programmering Fysisk design av databasen att ta hänsyn till implementationsaspekter minnesteknik filstrukturer indexering Minnesteknik Primärminne (kretsteknik) Flyktigt Snabbt Dyrt Sekundärminne (Olika tekniker: hårddisk, diskett, magnetband, CD, DVD mm) Permanent Långsamt Billigt Minnesteknik, forts Hybrider, sk solid state (usb-minne, kameraminnen) Permanent Snabbt Dyrt Hårddisk Skiva med magnetiserbar beläggning, packningstäthet Roterar: spår, rotationshastighet Läs/skrivhuvud Packe, cylinder storlek vs accesstid och pris per byte Krav: databaser är stora och persistenta
Hårddisk, forts Block fysiskt 1/2 till 4kB, logiskt upp till 64kB - minsta överföringsmängd till PM Fil lagras i ett antal block Accesstid = sök+rotation+läs = 5-50ms (millisekunder) (läsa hela skivan sekvensiellt dock snabbare) Blocköverföring tar alltså tid. Databasen Lagras som en samling poster i filer på hårddisk Post med fält = tupel med attribut Fil med poster = relation med tupler Datatyp (tecken, heltal osv) - utrymme Filer Filer och block Operativsystemets filer Databashanterarens filer Olika lösningar: databashanteraren har helt egna filer databashanteraren använder OS' filer Mellanting Viktiga operationer på poster: hitta, lägg till, ta bort, ändra, gå igenom ett antal Filer lagras som en serie poster i ett antal fysiska block Logiska block som en serie fysiska block Ligger efter varandra i samma spår så långt det går Efter raderingar och insättningar: fragmentering
Blockningsfaktor, bfr Filer Om R är poststorlek och B är blockstorleken är bfr = B/R" en fil med r stycken poster kräver n = #r/bfr$ stycken block Vilka block som ingår lagras i filhuvudet Består av filhuvud och en samling poster ordnade på något sätt i en samling block. Filhuvud - information om poststorlek, ingående block mm Hur är posterna ordnade inom filen? 1. Hög (heap) (osorterat) 2. Ordnad sekvens (sorterat) 3. Hashstruktur 4. Indexstruktur Hög (heap) Oordnad sekvens av poster Ny post - läggs sist. Adressen till sista blocket sparas i filhuvudet. Sökning - sekvensiell genomgång av filen tills man hittar den sökta posten. Medel=b/2, Max=b. Borttagning - sök rätt block, som läses in. Ta bort posten. Skriv tillbaks det reviderade blocket, som nu är delvis tomt. Sökning i hög, exempel Poststorlek, R = 100 byte blockstorlek, B = 1024 byte filstorlek, r = 30 000 st poster tid för blocköverföring: 20 ms Blockningsfaktorn blir: bfr=b/r"= =1024/100"= 10 poster per block Filen tar upp b=#r/bfr$=#30000/10$ st block För att hitta en viss post krävs i genomsnitt b/2= 1500 blocköverföringar = 30 sekunder.
Hög: fördelar och nackdelar Ordnad sekvens (sorterat) + Insättning går mycket fort. - Många borttagningar leder till tomrum på skivan. (Kräver periodisk omorganisering av filen.) - Sökning långsam - Om posterna har variabel längd kan ändring i en sådan post få blocket att svämma över - posten måste då tas bort och sättas in på nytt. Posterna i filen sorteras enligt värdet på något fält i posterna. Ny post - hitta rätt ställe (rätt block), skapa plats åt den nya posten, sätt in den. Skapa plats = flytta resten av posterna ett steg framåt. Sökning - t.ex. binärsökning, om listan av block sparas i filhuvudet eller sekvens av block nyttjas. Borttagning - som ny post om posten fysiskt ska tas bort. Man kan också markera posten som borttagen och organisera om då och då. Sökning i ordnad sekvens, exempel Samma fil som tidigare: blockfaktor, bfr = 10 poster per block antal block, b = 3000 block. tid för blocköverföring = 20 ms Binärsökning, antal blocköverföringar: n=#log2(b)$ = #log2(3000)$=12 För att hitta en viss post krävs maximalt 12 blocköverföringar = 0.24 sekunder. Ordnad sekvens, fördelar och nackdelar - Insättning av ny post tar tid om plats skapas genom att förskjuta övriga poster i filen - Borttagning eventuellt likaså. + snabbare sökning än hög
För filer med nyckel. Hashstruktur Posterna sprids över en hylla med fack med hjälp av en hashfunktion. Varje hylla=ett block Kollisionshantering vid fullt block: spillblock Hashstruktur, forts Ny post - beräkna hashvärde, om plats finns i blocket, sätt in. Om inte länka in nytt block. Sökning - beräkna hashvärde, läs. Om inte rätt block följ länken till nästa tills funnen. Tid för sökning: beror av hur många länkar man måste följa. Borttagning hitta som ovan, ta bort posten ur blocket och skriv tillbaks det ändrade blocket. Hashstruktur, fördelar och nackdelar + snabb sökning (fåtal blockaccesser) - avancerad algoritm för insättning och borttagning - tar viss extra plats (länkfältet samt luft ) - kräver hela nyckeln Indexstruktur För sökning på något speciellt fält (indexeringsfält). Jfr index till en bok Huvudfilen är ordnad efter något fält, t.ex. nyckeln. Kallas då primärindex. För varje block i huvudfilen skapas en post i indexfilen, som innehåller nyckeln från den första posten i blocket samt blockets adress. Indexfilen sorteras enligt nyckelvärdet.
Indexstruktur, forts Ny post - rätt block söks fram, läses in, ändras och skrivs tillbaks. Vid översvämning skapas ett nytt block och en ny indexpost läggs in i indexfilen Sökning sök nyckeln i indexfilen (som vid sökning i sorterad fil). Hämta aktuellt block. Borttagning - som ny post. Oftast lämnas tomrum i block istället för att organisera om varje gång. Sökning i indexerad fil, exempel Samma huvudfil som tidigare: antal block, b = 3000 block. tid för blocköverföring = 20 ms Antag att nyckelfältet är 9 bytes långt och adressen till block tar 6 bytes. Indexfilen är en sorterad fil som söks som sådan Sökning i indexfilen Indexfilens poststorlek ir blir då 15 bytes Indexfilens blockfaktor ibfr =1024/15"= 68 Indexfilen tar alltså upp ib = #3000/68$=45 block Hitta en viss indexpost (binärsökning i indexfilen): #log2(45)$blocköverföringar =6 st. Sedan ytterligare en för att läsa ur huvudfilen. Totalt 7 blockaccesser, 0.14 sekunder. Indexstruktur, fördelar och nackdelar - indexfilen tar extra plats i databasen. - insättning och borttagning kräver även uppdatering av indexfilen. + snabb sökning + relativt enkla algoritmer för insättning och borttagning
Index till indexfilen. Multipla index (indexnivåer) För varje block i indexfilen en post i indexindexfilen... Kan ha godtyckligt många nivåer... Sökning med multipelt index Samma huvudfil och samma indexfil: Indexfilens blockfaktor ibfr = 68 Indexfilen tar upp ib = 45 block Index på indexfilen behöver i2r= 45 poster. Den får plats i ett block: Hitta index till indexfilen (1 överföring). Hitta index till huvudfilen (1 överföring). Läsa in det eftersökta blocket ur huvudfilen. Totalt 3 blockaccesser, 0.06 sekunder. Klusterindex Sekundärindex Indexering på icke-unikt fält går det? Sortera filen på indexfältet och gör index för första posten av varje indexvärde. Ny post sortera in efter nyckeln Sökning sök rätt index som tidigare, sök sedan rätt post i blocket, eller nästa block Borttagning som för vanligt index. index på unikt fält som filen inte är sorterad efter? Detta index är tätt (en indexpost per post i huvudfilen, jfr primärindex, glest). Sekundärindexet får lika många poster som datafilen har poster.
Sökning på sekundärindex, exempel samma fil som tidigare och indexposter som tidigare, men med tätt index: Indexfilens poststorlek ir = 15 bytes Indexfilens blockfaktor ibfr =1024/15"= 68 Indexfilen tar ib =#30000/68$= 442 block Hitta en indexpost, binärsökning i indexfilen: #log2(442)$ blocköverföringar = 9 st sedan en blocköverföring ur huvudfilen. Totalt 10 blockaccesser, 0.2 sekunder. Hög Ordnad sekvens Hashstruktur Indexstruktur Filorganisationer primärindex (multipla nivåer) klusterindex sekundärindex Fysisk design designa databasen på fysisk nivå: avvägning mellan utrymme och snabbhet. Ta med i beräkningen hur ofta tabellen används och hur (sökning/matchning mot vilket fält). Åtgärder: Ordna datafilen - osorterad hög eller sorterad? På vad? Används alltid nyckel? Hashtabell Skapa index vilka behövs?