Databases are all around us, and ensuring their efficiency is of great importance. Database optimisation has many parts and many methods, two of these parts are database tuning and database optimisation. These can then further be split into methods such as indexing. These indexing techniques have been studied and compared between Database Management Systems (DBMSs) to see how much they can improve the execution time for queries. And many guides have been written on how to implement query optimisation and indexes. In this thesis, the question "How does indexing and query optimisation affect response time in PostgreSQL?" is posed, and was answered by investigating these previous studies and theory to find different optimisation techniques and compare them to each other. The purpose of this research was to provide more information about how optimisation techniques can be implemented and map out when what method should be used. This was partly done to provide learning material for students, but also people who are starting to learn PostgreSQL. This was done through a literature study, and an experiment performed on a database with different table sizes to see how the optimisation scales to larger systems. What was found was that there are many use cases to optimisation that mainly depend on the query performed and the type of data. From both the literature study and the experiment, the main take-away points are that indexes can vastly improve performance, but if used incorrectly can also slow it. The main use cases for indexes are for short queries and also for queries using spatio-temporal data - although spatio-temporal data should be researched more. Using the DBMS optimiser did not show any difference in execution time for queries, while correctly implemented query tuning techniques also vastly improved execution time. The main use cases for query tuning are for long queries and nested queries. Although, most systems benefit from some sort of query tuning, as it does not have to cost much in terms of memory or CPU cycles, in comparison to how indexes add additional overhead and need some memory. Implementing proper optimisation techniques could improve both costs, and help with environmental sustainability by more effectively utilising resources. / Databaser finns överallt omkring oss, och att ha effektiva databaser är mycket viktigt. Databasoptimering har många olika delar, varav två av dem är databasjustering och SQL optimering. Dessa två delar kan även delas upp i flera metoder, så som indexering. Indexeringsmetoder har studerats tidigare, och även jämförts mellan DBMS (Database Management System), för att se hur mycket ett index kan förbättra prestanda. Det har även skrivits många böcker om hur man kan implementera index och SQL optimering. I denna kandidatuppsats ställs frågan "Hur påverkar indexering och SQL optimering prestanda i PostgreSQL?". Detta besvaras genom att undersöka tidigare experiment och böcker, för att hitta olika optimeringstekniker och jämföra dem med varandra. Syftet med detta arbete var att implementera och kartlägga var och när dessa metoder kan användas, för att hjälpa studenter och folk som vill lära sig om PostgreSQL. Detta gjordes genom att utföra en litteraturstudie och ett experiment på en databas med olika tabell storlekar, för att kunna se hur dessa metoder skalas till större system. Resultatet visar att det finns många olika användingsområden för optimering, som beror på SQL-frågor och datatypen i databasen. Från både litteraturstudien och experimentet visade resultatet att indexering kan förbättra prestanda till olika grader, i vissa fall väldigt mycket. Men om de implementeras fel kan prestandan bli värre. De huvudsakliga användingsområdena för indexering är för korta SQL-frågor och för databaser som använder tid- och rum-data - dock bör tid- och rum-data undersökas mer. Att använda databassystemets optimerare visade ingen förbättring eller försämring, medan en korrekt omskrivning av en SQL fråga kunde förbättra prestandan mycket. The huvudsakliga användingsområdet för omskriving av SQL-frågor är för långa SQL-frågor och för nestlade SQL-frågor. Dock så kan många system ha nytta av att skriva om SQL-frågor för prestanda, eftersom att det kan kosta väldigt lite när det kommer till minne och CPU. Till skillnad från indexering som behöver mer minne och skapar så-kallad överhead". Att implementera optimeringstekniker kan förbättra både driftkostnad och hjälpa med hållbarhetsutveckling, genom att mer effektivt använda resuser.

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.

