2007:02 - Karlstads universitet

More documents

Recommendations

Info

ducerades i ekvation 3.1 s˚a lägger vi till: p = antal unika poster (3.4) Fr˚an parametern p kan vi definiera b som antalet bitar som krävs för att representera en pekare: b = log 2 (p) (3.5) Det finns totalt n poster i databasen och vi kan beräkna totala antalet bitar för pekarna i databasen som b · n. Storleken för tabellen beräknas genom att multiplicera det genomsnittliga antalet tecken per post med antalet unika poster: g · p. Sammantaget blir den totala storleken s allts˚a: s = b · n + 8 · g · p bitar (3.6) Storleken för en post beräknat p˚a formeln fr˚an ekvationen 3.6 ovan bör vara mindre än storleken för samma post beräknat p˚a formeln fr˚an ekvation 3.2, vilket ger: b · n + 8 · g · p < 8 · g · n (3.7) I Uppsalakatalogen finns det n = 87891 personer och p = 20027 unika efternamn. I genomsnitt best˚ar efternamnen av c:a g = 7, 46 tecken per post. Applicerar vi formeln fr˚an ekvation 3.6 s˚a blir storleken s för efternamnen i Uppsala totalt sett: s = b · n + 8 · g · p = log 2 (20027) · 87891 + 8 · 7, 46 · 20027 ≈ 172 Kb (3.8) 3.3.3 Token-tabell med buckets Översikt För att öka sökhastigheten kan tokentabellen utökas med pekare till relevanta poster i databasen. Som tidigare finns varje unik förekomst av exempelvis ett efternamn i tokentabellen. Associerad med varje post i tabellen finns ocks˚a en bucket inneh˚allandes 24
pekare till de databas-tuplar vilka har den egenskap som beskrivs av tabellposten. (Se Figur 3.3.) tuple db tokens Adam Bertil Ceasar David Östen Figur 3.3: Token-tabell med buckets buckets Hastighet Sökhastigheten förbättras eftersom sökalgoritmen inte behöver g˚a igenom hela databasen utan endast tokentabellen (förutsatt random access) vilken, enligt 3.3.2, inneh˚aller färre poster. Dessutom, d˚a en förekomst väl har hittats i tokentabellen s˚a f˚as alla pekarID för förekomster i databasen genom undersökning av bucket:en. Förutsatt att det g˚ar att hämta data i databasfilen med random access s˚a krävs det nu allts˚a först x instruktioner för att hitta posten (och tillhörande pekarID) i tokentabellen. Därefter krävs det en instruktion för varje pekarID i bucket:en. I genomsnitt s˚a inneh˚aller en bucket n p pekarID, vilket allts˚a resulterar i lika m˚anga instruktioner. Den tidigare beskrivna lösningen behöver, precis som denna, x instruktioner för att hitta rätt pekarID i tokentabellen. Därefter krävs n genomsökningar i databasen. Det genomsnittliga antalet instruktioner för att hitta rätt 25
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 36 and 37: typ, kan vara av variabel längd oc
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

Create successful ePaper yourself

Delete template?

Save as template?