Data används i stora mängder i dagens samhälle. Sjukvården är inget undantag och i den branschen kan analyser av data rädda liv eller uppfinna läkemedel. För att kunna bruka data i modern tid måste ett databassystem användas. Att välja rätt databassystem kan vara svårt och kräver att man vet varför man väljer den ena över den andra. Här jämförs två databaser för att generera data på om det skilljer sig mellan operationstiderna hos en relationsdatabas och en dokumentbaserad databas. Studien har valt att göra ett tekniskt experiment där MySQL brukas som relationsdatabas medans MongoDB används som dokumentbaserad databas. Node.js används som ramverk för att skapa applikationer där testning sker. Data är hämtad från U.S. Department of Health &amp; Human Services (2023) och representerar sjukvårdsdata från COVID. Operationstyperna INSERT och SELECT är de två som undersöks i denna studien. Resultatet bevisar att båda de framlagda hypoteserna stämmer. MongoDB var i båda testerna mer effektiv och producerade lägre operationstider för INSERT och SELECT. / <p>Stavningskorrigerad titel: MySQL och MongoDB operationer med Node.js som ramverk</p>

Higher demands on database systems have lead to an increased popularity of certain database system types in some niche areas. One such niche area is graph networks, such as social networks or logistics networks. An analysis made on such networks often focus on complex relational patterns that sometimes can not be solved efficiently by traditional relational databases, which has lead to the infusion of some specialized non-relational database systems. Some of the database systems that have seen a surge in popularity in this area are graph database systems. This thesis presents a prototype of a logistics network-related service using a graph database management system called Neo4j, which currently is the most popular graph database management system in use. The logistics network covered by the service is based on existing data from PostNord, Sweden’s biggest provider of logistics solutions, and primarily focuses on customer support and business to business. By creating a prototype of the service this thesis strives to indicate some of the positive and negative aspects of a graph database system, as well as give an indication of how a service using a graph database system could be created. The results indicate that Neo4j is very intuitive and easy to use, which would make it optimal for prototyping and smaller systems, but due to the used evaluation method more research in this area would need to be carried out in order to confirm these conclusions. / Högre krav på databassystem har lett till en ökad popularitet för vissa databassystemstyper i några nischområden. Ett sådant nischområde är grafnätverk, såsomsociala nätverk eller logistiknätverk. Analyser på grafnätverk fokuserar ofta påkomplexa relationsmönster som ibland inte kan lösas effektivt av traditionella relationsdatabassystem, vilket har lett till att vissa specialiserade icke-relationella databassystem har blivit populära alternativ. Många av de populära databassystemen inom detta område är grafdatabassystem. Detta arbete presenterar en prototyp av en logistiknätverksrelaterad tjänst som använder sig av ett grafdatabashanteringssystem som heter Neo4j, vilket är det mest använda grafdatabashanteringssystemet. Logistiknätverket som täcks av tjänsten är baserad på existerande data från PostNord, Sveriges ledande leverantör av logistiklösningar, och fokuserar primärt på kundsupport och företagsrelaterad analys. Genom att skapa en prototyp av tjänsten strävar detta arbete efter att uppvisa vissa av de positiva och negativa aspekterna av ett grafdatabashanteringssystem samt att visa hur en tjänst kan skapas genom att använda ett grafdatabashanteringssystem. Resultaten indikerar att Neo4j är väldigt intuitivt och lättanvänt, vilket skulle göra den optimal för prototyping och mindre system, men på grund av den använda evalueringsmetoden så behöver mer forskning inom detta område utföras innan dessa slutsatser kan bekräftas.

