MySQL är ett databassystem som hör till typen relationsdatabaser och lagrar dataenligt relationsdatamodellen och använder sig av frågespråket SQL. MySQL har flertalet datatyper och sedan version 5.7.8 finns datatypen JSON som kan användas för lagring av data med JSON-format. JSON är idag den ledande standarden för datautbyte för webbapplikationer. Ett experiment genomförs där datatyperna JSON, BLOB och TEXT testas i MySQL. Detta för att ta reda på vilken datatyp som är att föredra med avseende på svarstid vid hämtning och uppdatering av specifika värden i lagrad JSON-data. En miljö sätts upp för att genomföra en pilotstudie följt av ett antal tester för att påvisa detta. Resultatet visar på att datatyperna BLOB och TEXT presterar snabbare svarstid än JSON förutom i de fall då specifika funktioneranpassade för datatypen i MySQL används.

Relationsmodellen kom 1970 och är i våra dagar generellt accepterad som ett landmärke. Databasen lagrar sin data i form av tabeller och har ett välbeprövat sätt att lagra information på. Första generationens objektorienterade databaser kom 1986. Det som är kännetecknande för en objektorienterad databas är att data sparas i form av objekt i databasen. Vi vill med vår uppsats testa om användandet av Versant minskar relationsdatabasens nackdelar och därmed är ett bättre val till typ av databas. I objektorienterade databaser är det möjligt att spara komplexa datatyper, som t.ex. bilder. I våra tester framgår det att vid användandet av Versant minskar relationsdatabasens nackdelar. Fyra av sju tester visar att Versant skulle kunna vara bättre alternativ pga. att relationsdatabasens nackdelar minskar. De nackdelar som Versant inte löste var begränsade operationer, integritet och användardefinierade regler och rekursiva frågor. I slutsatsen analyserar vi vår hypotes, ”Om man använder den objektorienterade databasen Versant minskas antalet nackdelar som en relationsdatabas har” och ser om den stämmer. Vi kan inte utifrån testerna och slutsatsen utgå ifrån att hypotesen gäller alla objektorienterade databaser eller datamodeller* i ”verkliga” livet. Testerna gjordes utifrån ett tänkt fall på en högskola med studenter, kurser, institutioner och personal. Vi kom i våra tester fram till att fyra av sju av relationsdatabasens nackdelar avlägsnades vid användandet av Versant. Detta gäller vår datamodell över ett uppdiktat fall på en högskola och med reservation för att vi inte har utnyttjat Versant på ett optimalt sätt.

I detta arbete undersöks det hur en NoSQL-databas presterar jämfört med en relationsdatabas när kommunikation sker med en webbapplikation. Testning sker med hjälp av en PHP-applikation och Ajax för att simulera användningen av en webbapplikation. Den data som kommer lagras i databaserna kommer vara strukturerad och databaserna kommer vara på ett odistribuerat system. Metoden är teknikorienterade experiment men för framtida arbeten kan dessa tester utföras som en fallstudie för att ytterligare simulera en skarp användning av en webbapplikation.I detta arbete förklaras anledningen till framtagningen av NoSQL-databaser. Saker som diskussionen om att NoSQL kommer ta över platsen som de mest använda databaserna från relationsdatabaser tas också upp. Förhoppningsvis kan detta arbete ge viss insikt till den diskussionen.Resultatet av detta arbete visar att NoSQL kan passa bra för databaser som har en last som ärskriv- och uppdateringstung, men också att relationsdatabaser fortfarande passar bra i många fall.