La France connaît un vieillissement de sa population sans précédent. La part des séniors s’accroît et notre société se doit de repenser son organisation pour tenir compte de ce changement et mieux connaître cette population.De nombreuses cohortes de personnes âgées existent déjà à travers le monde dont quatre en France et, bien que la part de cette population vivant dans des structures d’hébergement collectif (EHPAD, cliniques de soins de suite) augmente, la connaissance de ces seniors reste lacunaire.Aujourd’hui les groupes privés de maisons de retraite et d’établissements sanitaires comme Korian ou Orpéa s’équipent de grandes bases de données relationnelles permettant d’avoir de l’information en temps réel sur leurs patients/résidents. Depuis 2010 les dossiers de tous les résidents Korian sont dématérialisés et accessibles par requêtes. Ils comprennent à la fois des données médico-sociales structurées décrivant les résidents et leurs traitements et pathologies, mais aussi des données textuelles explicitant leur prise en charge au quotidien et saisies par le personnel soignant.Au fil du temps et alors que le dossier résident informatisé (DRI) avait surtout été conçu comme une application de gestion de base de données, il est apparu comme une nécessité d’exploiter cette mine d’informations et de construire un outil d’aide à la décision destiné à améliorer l’efficacité des soins. L’Institut du Bien Vieillir IBV devenu entretemps la Fondation Korian pour le Bien Vieillir a alors choisi, dans le cadre d’un partenariat Public/Privé de financer un travail de recherche destiné à mieux comprendre le potentiel informatif de ces données, d’évaluer leur fiabilité et leur capacité à apporter des réponses en santé publique. Ce travail de recherche et plus particulièrement cette thèse a alors été pensée en plusieurs étapes.- D’abord l’analyse de contenu du data warehouse DRI, l’objectif étant de construire une base de données recherche, avec un versant social et un autre de santé. Ce fut le sujet du premier article.- Ensuite, par extraction directe des informations socio-démographiques des résidents dès leur entrée, de leurs hospitalisations et décès puis, par un processus itératif d’extractions d’informations textuelles de la table des transmissions et l’utilisation de la méthode Delphi, nous avons généré vingt-quatre syndromes, ajouté les hospitalisations et les décès et construit une base de données syndromique, la Base du Bien Vieillir (BBV) . Ce système d’informations d’un nouveau type a permis la constitution d’une cohorte de santé publique à partir de la population des résidents de la BBV et l’organisation d’un suivi longitudinal syndromique de celle-ci. La BBV a également été évaluée scientifiquement dans un cadre de surveillance et de recherche en santé publique au travers d’une analyse de l’existant : contenu, périodicité, qualité des données. La cohorte construite a ainsi permis la constitution d’un outil de surveillance. Cet échantillon de population a été suivi en temps réel au moyen des fréquences quotidiennes d’apparitions des 26 syndromes des résidents. La méthodologie d’évaluation était celle des systèmes de surveillance sanitaire proposée par le CDC d’Atlanta et a été utilisée pour les syndromes grippaux et les gastro entérites aiguës. Ce fut l’objet du second article.- Enfin la construction d’un nouvel outil de santé publique : la distribution de chacun des syndromes dans le temps (dates de transmissions) et l’espace (les EHPAD de transmissions) a ouvert le champ de la recherche à de nouvelles méthodes d’exploration des données et permis d’étudier plusieurs problématiques liées à la personne âgée : chutes répétées, cancer, vaccinations et fin de vie. / French population is rapidly aging. Senior citizens ratio is increasing and our society needs to rethink its organization, taking into account this change, better knowing this fast growing population group.Even if numerous cohorts of elderly people already exist worldly with four in France and, even as they live in growing numbers in nursing homes and out-patient treatment clinics, knowledge of this population segment is still missing.Today several health and medico-social structures groups as Korian and Orpéa invest in big relational data bases enabling them to get real-time information about their patients/residents. Since 2010 all Korian residents’ files are dematerialized and accessible by requests. They contain at the same time, structured medico-social data describing the residents as well as their treatments and pathologies, but also free-textual data detailing their daily care by the medical staff.Through time and as the computerized resident file (DRI) was mainly conceived as a data base management application, it appeared essential to mine these data and build a decision-making tool intended to improve the care efficiency. The Ageing Well Institute becoming meanwhile the Korian Ageing Well Foundation chose then, working in a private/public partnership, to finance a research work intented to better understand these datas’ informative potential, to assess their reliability and response to public health threats. This research work and this thesis were then designed in several steps:- First, a content analysis of the data warehouse DRI, the objective being to build a research data base, with a social side and a health side. This was the first paper subject.- Then, by direct extraction of the residents’ socio-demographic information at nursing home (NH) entry, adding hospitalizations and deaths, and finally, by an iterative textual extraction process of the transmissions data and by using the Delphi method, we created twenty-four syndromes, added hospitalizations and deaths and built a syndromic data base, the Ageing Well data base. This information system of a new kind, allowed the constitution of a public health cohort for elderly people from the BBV residents’population and its syndromic longitudinal follow-up. The BBV was also scientifically assessed for surveillance and public health research through present situation analysis: content, periodicity and data quality. This cohort then gave us the opportunity to build a surveillance tool and follow the residents’ population in real-time by watching their 26 daily frequency syndromic distributions. The methodology for that assessment, Atlanta CDCs’ health surveillance systems method, was used for flu and acute gastro enteritis syndroms and was the second paper subject.- Finally, the building of a new public health tool: each syndrom’s distribution through time (transmissions dates) and space (transmissions NH ids) opened the research field to new data exploration methods. I used these to study different health problems afflicting senior citizens: frequent falls, cancer, vaccinations and the end of life.

