Orientador: Mario Jino, Plinio de Sa Leitão Junior / Dissertação (mestrado) - Universidade Estadual de Campinas, Faculdade de Engenharia Eletrica e de Computação / Made available in DSpace on 2018-08-15T03:59:29Z (GMT). No. of bitstreams: 1 Cabeca_AndreaGoncalves_M.pdf: 8778522 bytes, checksum: c968246a4fb6a8fb41b47192a1d8cb15 (MD5) Previous issue date: 2009 / Resumo: O teste de aplicações de banco de dados é crucial para assegurar a alta qualidade do software, pois defeitos não detectados podem resultar em corrupção irrecuperável dos dados. SQL é a mais amplamente utilizada interface para sistemas de banco de dados. Nossa abordagem visa a alcançar testes efetivos pela seleção de bases de dados reveladoras de defeitos. Usamos a análise de mutantes em comandos SQL e discutimos dois cenários para aplicar as técnicas de mutação forte e fraca. Uma ferramenta para auxiliar na automatização da técnica foi desenvolvida e implementada. Experimentos usando aplicações reais, defeitos reais e dados reais foram conduzidos para: (i) avaliar a aplicabilidade da abordagem; e (ii) comparar bases de dados de entrada quanto à habilidade para detectar defeitos / Abstract: Testing database applications is crucial for ensuring high quality software as undetected faults can result in unrecoverable data corruption. SQL is the most widely used interface language for relational database systems. Our approach aims to achieve better tests by selecting fault-revealing databases. We use mutation analysis on SQL statements and discuss two scenarios for applying strong and weak mutation techniques. A tool to support the automatization of the technique has been developed and implemented. Experiments using real applications, real faults and real data were performed to: (i) evaluate the applicability of the approach, and (ii) compare fault-revealing abilities of input databases / Mestrado / Engenharia de Computação / Mestre em Engenharia Elétrica

Submitted by JÚLIO HEBER SILVA (julioheber@yahoo.com.br) on 2017-09-06T18:11:43Z No. of bitstreams: 2 Dissertação - Ludmila Irineu Toledo - 2017.pdf: 1781052 bytes, checksum: 809a5a8972f14af9bc5bd3cc2eb37f80 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Approved for entry into archive by Luciana Ferreira (lucgeral@gmail.com) on 2017-09-15T15:34:25Z (GMT) No. of bitstreams: 2 Dissertação - Ludmila Irineu Toledo - 2017.pdf: 1781052 bytes, checksum: 809a5a8972f14af9bc5bd3cc2eb37f80 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) / Made available in DSpace on 2017-09-15T15:34:26Z (GMT). No. of bitstreams: 2 Dissertação - Ludmila Irineu Toledo - 2017.pdf: 1781052 bytes, checksum: 809a5a8972f14af9bc5bd3cc2eb37f80 (MD5) license_rdf: 0 bytes, checksum: d41d8cd98f00b204e9800998ecf8427e (MD5) Previous issue date: 2017-08-11 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior - CAPES / Regression testing for database applications can be a computationally costly task as it often deals with databases with large volumes of data and complex SQL statements (for example, nested queries, set comparisons, use of functions and operators). In this context, some works only select a subset of the database for testing purposes, that is, select data to create a test database and thus improve test efficiency. But usually, the selection of test data is also a complex optimization problem. Thus, this work proposes a method of selecting test data for regression testing on SQL statements based on mutation analysis, called MutShrink. The goal is to minimize the cost of testing by reducing the size of the database while maintaining the same effectiveness as the original database. MutShrink consists of using the result of the generated mutants to evaluate the database and select tuples using filters in these results, selecting reduced sets of test data. Experiments were performed using a benchmark with complex SQLs and database with large data volume. We compared our proposal with the QAShrink tool and the results revealed that MutShrink overcame the QAShrink tool in 92.85 % of cases when evaluated by the Mutation Score metric and 57.14 % of cases when evaluated by the metric Full Predicate Coverage. / O teste de regressão para aplicações de banco de dados pode ser uma tarefa computacionalmente custosa, pois frequentemente lida com bancos de dados com grandes volumes de dados e instruções SQL com estruturas complexas (por exemplo, consultas aninhadas, comparação de conjuntos, uso de funções e operadores). Neste contexto, alguns trabalhos realizam seleção apenas de um subconjunto do banco de dados para fins de teste, ou seja, selecionam dados para criar um banco de dados de teste e assim, melhorar a eficiência do teste. Mas, normalmente, a seleção de dados de teste também é um problema complexo de otimização. Assim, este trabalho propõe um método de seleção de dados de teste para teste de regressão em instruções SQLs baseado em análise de mutação, chamado MutShrink. O objetivo é minimizar o custo do teste reduzindo o tamanho do banco de dados, mantendo a eficácia semelhante ao banco original. O MutShrink consiste em utilizar o resultado dos mutantes gerados para avaliar o banco de dados e selecionar tuplas a partir de filtros nestes resultados, selecionando conjuntos reduzidos de dados de teste. Foram realizados experimentos usando um benchmark com SQLs de estruturas complexas e banco de dados com grande volume de dados. Comparamos nossa proposta com a ferramenta QAShrink e os resultados revelaram que o MutShrink superou a ferramenta QAShrink em 92,85% dos casos quando avaliada pela métrica Escore de Mutação e em 57,14% dos casos quando avaliada pela métrica Full Predicate Coverage.

