<p>Databaser är vanligt förekommande i vardagen på företag och organisationer. De mer objektorinterade krav som idag ställs på vad en databas bör klara av att hantera, har med ökad datakapacitet gjort att mer komplexa dataobjekt måste kunna hanteras i databasen.</p><p>1990 skrevs ett manifest av den tidens ledande databasforskare om vad de ansåg att den tredje generationens databaser borde ha för funktionalitet. I detta arbete undersöks det huruvida dagens moderna relationsdatabasprodukter klarar av att hantera de krav som ställdes i manifestet på vad den tredje generationens databaser borde klara av.</p><p>Arbetet utgår ifrån manifestets krav och utförs med hjälp av en kombination av metoderna litteraturstudie och implementation. Fokus har lagts på att hitta en lösning i litteraturen för att om möjligt visa med kodexempel hur det kan se ut i en praktisk lösning.</p>

<p>Det blir allt vanligare att utvecklare av databasapplikationer använder någon form av kodgenererare för delar av eller fullständiga applikationer. De utvecklingsverktyg som används idag är antingen wizards eller kompletta applikationsgenererare. Problemet med detta är att wizards ger väldigt lite hjälp och kompletta applikationsgenererare skapar applikationer som inte går att förändra. Det finns alltså ett stort gap mellan dessa båda sorters utvecklingsverktyg. För att fylla ut detta gap kan användarvänlighet för en applikation läggas till en wizard, vilket får till följd att wizarden skall klara av att skapa en användarvänlig databasapplikation som har viss funktionalitet. I denna rapport föreslås en lösning för att skapa en prototyp till en wizard som kan automatgenerera skelettkod för användarvänliga databasapplikationer, givet metadata och indata. Den automatgenererade databasapplikationen skall användas mot relationsdatabaser.</p>

<p>Att undersöka huruvida det är möjligt att underlätta framställningen av ett elektroniskt handelssystem som använder sig av en existerande relationsdatabas är intressant av flera anledningar. Med Internets utveckling har möjligheterna till elektronisk handel ökat. Många företag har idag redan existerande databaser till sin verksamhet. Ändringar eller driftstopp i dessa databaser medför stora problem för företagen.</p><p>Denna rapport beskriver en prototyp som underlättar användandet av en existerande databas och som underlättar skapandet av de komponenter som ingår i ett enkelt elektroniskt handelssystem. För att skapa prototypen har en hybrid mellan en templatbaserad och en hårdkodad lösning använts. Resultaten visar att det är möjligt att skapa en prototyp som kan använda en existerande relationsdatabas utan att behöva ta den ur drift eller göra förändringar i den. Prototypen kan dock inte anses vara användbar i en verklig miljö. De brister som prototypen har är identifierade och om lösningar på dessa hittas bör prototypen kunna användas i en verklig miljö. Arbetet i denna rapport kan således ses som en inledande undersökning av hur framställningen av ett elektroniskt handelssystem kan underlättas.</p>

<p>Detta examensarbete omfattar utveckling och test av en metod för distribution av data i ett multidatabassystem. Testen av metoden har gjorts genom att den har implementerats i en fallstudie. Fallstudien berör en organisation som har behov av att integrera tre av sina databassystem. Detta för att information ska kunna utbytas mellan dessa. Integrationen av databassystemen har gjorts på ett sådant sätt att de data som distribueras från dessa skickas till en central databas, med SQL Server som databashanterare.</p><p>Det verktyg som har valts att användas i examensarbetet för att lösa uppgiften är Data Transformation Services, DTS, i SQL Server.</p>