Stream processing systems have been widely adopted in applications such as recommendation systems, anomaly detection, and system monitoring due to their real-time capabilities. Improving observability in stream processing systems can further expand their application scenarios, including the implementation of stateful serverless applications. Stateful serverless applications are an emerging model in serverless computing that focuses on addressing the challenges of state management, enabling developers to build distributed applications in a simpler way. One possible implementation of stateful serverless applications is based on stream processing engines. However, the current approaches for observability in stream processing engines suffer from issues such as efficiency, consistency, and functionality, resulting in limited practical use cases. To address these challenges, we propose Queryable Workflow, an extension to stream processing engines. This extension allows users to access or modify the state within stream processing engines with transactional semantics using a SQL interface, enabling use cases such as ad-hoc querying, serializable updates, or even stateful serverless applications. We implemented our system on stream processing engines such as Portals and Apache Flink, and evaluated their performance. The result showed that our system has achieved 4.33x throughput improvement and 30% latency reduction compared to a baseline implemented with Apache Flink and Apache Kafka. With hand-crafted optimizations, our system achieved to process over 29,000 queries per second with a 99th percentile latency of 8.58 ms under a single-threaded runtime. Our proposed system provides a viable option for implementing stateful serverless applications that require transactional guarantees, while also expanding the potential application scenarios for stream processing engines. / Strömbehandlingssystem har på grund av sina realtidsegenskaper fått stor spridning i tillämpningar som rekommendationssystem, anomalidetektering och systemövervakning. Förbättrad observerbarhet i stream processing-system kan ytterligare utöka deras tillämpningsscenarier, inklusive implementeringen av stateful serverless-applikationer. Stateful serverless-applikationer är en framväxande modell inom serverless computing som fokuserar på att hantera utmaningarna med tillståndshantering, vilket gör det möjligt för utvecklare att bygga distribuerade applikationer på ett enklare sätt. En möjlig implementering av stateful serverless-applikationer är baserad på stream processing-motorer. De nuvarande metoderna för observerbarhet i strömbehandlingsmotorer lider dock av problem som effektivitet, konsistens och funktionalitet, vilket resulterar i begränsade praktiska användningsfall. För att ta itu med dessa utmaningar föreslog vi Queryable Workflow, ett tillägg till stream processing-motorer. Med detta tillägg kan användare komma åt eller ändra tillståndet i strömbehandlingsmotorer med transaktionssemantik med hjälp av ett SQL-gränssnitt, vilket möjliggör användningsfall som ad hoc-förfrågningar, serialiserbara uppdateringar eller till och med serverlösa applikationer med tillstånd. Vi implementerade vårt system på stream processing-motorer som Portals och Apache Flink, och utvärderade deras prestanda. Resultatet visade att vårt system har förbättrat genomströmningen 4,33 gånger och minskat latensen med 30% jämfört med en baslinje som implementerats med Apache Flink och Apache Kafka. Med handgjorda optimeringar lyckades vårt system bearbeta över 29 000 frågor per sekund med en 99:e percentil latens på 8,58 ms under en enkeltrådad körtid. Vårt föreslagna system har gett ett hållbart alternativ för att implementera stateful serverless-applikationer som kräver transaktionsgarantier, samtidigt som det också utökat de potentiella applikationsscenarierna för stream processing-motorer.

Although approximate query processing is a prominent way to cope with the requirements of data analysis applications, current database systems do not provide integrated and comprehensive support for these techniques. To improve this situation, we propose an SQL extension---called SQL/S---for approximate query answering using random samples, and present a prototypical implementation within the engine of the open-source database system Derby---called Derby/S. Our approach significantly reduces the required expert knowledge by enabling the definition of samples in a declarative way; the choice of the specific sampling scheme and its parametrization is left to the system. SQL/S introduces new DDL commands to easily define and administrate random samples subject to a given set of optimization criteria. Derby/S automatically takes care of sample maintenance if the underlying dataset changes. Finally, samples are transparently used during query processing, and error bounds are provided. Our extensions do not affect traditional queries and provide the means to integrate sampling as a first-class citizen into a DBMS.