Undersökningen jämför databashanterarna MySQL och MongoDB svarstid vid hämtning av data i en webbapplikation. Denna jämförelse mellan databashanterarna kommer att avgöra vilken av dessa databaser som har en kortare svarstid för att hämta Kronofogdens data. Längden på svarstiden hos webbapplikationer är väsentlig eftersom den påverkar användarens nöjdhet. En webbapplikation har utvecklats i denna undersökning, för att presentera Kronofogdens data och detta genomfördes med hjälp av chart.js JavaScript biblioteket. Ett testskript utvecklades för att mäta den tid det tar att skicka en begäran till databasen och visa den hämtade datan. I denna undersökning genomfördes totalt fem tester för MySQL och MongoDB. Slutsatsen som drogs är att MySQL har den snabbaste hämtningstiden på alla tester. Framtida arbete kan bland annat öka mängden data från megabyte till gigabyte, samt att använda olika webbläsare vid mätningen för att se om resultaten varierar.

<p>Det blir allt mer vanligt förekommande att utvecklingen av applikationer sker enligt objektorienterade metoder, ofta som komponentbaserade applikationer. Samtidigt är användandet av traditionella relationsdatabaser fortfarande mycket utbrett. En kombination av komponentbaserad applikation och traditionell relationsdatabas har idag blivit vanlig. Här beskrivs en designstruktur som visar hur beteendet, vilket inte kan lagras i relationsdatabasen, bör tas om hand för att möjliggöra delad åtkomst samt återanvändning av programkoden. Beteendet implementeras som applikationens programkod i form av regler, beräkningar och operationer. Det har tagits i beaktning både hur uppdelningen av olika typer av beteende kan göras och var i systemet det bör implementeras, för att uppnå en generell lösning. För att underlätta framtagandet av applikationer med den framtagna designstrukturen, beskrivs de olika arbetsmoment som ingår. I lösningen används ett mellanlager med transaktionshanterare samt resurshanterare. Resultatet visar att designstrukturen fungerar för alla möjliga grundläggande konstruktioner som används i den beskrivna tekniken.</p>

Det blir allt mer vanligt förekommande att utvecklingen av applikationer sker enligt objektorienterade metoder, ofta som komponentbaserade applikationer. Samtidigt är användandet av traditionella relationsdatabaser fortfarande mycket utbrett. En kombination av komponentbaserad applikation och traditionell relationsdatabas har idag blivit vanlig. Här beskrivs en designstruktur som visar hur beteendet, vilket inte kan lagras i relationsdatabasen, bör tas om hand för att möjliggöra delad åtkomst samt återanvändning av programkoden. Beteendet implementeras som applikationens programkod i form av regler, beräkningar och operationer. Det har tagits i beaktning både hur uppdelningen av olika typer av beteende kan göras och var i systemet det bör implementeras, för att uppnå en generell lösning. För att underlätta framtagandet av applikationer med den framtagna designstrukturen, beskrivs de olika arbetsmoment som ingår. I lösningen används ett mellanlager med transaktionshanterare samt resurshanterare. Resultatet visar att designstrukturen fungerar för alla möjliga grundläggande konstruktioner som används i den beskrivna tekniken.

