IMM-B.Eng-2010-36 NYHEDSSØGEMASKINE Hasim Coskun Eksamensprojekt, Diplom IT Danmarks Tekniske Universitet 2010 Vejleder Finn Gustafsson
Abstrakt Implementerer en parser prototype i PHP til en nyhedssøgemaskine. Parseren skal udvikles så den kan fungere på et valgt nyhedsbureau, som er www.politiken.dk. Søgemaskinen skal kunne give brugeren muligheden for, at foretage søgninger på forskellige sprog og samtidig automatisk detektere, hvilket sprog brugeren har indtastet i en eventuel søgning. Oversættelse og sprog detektion skal udvikles således at der benyttes Google s API og dermed deres Google Translate funktionalitet. Søgemaskinen skal være up to date hvad angår design, og derfor skal det lægge sig tæt op ad Web 2.0 farver, skrifttyper mm. Inden denne parser prototype implementeres, skal der forskes og undersøges nærmere omkring hvordan nuværende søgemaskiner, såsom Google fungerer. Dette vil danne grundlag for, hvordan den mest optimale parser kan blive udviklet og dermed give ideer til udvikling af Nuttot s parser prototype. Danmarks Tekniske Universitet Side 1 af 91
Forord Denne rapport er udarbejdet af Hasim Coskun i forbindelse med det afsluttende eksamensprojekt på Diplomingeniør studiet ved Danmarks Tekniske Universitet. Projektet er en idé jeg selv har fundet på og ved vejledning af Finn Gustafsson er det blevet en realitet. Vejlederen på projekt har været Finn Gustafsson fra IMM DTU. Der er vedlagt en CD med kildekode bagerst i rapporten. På baggrund af denne rapports udførelse vil jeg gerne sige mange tak til Finn Gustafsson for hans hjælpsomhed og gode vejledning. DATO: UNDERSKRIFT: HASIM COSKUN S053232 Danmarks Tekniske Universitet Side 2 af 91
Indholdsfortegnelse 1. INDLEDNING 6 2. PLAN 7 3. KRAVSPECIFIKATION 8 3.1. BRUGERGRÆNSEFLADEN 8 3.2. DATABASEN 8 3.3. FUNKTIONALITET 8 4. TEORI 9 4.1. GOOGLE 9 4.1.1. PAGERANK 9 4.1.2. SEO 9 4.1.3. SPIDER & CRAWLER BOTS 10 4.1.4. KONKLUSION 13 5. ANALYSE 14 5.1. SPROG DETEKTOREN 14 5.1.1. PROBLEMATIKKEN I EN SPROGDETEKTOR 14 5.1.2. LØSNINGSMODELLER 15 5.1.2.1 ORDBOG BASERET (MODEL 1) 15 5.1.2.2 ORDBOG & ENDELSER BASERET (MODEL 2) 17 5.2. DATABASEN (MYSQL) 20 5.2.1. LØSNINGSMODELLER 20 5.2.1.1 MYSQL VS. MSSQL VS. POSTGRESQL 20 5.2.1.2 MYISAM VS. INNODB 21 5.2.1.3 AUTO INCREMENT VS. MANUEL INCREMENT 21 5.2.2. NØGLER 22 5.2.3. KOLLATION (TEGNSÆTNING) 23 5.2.4. SQL INJECTION 23 5.2.5. INDEXES 24 5.3. FUNKTIONALITET (PHP) 26 5.3.1. LØSNINGSMODELLER 26 5.3.1.1 PHP VS. ASP.NET 26 5.3.1.2 HTML VS. XHTML 27 5.3.2. CSS 27 5.3.3. JAVASCRIPT & AJAX 28 6. DESIGN 29 Danmarks Tekniske Universitet Side 3 af 91
6.1. GRÆNSEFLADE 29 6.2. DATABASEN (MYSQL) 31 6.2.1. RELATIONER 32 6.2.2. ER-DIAGRAM 32 6.2.3. DATABASE MODEL 33 6.2.4. DATABASE OVERSIGT 34 6.3. FUNKTIONALITET (PHP) 35 6.3.1. PARSER 35 6.3.2. LINK CRAWLER BOT 38 6.3.3. TRANSLATOR BOT 39 6.3.4. SPROGDETEKTOR 40 6.3.5. SØGEALGORITME 41 7. IMPLEMENTERING 43 7.1. GRÆNSEFLADE 43 7.1.1. SØGEFELT 44 7.1.2. SPROGDETEKTOR 44 7.1.3. OVERSÆTTER 44 7.1.4. VIRTUELT TASTATUR 44 7.1.5. PREVIEW 44 7.1.6. LOGO 45 7.1.7. SØGERESULTAT 45 7.1.8. BRUGERVENLIGHED 49 7.1.9. WEB 2.0 49 7.1.9.1 FARVER 49 7.1.9.2 SKRIFTTYPER 49 7.2. DATABASEN (MYSQL) 50 7.2.1. ORIGINAL 50 7.2.2. TRANSLATIONS 50 7.2.3. URL 51 7.2.4. SUPPORTED LANGUAGE 51 7.2.5. SEARCH HISTORY 52 7.2.6. SQL OPERATIONER 52 7.3. FUNKTIONALITET (PHP) 53 7.3.1. INSTALLATION 53 7.3.2. CRONJOBS 54 7.3.2.1 REGULÆRE UDTRYK 54 7.3.2.2 LINK CRAWLER 54 7.3.2.3 PARSER BOT 54 7.3.2.4 TRANSLATION BOT 55 7.3.3. KLASSEDIAGRAM 57 7.3.4. SCRIPT & OOP 58 7.3.5. GOOGLE API 58 7.3.6. FREMTIDIGE FORBEDRINGER 58 7.3.6.1 CLUSTER 58 7.3.6.2 SPECIALTEGN I SØGESTRENG 59 Danmarks Tekniske Universitet Side 4 af 91
8. TEST 60 8.1. VALIDERING 60 8.2. BLACKBOX 60 8.2.1. VIRTUELT TASTATUR 60 8.2.2. SØGEFELT SPROGDETEKTOR TASTATUR 61 8.2.3. SØGNING (MED OVERSÆTTELSE) 61 8.2.4. SØGNING (UDEN OVERSÆTTELSE) 61 8.2.5. SØGERESULTAT FUNKTIONER 62 8.2.6. CRONJOBS 63 8.3. BROWSER 63 8.4. TEST KONKLUSION 64 9. KONKLUSION 65 10. BILAG 66 10.1. LITTERATURLISTE 66 10.2. NUTTOT MANUAL 66 10.3. TEST BILAG 68 Danmarks Tekniske Universitet Side 5 af 91
1. Indledning Projektets formål er at udvikle en nyhedssøgemaskine som udskiller sig fra andre nuværende søgemaskiner ved at give brugeren en helt ny måde at søge efter nyheder på. Derfra kommer ideen om at kunne søge efter nyheder på andre sprog. Jeg vil på baggrund af Google s udgivelser og de artikler jeg har læst, forsøge at give et overordnet billede af hvordan Google s søgemaskine fungerer og forsøge at drage paralleller fra dette, således at disse kan benyttes i min egen nyhedssøgemaskine, Nuttot. Der skal anvendes en række værktøjer samt programmeringssprog, for at gøre Nuttot til en realitet. Disse består af følgende: - PHP (både script baseret og OOP) - MySQL - AJAX - JavaScript - CSS - HTML - Google API - Adobe Photoshop CS4 (billedbehandlingsværktøj) - PhpED (PHP udviklingsværktøj) Rapporten er opdelt i følgende emner: - Plan - Kravspecifikation - Teori - Analyse - Design - Implementering - Test - Konklusion - Bilag Disse ovenstående emner er opstillet og valgt, så de giver læseren et overblik over rapportens indhold. Danmarks Tekniske Universitet Side 6 af 91
2. Plan Tidsplanen er meget statisk sat op og mest brugt for blot at holde øje med deadlines. Der vil altid opstå situationer, hvor man er nødt til at gå tilbage for at rette i ens analyse eller design mens man f.eks. er i implementeringsdelen. Derfor er det meget smart med en planlægning, som angivet i Figur 1. Figur 1: Tidsplanen Danmarks Tekniske Universitet Side 7 af 91
3. Kravspecifikation For at Nuttot kan leve op til de nuværende søgemaskiner, kræver det at der opfyldes en række krav. Disse krav er både gældende for databasen, funktionaliteten og ikke mindst brugergrænsefladen. 3.1. Brugergrænsefladen Der skal benyttes levende farver, som lægger sig tæt op af Web 2.0. Der skal benyttes skrifttyper som er let læselige for brugeren og samtidig lægger sig tæt op af Web 2.0. Brugeren skal have et overblik over sidens indhold. Søgninger skal kunne foretages meget let. Det skal gøres klart og tydeligt, hvad Nuttot er og hvad den kan bruges til. 3.2. Databasen Der skal være en tabel i databasen for alle de sprog Nuttot understøtter. Alle oversættelser af nyheder skal findes i databasen. Der skal være understøttelse for tegn udover de danske alfabeter, således at der benyttes en UTF8 standard. Der skal være så meget optimering som muligt, for at få en høj performance. Der skal være sikkerhed, så der ikke kan udføres SQL injektioner. Database designet skal opfylde 3. normal form, 3NF. 3.3. Funktionalitet Automatisk sprog detektion skal returnere det sprog, brugeren har indtastet. Brugeren skal kunne oversætte et søgeord eller en sætning og søge på dette. Brugeren skal have overblik over søgeresultaterne, således at man kan referere til dem. Maksimum 20 søgeresultater skal udskrives pr. side. Søgeresultaterne skal sorteres efter mest relevante nyheder. Der skal være et preview funktion for brugeren, så man ikke behøver at forlade søgeresultatsiden for at se indhold af nyheden. Danmarks Tekniske Universitet Side 8 af 91
4. Teori 4.1. Google Google 1 er uden tvivl verdens største søgemaskine, som i øjeblikket benyttes af internet brugere verden over. Dette skyldes dels, at man stort set kan finde det man søger efter på Google og at den er utrolig simpel at benytte. Desværre offentliggør Google ikke noget omkring deres web crawlers mht. hvordan disse fungere. Dog er de ikke alene omkring dette, da Yahoo og Bing ligeledes heller ikke forklarer, hvordan deres søgemaskiner er opbygget. Det er selvfølgelig forstået, at ingen af dem offentliggøre deres metoder, da det vil være en stor ulempe for deres markedsføring. Google udgiver ingen konkrete informationer omkring hvordan deres søgemaskine fungerer, men de udgiver dog en masse andet, som kan hjælp med at gætte sig frem til deres søgealgoritmer. De udgiver f.eks. en masse artikler omkring deres PageRank 2 system og omkring, hvad der skal til for at komme højere op i søgeresultaterne, som også kaldes SEO 3. 4.1.1. PageRank Et søgeresultat fra Google sorteres bl.a. ud fra et numerisk PageRank værdi, som repræsenterer hvor betydningsfuld en hjemmeside er på nettet. Værdien af PageRank ligger i virkeligheden i et interval mellem 0.15-milliarder, men vises som et interval mellem 0-10, hvor 0 er den mindste værdi og 10 er den højeste. Google har specielle algoritmer, som udelukkende definerer PageRank værdier på de hjemmesider, som deres web crawlers finder frem på internettet. Disse algoritmer går ind og finder ud af om, en hjemmeside har indgående links og udgående links, dog er det indgående links, som spiller en speciel rolle i PageRank. Google anser nemlig at, hvis en hjemmeside har indgående links fra andre hjemmesider, så må denne hjemmeside have en større værdi og derfor får den en større PageRank. 4.1.2. SEO Google anbefaler at man opbygger sin hjemmeside ud fra deres kriterier, hvis man selvfølgelig ønsker at have en hjemmeside, som er SEO venlig. De mener at, hvis en webside er SEO venlig, så er den også kodet korrekt. 1 Google er en søgemaskine til internettet. Google anses som den største søgemaskine på internettet i dag, da den har over 200 millioner forespørgsler om dagen. 2 Google PageRank (systemet som, definere hvor en hjemmeside ligger i søgeresultaterne). 3 Search Engine Optimization (Søgemaskine Optimering) Danmarks Tekniske Universitet Side 9 af 91
Google mener at en hjemmeside er SEO venlig, hvis den gør brug af alle HTML tags de rigtige steder. En stor fejl, som mange web udviklere kommer til at lave, er bl.a. at de ikke benytter H1, H2 og H3 tags til henholdsvis hovedtitler, undertitler mm. Man benytter nemlig ofte i stedet CSS med en simpel <font> tag, og derved kun ændrer størrelsen. Problemet er dog, at Google opfatter <font> tags, som normal tekst, i stedet for f.eks. en overskrift. Benyttelse af alle HTML tags de rigtige steder er dog desværre ikke nok, da der vel og mærke vil forekomme et stort problem på søgeresultaterne, da alle webudviklere sagtens har mulighed for, at opbygge en hjemmeside ud fra Google s anvisninger. Derfor vælger Google at udføre særlige algoritmer, som tjekker et websites indhold for om, der er sammenhæng med de keywords man har defineret i hjemmesidens META TAGS 4. 4.1.3. Spider & Crawler bots Web crawlers, spiders og crawler bots kaldes de, men Google kalder det en, spider 5. Det er Google s mange spidere, som er starten på Google s søgemaskine. Den kaldes en spider, fordi den kravler rundt fra website til website, altså realt set vil de aldrig stoppe, da der altid bliver oprettet nye links, domæner og websites. Denne spider starter på et website og undersøger dette website for alle eksisterende hyperlinks, både intern og eksternt. Alle disse links bliver herefter gemt i en database, med unikke id er (Figur 2). Dette er primært spiderens opgave, altså at finde hyperlinks og fylde databasen med links, som er klar til at blive gennemløbet af crawling bots. Crawler bots er modsat en spider langt mere intelligente, hvad angår undersøgelse af et website. Når en crawling bot er sat i gang, bliver der sendt en vilkårlig url adresse fra databasen, som spideren i forvejen har fyldt op med links. Crawleren vil dernæst gå ind på det modtagne url og gennemløbe websiden igennem for at producere et dokument, som er klar til udarbejdelse senere af andre algoritmer. Det endelig dokument vil blive tildelt et unikt id og vil udelukkende være baseret på rent tekst og samtidig få tildelt en PageRank værdi. Dette dokument vil selvfølgelig blive gemt på Google s databaser og servere. Det vil blive gemt på Google s servere, da Google har Cached 6 funktionalitet indbygget. 4 Meta tags er data information, som sættes ind i <head> sektionen i HTML dokumenter. Meta tags kan for eksempel fortælle browseren, hvilket sprogtegn (character set), der benyttes. 5 Google spider bot. Fungerer reelt set, som en edderkop som udforsker WWW (World Wide Web) hele tiden. 6 Cached funktionen giver mulighed for at se et levende skærmbillede af en allerede crawlet og gemt hjemme, blot med den forskel at man får lov til at se, hvordan siden så ud på det tidspunkt den blev crawlet. Danmarks Tekniske Universitet Side 10 af 91
Figur 2: Viser hvordan en Google spider fungerer. Google benytter herefter en masse algoritmer samtidigt og jonglere rundt med ordene i de enkelte dokumenter for at skabe en kæmpe oversigtsdatabase, for hvert dokument. De tager hvert ord i et dokument og gemmer dette i en database, og ud fra dette ord, gemmer de dokuments unikke id, som ordet er blevet fundet i (Figur 2). Denne metode giver dem muligheden for ikke at søge igennem alle dokumenter, men i stedet nøjes med at søge i den aktuelle database, som indeholder ordene og dokumenternes unikke id (Figur 3). Danmarks Tekniske Universitet Side 11 af 91
Figur 3: Viser hvordan Google overordnet fungerer. Disse beskrevne metoder som Google benytter er dog ikke nogen forklaringer på, hvordan det kan være at Google er en så hurtig og effektiv søgemaskine, til netop at finde det som man forespørger ud fra millioner af søgeresultater. Denne høje performance skyldes dels smarte algoritmer, men samtidig også et smart valg af beregningsudstyr, som f.eks. et Cluster dvs. de udnytter effekten ikke kun en, men flere sammenkoblede computere (yderligere beskrevet under afsnittet Design ). Danmarks Tekniske Universitet Side 12 af 91
4.1.4. Konklusion Det største problem ved at beskrive Google s metoder og løsninger er, at meget af det består af gæt og teorier, da de ikke direkte forklarer, hvordan deres algoritmer fungerer, hvilket mest skyldes pga. det store marked for SEO. De hidtil beskrevne metoder og forklaringer er udelukkende mine egne iagttagelser og opfattelse af, hvordan en store søgemaskine som Google i virkeligheden fungerer. Danmarks Tekniske Universitet Side 13 af 91
5. Analyse 5.1. Sprog detektoren 5.1.1. Problematikken i en sprogdetektor Det er utrolig svært at udvikle en sprogdetektor, som automatisk bestemmer sproget ud fra det brugeren har indtastet. Dette skyldes til dels, at man er nød til at udvikle mange avancerede algoritmer, som kan læse contexten før der defineres et sprog. Dog er contexten ikke det eneste problem ved en sprogdetektor, da der sagtens kan optræde sammenligninger ved flere sprog på samme tid, som f.eks. de skandinaviske sprog. Norsk og Dansk er blot et af de mange sprog, som har flere ord tilfælles og som staves på samme måde. Dette problem vil man ikke kunne løse på nuværende tidspunkt, da der her kræves, at man læser brugerens tanker for at finde ud af hvilket sprog, brugeren faktisk forsøgte at indtaste. Dog kan man lave en sideløsning på dette problem, ved blot at spørge brugeren om han eller hun mente Dansk eller Norsk som indtastningssprog. Hvis brugeren for eksempel indtaster Hej med dig, vil en typisk sprogdetektor fremvælge et sprog. Det fremvalgte sprog, vil som regel være det sprog som benyttes oftest, hvilket naturligvis vil være forkert. Problematikken i en sprogdetektor giver os 3 præsentationsmåder for det endelige resultat i en sprogdetektor, som er følgende: 1. Fortælle brugeren, at den indtastede sætning kan skrives på flere sprog, og i dette tilfælde: Dansk og Norsk. 2. Læse brugerens tanker og ud fra det, bestemme om brugeren mente Dansk eller Norsk. 3. Angiver det sprog som er mest udbredt, baseret på statistik og sandsynligheder. Hvilket i dette tilfælde hos Google Translate 7 er Norsk som resultat. Naturligvis vil punkt 2 være den mest præcise og næsten fejlfrie løsninger for en sprogdetektor. Dog er denne løsning ikke mulig på nuværende tid grundet teknologien og derfor vil punkt 1 være den mest optimale løsning. Den første løsning vil nemlig altid give brugeren mulighed for, at have en indflydelse på resultatet. Brugerens valg på denne løsning vil samtidig også kunne benyttes til fremtidige sprogdetektere, som kunne opbygges ud fra punkt 3, dog med den forskel at man vil sammenligne flere egenskaber omkring brugeren. Hvis en bruger i Danmark f.eks. vælger at indtaste Hej med dig., og herefter vælger Dansk ud fra de to valgmuligheder sprogdetektoren foreslår brugeren, kan man gemme forskellige 7 Google Translate, en service hvor man har mulighed for at oversætte tekst til 52 forskellige sprog til og fra, samt sprog detektion. Danmarks Tekniske Universitet Side 14 af 91
oplysninger omkring denne bruger på en række forskellige databaser. Disse oplysninger kunne være: - Landet som brugeren indtaster sproget fra, hvilket i dette tilfælde er Danmark. - Sproget som brugerens computer er indstillet til. - Sproget som brugerens browser er indstillet til. - Brugerens IP adresse, så man har mulighed for at følge efter denne bruger og evt. tjekke for denne IP adresses tidligere søgninger og valg af sprog. Disse ovenstående informationer kan herefter benyttes til punkt 3 s præsentationsmåde for det endelige resultat i en sprogdetektor. Dog er det selvfølgelig ikke ensbetydende med, at det udskrevne sprog er det sprog, som brugeren har indtastet eller ønsket, men denne løsning vil være den mest optimale efter punkt 1. Grunden til at punkt 1 er mere optimal end punkt 3, skyldes at det 1 punkt ikke kræver nær så meget analyse, beregning og eksisterende data fra selve brugeren eller en tilsvarende bruger. 5.1.2. Løsningsmodeller Der diskuteres her 2 mulige løsningsmodeller til en sprogdetektor, samt hvilke ulemper og fordele disse kan have. 5.1.2.1 Ordbog baseret (Model 1) Den nemmeste måde at lave en sprogdetektor vil være, at tage udgangspunkt i ordbøger og nærmest konvertere disse til elektroniske databaser. Altså hvis man f.eks. skal lave en database som skal understøtte 5 forskellige sprog, vil det kræve at man har 5 forskellige databaser, hvor indeholder alle eksisterende stam ord for hvert af de enkelte 5 sprog. Når dette så er opfyldt, har man mulighed for at sammenligne alle ord i de enkelte databaser med det som brugeren indtaster. Lad os antage at vores sprogdetektor understøtter disse 5 forskellige sprog: - Dansk - Fransk - Engelsk - Tysk - Spansk Det vil sige, at vi har 5 forskellige databaser, hvor den danske database indeholder alle danske stam ord, præcist som en fysisk ordbog. Danmarks Tekniske Universitet Side 15 af 91
Vi antager nu at brugeren indtaster følgende sætning: Hello min ven og at vores sprogdetektor skal angive, hvilket sprog brugeren har indtastet. Nu kan vi både analytisk og grafisk (Figur 4) gennemgå, hvordan sprogdetektoren vil forsøge, at angive et sprog: 1. Kigger på det første ord i sætningen, Hello. 2. Løber alle databaser igennem ved at søge efter et eller flere matchende ord i de eksisterende 5 databaser. 3. Søgning giver resultat, og viser sig at ordet Hello fremkommer en gang i den Engelske database. 4. Gemmer resultat fra punkt 3, og vender tilbage til punkt 1 blot med den forskel at der denne gang kigges på ordet, min. Det samme udføres herefter for det sidste ord i sætningen, ven. 5. Nu er der blevet søgt på alle ord og forskellige sprog er blevet fundet. Punkt 4 indeholder 3 forskellige resultater, som er: o Engelsk o Dansk o Dansk 6. Sprogdetektoren ser at Dansk optræder flest gange, derfor angives Dansk som det sprog brugeren har indtastet. Sprog detektor Sprog databaser Temp resultat Output Sender et ord navn på den db, ordet er fundet i returnere det sprog som optræder flest gange Figur 4: Sekvensdiagram for ordbog baseret sprog detektor. Løsningsmodellen på Figur 4 er yderst effektiv, men desværre meget utroværdig, da den rigtig mange gange enten ikke vil angive et sprog eller angive et forkert sprog. Nedenstående karakterer viser, hvor troværdig og god denne løsningsmodel er: Danmarks Tekniske Universitet Side 16 af 91
Model 1? Point (1-5) Er denne løsningsmodel reel til en sprogdetektor? NEJ 1 Kan denne løsningsmodel opfange alle ord i en sætning? NEJ 1 Er denne løsningsmodel hurtig til at angive det indtastede sprog? (I et succesfuldt scenarie) JA 3 Tabel 1 Denne løsningsmodel er desværre udelukkende for alle stam ord i de forskellige sprog, da der ikke tages hensyn for endelser på ordene. Hvis brugeren eksempelvis havde skrevet Hello mine venner, så ville denne løsningsmodel angive Engelsk, som det indtastede sprog, da ordene mine og venner ikke er stam ord, men kommer af stam ordene min og ven. Konklusionen er derfor at denne løsningsmodel ikke er en løsning for en velfungerende sprogdetektor. 5.1.2.2 Ordbog & endelser baseret (Model 2) En anden løsningsmodel til opbyggelse af en sprogdetektor kunne være en udvidelse af model 1. Således at man stadig har samme ordbogsdatabaser, som i model 1, dog med den forskel at man ved siden af disse databaser har yderligere en database, som indeholder endelser/bøjninger for de enkelte sprog. Det vil sige at man udbygger en separat database, som for eksempel indeholder følgende: endelseid endelser sprog 0 en da 1 et da 2 es da 3 er da 4 ede da Tabel 2 Denne separate database med endelser og bøjninger til alle eksisterende stam ord, vil give en sprogdetektor mulighed for at opfange flere ord end løsningsmodel 1. Dette kan beskrives ved blot at tage et eksempel, hvor brugeren for eksempel indtaster jeg arbejdede today. Vores sprogdetektor fra løsningsmodel 1, ville i dette eksempel kun opfange 2 ord, som ville være ordene; jeg & today. Dette betyder at sprogdetektoren fra model 1, ville give brugeren mulighed for enten at vælge, hvilket sprog der er indtastet eller også selv gætte sig frem til sproget, mens model 2 vil fortælle brugeren at sproget der er indtastet er Dansk. Danmarks Tekniske Universitet Side 17 af 91
Denne sprogdetektor aflæser nemlig brugerens indtastninger på en mere intelligent måde og hvis vi antager at brugeren har indtastet jeg arbejdede today, så kan vi gennemgå detektorens handlinger både analytisk og grafisk (Figur 5) trin for trin: 1. Kigger på det første ord i sætningen, jeg. 2. Løber alle databaser igennem ved at søge efter en eller flere matchende ord i de eksisterende 5 databaser. 3. Sprogdetektoren reagerer her anderledes, alt afhængig af det resultat som forrige punkt returnerer. A. Søgning giver resultat, og viser sig at ordet jeg fremkommer en gang i den Danske database. B. Søgningen giver ikke resultat, derfor forsøger sprogdetektoren nu at slette en endelse på ordet, på baggrund af de forskellige endelses databaser. Vi gennemgår nu denne proces med et eksempel, hvor ordet arbejdede undersøges: a) Ordet gennemløbes bagfra, for at se om det eksakt indeholder nogle af endelserne fra Tabel 2. b) Endelsen ede findes og ordet arbejdede forkortes således at endelsen ede slettes, og sprogdetektoren arbejder videre med ordet arbejd. c) Der søges nu efter arbejd i databaserne og det bliver fundet i den Danske database, som videresendes som resultatet til punkt 4. 4. Gemmer resultat fra punkt 3, og vender tilbage til punkt 1 blot med den forskel at der denne gang kigges på ordet arbejdede. Det samme udføres herefter for det sidste ord i sætningen, today. 5. Nu er der blevet søgt på alle ord og forskellige sprog er blevet fundet. Punkt 4 indeholder 3 forskellige resultater, som er: o Dansk o Dansk o Engelsk 6. Sprogdetektoren ser at Dansk optræder flest gange, derfor angives Dansk som det sprog brugeren har indtastet. Danmarks Tekniske Universitet Side 18 af 91
Figur 5: Sekvensdiagram for ordbog og endelser baseret sprog detektor. Løsningsmodellen på Figur 5 er mere effektiv end løsningsmodellen illustreret i Figur 4, men desværre kræves der mere i opbygning af denne model end tidligere model 1. Denne model vil udskrive et troværdigt resultat, hvis man formår at opbygge databaser med perfekte endelser/bøjninger indenfor alle sprog. Problemet ved denne model er dog at, hvis der mangler en eller flere endelser/bøjninger i databaserne, vil detektoren enten udelade at angive et sprog eller også vil den angive et forkert sprog. Nedenstående karakterer viser, hvor troværdig og god denne løsningsmodel er: Model 1? Point (1-5) Er denne løsningsmodel reel til en sprogdetektor? JA/NEJ 4 Kan denne løsningsmodel opfange alle ord i en sætning? NEJ 3 Er denne løsningsmodel hurtig til at angive det indtastede sprog? (I et succesfuldt scenarie) JA 3 Tabel 3 Denne løsningsmodel er mere avanceret end model 1, da den næsten kan benyttes for alle typer af ord. Detektoren kan nemlig opfange stam ord, som allerede er bøjet eller opskrevet med en endelse, og konvertere disse ord til stam ord. Der kan altså som nævnt i konklusionen for model 1, nævnes at sætningen Hello mine venner vil resultere i at, det anvendte sprog er Dansk. Sproget dansk vil blive valgt, da det op- Danmarks Tekniske Universitet Side 19 af 91
træder flest gange med ordene mine og venner. Disse to danske ord er allerede bøjet, men da vores sprogdetektor har mulighed for at nedskære ordene til stam ord, så vil denne sprogdetektor være succesfuld. Vi kan derfor konkludere at denne løsningsmodel er en udmærket løsning for en velfungerende sprogdetektor, dog med en relativ høj fejlprocent. 5.2. Databasen (MySQL) 5.2.1. Løsningsmodeller Der diskuteres her løsningsmodeller til databasen, samt hvilke ulemper og fordele disse kan have. 5.2.1.1 MySQL vs. MSSQL vs. PostgreSQL De to mest udbredte database platforme, indenfor web verdenen er uden tvivl MySQL og MSSQL, da de anvendes mest blandt web udviklerne. Begge database platforme har både fordele og ulemper, som vi vil prøve at opstille overfor hinanden og derved forklare, hvorfor Nuttot s database platform er, MySQL. Krav, funktion, scenarie MySQL MSSQL PostgreSQL Brugervenligt værktøj f.eks. som MySQL s phpmyadmin JA NEJ NEJ Stored procedures? JA JA JA Open Source JA NEJ JA Lærenem syntaks? JA NEJ NEJ Høj performance? * JA JA NEJ Nem integration? JA NEJ NEJ * Performance er et område som altid kan optimeres, men indenfor dette felt er det vigtigt at benytte den database platform, som er nemmest at optimere. Heraf gives der et JA svar for den database platform, som er nemmest at optimere og omvendt NEJ for den som kræver meget for at optimere. Tabel 4 Tabel 4 viser at MySQL overlegent er den store vinder overfor de to store konkurrenter, MSSQL og PostgreSQL. Vi har ikke valgt MSSQL da der kræves en licens for at benytte denne, men også fordi at vi ikke har noget erfaring indenfor MSSQL. PostgreSQL og MySQL var de to stærke database platforme, som der var mulighed for at vælge mellem, men valget blev dog MySQL da vi har mere erfaring med denne platform end PostgreSQL. Danmarks Tekniske Universitet Side 20 af 91
5.2.1.2 MyISAM vs. InnoDB MySQL giver flere muligheder indenfor valg af datatyper ved oprettelse af en tabel, og de to mest udbredte datatyper er uden tvivl: MyISAM og InnoDB. Begge datatyper har både fordele og ulemper, som vi vil prøve at opstille overfor hinanden og derved forklare, hvorfor der er valgt MyISAM datatypen. Krav, funktion, scenarie MyISAM InnoDB Gendanner hurtigt ved tab af data? NEJ JA Lås af tabel ved insert og updates? JA NEJ Høj performance? * JA JA Fuld tekst søgning? JA NEJ * Performance er et område som altid kan optimeres, men indenfor dette felt er det vigtigt at benytte den datatype, som er nemmest at optimere. Heraf gives der et JA svar for den datatype, som er nemmest at optimere og omvendt NEJ for den som kræver meget for at optimere. Tabel 5 Begge datatyper er meget anvendelige til Nuttot s database del, men alligevel vælger vi dog at anvende MyISAM, da denne datatype er hurtigere at operere med. Tabel 5 viser at begge datatyper yder høj performance, men dette er kun gældende for InnoDB, hvis man for eksempel har en stor tabel, som hele tiden skal opdateres. InnoDB giver nemlig brugeren mulighed for at opdatere flere rækker på samme tid i samme tabel, mens MyISAM låser en tabel, så snart der bliver skrevet til den. Men da vi ikke har krav på at kunne redigerer i flere rækker på samme tid, så har vi valgt at benytte MyISAM, da denne er hurtigere til at reagere på inserts, updates og deletes. 5.2.1.3 Auto Increment vs. Manuel Increment Alle database tabeller har som regel en primær unik id felt, som udelukkende indeholder det antal rækker man er nået op til. Der er to løsninger på at lagre dette unikke id nummer for hver gang en ny række indsættes i tabellen. Disse to løsninger er: 1. Auto Increment Når man har oprettet en tabel og skal til at opbygge strukturen i tabellen, ved at angive en række feltnavne, så har man mulighed for bl.a. at angive om et valgt feltnavn skal være en primær nøgle og om dette felt skal have egenskaben AUTO_INCREMENT aktiveret. Hvis man vælger at aktiverer dette, så vil dette felt værdi automatisk stige med tallet 1 for hver gang en række indsættes i tabellen. Dette tal vil altid starte med tallet 0 og forsætte til uendeligt, afhængig af hvilke andre begrænsninger man har givet tabellen. 2. Manuel Increment Danmarks Tekniske Universitet Side 21 af 91
Modsat auto increment, så har man mulighed for at gøre dette manuelt, hvilket dog kræver at man hele tiden ved hvilket nummer man er nået til inde i databasen, for at undgå ikke at indsætte det samme tal to gange i databasen. Afhængig af ens database design kan man komme ud for at være nød til at benytte manuel increment, men dette vil virkelig sløve ens database performance, da det vil kræve en masse læsninger og manuel inserts. Vi har valgt at vælge den første løsning med auto increment, da denne uden tvivl er den hurtigste og effektiveste løsning. 5.2.2. Nøgler Alle tabeller i Nuttot s database indeholder en række forskellige nøgler. De er to typer af nøgler i Nuttot s database som kaldes; Primær- og Fremmednøgler. Forskellen mellem disse to typer af nøgler kan forklares således: Primær (PK) 8 o Anvendes til unikt at identificerer hver række i en tabel o Kan bestå af flere kolonner, en såkaldt sammensat primærnøgle o Der stilles følgende krav til en primærnøgle Der må ikke være to rækker med den samme primærnøgle Alle data i primærnøglen skal være unikke Der må ikke forekomme tomme (null) 9 felter Fremmed (FK) 10 o Sikrer integriteten mellem tabeller o Kan referere til den samme tabel, som den selv er placeret i, hvilket kaldes Rekursivt hierarki. o Der stilles følgende krav til en fremmednøgle Skal referere til en primær- eller uniknøgle Fremmednøglens datatype skal være den samme som kolonnen med den primære eller unikke nøgle i reference tabellen Værdien skal enten kunne findes i reference tabellen eller være null. Nuttot s database gør benyttelse af begge former for nøgle, som kan ses nærmere under Design afsnittet. 8 Den engelske betegnelse for en primærnøgle er Primary Key, deraf kommer forkortelsen PK. 9 Null er den engelske betegnelse for et tomt felt i en MySQL tabel. 10 Den engelske betegnelse for en fremmednøgle er Foreign Key, derfor kommer forkortelsen FK. Danmarks Tekniske Universitet Side 22 af 91