[pt] Usuários atualmente esperam consultar dados de maneira semelhante ao Google, digitando alguns termos, chamados palavras-chave, e deixando para o sistema recuperar os dados que melhor correspondem ao conjunto de palavras-chave. O cenário é bem diferente em sistemas de gerenciamento de banco de dados em que os usuários precisam conhecer linguagens de consulta sofisticadas para recuperar dados, ou em aplicações de banco de dados em que as interfaces de usuário são projetadas como inúmeras caixas que o usuário deve preencher com seus parâmetros de pesquisa. Esta tese descreve um algoritmo e um framework projetados para processar consultas baseadas em palavras-chave para bases de dados com esquema, especificamente bancos relacionais e bases de dados em RDF. O algoritmo primeiro converte uma consulta baseada em palavras-chave em uma consulta abstrata e, em seguida, compila a consulta abstrata em uma consulta SPARQL ou SQL, de modo que cada resultado da consulta SPARQL (resp. SQL) seja uma resposta para a consulta baseada em palavras-chave. O algoritmo explora o esquema para evitar a intervenção do usuário durante o processo de busca e oferece um mecanismo de feedback para gerar novas respostas. A tese termina com experimentos nas bases de dados Mondial, IMDb e Musicbrainz. O algoritmo proposto obtém resultados satisfatórios para os benchmarks. Como parte dos experimentos, a tese também compara os resultados e o desempenho obtidos com bases de dados em RDF e bancos de dados relacionais. / [en] Users currently expect to query data in a Google-like style, by simply typing some terms, called keywords, and leaving it to the system to retrieve the data that best match the set of keywords. The scenario is quite different in database management systems, where users need to know sophisticated query languages to retrieve data, and in database applications, where the user interfaces are designed as a stack of pages with numerous boxes that the user must fill with his search parameters. This thesis describes an algorithm and a framework designed to support keywordbased queries for datasets with schema, specifically RDF datasets and relational databases. The algorithm first translates a keyword-based query into an abstract query, and then compiles the abstract query into a SPARQL or a SQL query such that each result of the SPARQL (resp. SQL) query is an answer for the keywordbased query. It explores the schema to avoid user intervention during the translation process and offers a feedback mechanism to generate new answers. The thesis concludes with experiments over the Mondial, IMDb, and Musicbrainz databases. The proposed translation algorithm achieves satisfactory results and good performance for the benchmarks. The experiments also compare the RDF and the relational alternatives.

Det finns en stor mängd databaser som används inom många olika sorters användningsområden. Bland dessa finns det sådana som har funktion för att behandla spatiala data. Problemet som detta medför är att välja en databas som kan hantera en viss tänkt typ av spatiala data med bäst prestanda. Denna rapport presenterar en utredning för detta utifrån ett dataset som erhållits från Norconsult Digital. Bland de databaser som valts finns tre SQL databaser (PostgreSQL, MySQL och SQLite) och en NoSQL databas (MongoDB). Dessa databaser genomgick fem likvärdiga operationer/tester som resulterade i att PostgreSQL med dess GiST/SP-GiST index och MongoDB presterade på en nivå långt över resterande databaser som testades. Utifrån detta arbete kan det konstateras att fler utförliga prestandatester bör utföras, där större och mer komplexa dataset, samt fler alternativ till databaser och spatiala index bör finnas med. Detta för att ge en bättre bild över vilka databaser, med stöd för spatiala data, som presterar bättre. / There are a large number of databases that are used in many different areas. Among these, some have a function for processing spatial data. The problem that this entails is the choice of a database that can handle a certain type of spatial data with the best possible performance. This report presents an analysis of this based on a dataset obtained from Norconsult Digital. Among the chosen databases are three SQL databases (PostgreSQL, MySQL and SQLite) and one NoSQL database (MongoDB). These databases underwent five identical operations/tests resulting in PostgreSQL with its GiST/SP-GiST index and MongoDB performing at a level well above the rest of the databases tested. Based on this work, it can be concluded that more detailed performance tests should be carried out, where larger and more complex datasets, as well as more alternatives to databases and spatial indexes, should be included. This is to give a better picture of which databases, with support for spatial data, perform better.