I denna rapport undersöks olika system för hanteringen av forskning och utvecklingsprojekt som Stockholms stad kan använda som en gemensam plattform med syfte att sprida information och kunskap gällande projekt. Målet med rapporten var att hitta en anpassad kravspecifikation som summerade de tre kontorens gemensamma arbetsprocesser. Kravspecifikationen var ett hjälpmedel för att finna och utvärdera olika system som främjar hanteringen av Stockholms stads forskning och utvecklingsprojekt. En kravspecifikation har tagits fram i syfte att informera Stockholms stad om hur ett generellt arbetssätt ser ut bland de olika forskning och utvecklingskontoren. Genom informationsspridning internt pa kontoren kan effektiviteten öka då målkonikter kan undvikas och ett samarbete kan leda till ett bättre resultat. Att lagra informationen kopplade till ett projekt i en relationsdatabas visade sig passa kontoren bäst och skulle kunna möjliggöra vidare anpassning. Ytterligare en aspekt med systemen som utvärderades i rapporten var att de skulle kunna förbättra Stockholms stads kunskapsöverföring. Det kan medföra att innovativa och hållbara ideer sprids i större utsträckning än med kontorens nuvarande hantering av forskning- och utvecklingsprojekt. Resultatet av rapporten var två rekommendationer som togs fram utifrån utvärderingen av de utvalda systemen. Den kortsiktiga lösningen var att använda Excel med delad arbetsbok och den långsiktiga lösningen var att använda SharePoint Server som en gemensam kommunikationsplattform. / The purpose of this report is to find and evaluate different systems that can be used as a central platform for publishing information and knowledge about Stockholms stad's various projects spanning several agencies. The goal of this report was to present a requirement specification which summarize the three chosen agencies common work pattern. The requirement specification was used to find and evaluate the different systems that improves Stockholm's stads management of research and development projects. A requirement specification has been defined to help Stockholms stad to acknowledge a common work pattern for the three agencies presentation of project information. By increasing the dissemination of information internally, the efficiency will increase when goal conflicts are avoided and a formal cooperation can lead to better work results. A relational database was proven to be the best option for the agencies and could allow further development and adjustments to the agencies. One advantage with the systems evaluated in this report is that they could help Stockholms stad's transferal of knowledge. This could result in a wider spread of innovative and sustainable ideas than Stockholms stad's current system for managing research and development projects. The final recommendation from the evaluation of the selected systems gave Stockholms stad two possible solutions. The short-term solution was to use Excel with a shared workbook and the long-term solution was to use SharePoint Server as a common platform for communication.

Denna uppsats mäter och jämför prestanda mellan en objektorienterad databas och en relationsdatabas. Uppsatsen bygger på en utredande karaktär utifrån vår hypotes och vårt intresse att testa den.Hypotesen bygger på problematiken omkring mängden kod utvecklaren måste skriva för att kunna koppla ihop applikation med databas. En större mängd skriven kod som utvecklaren måste skriva borde göra att prestanda och svarstider blir långsammare. Därför ville vi undersöka om verktyg som medför en mindre mängd skriven kod kan förbättra prestandan och ge snabbare svarstider. Vi valde att testa vår hypotes mellan ADO. NET relationsdatabas och ADO. NET Entity Framework objektorienterade databas då ADO. NET genererar större mängd kod och Entity Framework innehåller verktyg som i sin tur genererar mindre mängd kod. För att kunna mäta och jämföra prestandan utvecklades en mindre kundapplikation kopplad med respektive ramverks databasmodell där båda använder sig av samma databas. Genom att mäta prestandan har vi kunnat jämföra de olika modellerna och då även kunnat se vilka fördelar och nackdelar respektive modell genererat. Vi har även mätt antal kodrader och diskuterat hur det påverkar kostnaden av systemutvecklingen samt underhållbarheten för applikationen. Det som framförallt framkom var att relationsdatabasen resulterade i en något snabbare prestanda mätt i millisekunder trots att antal kodrader blev fler jämfört med en objektorienterad databas. Den objektorienterade databasen resulterade i något sämre prestanda men med färre antal skrivna kodrader. Det medför att den kräver mindre underhåll i koden vid förvaltning av den nya applikationen. Det innebär även att tiden vid utveckling för den vane programmeraren minskar med cirka 50 % och därmed sjunker även utvecklingskostnaden, under förutsättning att en något långsammare prestanda kan accepteras.