Semantiska webben är ett begrepp som handlar om att göra data tillgängligt på ett sätt som gör att datorer kan söka, tolka och sätta data i ett sammanhang. Då mycket av datalagring idag sker i relationsdatabaser behövs nya sätt att omvandla och lagra data för att det ska vara tillgängligt för den semantiska webben.Forskning som genomförts har visat att transformering av data från relationsdatabaser till RDF som är det format som gör data sökbart på semantiska webben är möjlig men det finns idag ingen standardisering för hur detta ska ske.För att data som transformeras ska få rätt betydelse i RDF så krävs ontologier som beskriver olika begrepps relationer. Nationella vägdatabasen (NVDB) är en relationsdatabas som hantera geospatiala data som används i olika geografiska informationssystem (GIS). För samarbetspartnern Triona var det intressant att beskriva hur denna typ av data kan omvandlas för att passa den semantiska webben.Syftet var att analysera hur man överför geospatiala data från en relationsdatabas till den semantiska webben. Målet med studien var att skapa en modell för hur man överför geospatiala data till i en relationsdatabas till en RDF-lagring och hur man skapar en ontologi som passar för NVDB’s data och datastruktur.En fallstudie genomfördes med dokumentstudier utifrån en inledande litteraturstudie.En ontologi skapades för det specifika fallet och utifrån detta skapades en modell för hur man överför geospatiala data från NVDB till RDF via programvaran TripleGeo. Analysen har skett genom att transformerad data har analyserats med hjälp av befintlig teori om RDF och dess struktur och sedan jämföra och se så att data får rätt betydelse. Resultatet har också validerats genom att använda W3C’s tjänst för att validera RDF.Resultatet visar hur man transformerar data från en relationsdatabas med geospatiala data till RDF samt hur en ontologi för detta skapats. Resultatet visar också en modell som beskriver hur detta utförs och kan ses som ett försök till att generalisera och standardisera en metod för att överföra geospatiala data till RDF. / Semantiska webben är ett begrepp som handlar om att göra data tillgängligt på ett sätt som gör att datorer kan söka, tolka och sätta data i ett sammanhang. Då mycket av datalagring idag sker i relationsdatabaser behövs nya sätt att omvandla och lagra data för att det ska vara tillgängligt för den semantiska webben.Forskning som genomförts har visat att transformering av data från relationsdatabaser till RDF som är det format som gör data sökbart på semantiska webben är möjlig men det finns idag ingen standardisering för hur detta ska ske.För att data som transformeras ska få rätt betydelse i RDF så krävs ontologier som beskriver olika begrepps relationer. Nationella vägdatabasen (NVDB) är en relationsdatabas som hantera geospatiala data som används i olika geografiska informationssystem (GIS). För samarbetspartnern Triona var det intressant att beskriva hur denna typ av data kan omvandlas för att passa den semantiska webben.Syftet var att analysera hur man överför geospatiala data från en relationsdatabas till den semantiska webben. Målet med studien var att skapa en modell för hur man överför geospatiala data till i en relationsdatabas till en RDF-lagring och hur man skapar en ontologi som passar för NVDB’s data och datastruktur.En fallstudie genomfördes med dokumentstudier utifrån en inledande litteraturstudie.En ontologi skapades för det specifika fallet och utifrån detta skapades en modell för hur man överför geospatiala data från NVDB till RDF via programvaran TripleGeo. Analysen har skett genom att transformerad data har analyserats med hjälp av befintlig teori om RDF och dess struktur och sedan jämföra och se så att data får rätt betydelse. Resultatet har också validerats genom att använda W3C’s tjänst för att validera RDF.Resultatet visar hur man transformerar data från en relationsdatabas med geospatiala data till RDF samt hur en ontologi för detta skapats. Resultatet visar också en modell som beskriver hur detta utförs och kan ses som ett försök till att generalisera och standardisera en metod för att överföra geospatiala data till RDF.

Syftet med denna studie är att undersöka vilken av databaserna MySQL och MongoDB som utför hämtning av fordonsrelaterade skulder data på kortaste tiden. För att undersöka prestanda gällande hämtningstiden utvecklades en webbapplikation som visualiserar datan i form av diagram med hjälp av Javascript biblioteket Chart.js. Experimentet genomfördes fem gånger med olika mängder data och mätningspunkter för att se hur det kan påverka svarstiden hos databasen. Resultaten visade att MySQL var snabbare än MongoDB oavsett datamängden eller mätningspunkter. Framtida arbete kan bland annat hämta data slumpmässigt från databaserna och öka mängden data till en stor del samt användning av olika webbläsare för att undvika bias i studien.