Abstract As a developer of database-driven applications you will be faced with difficult choices, when it comes to choosing database, server and programming language. For the result to be satisfactory it requires the different techniques to interact well with each other and also fulfill performance expectations. This is even more important when the application is deployed to the cloud and the response time plays a major role.This paper evaluates different databases and their performance. To test the databases there was an application made in the server script language PHP or Hypertext Preprocessor and it was deployed to Windows Azure cloud platform. The test applications task is to call and load databases by controlled requests which creates, reads, updates and deletes data in an relatively large extent.The results shows that locale databases or databases in the same data center as the server generates the fastest response. The diffrence between NoSQL and SQL is practically nothing when it comes to simple requests. The type of data and the type of usage are major factors in the choice between the two databases.This paper works as a guidance in the choice of database for development of applications in the cloud. Keywords: SQL, NoSQL, databas, cloud, Azure, CouchDB, IrisCouch, database.com, databaseperformance / Abstrakt Som utvecklare av databasdrivna applikationer ställs man inför avgörande val när det kommer till databas, server och programmeringsspråk. För att resultatet ska bli en väl fungerande applikation krävs det att alla tekniker interagerar på ett bra sätt med varandra samt att de uppfyller vissa prestandakrav. Detta blir än viktigare när applikationen lyfts ut i molnet och svarstider spelar en stor roll.I arbetet undersöks olika databasers svarstider med hjälp av en testapplikation som är skriven i scriptspråketet PHP och driftsatt på Windows Azure-plattformen. Applikationens uppgift är att anropa och belasta databaser genom att genomföra kontrollerade operationer som skapar, hämtar, uppdaterar eller tar bort data i relativt stor omfattning.De databaser som praktiskt testats och utvärderats är Azure Table, Azure SQL, CouchDB, IrisCouch samt Database.com.Resultaten visar att lokala databaser, eller databaser inom samma datacenter som servern, generar de snabbaste responstiderna. Skillnaderna mellan NoSQL och SQL är i det närmaste försumbara när det handlar om enklare operationer. I valet mellan de två handlar det i mångt och mycket om vad databaserna ska användas till samt vilken typ av information som ska lagras i dem.Arbetet är tänkt att fungera som en vägledning i valet av databas vid utveckling av molntjänster. Nyckelord: SQL, NoSQL, databas, moln, Azure, CouchDB, IrisCouch, database.com, databasprestanda

This diploma thesis deals with usability of the SAS system and its components for building and running data warehouse and complete solution of Business Intelligence. In the beginning it introduces the meaning and benefits of putting on Business Intelligence and its spot in an organization. It especially focuses on the running BI project in Kooperativa, a.s., insurance company. The main goal of this thesis is to aim on ETL processes of data warehouse, their specificity, characteristics and regular tasks solved across data layers, measuring their performance and feasibility of ETL optimalization. This optimalization can be considered from two different points of view – the first is a creation and maintenance of the ETL source code, the second is tuning for faster data processing. Log files, which are are the main source for performance monitoring, are processed by macroprogram specially tailored to this particular reason. Gained results are analyzed and on that basis I outline spots that need attention. The last part offers comparison of some alternatives to data transformation process typically solved by ETL tasks. Acquired results could be taken as hints used in designing and tweaking other akin ETL processes.

