Diss. Uppsala : Univ., 2009.

No description available.

No description available.

Diss. Linköping : Linköpings universitet, 2007.

Monitors affärssystem MONITOR är under ständig utveckling och i och med detta ville man kolla upp huruvida PostgreSQL skulle kunna användas som DBMS istället för det nuvarande; Sybase SQL Anywhere. Examensarbete har därför bestått av en jämförelse hur PostgreSQL står sig jämte andra DBMS:er, en implementering utav en PostgreSQLdatabas som MONITOR arbetar mot samt ett prestandatest utav skapandet av databasen. I många avseenden verkar PostgreSQL vara ett alternativ till SQL Anywhere; Alla datatyper finns i båda dialekterna. Backup av data finns i olika utföranden och går att automatisera. Enkelt att installera och uppdatera. Ingen licensieringskostnad existerar. Support finns tillgänglig i olika former. Dock så är inte PostgreSQL ett bra DBMS att byta till i dagsläget då systemet inte fungerade på grund av att vissa uttryck inte översattes ordentligt samt att ingen motsvarighet till LIST existerar. Ännu större är dock problemet med tiden det tar att flytta data till en PostgreSQL-databas då det inte är intressant att lösa problem med funktioner i systemet om det ändå inte går att använda på grund utav att konvertering av data tar så lång tid som det gör.

<p>Denna rapport behandlar framtagandet av en modell för beräkning av lastbilars nyttjandegrad. Vidare beskrivs hur denna modell har implementerats och vilka möjliga ekonomiska besparingar som finns att hämta med ett ökat nyttjande. Den kostnadskalkyl som upprättades för att kunna beräkna dessa möjliga besparingar resulterade i en kalkylerad timkostnad på 551 SEK per timme och lastbil. </p><p>De resultat som beräkningarna av lastbilarnas nyttjandegrader gav, tyder på att bilarna i den södra regionen, som förväntat, hade en klart lägre nyttjandegrad än övriga. Mer oväntat var dock att detta till stor del berodde på ett lågt kapacitetsutnyttjande. </p><p>Ett förslag på ny utformning av den databas vari information om utförda transporter registreras har också tagits fram. Om databasen omarbetas enligt detta förslag, eller på annat lämpligt sätt, skulle den här typen av beräkningar kunna snabbas upp betydligt. </p><p>De totala ekonomiska besparingarna som skulle uppnås om samtliga bilar höll ett kapacitetsutnyttjande och ett tidsutnyttjande motsvarande medelvärdet av de bästa 25 procenten i respektive kategori, motsvarar 14,1%, alltså nästan 36 miljoner SEK per år. Stora problem ses dock med att kunna förverkliga dessa besparingar, åtminstone på någorlunda kort sikt.</p>

Denna rapport behandlar framtagandet av en modell för beräkning av lastbilars nyttjandegrad. Vidare beskrivs hur denna modell har implementerats och vilka möjliga ekonomiska besparingar som finns att hämta med ett ökat nyttjande. Den kostnadskalkyl som upprättades för att kunna beräkna dessa möjliga besparingar resulterade i en kalkylerad timkostnad på 551 SEK per timme och lastbil. De resultat som beräkningarna av lastbilarnas nyttjandegrader gav, tyder på att bilarna i den södra regionen, som förväntat, hade en klart lägre nyttjandegrad än övriga. Mer oväntat var dock att detta till stor del berodde på ett lågt kapacitetsutnyttjande. Ett förslag på ny utformning av den databas vari information om utförda transporter registreras har också tagits fram. Om databasen omarbetas enligt detta förslag, eller på annat lämpligt sätt, skulle den här typen av beräkningar kunna snabbas upp betydligt. De totala ekonomiska besparingarna som skulle uppnås om samtliga bilar höll ett kapacitetsutnyttjande och ett tidsutnyttjande motsvarande medelvärdet av de bästa 25 procenten i respektive kategori, motsvarar 14,1%, alltså nästan 36 miljoner SEK per år. Stora problem ses dock med att kunna förverkliga dessa besparingar, åtminstone på någorlunda kort sikt.