In recent years, there has been tremendous growth in both the volumes of data that is produced, stored, and queried by organizations. Organizations spend more money to investigate and obtain useful information or knowledge against terabytes and even petabytes of data. Large-scale data analysis is the key functionality provided by Big Data platforms. Previously, data platforms would get the information from unstructured data in the form of files, text, and videos. In recent times, the Hadoop stack has played a vital role in Big Data, becoming the defector open source software used to process and analyze Big Data. Hops is a Hadoop distribution developed by KTH and RISE SICS. Hops modifies the Hadoop stack by moving the meta-data for YARN and HDFS to NDB, an open-source in-memory distributed database. HopsWorks is the User Interface for Hops and provides support for multi-tenant users, as well as self-service, graphical access to frameworks such as Hadoop, Flink, Spark, Kafka, and Kibana. HopsWorks currently does not provide a SQL-on-Hadoop service, although work is ongoing for supporting Hive. Presto is one of the main SQL-on-Hadoop platform, but, currently, Presto does not provide multi-tenancy support for users. This thesis investigates providing multitenancy support to Presto with the help of HopsWorks, including both the security problem and the self-service UI requirements of HopsWorks. Presto is a distributed SQL query Engine which can run SQL queries against up to petabytes of data. As HopsWorks provides UI access to services, we decided to build our UI for Presto on an existing open-source UI for Presto, called Airpal, developed by Airbnb. This provided solution of the thesis divided into two functionalities. First one, maintain two separate Applications (HopsWorks and Airpal Applications) run by the help of two JVMs and maintain ProxyServlet to control traffic between them. Second one HopsWorks-Presto-service leverages HopsWorks access-control (Data owner and Data-scientist) and self-service security model. The evaluation of the thesis used qualitative approach by comparing HopsWorks-PrestoService with standalone PrestoDB and comparing HopsWorks-PrestoService with HopsWorks without Presto-Service. / De senaste åren, har det varit en avsevärd ökning vad gäller mängden av data som produceras, lagras och som används för analys av olika organisationer. Organisationer spenderar mer pengar för att undersöka och extrahera information och insikter i enorma datavolymer på flera terabyte eller petabyte. Storskalig dataanalys är en central funktionalitet som tillhandahålls av Big Data plattformar. I tidigare tillvägagångssätt hämtade data plattformaro-strukturerade data i form av filer, texter och videoklipp. I nutid, så har Hadoop-stacken spelat en kärnroll i Big Data, och blivit en viktig öppen källkod mjukvara som används för att processera och analysera Big Data. Hops är en Hadoop distribution som har utvecklats av KTH och RISE SICS. Hops tillför ändringar till Hadoop stacken genom att migrera metadata för YARN och HDFS till NDB, en öppen källkod i-minnet distribuerad databas. HopsWorks är ett användargränssnitt för Hops och tillför stöd för flera användare, med tillgång till självservice och tjänster såsom Hadoop, Flink, Spark, Kafka och Kibana. HopsWorks stödjer i nuläget inte någon SQL på Hadoop tjänst, även om arbete utförs i nuläget för att integrera Hive. Presto är en av de mest populära SQL på Hadoop plattformarna, men i nuläget så stödjer inte Presto flera användare. Den här uppsatsen utreder stöd för flera användare i Presto med hjälp av HopsWorks, både vad gäller säkerhetsproblem och självservice i HopsWorks. Presto är en distribuerad SQL frågespråk motor som kan ställa frågor mot upp till petabyte med data. Eftersom HopsWorks tillhandahåller ett gränssnitt för att interagera med tjänster, beslutade vi oss att bygga ett gränssnitt för Presto på det existerande öppen källkod gränssnittet för Presto, vid namn AirPal, utvecklat av Airbnb. Den utvecklade lösningen för uppsatsen kan delas in i två delar. Den första delen, att hantera två separata applikationer (HopsWorks och AirPal) som kör med hjälp av två Java virtuella maskiner och använder en ProxyServlet för att kontrollera trafik mellan dom. Den andra, HopsWorks-Presto-service som tillhandahåller HopsWorks åtkomstkontroll (Dataägare och Dataforskare) och en självservice säkerhetsmodell. Utvärderingen i uppsatsen är att genom ett kvalitativt tillvägagångssätt jämföra HopsWorks-Presto-service med en fristående PrestoDB och jämföra HopsWorks-Presto-service med HopsWorks utan Presto-service.

