2007:02 - Karlstads universitet

More documents

Recommendations

Info

typ, kan vara av variabel längd och inneh˚aller mer information än ett heltal. I den fortsatta utredningen antas dock att en jämförelse kräver en instruktion, där det med instruktion menas att n˚agon typ av operation ska utföras. Ett s˚adant m˚att tar allts˚a inte hänsyn till om det är heltal eller strängar som jämförs. Minne Denna metod är, i relation till dess prestanda i sökhastighet, inte minnessn˚al. Det existerar mycket redundant information som ligger utspritt i databasen d˚a t.ex. m˚anga personer har samma namn, bor p˚a samma gata eller har samma postnummer. Den här lösningen är inte optimerad för denna typ av redundant information. För att beräkna den totala storleken för en godtycklig post i databasen, i syfte att kunna jämföra med de andra lösningarna, s˚a definierar vi parametrarna n och g: n = totala antalet poster g = antal tecken i genomsnitt per post Totala antalet bitar s för en godtycklig post blir d˚a 7 : (3.1) s = 8 · g · n bitar (3.2) I Uppsalakatalogen finns det n = 87891 personer. I genomsnitt best˚ar efternamnen av c:a g ≈ 7, 46 tecken per post. Applicerar vi formeln fr˚an ekvation 3.2 för efternamnen i Uppsala s˚a blir den totala storleken s: 3.3.2 Token-tabell s = 8 · g · n = 8 · 87891 · 7, 46 ≈ 640 Kb (3.3) Översikt För att optimera minnesutrymmet när det gäller redundant information, som beskrevs tidigare, s˚a kan man lägga den informationen i en egen tabell. I en s˚adan tabell 7 1 tecken = 8 bitar 22
finns t.ex. alla unika efternamn samlade p˚a ett organiserat sätt, exempelvis i bokstavsor- dning. För varje relevant fält i databasen, d.v.s. där redundant information förekommer, konstrueras motsvarande tabeller. För varje tuple i databasen ligger nu istället pekare. Pekarna hänvisar till var i de olika tabellerna som informationen för just den tupeln finns. Detta illustreras i Figur 3.2. tuple db Figur 3.2: Token-tabell tokens Adam Bertil Ceasar Hastighet Den här metoden skiljer sig inte nämnvärt fr˚an den föreg˚aende gällande sökhastighet. Lite längre söktid kan förväntas d˚a man först m˚aste göra ett uppslag i tabellen för att veta vilket pekarID man ska leta efter i databasen. Minne Hur mycket minne den här lösningen kräver beror till stor del p˚a egenskaperna och karaktären i databasen; mycket redundant information medför bättre minnesutnytt- jande. Det innebär att man m˚aste analysera vilka av fälten som är lämpliga att ha tabeller för. Vilka parametrar kan p˚averka ett s˚adant beslut? Förutom de parametrar vilka intro- 23 David Östen
Page 1: Avdelning för datavetenskap Sebast
Page 5: Denna rapport är skriven som en de
Page 8 and 9: Abstract The PhonePages of Sweden i
Page 10 and 11: 3.4.1 Trie hashing . . . . . . . .
Page 12 and 13: Figurer 2.1 Olika typer av ändsyst
Page 14 and 15: Tabeller 3.1 Huvudargument för val
Page 16 and 17: framförallt för existerande syste
Page 18 and 19: det finns tydliga begränsningar ä
Page 20 and 21: Eftersom data ligger centraliserat
Page 22 and 23: standa av enheten. Den ska rymma en
Page 24 and 25: 3 Analys av möjliga lösningar Huv
Page 26 and 27: - Prioritet • För att kunna sök
Page 28 and 29: • Minne, varaktigt: hur mycket pl
Page 30 and 31: 3.2.2 File Connection Optional Pack
Page 32 and 33: Minne - varaktigt Inga extra varakt
Page 34 and 35: Tabell 3.1: Huvudargument för val
Page 38 and 39: ducerades i ekvation 3.1 s˚a lägg
Page 40 and 41: token i tabellen är x = p . Formle
Page 42 and 43: element i en sekventiell fil tar n
Page 44 and 45: Tabell 3.2: Ordning för hur eftern
Page 46 and 47: abrahamsson adamsson adenmark adolf
Page 48 and 49: ställs p˚a kommande releaser s˚a
Page 50 and 51: att avgöra hur komponenterna ritas
Page 52 and 53: • Om alla pi är lika, det vill s
Page 54 and 55: oavsett var i meddelandet de förek
Page 56 and 57: BPE inte med i detta projekt. 3.7 S
Page 58 and 59: medföra, dvs. Hur koefficienten R
Page 60 and 61: Figur 3.10: Centrala Göteborg, ska
Page 62 and 63: 4 Design Detta kapitel kommer beskr
Page 64 and 65: Figur 4.2: En Sony-Ericsson W800i m
Page 66 and 67: problem och dess lösningar, inte l
Page 68 and 69: Modell Informerar Uppdaterar Inform
Page 70 and 71: detta. Mönstret har m˚anga använ
Page 72 and 73: endast ska f˚a finnas en instans a
Page 74 and 75: metoden TextInputChoices.showNotify
Page 76 and 77: som lyssnar först implementera Obs
Page 78 and 79: Figur 4.11: UML-klassdiagram över
Page 80 and 81: Innehåller 4.5.2 Databas Har Telef
Page 82 and 83: Figur 4.15: UML-klassdiagram för A
Page 84 and 85: 5 Implementation I detta kapitel ko
Page 86 and 87:
1 p r i v a t e synchronized char g
Page 88 and 89:
knapptryckningarna kom tillräcklig
Page 90 and 91:
1 p u b l i c synchronized void run
Page 92 and 93:
skall run endast nollställa medlem
Page 94 and 95:
1 p u b l i c c l a s s Soundex { 2
Page 96 and 97:
till den nuvarande soundex-koden. D
Page 98 and 99:
trädstrukturen. 5.4.1 Traversera t
Page 100 and 101:
1 p r i v a t e void p o s t o r d
Page 102 and 103:
5.4.3 Spara trädstruktur För att
Page 104 and 105:
3. Om nästa tecken är ’2’, s
Page 106 and 107:
stacken. När hela den här process
Page 108 and 109:
Av denna anledning s˚a m˚aste en
Page 110 and 111:
1 p r i v a t e Set i n t e r s e c
Page 112 and 113:
1 p r i v a t e Vector i n t e r s
Page 114 and 115:
har inbyggt stöd för att använda
Page 116 and 117:
Ett problem av allvarligare grad va
Page 118 and 119:
Referenser [1] Alfred V. Aho, John
Page 120 and 121:
2FgetArticle.do%3Flocale%3DSV%26art
Page 122 and 123:
Examensarbete - Mobile Search - Jav
Page 124 and 125:
Abstract LocalDirectory_Requirement
Page 126 and 127:
Document name Security class Page P
Page 128 and 129:
Document name Security class Page P
Page 130 and 131:
LocalDirectory_RequirementSpecifica
Page 132 and 133:
5.3 LAPD SECURITY LocalDirectory_Re
Page 134 and 135:
LocalDirectory_RequirementSpecifica
show all

2007:02 - Karlstads universitet

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?