I mätrummet på Sandvik Coromant finns en lösning för att visualisera maskinhälsa, mäthistorik och servicetider för olika mätinstrument. Lösningen för datavisualiseringen nyttjar verktyget Power BI och är kopplad till Excelfiler. När data väl hämtats in görs en rad modifieringar på tabellerna för att få fram visualiserbar data. Dessa modifieringar i kombination med många Excelark resulterar i att ledtiderna för att uppdatera en Power BI rapport blir väldigt långa. Nu önskas det att istället nyttja en databaslösning för den data dessa Excelfiler innehåller och därmed förbättra dessa ledtider. Således skapades en databas utifrån den data dessa Excelfiler innehöll. Power BI tillåter användaren att importera data från en databas till applikationen på två sätt, via Import Mode eller DirectQuery. Import Mode läser in samtliga tabeller som efterfrågas och lagrar dessa i minnet. DirectQuery ställer frågor direkt till databasen utifrån vad som efterfrågas. I och med denna skillnad i importsätt finns metoder för att optimera den databas som data läses in ifrån. Studien undersöker hur olika typer av indexering och olika typer av kompression av dessa index påverkar svarstiden på frågor ställda av Power BI för att besvara följande två forskningsfrågor: Hur påverkar olika typer av indexering av en databas datahämtningshastigheten vid användning av Power BI? Hur påverkar olika typer av kompression av index datahämtningshastigheten vid användning av Power BI? Studien utfördes genom att studera execution plans och exekveringshastighet för de frågor som ställdes mot databasen av Power BI. Med hjälp av T-SQL kunde exekveringshastigheten för en specifik fråga tas fram. Denna exekveringshastighet jämfördes sedan för de olika typerna av index och kompression mot exekveringshastigheten för samma fråga mot en tabell helt utan index. Detta utfördes sedan på tabeller med varierande antal rader, där antalet rader som testades var 33 001, 50 081, 100 101, 500 017 och 1 000 217. Resultatet av studien visar att för Import Mode är det bästa typen av index ett clustered rowstore index utan kompression, med undantag för tabeller med över 1 001 217 rader där radkompression presterade bättre. För DirectQuery presterade non-clustered rowstore index bäst, men för vilken kompression var resultatet tvetydigt. Detta eftersom samtliga typer av kompression presterade bäst för olika antal rader i tabellen. För tabeller med fler än 500 017 rader presterade dock ingen kompression allra bäst. / In the measurement room at Sandvik Coromant there is a solution for visualizing machine health, measurement history and service times for different measuring instruments. The data visualization solution uses Power Bi and connects to Excel files. Once the data has been collected, a number of modifications are made on the tables to produce something that is possible to visualize. These modifications in combination with many Excel sheets result in very long lead times for updating a Power BI report. Now it is desired to use a database solution for the data contained in the Excel files and thus improve these lead times. For this, a database was created based on the data that these Excel files contained. Power BI allows the user to import data from a database into the application in two ways, via Import Mode or DirectQuery. Import Mode loads all the requested tables and stores them in memory. DirectQuery runs queries directly to the database, based on what is requested. Due to this difference, there are methods to optimize the database from which the data is loaded. This study examines how different types of indexing and different types of compression affect the response time for queries ran by Power BI to answer the following two research questions: How do different types of indexing affect a database's data retrieval rate when using Power BI? How do different types of compression affect the data retrieval rate when using Power BI? This was done by studying execution plans and execution rate for the queries that was done towards the database by Power BI. With the help of T-SQL, the execution rate for a specific query was obtained. The execution rate for different types of index and compression was then compared against a table without an index. This was then performed on tables with varying numbers of rows, where the numbers of rows that were tested was 33 001, 50 081, 100 101, 500 017 and 1 000 217. The results of the study show that for Import Mode, the best type of index is a clustered rowstore index without compression, with the exception of tables with over 1 001 217 rows where row compression performed better. For DirectQuery, non-clustered rowstore index performed best, but for which compression the result was ambiguous. This was because all types of compression performed best for different number of rows in the table. However, for tables with more than 500 017 rows, no compression performed best.

This diploma thesis focuses on the design, development and subsequent implementation of the web application at the company BKB Metal Plc. In that case it is the complete supply ready-made solution. The aim of this work is to develop and implement the web application into corporate environment that will serve as a support of project management and will especially provide the solution for creating visualization by using a Gantt diagram. The impetus for this project was primarily the inconvenient of the current solution, which is not support the key company requirements and as well efforts to reduce costs.

At the very beginning of the diploma thesis, we introduce the reader to the issues of BI and controlling of manufacturing companies. Subsequently, we perform an analysis and evaluation of the current state of the selected manufacturing company in terms of variations in production. Then we use MSSQL server and SSAS to create a controlling model. The company will be able to unambiguously and quickly identify weaknesses in production and quickly eliminate them. Finally, we evaluate the real benefits of this project for the company.

he goal of this thesis is to analyze current situation in the area of internet commerce and design and implement own application to solve administration of customers and productcs of the firm, which deals with selling musical pieces in electronic form. The main component will be an internet shop based on subscribed custom accounts and enabled prompt offtake of the musical pieces. Designed system will be implemented as a WWW application in PHP language with using database MySQL.

This thesis deals with the design and implementation of a dynamic user-definable dashboard. The user will be able to define conditions dynamically, which will filter out and save only the data he needs. The application will support the changing of the condition definitions and the display of the graphs after they were created. The current implementations available on the internet are usually solutions designed to fit only one type of project and are not designed to meet general guidelines for a dashboard. The dashboard is designed for a smooth cooperation with high load databases and therefore not to slow down the whole solution.

No description available.