Databaser är vanligt förekommande i vardagen på företag och organisationer. De mer objektorinterade krav som idag ställs på vad en databas bör klara av att hantera, har med ökad datakapacitet gjort att mer komplexa dataobjekt måste kunna hanteras i databasen. 1990 skrevs ett manifest av den tidens ledande databasforskare om vad de ansåg att den tredje generationens databaser borde ha för funktionalitet. I detta arbete undersöks det huruvida dagens moderna relationsdatabasprodukter klarar av att hantera de krav som ställdes i manifestet på vad den tredje generationens databaser borde klara av. Arbetet utgår ifrån manifestets krav och utförs med hjälp av en kombination av metoderna litteraturstudie och implementation. Fokus har lagts på att hitta en lösning i litteraturen för att om möjligt visa med kodexempel hur det kan se ut i en praktisk lösning.

Att undersöka huruvida det är möjligt att underlätta framställningen av ett elektroniskt handelssystem som använder sig av en existerande relationsdatabas är intressant av flera anledningar. Med Internets utveckling har möjligheterna till elektronisk handel ökat. Många företag har idag redan existerande databaser till sin verksamhet. Ändringar eller driftstopp i dessa databaser medför stora problem för företagen. Denna rapport beskriver en prototyp som underlättar användandet av en existerande databas och som underlättar skapandet av de komponenter som ingår i ett enkelt elektroniskt handelssystem. För att skapa prototypen har en hybrid mellan en templatbaserad och en hårdkodad lösning använts. Resultaten visar att det är möjligt att skapa en prototyp som kan använda en existerande relationsdatabas utan att behöva ta den ur drift eller göra förändringar i den. Prototypen kan dock inte anses vara användbar i en verklig miljö. De brister som prototypen har är identifierade och om lösningar på dessa hittas bör prototypen kunna användas i en verklig miljö. Arbetet i denna rapport kan således ses som en inledande undersökning av hur framställningen av ett elektroniskt handelssystem kan underlättas.

Det blir allt vanligare att utvecklare av databasapplikationer använder någon form av kodgenererare för delar av eller fullständiga applikationer. De utvecklingsverktyg som används idag är antingen wizards eller kompletta applikationsgenererare. Problemet med detta är att wizards ger väldigt lite hjälp och kompletta applikationsgenererare skapar applikationer som inte går att förändra. Det finns alltså ett stort gap mellan dessa båda sorters utvecklingsverktyg. För att fylla ut detta gap kan användarvänlighet för en applikation läggas till en wizard, vilket får till följd att wizarden skall klara av att skapa en användarvänlig databasapplikation som har viss funktionalitet. I denna rapport föreslås en lösning för att skapa en prototyp till en wizard som kan automatgenerera skelettkod för användarvänliga databasapplikationer, givet metadata och indata. Den automatgenererade databasapplikationen skall användas mot relationsdatabaser.

Detta examensarbete omfattar utveckling och test av en metod för distribution av data i ett multidatabassystem. Testen av metoden har gjorts genom att den har implementerats i en fallstudie. Fallstudien berör en organisation som har behov av att integrera tre av sina databassystem. Detta för att information ska kunna utbytas mellan dessa. Integrationen av databassystemen har gjorts på ett sådant sätt att de data som distribueras från dessa skickas till en central databas, med SQL Server som databashanterare. Det verktyg som har valts att användas i examensarbetet för att lösa uppgiften är Data Transformation Services, DTS, i SQL Server.