Syftet med denna studie var att klargöra hur användarvänligheten ser ut för NoSQL- respektive Relationsdatabaser samt hur arbetseffektiviteten kan påverkas av dessa datamodeller. Denna problematik har belysts med forskningsfrågan ”Hur skiljer sig användarvänligheten mellan NoSQL-databaser och Relationsdatabaser, och vad fås för inverkan på arbetseffektiviteten vid en blandad användning av de två datamodellerna?” samt underfrågan ”Hur påverkar respektive datamodells användarvänlighet arbetseffektiviteten?”. En teoretisk grund inom problemområdet upprättades med hjälp av olika typer av litterära medel. Genom individuella intervjuer med totalt elva uppgiftslämnare samlades sedan datamaterial in, som transkriberades och analyserades genom kombinering av kategorier. Studiens resultat visade att de främsta dragen hos Relationsdatabasers användarvänlighet är att de är standardiserade sett till tillägg och dokumentation samt naturliga för sitt syfte. NoSQL-databaser har sina främsta drag inom användarvänlighet i en lättförståelig datastruktur, flexibilitet vid hantering av data samt snabba svar och korta väntetider vid frågeställningar. Generellt upplevdes Relationsdatabaser ha en högre användarvänlighet än NoSQL-databaser. Vidare pekade resultaten på att en negativ inverkan på arbetseffektiviteten är mest trolig vid en blandad användning de två datamodellerna. Detta beror främst på att det blir mer tidsresurser på inlärning och flera olika system att administrera. Sannolikheten att ingen utmärkande inverkan skulle ske är mindre, men det sprungar i fåtal fall ur att modifierbarhet och kompabilitet inte är vanliga moment i arbetet. Minst troligt är en positiv inverkan, som i sina fall grundar sig i att flera datamodeller ger en bredare modifierbarhet. Likaså nåddes resultatet att arbetseffektiviteten kan få en positiv inverkan av Relationsdatabasers användarvänlighet i avseendet kompabilitet, och av NoSQL-databasers användarvänlighet i avseendet modifierbarhet. På en övergripande nivå kan Relationsdatabasers användarvänlighet ha en större positiv inverkan på arbetseffektiviteten än NoSQL-databasers.

B-SPORT+ är ett projekt som var intresserat av att utveckla en applikation för tips och vägledning inom fysisk träning anpassad till personer med funktionsnedsättningar. B-SPORT+ identifieradebehovet av en decentraliserad ledger i applikationen. En ledger innebär en digital huvudbok som lagrar data över transaktioner utförda i en applikation. I ett tidigare arbete lyftes Blockkedja fram som en möjlig lösning för applikationen. B-SPORT+ upplevde dock att denna teknik innehöll nackdelar som hög energiförbrukning och dyr implementation. Därför skulle detta arbete undersöka,utveckla och utvärdera ett alternativ till Blockkedja med hjälp av relationsdatabaser. Resultatet blev två prototyper. Den första prototypen efterliknade Blockkedja-teknik genom att horisontellt fragmentera en relationsdatabas som innehöll en tabell för utförda transaktioner. Sedan användes hasning för att validera transaktioner mellan databas fragment. Det utvecklades även en prototyp med hjälp av Blockkedja-teknik, denna prototyp användes för att utvärdera den första prototypen. Utvärderingen visade att SQL-prototypens struktur minskade minnesutnyttjandet i användardatorer samt minskade den transaktioners energikonsumtionen och tid. Denna struktur tillät även moderering utav data i ledgern vilket var vitalt för den applikation B-SPORT+ ville utveckla / B-SPORT+ is a project that was interested in developing an application for advice and guidance in regards to physical exercise adapted for people with disabilities. B-SPORT+ identified the need for a decentralized ledger in the application. A decentralized ledger is a register that stores data on transactions performed in an application. In previous work on the application, a Blockchain was highlighted as a possible solution. However, B-SPORT+ experienced that this technology contained disadvantages such as high energy consumption and expensive implementation. Therefore, this work investigated, developed and evaluated an alternative to Blockchain using relational databases. The result was two prototypes. The first prototype mimicked Blockchain technology by horizontally fragmenting a relational database that stored a table of performed transactions. Then, cryptographic hashing was used to validate transactions between database fragments. A prototype was also developed using Blockchain technology, this prototype was used to evaluate the first prototype. The evaluation showed that the structure of the SQL prototype reduced memory utilization in user computers it also reduced energy consumption and time when performing transactions. This structure also allowed moderation of data in the ledger, which was vital for the application BSPORT + wanted to develop.