Traditional relational databases store data in tabular form and have existed for several decades. The new requirements for data such as high availability and scalability have led to an increase in NoSQL databases in popularity. NoSQL databases meet these requirements as they use other methods for handling and storing data, for example document databases and graph databases are two of these variants. This study examined the difference in performance between the SQL Server 19 relational database and the Neo4j graph database. An experiment with the hypothesis: "Graph databases have faster response times compared to relational databases when retrieving the shortest route between two specified locations" was performed by executing a function on a dataset provided by the study's partner the Swedish Transport Administration. The data set represents Sweden's railway network and consists of 1320 places and 2788 associated connections. The function searched for the shortest route between two locations for four selected sections in each database architecture. The observed and analyzed response times show that Neo4j has an average response time that is 50 times faster than SQL Server 19, which verifies the hypothesis. The response times from the two databases were also tested with a Wilcoxon test which showed that the median response times differ from each other at a 1 % significance level. In addition, the results show that the average response time for SQL Server 19 will increase more than Neo4j as more sites and connections become involved in the search. Relational databases have slower response times than graph databases as they use join statements to find current relationships between its tables, which means that they must search all the data to find the shortest path between two places. Unlike relational databases, graph databases only use relationships directly connected to the current node where the algorithm is located, which means that response times are shorter. / Traditionella relationsdatabaser lagrar data i tabellform och har existerat i flera årtionden. De nya kraven på data som hög tillgänglighet samt skalbarhet har gjort att NoSQL databaser ökat i popularitet. NoSQL databaser tillgodoser dessa krav då de använder andra sätt för hantering och lagring av data, exempelvis är dokument-databaser samt grafdatabaser två av dessa varianter. I denna studie undersöktes skillnaden i prestanda mellan relationsdatabasen SQL Server 19 och grafdatabasen Neo4j. Ett experiment med hypotesen: “Grafdatabaser har snabbare svarstider i jämförelse mot relationsdatabaser vid hämtning av kortaste vägen mellan två angivna platser” genomfördes genom att exekvera en funktion på ett dataset som tillhandahållits av studiens samarbetspartner Trafikverket. Datasetet representerar Sveriges järnvägsnätverk och består av 1320 platser och 2788 tillhörande förbindelser. Funktionen sökte efter den kortaste vägen mellan två platser för fyra utvalda sträckor i varje databasarkitektur. De observerade och analyserade svarstiderna visar att Neo4j har en genomsnittlig svarstid som är 50gånger snabbare än SQL Server 19 vilket verifierar hypotesen. Svarstiderna från de två databaserna testades även med ett Wilcoxon-test som visade att svarstidernas median skiljer sig från varandra påen 1 % signifikansnivå. Därtill visar resultatet att den genomsnittliga svarstiden för SQL Server 19 kommer att öka mer än Neo4j då fler platser och förbindelser blir involverade i sökningen. Relationsdatabaser har långsammare svarstider än grafdatabaser då de använder join-satser för att hitta aktuella relationer mellan dess tabeller vilket gör att de måste söka igenom all data för att hitta kortaste vägen mellan två platser. Till skillnad från relationsdatabaser använder grafdatabaser endast relationer direkt anslutna till den nuvarande noden där algoritmen befinner sig vilket gör att svarstiderna blir mindre.

Två grundläggande paradigm inom datavetenskap är objektorienterad programmering och relationsdatabasteknik. En kombinering av applikationer gjorda i ett objektorienterat programmeringsspråk med den beständighet och funktionalitet som ges av relationsdatabaser är en möjlig vidareutveckling av ens kunskaper inom dessa områden. Kombinationen av dessa båda förutnämnda paradigm innebär åtminstone ett problem som uppkommer då en relationsdatabas lagrar data i tabeller och en objektorienterad applikation lagrar data i objekt. Detta problem kallas objekt/relations paradigmens missanpassning. På grund av detta problem så måste kopplingen mellan paradigmen skötas av ett ramverk av något slag. I vår rapport så undersöker vi två av de ramverk som behandlar kopplingen mellan paradigmen. Specifikt i våran studie kommer vi att fokusera på kvalitetsattributet användbarhet. De ramverk som vi undersöker heter Java Database Connectivity (JDBC) och Hibernate. Båda dessa verktyg är skapade för det objektorienterade programmeringsspråket Java. / Two of the fundamental paradigms within computer science are object oriented programming and relational databases. A combination of an object oriented application with the persistence and functionality provided by relational databases is a further development of one’s knowledge within these areas. The combination of the two aforementioned paradigms will yield at least one problem, which occurs because in a database data is stored in tables whereas an object oriented application stores data in objects. This problem is called the object/relational paradigm mismatch. Because of this problem the connection between the paradigms must be handled by some kind of framework. In our report we investigate two of the frameworks which handle the connection between the paradigms. Specifically in our study we will focus on the quality attribute usability of the two frameworks and conduct a comparison between these two. The frameworks we investigate are called Java Database Connectivity (JDBC) and Hibernate. Both of these tools are created for the object oriented programming language Java.