Unik objektmärkning är ett ord som uppstått i samband med projekteringen av Nya Karolinska Solna (NKS) och var det första projektet i Sverige där unika objektmärkningar var ett krav vid projekteringen. Syftet med rapporten är att undersöka vad en unik objektmärkning är och vad den genererar för information till förvaltaren. Vidare är syftet att undersöka vad en unik objektmärkning bidrar med under förvaltningen och mer specifikt vad den bidrar med i förvaltningen av NKS.För att undersöka detta hölls intervjuer med respondenter som var med och objektmärkte 2500 ritningar av Nya Karolinska Solna (NKS). För att undersöka effekten av de unika objektmärkningarna i förvaltningsskedet intervjuades en respondent från Coor som förvaltar NKS i dagsläget. Utöver intervjuer utfördes en omfattande litteraturstudie om hur arbetet med märkning av ritningar går till.Objektmärkningen av NKS resulterade i 600 000 stycken unika objektmärkningar varav 150 000 stycken av dessa förvaltas av fastighetsbolaget Coor idag. Informationen om objekten överlämnades i form av en databas som har gjort det möjligt för Coor att koppla informationen till underhållssystemet Maximo och plattformen Forge Viewer.Unika objektmärkningar definierades som en märksträng som särskiljer varje objekt från varandra i ett projekt. Märksträngen innehåller information om exempelvis rumsplacering, vilket system objektet tillhör och grupp och redovisas som koder i märksträngen. Under arbetets gång kunde det konstateras att den unika objektmärkningen resulterade i ett kvalitetssäkrat förvaltningsarbete på NKS. / Unique asset codes is a word that emerged in the development of Nya Karolinska Solna (NKS). The purpose of the thesis is to investigate what a unique asset code is and what kind of information it generates to the facility manager. Furthermore, the purpose is to investigate what a unique asset code contributes to during the facility management and, more specifically, what it contributes to the management of NKS. To investigate this, interviews were held with respondents who took part of the development of unique asset codes at New Karolinska Solna (NKS). In order to investigate the effect of the unique asset codes in the facility management phase, a respondent from Coor, the company which is responsible for the facility management at NKS, was interviewed. In addition to interviews, a comprehensive literature study was conducted on how regular asset codes are made. The NKS project resulted in 600,000 unique asset codes, of which 150,000 of these are managed by the facility management company Coor. The information about the assets was transmitted in the form of a database that enabled Coor to link the information to the Maximo facility management software and the Forge Viewer platform. Unique asset codes were defined as a tag string that distinguishes each asset from each other in a project. The tag string contains information about, for example, placement, which system it belongs to and group. The information is reported as codes in the tag string. During the course of the work it was noted that the unique asset codes resulted in quality assured facility management work at NKS.

Syftet med denna studie var att utveckla en generell applikation som kan generera DDL-skript från tre olika databaser: Oracle, SQL Server och DB2, genom att enbart använda en JDBC-uppkoppling. Behovet av denna studie kommer från att databasadministratörer och utvecklare effektivt ska kunna hantera databaser med olika system med varierande syntax och struktur. Processen genomfördes i IDEAn IntelliJ med java.sql-APIt för databasoperationer. Resultatet visade att trots skillnaderna mellan dessa databaser var det möjligt att utveckla en generell process för att extrahera DDL-kod med endast en JDBCuppkoppling. Dock krävdes vissa specifika anpassningar för varje databassystem. En observation var hanteringen av primärnycklar och index mellan systemen. Denna applikation har potential att vidareutvecklas till ett kraftfullt verktyg för databashantering, vilket sparar tid och resurser. Områden för framtida undersökning inkluderar hantering av komplexa datatyper och strukturer, samt prestanda med stora databaser. / This study was aimed at developing a generic application capable of generating DDL-code from three different databases: Oracle, SQL Server and DB2 by using JDBC. This research necessity origins from database administrators and developers need to effectively manage databases across different systems with different syntax and structure. The process was conducted in the IDEA IntelliJ using the java.sql-API for database operations. The result showed that despite the differences between these databases it was possible to develop a generic process for extracting DDL-code only using a JDBC connection. However, some specific adaptions were required for each database system. An observation was the managing of primary keys and indexes across the systems. This application has the potential to be developed further into a powerful tool for database management that saves time and resources. Areas for further investigation is handling of complex data types and structures and performance with large databases.