The development of database systems is moving more and more towards handling large quantities of data, also known as Big Data. New database systems have been developed both within NoSQL and the newer system architecture called NewSQL used to tackle the problems that arise with Big Data. NewSQL is becoming more popular due to its ability to handle the security behind data transactions and simultaneously offer scalability. This has led to database systems constantly being optimized. This report goes into detail on how the handling of datatypes affect how database systems are built based on their architecture and code base.  An experiment was conducted on two NewSQL databases, VoltDB and CockroachDB. The purpose of the experiment was to find out how datatypes can be optimized based on time differences in datatypes and then present causes to those time differences. There were clear time differences which showed what datatypes were fastest. When analyzing the codebase and architecture it became clear that VoltDB handles datatypes when compiling while CockroachDB does so during execution.  Another potential reason is that the time differences have to do with their differences in architecture.  This report has, with the available resources, started to build the foundation for a better standard in how datatypes can be implemented in code to increase the performances of database systems. More research is required due to time constraints that can strengthen and expand the results reached in this paper. / Utvecklingen av databassystem rör sig alltmer mot att hantera stora datamängder, även kallat Big Data. Nya databassystem har utvecklats både inom NoSQL och det nyare NewSQL för att tackla problemen med Big Data. För att hantera både säkerheten bakom databastransaktioner och samtidigt behålla skalbarheten så börjar NewSQL klättra alltmer i databasvärlden. Det har lett till att databassystem effektiviseras så mycket som möjligt. Denna rapport går in i detalj på hur hantering av vissa datatyper påverkas av hur databassystem är uppbyggda baserat på deras arkitektur och kodbas. För att ta reda på hur hantering av datatyper kan effektiviseras utfördes ett experiment på NewSQL databaserna VoltDB och CockroachDB för att hitta tidsskillnader för datatyper och sedan ta fram orsaker till dessa skillnader. Det fanns klara tidsskillnader för vilka datatyper som var snabbast och vid analys av kodbas och arkitektur framgick det att VoltDB hanterar datatyper vid kompilering medan CockroachDB gör det vid exekvering. Dessutom ser deras arkitekturer olika ut vilket kan ytterliggare bidra till tidsskillnaderna. Med de resurser som varit tillgängliga har denna rapport påbörjat ett arbete till att lägga en grund för att ta fram en bättre standard till hur datatyper kan implementeras i kod för att öka prestandan i databassystem. På grund av de tidsbegränsningar som funnits behöver mer forskning tas fram som kan stärka och utvidga resultatet som uppnåtts i detta arbete.

The rapid advancement of computer software in the digital revolution has created a diverse range of powerful tools for various industries. Even though there is such a broad selection, there is no software that fits every individual or organization because of the different criterias. This is no exception for designing tools. To stay competitive and foster further growth, Valmet Tissue Mills recognizes the need to embrace the latest technology. They are in their quest for an updated design software that incorporates a database, they have chosen CADMATIC Electrical, a Finnish CAD tool specifically designed for electrical and automation engineering. However, through complications with implementing the tool under the COVID-19 lockdown, it has resulted in lasting challenges. The management has experienced resistance to change, because of lack of knowledge and a complicated system. In order to decrease the uncertainty, this study has researched the opportunities and challenges with CADMATIC Electrical. The availability of functions and how they work in the software.  The thesis found that CADMATIC Electrical can increase collaboration, decrease human error, surmountable revision control, etc. However, it is important to consider the complexity and security of using a database CAD tool. CADMATIC Electrical was also found to have the majority of the functions that the engineers desired. / Den snabba utvecklingen av datorprogramvara i den digitala revolutionen har skapat en mängd kraftfulla verktyg för olika branscher. Trots det breda utbudet finns det ingen programvara som passar varje individ eller organisation på grund av olika kriterier. Detta gäller även för designverktyg. För att vara konkurrenskraftig och främja ytterligare tillväxt, erkänner Valmet Tissue Mills behovet av att omfamna den senaste tekniken. I sin strävan efter en uppdaterad design programvara som inkluderar en databas har de valt CADMATIC Electrical, ett finskt CAD-verktyg speciellt utformat för el- och automationsingenjörer. Dock har komplikationer med att implementera verktyget under COVID-19-lockdownen resulterat i långvariga utmaningar. Ledningen har stött på motstånd mot förändring på grund av brist på kunskap och en komplicerad systemmiljö. För att minska osäkerheten har denna studie undersökt möjligheterna och utmaningarna med CADMATIC Electrical, samt tillgängligheten av funktioner och hur de fungerar i programvaran. Avhandlingen visade att CADMATIC Electrical kan öka samarbete, minska mänskliga fel, hantera revision med mera. Det är emellertid viktigt att beakta komplexiteten och säkerheten vid användning av ett CAD-verktyg med databas. Det konstaterades också att CADMATIC Electrical hade majoriteten av de funktioner som ingenjörerna önskade.