This report summarizes the procedure of the independent work in the final course DT140G. The project's task and main goal has been to help the company involved to enable a potential interruption with a time registration service called Harvest which they currently consume. The task itself has been sectioned into three clear parts with completely different orientations but towards the same end goal. The first part has involved data management from the consumed time registration service in terms of both exporting and importing data. The second part has been about developing a CRUD functionality that can be consumed in the frontend by another developer. The last part has meant that a report compilation application has been created where data from the previous parts is handled and produces various reports which could then be exported in Excel files. The result of this independent work resulted in an application with great similarities in terms of functionality as the previous time registration service. The company has taken a step closer to their vision of a break from Harvest. This has been done with access to source code from a previous developer who shared his repository via GitLab and the React Admin framework. The CRUD functionality has been checked with the help of the test tool ARC and all code development has taken place in the software development environment Visual Studio Code. / Denna rapport sammanfattar proceduren av det självständiga arbetet i slutkursen DT140G. Projektets uppgift och främsta mål har varit att hjälpa det involverade företaget att möjliggöra ett potentiellt avbrott med en tidsregistreringstjänst vid namn Harvest som de i dagsläget konsumerar. Själva uppgiften i sig har varit sektionerad i tre tydliga delar med helt olika inriktningar fast mot samma slutmål. Den fösta delen har involverat datahantering ifrån den konsumerade tidsregistreringstjänsten vad det gäller att både exportera och importera data. Den andra delen har handlat om att utveckla en CRUD-funktionalitet som skall kunna konsumeras i frontend av en annan utvecklare. Den sista delen har inneburit att en rappportsammanställningsapplikation har skapats där data ifrån de tidigare delarna hanteras och frambringar olika rapporter som sedan skulle kunna exporteras i Excel-filer. Utkomsten av detta självständiga arbete resulterade i en applikation med väldiga likheter funktionsmässigt vad det gäller den tidigare tidsregistreringstjänsten. Företaget har tagits ett steg närmare sin vision om en frislagning ifrån Harvest. Detta har genomförts med tillgång till källkod ifrån en tidigare utvecklare som delat sitt repository via GitLab samt ramverket React Admin. CRUD-funktionaliteten ha kontrollerats med hjälp av testverktyget ARC och all utveckling av kod har skett i programutvecklingsmiljön Visual Studio Code

The primary purpose of this thesis is to explore what issues may arise during development of a framework for handling and display of streamed real-time data. In addition to this, it also investigates how the display of different types of data, along with a change of execution platform, impacts execution time. Through the undertaking of two case studies, each split into developmental and an experimental phases, the thesis goes through the development of such a real-time data handling framework. The framework was developed in both stationary and mobile forms, and the developmental issues encountered along each of these paths are highlighted. Afterwards, the results gathered from performance tests run on each framework version were compared, in order to ascertain whether the handling and display of different data types, along with a change in execution platform, had had an impact upon the frameworks execution time. The results from the developmental observations revealed that the most commonly encountered issues were those relating to program latency, commonly due to sub-optimal program architecture along with connectivity issues encountered during data streaming. The second most encountered issue regarded the choice of an appropriate display method, in order to communicate changes in the displayed data along with correlation between several tracked data points. The results from the experimental comparisons revealed that while the impact on execution time caused by the use of calculated data, as opposed to raw data values, was marginal at most, a change of execution platform impacted said time drastically. By porting the framework to the mobile platform, the different processes whose execution time were measured during the tests experienced an increase in execution time ranging from 2405% all the way to 15860%. The authors recommend that the framework be developed towards gaining the ability to connect to any given relational database, and to handle and display the data therein, in order for it to have application areas other than as a test instrument. Further, the authors also recommend that additional tests be run on the framework using a wider variety of stationary and mobile devices, in order to determine whether the conclusions drawn from the results in the thesis hold up in the face of greater hardware variety. / Denna studies primära mål är att utforska vilka problem som kan uppstå under utveckling av ett ramverk för hantering och visande av streamad realtidsdata. Utöver det undersöks även hur visande av olika datatyper, ihop med ett byte av exekveringsplattform, påverkar exekveringstiden. Genom utförandet av två fallstudier, båda uppdelade i utvecklingsoch experimenteringsfaser, går denna studie igenom utvecklingen av ett sådant ramverk för hantering av realtidsdata. Ramverket utvecklades i både stationär och mobil form, och de utvecklingsrelaterade problem som påträffades i vardera fall belyses. Efteråt jämfördes resultaten framtagna genom prestandatester, som kördes på samtliga ramverksversioner, för att upptäcka om hantering och visning av olika datatyper, samt ett skifte av exekveringsplattform, hade påverkat ramverkets exekveringstid. Resultaten från de utvecklingsrelaterade observationerna visade att det mest påträffade problemet hade att göra med programlatens, vanligtvis p.g.a. ickeoptimal programarkitektur kombinerat med konnektivitetsproblem. Det näst mest påträffade problemet hade att göra med valet av en passande visningsmetod, för att kunna förmedla förändringar i den visade datan, samt korrelation mellan flera följda datapunkter. Resultaten från de experimentella jämförelserna visade att medan påverkan av exekveringstiden som uppstått genom användandet av kalkylerad data, till skillnad från rådatavärden, endast var marginell som bäst, påverkade förändringen av exekveringsplattform denna tid drastiskt. Genom att porta ramverket till den mobila plattformen upplevde de processer vars exekveringstid mättes under testerna en ökning från 2405% hela vägen upp till 15860%. Författarna rekommenderar att ramverket utvecklas mot förmågan att koppla till godtycklig databas, och att kunna hantera och visa datan från denna, för att ha ett användningsområde bortom användandet som testinstrument. Vidare rekommenderar även författarna att ytterliggare test utförs på ramverket med en större variation av stationära och mobila enheter, för att kunna bekräfta om slutsatserna som dragits utifrån resultaten av denna studie kvarstår efter att de utsatts för mer varierande hårdvara.

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.