Indoor Positioning System (IPS) are becoming more common in many areas such as retail, warehouses, smart facilities, and manufacturing.In recent years, Bluetooth Low Energy (BLE)-based IPS has become increasingly popular due to its low cost and low energy consumption. One of the more recent updates, Bluetooth 5.1, provides the ability to compute the location using Angle of Arrival (AoA) or Angle of Departure (AoD). These new features have allowed for better positioning accuracies, where AoA-based positioning has shown sub-meter accuracy. An application area for BLE-based IPS is retail stores where the technology can benefit both the store and its customers. This thesis investigates how to populate a database to be used with an IPS in a real-life store. The assumption is that customers will have BLE equipped devices and run an application that will send the properly formatted BLE advertisements, such that an BLE IPS can locate the user in the store. Additionally, we assume that the application can use the device's e-compass or other means to determine in which direction the user's device is oriented. Based on the position and orientation of the user, the software is assumed to access a database to know what item(s) are near the customer. However, the question remains of how did this data get into the database? This degree project explores this in detail and assesses the amount of time and effort needed to populate this database and the amount of time and effort needed to keep this database up to date. This project followed an iterative Design Science Research (DSR) methodology where the artifact is the database. A relational database was used as they are widely used and joins can easily be performed and it is easy to modify existing tables. The application was developed in Spring Boot and React. Amazon Web Services (AWS) was used to host and provide the necessary services for the database and application. The result showed that the estimated time needed to populate the database in a supermarket with a sales area of 5300 m2, 36623 products, and 220 containers is 106.64 hours and 107.13 hours in the worst case assuming a walking speed of 1.4 m s-1. Updating a product would take 10.34 s and 10.37 s if the time it takes for a staff member to walk to the place where the product is located is excluded. / Inomhuspositioneringssystem (IPS) har blivit allt vanligare inom många områden. De senaste åren har Bluetooth Low Energy (BLE)-baserad inomhuspositionering blivit mer populärt på grund av egenskaper som låg kostnad och låg energikonsumption. En av de senaste versionerna; Bluetooth 5.1 kan beräkna positionen med hjälp av ankomstvinkeln (eng. Angle of Arrival (AoA)) och utgångsvinkeln (eng. Angle of Departure (AoD)). Angle of Arrival (AoA)-baserad positionering kan uppnå en noggrannhet under 1 m. Ett Bluetooth Low Energy (BLE)-baserat IPS kan tillämpas i butiker där det kan gynna både butikens medarbetare och dess kunder. Detta examensarbete kommer att undersöka hur en databas som ska användas med ett IPS i en butik kan populeras. Antagandet i detta projekt är att kunderna kommer ha BLE utrustade enheter som kör ett program som tillåter att användaren kan lokalisera sig i butiken. Dessutom antar vi att applikationen kan använda enhetens e-kompass eller annan hårdvara för att kunna avgöra i vilken riktning användarens enhet är orienterad. Baserat på användarens position och riktning, antas det att mjukvaran kan komma åt databasen och veta vilka produkter som ligger i närheten av kunden. Dock kvarstår frågan: Hur sparades denna data i databasen? Det här examensarbetet kommer alltså att undersöka hur en databas i en butik kan vara uppbyggd om vi utgår från antagandet att BLE är tillämpat i butiken. Vi kommer även bedöma hur mycket tid som krävs för att populera en databas och hålla denna databas uppdaterad. Ett iterativ arbetsätt tillämpades i examensarbetet. I projektet användes en relationsdatabas eftersom det är enkelt att utföra join-operationer och uppdatera tabbeller i databasen. Applikationen som skapades tillhandahåller funktioner för att spara, uppdatera, radera och söka produkter i databasen. Frontend var kodad i React och backend var kodad i Spring Boot. Amazon Web Services (AWS) molntjänser och deras verktyg användes för att köra applikationen och databasen. Resultatet visade att populera en databas med produkter i en mataffär med en säljyta på 5300 m2, 36623 produkter, och 220 behållare (hyllor, kylskåp, etc.) tog 106.64 timmar i bästa fall och 107.13 timmar i värsta fall om vi antar en gångfart i 1.4 m s-1.