BRUNA GONÇALVES
BANCO DE DADOS PARA REGISTROS HOSPITALARES DE
CÂNCER: UM ESTUDO DIRECIONADO PARA PROJETO E
AVALIAÇÃO
Santa Rosa 2017
BANCO DE DADOS PARA REGISTROS HOSPITALARES DE
CÂNCER: UM ESTUDO DIRECIONADO PARA PROJETO E
AVALIAÇÃO
Trabalho de Conclusão de Curso do curso de Ciência da Computação da Universidade Regional do Noroeste do Estado do Rio Grande do Sul como requisito básico para obtenção de grau de Bacharel em Ciência da Computação.
Orientador: Prof. Me Leonardo Minelli
Santa Rosa 2017
BANCO DE DADOS PARA REGISTROS HOSPITALARES DE
CÂNCER: UM ESTUDO DIRECIONADO PARA PROJETO E
AVALIAÇÃO
Trabalho de Conclusão de Curso apresentado ao Curso de Ciência da Computação do Departamento de Ciências Exatas e Engenharias (DCEEng), da Universidade Regional do Noroeste do Estado do Rio Grande do Sul (UNIJUÍ), como requisito para a obtenção do título Bacharel em Ciência da Computação.
Santa Rosa, 14 de julho de 2017
Prof. Leonardo Minelli Mestre pela Universidade Federal de Santa Maria - Orientador BANCA EXAMINADORA Prof. Romario Lopes Alcantara (UNIJUÍ) Mestre pela Universidade Federal de Santa Catarina
Bendito seja Deus que não rejeitou a minha oração, nem retirou de mim a sua misericórdia. (Salmo 65,20).
Agradeço primeiramente a Deus por me ajudar a superar as dificuldades.
Ao meu orientador Leonardo Minelli, pelo suporte e dedicação na orientação, pelas correções e incentivos que tornaram possível a realização e conclusão deste trabalho;
A todos os professores, por todo conhecimento compartilhado, pela dedicação e conselhos que levarei para minha vida.
A minha mãe, meu irmão, meu companheiro Mateus e todos meus familiares, pelo amor, incentivo, apoio, por acreditarem na minha capacidade de concluir mais esta etapa da minha vida para crescimento profissional e pessoal, me ajudando com as dificuldades encontradas durante a graduação;
Aos colegas que se tornaram verdadeiras amizades nestes anos de estudos, pelo apoio constante, pela ajuda mutua perante as dificuldades, pelas alegrias, tristezas e vitórias compartilhadas.
E a todos que direta ou indiretamente fizeram parte da minha formação, o meu muito obrigada.
Ninguém é suficientemente perfeito, que não possa aprender com o outro e, ninguém é totalmente destituído de valores que não possa ensinar algo ao seu irmão.
GONÇALVES, Bruna. Banco de Dados para Registros Hospitalares de Câncer: Um Estudo Direcionado para projeto e Implementação. 2016. Trabalho de Conclusão de Curso. Curso de Ciência da Computação, Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUÍ, Santa Rosa, 2017.
Os Registros Hospitalares de Câncer (RHC) tornaram-se um instrumento essencial e determinante em apoio a formulação de política nacional de prevenção e vigilância do Câncer. Todos os anos é realizada a divulgação dos RHC, de forma padronizada em todo país, e seus dados são disponibilizados através do Integrador de Registros Hospitalares de Câncer (IRHC). O banco de dados do IRHC possui um grande volume de dados e informações que são incrementados a cada ano, o que implica diretamente na complexidade da modelagem e implementação deste banco. Uma quantia massiva de dados exige recursos computacionais elevados para realizar as consultas e cláusulas SQL. Em vista disto, este trabalho apresenta um estudo de caso com base nos RHC através do desenvolvimento de modelagens distintas para realização de testes comparativos com foco na otimização de desempenho na execução de consultas dos dados, possibilitando novas representações e implementações para este banco de dados.
GONÇALVES, Bruna. Banco de Dados para Registros Hospitalares de Câncer: Um Estudo Direcionado para projeto e Implementação. 2016. Trabalho de Conclusão de Curso. Curso de Ciência da Computação, Universidade Regional do Noroeste do Estado do Rio Grande do Sul – UNIJUÍ, Santa Rosa, 2016.
The RHC (Registros Hospitalares de Câncer - Cancer Hospital Records) has become an essential and decisive instrument in support of the formulation of a national cancer prevention and surveillance policy. Every year, the RHC are disseminated in a standard way throughout the country, and all data are made available through the IRHC (Integrador de Registros Hospitalares de Câncer - Integrator of Cancer Hospital Records). The IRHC database has a large quantity of data and information that is incremented each year, which directly implies the complexity of the modeling and implementation of this database. A massive quantity of data requires high computational resources to perform SQL queries. This way, this monograph presents a case study based on the RHC through the development of different models for conducting comparative tests with a focus on performance optimization in the execution of data queries, making possible new representations and implementations for this database.
Figura 1: Representação do minimundo ... 16
Figura 2: Representação do projeto de um banco de dados ... 19
Figura 3: Esquema gráfico do modelo conceitual ... 20
Figura 4: Representação de entidade-relacionamento ... 21
Figura 5: Exemplo de tabelas de banco de dados ... 22
Figura 6: Representação do modelo lógico relacional... 22
Figura 7: Exemplo de script (conjunto de comando DDL) ... 23
Figura 8: Análise de dados para apoio a decisão ... 36
Figura 9: Exemplos de transações no modelo de data warehouse ... 38
Figura 10: Ficha de Registro de Tumor ... 43
Figura 11: Modelo ER do banco de dados RHC1 ... 45
Figura 12: Modelo ER do banco de dados RHC2 ... 47
Figura 13: Esquema lógico do banco de dados RHC1 ... 49
Figura 14: Esquema lógico do banco de dados RHC2 ... 50
Figura 15: Item 43 da Ficha de Registro de Tumor ... 52
Figura 16: Script tabela histórico_familiar_cancer do RHC1 ... 52
Figura 17: Script SQL para consulta no banco de dados RHC1 ... 55
Figura 18: Script SQL para consulta no banco de dados RHC2 ... 55
Figura 19: Script SQL para consulta no banco de dados RHC1 ... 55
Figura 20: Script SQL para consulta no banco de dados RHC2 ... 55
Figura 21; Script SQL para consulta nos bancos de dados RHC1 e RHC2 ... 56
Figura 22: Script SQL para consulta nos bancos de dados RHC1 e RHC2 ... 56
Figura 23: Script SQL para consulta nos bancos de dados RHC1 e RHC2 ... 56
Figura 24: Script SQL para consulta nos bancos de dados RHC1 e RHC2 ... 57
Figura 25: Script SQL para consulta no banco de dados RHC1 ... 57
Figura 26: Script SQL para consulta no banco de dados RHC2 ... 57
Figura 27: Script SQL para consulta no banco de dados RHC1 ... 57
Figura 28: Script SQL para consulta no banco de dados RHC2 ... 58
Tabela 1: Representação das situações críticas ... 27
Tabela 2: Estrutura do banco de dados do RHC da ficha de registros de tumores ... 29
Tabela 3: Críticas e estrutura do banco de dados para a ficha de seguimento ... 33
Tabela 4: Números de dados inseridos nos bancos de dados RHC1 e RHC2 ... 53
Tabela 5: Comparação do espaço em disco ocupado pelos bancos RHC1 e RHC2 .... 61
Tabela 6: Comparação do tempo das consultas SQL do RHC1 ... 62
Tabela 7: Comparação do tempo das consultas SQL do RHC2 ... 63
Tabela 8: Comparação do tamanho ocupado em disco pelos bancos de dados com diferentes tipos de dados ... 64
ACID Atomicidade, Consistência, Isolamento e Durabilidade BD Banco de dados ou Base de dados
CACON Centros de Tratamento de Alta Complexidade CBO Classificação Brasileira de Ocupações
DER Diagrama Entidade Relacionamento
DDL Data Definition Language (Linguagem de Definição de Dados)
DSS Decision Support Systems (Sistemas de apoio à decisão)
ER Entidade Relacionamento
IBGE Instituto Brasileiro de Geografia e Estatística
INCA Instituto Nacional de Câncer José Alencar Gomes da Silva IRHC Integrador de Registros Hospitalar de Câncer
OLAP On Line Analytical Processing (Processamento Analítico On-line)
RHC Registro Hospitalar de Câncer
SGBD Sistema Gerenciador de Banco de Dado
SisRHC Sistema para Informatização dos dados de Registros Hospitalares de Câncer SQL Structured Query Language (Linguagem de Consulta Estruturada)
SVS Secretaria de Vigilância em Saúde
1 INTRODUÇÃO ... 13 2 REFERENCIAL TEÓRICO ... 15 2.1 BANCO DE DADOS ... 15 2.1.1 Modelo Conceitual ... 19 2.1.2 Modelo Lógico ... 21 2.1.3 Modelo Físico ... 22
2.2 INTEGRADOR DOS REGISTROS HOSPITALARES DE CÂNCER ... 23
2.2.1 Regras de Negócios ... 25
2.2.2 Dados Disponíveis ... 26
2.3 BIG DATA E DATA WAREHOUSE ... 34
2.3.1 Big Data ... 34
2.3.2 Data Warehouse ... 36
3 DESENVOLVIMENTO E REPRESENTAÇÃO EM MYSQL DO BANCO DE DADOS DO IRHC ... 40
3.1 MODELO CONCEITUAL ... 41
3.1.1 Primeiro Banco de Dados RHC1 ... 43
3.1.2 Segundo Banco de Dados RHC2 ... 46
3.2 MODELO LÓGICO ... 48
3.3 MODELO FÍSICO ... 51
3.4 AVALIAÇÃO DO DESEMPENHO ENTRE PROJETOS ... 52
3.4.1 Comparativo entre Relacionamentos ... 54
3.4.2 Comparativo entre Tipos de Dados ... 58
4 ANÁLISE DOS RESULTADOS ... 61
5 CONCLUSÃO ... 67
REFERÊNCIAS ... 70
1 INTRODUÇÃO
O projeto e modelagem de banco de dados sofreu significativas evoluções nos últimos anos devido aos avanços das aplicações empresariais com o uso da modelagem relacional e sistemas de banco de dados. Os dados tornaram-se um dos recursos mais importantes das empresas e corporações, assim como a modelagem de dados, sendo uma das técnicas fundamentais utilizada nas fases de planejamento e análise dos projetos de sistemas da informação. É necessário procurar o equilíbrio entre a análise dos processos e dos dados envolvidos na modelagem e projeto de banco de dados, com base na visão do negócio, sendo a informação o objetivo final de toda aplicação. (MACHADO, 2008a, p.13).
Um banco de dados pode abranger diferentes complexidades. Esta complexidade pode ser representada por um banco de dados simples, com poucos registros e poucas tabelas, até bancos de dados com uma quantia massiva de tabelas e, por consequência, registros. Os bancos de dados complexos envolvem vários tipos diferentes de dados, suas interdependências e inter-relacionamentos, também podendo conter um grande número de itens inseridos (GUIMARÃES, 2003, p. 14).
Fatores como uma grande quantidade de registros, as interdependências e inter-relacionamentos destes implicam diretamente na complexidade da modelagem e implementação do banco de dados, exigindo recursos computacionais expressivos para realizar as buscas pelos dados contidos na base. Por esses motivos, um banco de dados nessas proporções necessita de uma estrutura consistente e robusta, havendo a obrigação desta estrutura estar otimizada. Cada etapa da modelagem dever ser cuidadosamente desenvolvida, analisada e testada para resultar em um banco de dados otimizado com recuperação dos dados de forma ágil.
Os RHC (Registros Hospitalares de Câncer) são divulgados todos os anos, após validação e consolidação. Os dados são armazenados de acordo com um único padrão utilizado por todos os estados e centros de oncologia do país (KLIGERMAN, 2001). Estes dados são disponibilizados através do IRHC - integrador de dados desenvolvido para criar um banco de dados nacional da incidência de câncer no país. O acesso aos dados que estão armazenados neste banco se dá através
do tabulador de dados do IRHC, podendo apenas ser acessados, analisados e extraídos de forma tabular.
O banco de dados do IRHC possui grande volume de dados e complexidade. O desenvolvimento de um modelo de dados, com aplicação de modelagens distintas no objetivo de otimizar o desempenho da execução das consultas e cláusulas SQL, possibilitará novas representações e implementações para o banco de dados, propondo soluções que abordem concisamente as regras de negócio do IRHC.
O tema deste trabalho concentra-se em representar as possibilidades destas modelagens distintas do banco de dados, utilizando os dados do IRHC. O foco principal, após a apresentação das modelagens, será a avaliação de desempenho da execução das consultas e cláusulas SQL para o banco de dados em questão. Em vista disto, o objetivo deste trabalho é realizar a avaliação da estrutura dos dados disponíveis. Baseando-se em conceitos de projeto e modelagem de banco de dados, estes dados serão trabalhados para definir quais são as melhores técnicas a serem utilizadas para prover a otimização do banco de dados.
A proposta do presente trabalho tratará o seguinte problema: como desenvolver um modelo de banco de dados com uma estrutura otimizada, baseado nos dados dos RHC do país, para a realização de trabalhos de pesquisa. Também, abordará como organizar esta estrutura e quais técnicas utilizar, para que resulte em um melhor desempenho na execução das consultas e cláusulas SQL do banco de dados.
2 REFERENCIAL TEÓRICO
Para o desenvolvimento do trabalho foram elaboradas pesquisas e estudos sobre os temas relacionados com o mesmo, a descrição teórica apresentada neste capítulo abrange os seguintes temas: modelagem e projeto de banco de dados, modelagem conceitual, modelagem lógica, modelagem física, Sistema Gerenciador de Banco de Dados (SGBD), Registros Hospitalares de Câncer (RHC) e Integrador de Registros Hospitalares de Câncer (IRHC), big data e data
warehouse.
2.1 BANCO DE DADOS
O surgimento e evolução da área de banco de dados, na tecnologia da informação, possibilitou o armazenamento digital de dados, que anteriormente eram armazenados em arquivos físicos por empresas e organizações. Isto causou uma revolução não apenas em sistemas empresariais, mas também em aplicações utilizadas por usuários domésticos. De acordo com Navathe (2005, p. 4), os bancos de dados estão presentes de forma intrínseca na vida da sociedade moderna, tornando-se componentes essenciais do cotidiano. Visto que no decorrer do dia, a maioria das pessoas se depara com atividades que envolvem interações com os bancos de dados, seja através de um depósito bancário, acessando o catálogo de uma biblioteca virtual ou comprando um produto de um fornecedor através de sua página web.
Segundo Heuser (2009, p. 22), um banco de dados é definido como um conjunto de dados integrados que possuem o objetivo de atender um conjunto de sistemas. Esses conjuntos de dados são uma representação da realidade captada de acordo com os requisitos das aplicações que serão realizadas sobre os dados. Machado (2008a, p. 20) descreve a porção da realidade representada pelos dados como minimundo, pois representa um aspecto do mundo real, e qualquer alteração que esse sofrer será automaticamente refletida no banco de dados.
Figura 1: Representação do minimundo
Fonte: Machado (2008a, p. 20).
Possuir dados integrados, ou seja, relacionados entre si, é característica fundamental do banco de dados. Esses inter-relacionamentos de dados exigem regras de consistência para o gerenciamento do mesmo. Podendo tais regras ser muito simples, apenas envolvendo um pequeno conjunto de dados, ou muito complexas, abrangendo um grande conjunto de informações que refletem a forma específica de gerenciamento de uma empresa, por exemplo. Estas regras são denominadas regras de negócio e proporcionam a consistência do banco de dados, sendo isto um dos requisitos fundamentais que um banco de dados deve atender para garantir pleno funcionamento e manutenção. (GUIMARÃES, 2003, p. 20).
Outro requisito fundamental de um banco de dados moderno é a atomicidade. Este refere-se ao suporte a transações, em geral envolvendo diversas operações conjuntas no banco de dados, principalmente várias operações de atualização. Por exemplo, a transferência de uma quantia de dinheiro de uma conta bancária A para conta B, neste caso são exigidas duas atualizações, uma para retirar o dinheiro da conta A e outra para depositar esse dinheiro na conta B. Se declarado pelo usuário que as duas atualizações fazem parte da mesma transação, deve ser garantido que ambas sejam realizadas ou nenhuma delas, mesmo que ocorram falhas em meio ao processo, como queda de energia por exemplo. (DATE, 2003).
Já o controle de concorrência é um dos requisitos mais complexos, pois o banco de dados requer o acesso simultâneo ou concorrente dos dados e deve ser realizado sem que as operações possam causar inconsistências. Uma exemplificação para ilustrar este requisito seria um sistema de reservas de passagens aéreas, em que dois agentes de viagens descobrem uma última vaga de
um voo concorrido. Seria inaceitável que eles pudessem reservar esta passagem para passageiros distintos (GUIMARÃES, 2003, p. 21).
O banco de dados também deve possuir persistência ou durabilidade dos dados, o requisito mais básico que aborda o armazenamento confiável, assim o sistema deve ser robusto para se recuperar de problemas como falta de energia ou falha nos discos sem perdas dos dados (GUIMARÃES, 2003, p. 21). Esse conjunto de requisitos que um banco de dados deve atender para garantir o pleno funcionamento e manutenção, é denominado ACID (atomicidade, consistência, isolamento e durabilidade).
Para tornar possível que o banco de dados atenda todos estes requisitos, o projeto, o desenvolvimento e a manutenção de um banco de dados exige a utilização de programas robustos para auxiliar neste processo. Guimarães (2003, p. 21) relata que estes programas deveriam ser suficientemente genéricos, permitindo a criação e manutenção de qualquer banco de dados, independentemente da aplicação pretendida.
Os Sistemas Gerenciadores de Banco de Dados (SGBD) são os programas utilizados para o desenvolvimento e manutenção dos bancos de dados. Segundo Heuser (2009, p. 23), são softwares que incorporam as funções de definição, recuperação e alteração de dados em um banco. Os SGBDs descrevem a estrutura de um banco de dados que é armazenada na forma de metadados, estes são conceituados como dados referenciais de outros dados. Os metadados possibilitam a facilidade para o entendimento do relacionamento das informações contidas no banco de dados.
Guimarães (2003, p. 22) ressalta que o SGBD possui como outras tarefas: permitir apenas o acesso autorizado aos dados, restringindo certos dados a determinada categoria de usuário, ou restringindo atividades como remoção de dados e atualização a determinados tipos de dados e usuários; proporcionar recursos de backup do banco de dados e sua posterior recuperação; possibilitar aos usuários meios para apresentação de uma descrição ou representação conceitual dos dados que seja independente, ou ao menos esconda a representação interna dos dados. Este processo é denominado de modelagem de dados, um dos mais importantes aspectos do projeto de um banco de dados.
A modelagem de dados é um estudo de informações existentes em um contexto, a fim de construir um modelo de representação e entendimento para este. O objetivo é minerar informações
que representam um contexto e organizá-las em um conjunto denominado modelo de dados (MACHADO, 2008a, p. 16). Segundo os autores Heuser (2009, p. 24) e Machado (2008a, p. 16), o modelo de dados é um conjunto de conceitos que podem ser utilizados para realizar uma descrição formal dos tipos de informações armazenadas em um banco dados, além de sua estrutura lógica e, ou física.
A modelagem de dados proporciona diferentes níveis de abstração dos dados, que podem permitir a omissão de aspectos da estrutura física do banco. O objetivo é facilitar a compreensão da organização dos dados, ou conter maior detalhamento de informações sobre a organização da estrutura de um banco de dados.
De acordo com Heuser (2009, p. 24), em um projeto de banco de dados, geralmente considera-se dois níveis de abstração de modelos de dados: o modelo conceitual e o modelo lógico, possibilitando a construção de modelos de dados com vários níveis de abstração e a utilização de diferentes técnicas e aplicações de conceitos. Este conjunto de conceitos são chamados de abordagem de dados e são utilizados na construção de um modelo.
Segundo Guimarães (2003, p.32), o modelo lógico está entre a modelagem de dados que é independente do SGBD e a última etapa do projeto do banco de dados que é específica ao SGBD, o modelo físico. Este corresponde a organização interna do armazenamento de dados pelo SGBD, como também a estrutura de dados auxiliares com o propósito de promover maior eficiência na recuperação e manipulação dos dados.
Figura 2: Representação do projeto de um banco de dados
Fonte: Guimarães (2003, p.33)
Observa-se na figura 2 que, partindo da realidade captada, são definidos os requisitos para a criação do modelo conceitual na primeira etapa. Então, com base neste, inicia-se a segunda etapa com a criação do modelo lógico e após, o desenvolvimento do esquema físico, na última etapa.
2.1.1 Modelo Conceitual
O modelo conceitual é a primeira etapa do projeto de banco de dados, na qual busca-se descrever o banco de dados independente do SGBD. Segundo os autores Heuser (2009, p. 25) e Guimarães (2003, p. 32), esta etapa representa e descreve a realidade do ambiente do problema, proporcionando uma visão global dos dados e seus relacionamentos, ou seja, a estrutura da informação. Assim, o modelo conceitual descreve quais dados podem estar presentes no banco de dados, mas não aborda como estarão armazenados a nível de SGBD.
Para o desenvolvedor, o modelo conceitual é uma descrição em alto nível com o objetivo de possibilitar ao usuário final ou uma pessoa leiga, fácil entendimento de como as informações requisitadas pelo problema serão estruturadas e manipuladas no banco de dados. Porém ao mesmo tempo, é uma maneira de formalizar os aspectos do projeto.
O modelo conceitual não está vinculado a aspectos como a abordagem de qual banco de dados será utilizado ou as formas de acesso e estruturas físicas, que são implementadas em um SGBD. Sem o modelo conceitual não é possível obter uma visão clara das regras de negócio, com riscos de criar aplicações sem compreender o propósito para qual foram criadas (MACHADO, 2008a, p. 21).
Figura 3: Esquema gráfico do modelo conceitual
Fonte: Machado (2008a, p.21)
Como representado na figura 3, através do modelo conceitual obtêm-se um esquema gráfico a partir das informações de um contexto de negócios. Este é a formalização da estrutura de dados e organização destas informações, baseando-se nas representações gráficas padronizadas de acordo com a modelagem utilizada.
Segundo Heuser (2009, p.25), a técnica de modelagem conceitual usualmente utilizada é a abordagem entidade-relacionamento (ER). Nesta técnica, o modelo conceitual é representado pelo diagrama entidade-relacionamento (DER), como é possível visualizar na figura 4 a seguir.
Figura 4: Representação de entidade-relacionamento
Fonte: Heuser (2009, p. 26)
A figura 4 mostra a representação das entidades Produto e Tipo de produto, assim como os dados que serão contidos nestas. O losango representa o relacionamento entre as entidades, ou seja, a regra que especifica o inter-relacionamento entre os dados.
2.1.2 Modelo Lógico
Esta etapa é iniciada somente após a modelagem conceitual do banco de dados. Segundo Heuser (2009, p. 26) o objetivo é transformar o modelo conceitual em um modelo lógico, que é a descrição de um banco de dados no nível da abstração utilizada pelo usuário do SGBD. Portanto, é nessa etapa que se define como um banco de dados será implementado, estando diretamente relacionada com SGBD que for utilizado.
Segundo Machado (2008a, p. 21), realizar a elaboração direta do modelo lógico induz a análise do contexto sob a ótica tecnológica, perturbando uma interpretação pura deste. Nestes casos ocorre a distorção da realidade, resultando em restrições da tecnologia e modelos de dados que não tem aderência ao minimundo descrito.
Heuser (2009, p. 26) descreve que em um modelo lógico referente ao SGBD relacional, os dados são organizados em tabelas, devendo-se definir quais estarão presentes no banco de dados, assim como os nomes das colunas de cada. Esta representação é demonstrada nas figuras 5 e 6.
Figura 5: Exemplo de tabelas de banco de dados
Fonte: Heuser (2009, p. 27)
Figura 6: Representação do modelo lógico relacional
Fonte: Heuser (2009, p. 27)
2.1.3 Modelo Físico
O modelo físico é a última etapa do projeto de banco de dados. Segundo Machado (2008a, p. 22), esta é construída a partir do modelo lógico, descrevendo as estruturas físicas de armazenamento dos dados. Estas estruturas podem ser exemplificadas como: tipo e tamanho de campos, índices, domínio de preenchimento desses campos, nomenclaturas, exigência de conteúdo, gatilhos e etc.
Heuser (2009, p. 29) descreve que, no modelo físico, os detalhes do armazenamento interno podem não influenciar sobre a programação de aplicações no SGBD, mas podem influenciar no desempenho destas. Esses detalhes referem-se às estruturas de arquivos utilizadas no acesso a informação, implicando na otimização do desempenho.
Para alcançar um bom desempenho do SGBD, as estruturas devem ser projetadas de acordo com os requisitos de processamento e de forma que os recursos computacionais sejam economizados, como por exemplo, o espaço ocupado pelo banco de dados no disco rígido. O modelo físico detalha o estudo de métodos de acesso do SGBD, com a finalidade de criar os índices necessários para as informações apresentadas nos modelos conceitual e lógico (MACHADO, 2008a, p. 22).
Ainda de acordo com Machado (2008a, p. 23), é no modelo físico que será utilizada a linguagem de definição de dados do SGBD (DDL) para a montagem do banco de dados. No ambiente de banco de dados relacional, o conjunto de comandos SQL (DDL) é denominado de script de criação do banco de dados e são executados pelo SGBD, o que resulta na criação do banco de dados correspondente ao modelo físico.
Figura 7: Exemplo de script (conjunto de comando DDL)
Fonte: Machado (2008a, p. 23)
2.2 INTEGRADOR DOS REGISTROS HOSPITALARES DE CÂNCER
No Brasil, os Registros Hospitalares de Câncer (RHC) têm se consolidado durante anos como o instrumento de apoio a formulação da política nacional de prevenção e vigilância do câncer. Esses registros também auxiliam no planejamento da assistência oncológica, no processo administrativo hospitalar, e a elaboração de trabalhos científicos (Kligerman, 2001).
A consolidação e permanente atualização dos RHC são realizadas pelo INCA (Instituto Nacional de Câncer José Alencar Gomes da Silva), juntamente com a Secretaria de Vigilância em Saúde (SVS) e organizações governamentais e não governamentais. O objetivo fundamental é aprimorar a política de prevenção e vigilância do câncer, seus fatores de risco e, consequentemente,
reduzir a incidência e a mortalidade por câncer para melhorar a qualidade de vida da população (INCA, 2010; INCA 2012).
Os Registros Hospitalares de Câncer têm a sua importância reconhecida como centros responsáveis pela coleta, análise e divulgação de forma contínua e sistemática de informações sobre o comportamento da doença, suas características e tendências (INCA, 2012). Nos últimos anos os RHC multiplicaram-se pelo país, consolidando essa sua participação como fonte de informações para o planejamento e a assistência ao paciente oncológico (INCA, 2016).
O crescimento do alcance dos RHC pelo país deu-se, em grande parte, pela Portaria GM/MS nº 3.535/98 do Ministério da Saúde, que incluiu a exigência dos Registros Hospitalares de Câncer nos critérios para cadastramento dos CACONs (Centros de Tratamento de Alta Complexidade) nos hospitais (INCA, 2010). Com a exigência obrigatória de RHC nesses hospitais, tornou-se possível a criação de um banco de dados com as informações coletadas de incidências da doença atendidas por estas instituições.
O INCA é o responsável por viabilizar os mecanismos que propiciam a integração, a padronização e a continuidade de funcionamento dos Registros de Câncer. Estas ações são efetivadas através da capacitação de profissionais e do desenvolvimento de programas para a informatização de dados coletados pelos RHC (Kligerman, 2001).
Da mesma forma, o INCA também proporciona o apoio técnico e divulgação dos dados do RHC. Sendo assim, desenvolveu e implantou um sistema web para o envio, consolidação, acompanhamento e análise dos dados nacionais dos RHC brasileiros. Este sistema abrange a captação de dados, realizada através do SisRHC (Sistema para Informatização dos dados de Registros Hospitalares de Câncer) e a consolidação das informações no IRHC (Integrador de Registros Hospitalares de Câncer) (INCA, 2010).
O IRHC é a aplicação com a função de consolidar os dados hospitalares do RHC. É ele que faz a criação do banco de dados nacional com as informações coletadas, e possibilita o acesso a essa base de dados para análise, pesquisa, tabulações e exportações.
2.2.1 Regras de Negócios
As informações chegam aos Registros Hospitalares de Câncer de diversas formas, através de fichas de notificação, relatórios impressos ou mídias eletrônicas. O processo para a organização destas informações dá-se em duas etapas: codificação e a validação (INCA, 2012).
A organização das informações requer um processo de codificação. Para prover uma forma segura de alcançar comparabilidade entre os registros é preciso utilizar os sistemas de codificação reconhecidos internacionalmente como a CID-O (Classificação Estatística Internacional de Doenças e Problemas Relacionados à Saúde) para classificar os tumores, a CBO (Classificação Brasileira de Ocupações) para classificar as profissões e a classificação do IBGE (Instituto Brasileiro de Geografia e Estatística) para localidades (INCA, 2012).
A validação do banco de dados é uma importante etapa do RHC realizada de acordo com cada ano-calendário. A análise de casos e as solicitações de levantamento dos bancos de dados do RHC, são feitos de acordo com o ano da matricula do paciente no hospital. Cada RHC coleta um conjunto de dados que podem variar dependendo das necessidades de cada instituição. Assim, definir quais itens serão utilizados a partir da lista de itens classificados como opcionais ou complementares é uma decisão importante no início da coleta de dados (INCA, 2010).
Porém, existe o conjunto mínimo dos itens obrigatórios, a nomenclatura e as definições referentes a cada item são as mesmas para todo registros, independente dos itens adicionais selecionados. Esses itens são estabelecidos com base nas classificações nacionais ou padrões internacionais recomendados para as instituições de saúde (INCA, 2010). Todas as informações coletadas são transferidas para um computador após o processo de organização e posteriormente armazenadas em um banco de dados do SisRHC.
A etapa de validação das informações do banco de dados do SisRHC é realizada pelo coordenador do RHC, isto ocorre antes da liberação final das informações do banco de dados para consultas e da transmissão dos dados para o IRHC. Essa etapa é a finalização do processo de alimentação do SisRHC que foi iniciada com a identificação de novos casos de câncer, seguida pela coleta de dados e sua transcrição para fichas de Registros, e incluídas na base de dados (INCA, 2010).
Quando selecionado para inclusão no RHC, o caso deve ser classificado como analítico ou não analítico e esta tarefa compete exclusivamente ao registrador de câncer. Essa seleção é importante para a determinar se o caso terá ou não seguimento (INCA, 2010).
2.2.2 Dados Disponíveis
Durante a etapa dos registros são cadastradas todas ocorrências de câncer coletadas. O sistema irá proceder de acordo com críticas de consistência: sexo, idade, topografia, morfologia, dentre outras. Porém, após o cadastro, mesmo com críticas o caso poderá ser incluído com invalidações e apenas será válido após verificação e correção destas inconsistências (INCA, 2012). As críticas estão incluídas no SisRHC com o objetivo de facilitar o processo de validação para identificar inconsistências e os casos que não estão enquadrados nas regras gerais de coerência pré-definidas. Algumas das críticas referem-se apenas às opções disponíveis em cada item das fichas para evitar as inclusões de dados inexistentes nos itens, como exemplo, o item sexo que apenas são aceitas as duas opções: masculino e feminino. Já para outros itens, leva-se em consideração o cruzamento de determinados itens com outros presentes na ficha. Isto ocorre com a crítica que correlaciona sexo com topografia, por exemplo, não é aceito tumor de testículos em mulheres ou tumor de colo uterino em homens. (INCA, 2010).
No final do processo de registro dos casos, poderão ocorrer situações que não estavam previstas segundo as regras do RHC. Os casos registrados que houverem uma ou mais invalidações serão analisados pelo coordenador do RHC ou por um registrador experiente designado por esse. Nestas situações é conferido se os casos são decorrentes de erros de digitação ou se tratam de casos incomuns, mas passíveis de ocorrer. (INCA, 2010; INCA, 2012).
O coordenador do RHC deve ter o conhecimento pleno das regras de cadastro de casos e também do significado e correlações de cada item da ficha. Apenas assim é possível realizar a análise crítica do banco de dados e validar casos inconsistentes. Esta função possibilita a visualização de todos os casos que geram inconsistências e não foram resolvidos. (INCA, 2010; INCA, 2012). As críticas para auxiliar os coordenadores a identificar situações de inconsistência seguem representadas na tabela 1.
Tabela 1: Representação das situações críticas
ITEM DA FICHA CRITICADO COM
ITEM DA FICHA Caso analítico • Ficha de seguimento.
Sexo • Localização do tumor primário.
Idade • Gerada a partir da data de nascimento com a data de 1ª consulta. Data da 1ª consulta • Diagnóstico e tratamento anterior.
• Data de diagnóstico.
• Data do início do tratamento no hospital.
Data do diagnóstico • Diagnóstico e tratamento anteriores.
• Data de 1ª consulta.
• Data do início do tratamento no hospital.
Diagnóstico e tratamento anteriores
• Data da 1ª consulta. • Data do Diagnóstico e.
• Data do Início do tratamento no hospital.
Localização do tumor primário • Sexo.
• Tipo histológico do tumor primário (vide correlação topografia x histologia). • Estadiamento clínico do tumor (vide TNM).
Tipo histológico do tumor primário
• Localização do tumor primário (vide correlação topografia x histologia). • Estadiamento clínico do tumor (vide TNM).
• Estadiamento patológico (pTNM) (vide TNM).
Estadiamento clínico do tumor – TNM
• Idade.
• Localização do tumor primário.
• Tipo histológico do tumor primário (vide – pTNM).
Estadiamento patológico do tumor – pTNM
• Localização do tumor primário.
• Tipo histológico do tumor Primário (vide – pTNM). • Códigos de preenchimento – TNM.
Data do início do primeiro tratamento
• Diagnóstico e tratamento Anteriores. • Data de triagem.
• Data do diagnóstico e. • Data da 1ª consulta.
Principal razão para a não realização do tratamento
• Primeiro tratamento recebido. • Data do início do tratamento. • Data do óbito.
ITEM DA FICHA CRITICADO COM Primeiro tratamento recebido
no hospital
• Principal razão para a não realização do tratamento. • Data do óbito.
• Estado da doença no final do primeiro tratamento.
Estado da doença no final do primeiro tratamento
•Principal razão para a não realização do tratamento. • Primeiro tratamento recebido.
• Data do óbito.
Data do óbito • Principal razão para a não realização do tratamento.
• Primeiro tratamento recebido.
• Estado da doença ao final do primeiro tratamento. • Causa básica da morte.
Relação do óbito do paciente com o câncer
• Data do óbito.
Indicação de realização de seguimento
• Caso analítico.
Data de preenchimento da ficha • Data da triagem.
• Data da primeira consulta.
ITEM DA FICHA CRITICADO COM
ITENS OPCIONAIS Data da triagem • Diagnóstico e tratamento anteriores.
• Data da primeira consulta. • Data do diagnóstico.
• Data do início do tratamento no hospital. • Data do óbito.
Localização provável do tumor Primário
• Localização do tumor primário.
Ocorrência de mais de um tumor primário
• Necessário o preenchimento de uma ficha para cada tumor.
Causa básica da morte do paciente
• Data do óbito.
ITENS COMPLEMENTARES Não possuem críticas no SisRHC, por serem definidas por cada Hospital.
Fonte: INCA (2010)
Com base na representação das situações críticas, é listado na tabela 2 as informações da estrutura do banco de dados do registro hospitalar de câncer, disponibilizadas pelo INCA, para a ficha de registro de tumores.
Tabela 2: Estrutura do banco de dados do RHC da ficha de registros de tumores
ITEM NOME TIPO TAMANHO PREENCHIMENTO
ITENS OBRIGATÓRIOS
- ANALÍTICO Caractere 1 dd/mm/aaaa
01 PRONTUÁRIO Caractere 7 Nº do prontuário hospitalar
- IDENTIFICAÇÃO NO RHC Caractere 20 Atribuído pelo SisRHC
02 NÚMERO DA IDENTIDADE
Caractere 16 Número do documento
03 TIPO DE DOCUMENTO
Caractere 1 1 a 9, exceto 8
04 NOME Caractere 40 Nome completo do paciente
05 NOME DA MÃE Caractere 40 Nome completo da mãe do paciente
06 SEXO Caractere 1 1,2
07 DATA NASCIMENTO Data 8 dd/mm/aaaa
08 IDADE Numérico 3 Calculado diretamente pelo sistema
09 LOCAL DE NASCIMENTO
Caractere 2 Sigla do estado ou ex (estrangeiro)
10 RAÇA / COR Caractere 1 1, 2, 3, 4, 5 ou 9
11 ESCOLARIDADE Caractere 1 1, 2, 3, 4, 5, 6 ou 9
12 OCUPAÇÃO Caractere 4 Classificação de ocupações da CBO
13 PROCEDÊNCIA Caractere 7 Classificação de municípios do IBGE
14 ENDEREÇO Caractere 70 Endereço (logradouro, número e complemento)
15 BAIRRO Caractere 20 Nome do bairro
16 CIDADE Caractere 20 Nome da cidade
17 SIGLA DA UNIDADE DA FEDERAÇÃO
Caractere 2 Sigla do estado ou ex (estrangeiro)
18 TELEFONE Caractere 10 Código da cidade e número do telefone
19 CEP – CÓDIGO POSTAL Caractere 8 Código de endereçamento postal
20 E-MAIL Caractere 24 Descrição completa do endereço eletrônico 21 DATA DA PRIMEIRA CONSULTA Data 8 dd/mm/aaaa 22 DATA DO DIAGNÓSTICO Data 8 dd/mm/aaaa
ITEM NOME TIPO TAMANHO PREENCHIMENTO 23 DIAGNÓSTICO E TRATAMENTO ANTERIOR Caractere 1 1, 2, 3, 4 ou 9 24 BASE MAIS IMPORTANTE DO DIAGNÓSTICO Caractere 1 1 a 9, exceto 8 25 LOCALIZAÇÃO DO TUMOR PRIMÁRIO
Caractere 4 Código de topografia CID-O/3º versão
26 TIPO HISTOLÓGICO DO TUMOR
PRIMÁRIO
Caractere 5 Código de histologia CID-O/3º versão
27 TNM Caractere 3 Código do TNM Clínico – 6ª edição
28.a ESTADIAMENTO INICIAL (com base no TNM)
Caractere 2 Código alfanumérico de estadiamento TNM
28.b OUTRO ESTADIAMENTO Caractere 2 Código alfanumérico de estadiamento
29 p TNM Caractere 3 Código do TNM Patológico – 6ª edição
30 LOCALIZAÇÃO DE METÁSTASE À DISTÂNCIA
Caractere 4 campos com 3
Código topográfico da metástase - CID-O/3
31 CLÍNICA DO INÍCIO DO TRATAMENTO
Caractere 2 Código da clínica de início de tratamento 32 DATA DO INÍCIO DO 1º TRATAMENTO Data 8 dd/mm/aaaa 33 RAZÃO PARA NÃO REALIZAÇÃO DO TRATAMENTO Caractere 1 1 a 9 34 PRIMEIRO TRATAMENTO RECEBIDO Caractere 8 1 a 9 35 ESTADO DA DOENÇA AO FINAL DO 1º TRATAMENTO Caractere 1 1 a 8 (exceto 7) e 9
ITEM NOME TIPO TAMANHO PREENCHIMENTO 36 DATA DO ÓBITO Data 8 dd/mm/aaaa
37 RELAÇÃO DO CÂNCER COM
O ÓBITO
Caractere 1 1, 2 e 9
38 CASO ANALÍTICO Caractere 1 1, 2
39 SEGUIMENTO Caractere 1 1, 2 40 CÓDIGO DO REGISTRADOR Caractere 1 1 a 9 - DATA DO PREENCHIMENTO DA FICHA Data 8 dd/mm/aaaa ITENS OPCIONAIS 41 ESTADO CONJUGAL ATUAL Caractere 1 1,2,3,4 e 9
42 DATA DA TRIAGEM Data 8 dd/mm/aaaa
43 HISTÓRICO FAMILIAR DE CÂNCER
Caractere 1 1, 2 e 9
44 CONSUMO DE ÁLCOOL Caractere 1 1 a 4, 8 e 9
45 TABAGISMO Caractere 1 1 a 4, 8 e 9 46 ORIGEM DO ENCAMINHAMENTO Caractere 1 1 a 4, 8 e 9 47 CLÍNICA DE ENTRADA
Caractere 2 Código da clínica
48 EXAMES RELEVANTES Caractere 1 1 a 5, 8 e 9
49 LOCALIZAÇÃO PRIMÁRIA PROVÁVEL
Caractere 3 Código de topografia CID-O/3º versão 50 LATERALIDADE DO TUMOR Caractere 1 1,2,3, 8 e 9 51 MAIS DE UM TUMOR PRIMÁRIO Caractere 1 1,2 e 3 52 CUSTEIO DO DIAGNÓSTICO Caractere 1 1 a 4, 8 e 9 53 CUSTEIO DO TRATAMENTO Caractere 1 1 a 4, 8 e 9 54 CAUSA BÁSICA DA MORTE
ITENS COMPLEMENTARES 1-7 DEFINIDOS POR CADA HOSPITAL – OPÇÕES Caractere 1 0 a 9 1-3 DEFINIDOS POR
CADA HOSPITAL – DATA
Data 8 dd/mm/aaaa
Fonte: INCA (2010)
Se o caso for classificado como analítico, torna-se necessário abrir a ficha de seguimento. Através das críticas dos itens obrigatórios todos os itens serão analisados e também suas correlações para a inclusão no SisRHC, por exemplo, o campo sexo que será cruzado com a topografia do tumor primário como já citado. Já a idade não tem crítica na entrada de dados, pois é preenchido automaticamente de acordo com a data de nascimento e a data da primeira consulta. Porém a idade será um campo chave na realização de levantamentos e seleção de casos, pois algumas topografias são prevalentes ou raras de acordo com a faixa etária (INCA, 2010).
Do mesmo modo que os itens obrigatórios, os hospitais que optarem pelo preenchimento de itens opcionais deverão submetê-los as críticas da entrada de dados no SisRHC. Um exemplo disto seria o item da data de triagem, que será sempre anterior ou igual a data da primeira consulta e a data de óbito (INCA, 2010).
No caso do seguimento de tumores utiliza-se a crítica nos itens da ficha de seguimento. Este procedimento é exclusivo para os casos classificados como analíticos e com indicação de seguimento. Se paciente possuir mais de um tumor primário classificado como analítico será feito um seguimento para cada tumor baseado na data de diagnóstico do respectivo tumor (INCA, 2010). As informações do seguimento são associadas às informações contidas na ficha de registro de tumor. A data de identificação do evento, por exemplo, possui relação direta com a data do diagnóstico do tumor e precisa corresponder a um dos períodos pré-estabelecidos (INCA, 2010).
A fonte da informação deve ser preenchida com uma das opções válidas. Se no caso for marcada a opção 2, sistema de mortalidade, torna-se obrigatório o preenchimento dos itens referente ao óbito na ficha de registro de tumor e encerrado o seguimento. Já se a opção marcada for a 09, sem informação, os itens de estado da doença, qualidade da sobrevida, tratamento
subsequente, tipo de recidiva, novas metástases e data de recidiva também devem ser preenchidos com 9, sem informação (INCA, 2010).
Se o estado da doença for preenchido por 1 a 3, paciente vivo, os itens: qualidade de sobrevida, tratamento subsequente, tipo de recidiva, novas metástases e data de recidiva devem ser preenchidos. Entretanto, se for preenchido com as opções 4 a 6, óbito, o item qualidade de sobrevida será preenchido com a opção 6 (óbito) e serão complementadas as informações dos itens referentes ao óbito na ficha de registro de tumor e encerrado o seguimento (INCA, 2010).
Segue a tabela referente a estrutura do banco de dados do registro hospitalar de câncer, para a ficha de registro de seguimento.
Tabela 3: Críticas e estrutura do banco de dados para a ficha de seguimento
NOME TIPO TAMANHO PREENCHIMENTO
Data da identificação do evento Data 8 dd/mm/aaaa
Data da última informação do paciente
Data 8 dd/mm/aaaa
Fonte de informação Caractere 1 1 a 7 e 9
Estado da doença Caractere 1 1 a 7 e 9
Qualidade da sobrevida Caractere 1 1 a 6, 8 e 9
Tratamento subsequente Caractere 8 1 a 9
Tipo de recidiva Caractere 1 1, 2, 8 e 9
Novas metástases à distância Caractere 4 campos com 3 posições
Código topográfico da CID-O/3 com 3 dígitos
Data da recidiva/metástase Data 8 dd/mm/aaaa
Fonte: INCA (2010)
A última etapa no processo de validação do banco de dados para que seja feita a sua liberação, é realizada utilizando os relatórios produzidos pelo próprio SisRHC para análise das incidências da doença. Após todas as verificações o banco de dados será liberado para consulta e transmissão para o IRHC (INCA, 2010).
2.3 BIG DATA E DATA WAREHOUSE
No cenário atual do mercado, as empresas precisam tomar decisões rápidas para desenvolver vantagens competitivas de negócios. Segundo Canary (2013) a informação tornou-se um instrumento fundamental para as empresas, pois essa pode minimizar os riscos em tomadas de decisões com base em informações relevantes e seguras.
As empresas têm armazenado grande volume de informações possuindo à disposição enormes quantidades de dados que são gerados pelos consumidores. Porém, o maior desafio enfrentado pelas empresas é como tratar adequadamente este grande volume de dados para obter informações pertinentes de apoio a tomada de decisões.
Dessa forma, as empresas necessitam utilizar métodos da tecnologia da informação para armazenar, acessar e analisar de maneira eficaz os dados. (HENRIQUES e COSTA, 2013). De acordo com as necessidades das empresas, as tecnologias de big data e data warehouse podem prover a soluções para este desafio.
2.3.1 Big Data
Com a crescente competitividade do mercado e necessidade de inovações para alavancar os negócios, torna-se fundamental para as empresas e organizações ter compreensão de como as informações permeiam os níveis estratégicos, táticos e operacionais da gerência de um negócio. O tratamento destas informações depende de uma ferramenta que deve ser determinada com base nas características da informação, como fonte, grau de repetição, precisão e a forma de classificá-las. (HENRIQUES e COSTA,2013)
Existe uma alta tendência de os dados existentes no mundo aumentarem com o passar dos anos pelo fato das pessoas divulgarem suas experiências de vida, de compras, seus interesses e sentimentos. Estes dados determinam os perfis de consumidores, fornecendo as empresas um fluxo continuo de informações. Portanto, as empresas têm utilizado o meio digital para acompanhar os consumidores e relacionar-se com o público alvo, além do armazenamento de documentações para reduzir custos com espaço físico. Dessa forma são gerados grandes volumes de dados armazenados digitalmente. (CANARY, 2013).
Devido ao surgimento destas novas fontes de dados mais detalhados, as empresas e organizações podem lidar com oportunidades de negócios que anteriormente não eram possíveis. (SCHMARZO, 2011). É necessário que as empresas determinem uma forma de tratar os grandes volumes de dados e, através de análises, extrair informações pertinentes e fundamentais para apoio de decisões.
Segundo Canary (2013) definir como lidar com estes grandes volumes de dados é um dos principais objetivos e desafios de um big data. Este é um fator que poderá trazer o diferencial no desempenho das empresas no mercado, se as informações forem trabalhadas e analisadas de forma adequada, caso contrário, pode prejudicar o negócio da empresa.
De acordo com Silva (2016), na literatura são encontradas várias definições de big data. Mas, pode-se definir como um termo utilizado para descrever conjuntos de dados em que a captura, armazenamento, distribuição e análise destes necessita de métodos e tecnologias avançadas. Isto devido a qualquer combinação do tamanho (volume), a frequência de atualização (velocidade) e sua diversidade de dados.
Da mesma forma, Henriques e Costa (2013) descreve big data como um conjunto de dados que apresentam grande volume ou rápidas mudanças. Portanto não podem ser analisados com a utilização de técnicas dos bancos de dados relacionais tradicionais, multidimensionais ou por softwares usualmente utilizados para capturar e processar dados em tempo razoável.
Um big data precisa de uma infraestrutura de tecnologia altamente dimensionável para petabytes de dados que tenha suporte ao acesso a dados de baixa latência e à tomada de decisões. É necessário que possua lógica integrada para acelerar os processos de modelagem e operacionalização. A possibilidade de novas escalas de capacidade de processamento para grandes conjuntos de dados permite a identificação de novas percepções sobre as informações provindas do big data, proporcionando novas perspectivas para tomadas de decisões das empresas. (SCHMARZO, 2011)
Segundo Henriques e Costa (2013), com a utilização de big data as empresas podem ter oportunidades de negócio significativas, entretanto alguns desafios são encontrados. A autora cita que em uma pesquisa realizada por Erik Brynjolfsson, economista da Sloan School of Management do Instituto de Tecnologia de Massachusetts (EUA), mostrou que as empresas que operam com a
tomada de decisão com base em dados alcançam um aumento de cinco a seis por cento em produtividade. Assim, a utilização do big data requer mais do que apenas coletar e analisar grandes volumes de dados, é necessária a percepção de como e quando utilizar os dados como apoio a decisões importantes, como é demonstrado a seguir.
Figura 8: Análise de dados para apoio a decisão
Fonte: Henriques e Costa (2013)
Obter a otimização dos dados corretos proporciona vantagens competitivas para uma empresa. Alinhando os processos de gerenciamento de dados com a estratégia de negócio da empresa, a análise de big data pode impactar positivamente trazendo benefícios financeiro em: desenvolvimento de produtos, desenvolvimento de mercado, eficiência operacional, experiência e lealdade do cliente, previsões de demanda do mercado. (HENRIQUES; COSTA, 2013).
2.3.2 Data Warehouse
Devido a globalização da informação que ocorreu através do avanço tecnológico nas últimas décadas, o cenário atual do mundo é um mercado competitivo entre empresas e quem domina este cenário é o que deter melhor utilização da informação. (MACHADO, 2008b, p. 13). Isto se torna fundamental para as empresas pois, através da informação, é possível conhecer o negócio e apoiar as tomadas de decisões.
Entretanto, é um desafio para as empresas gerenciar eficientemente as informações para que possam apoiar as tomadas de decisões. Assim, de acordo com Machado (2008b, p. 14), a utilização de tecnologias da informação é substancial para viabilizar o gerenciamento das informações, proporcionando vantagens competitivas no mercado. Muitas organizações detém um grande volume de dados, mas não de informações. Deste modo, a utilização de data warehouses possibilita o auxílio para que as empresas possam gerenciar e tratar o grande volume de dados para obter informações analíticas de valor.
De acordo com Dill (2002) e Navathe (2005, p. 646), com a evolução dos ambientes de suporte à decisão, surgiu o ambiente de data warehouse integrando fontes de dados dos sistemas transacionais (relacional, orientado a objetos, de rede, ou hierárquico). Assim um data warehouse proporciona armazenamento, funcionalidades e capacidades de responder consultas superiores às capacidades dos bancos de dados transacionais. Mas a principal característica distinta do data
warehouse é que suas funções são direcionadas para aplicações de processamento analítico de
informações para as organizações. É válido ressaltar que um data warehouse é otimizado para recuperação de dados, não para o processamento rotineiro de transações.
Segundo Navathe (2005, p. 647), o uso inicial do termo data warehouse é creditado a Inmon (1992), que caracterizou como “uma coleção de dados orientada por assunto, integrada, não-volátil, variante no tempo, que dá apoio ás decisões da administração”. Ou seja, os data warehouses viabilizam acesso aos dados para a realização de analises complexas, descoberta de conhecimentos e tomada de decisões. Eles dão suporte a aplicações como OLAP, DSS e também aplicações de
data mining para a realização de análises dos dados.
Em sistemas de suporte à decisão com grande volume de dados e consultas altamente complexas, os requisitos do ambiente são difíceis de determinar, acarretando na necessidade de ferramentas flexíveis e customizáveis. Desta forma são utilizados os sistemas OLAP (On Line
Analytical Processing - Processamento Analítico On-line). (HOKAMA et al., 2004).
Segundo Kanashiro (2007), os sistemas OLAP são projetados para apoiar análises e consultas no objetivo de auxiliar os usuários de alto nível a sintetizar as informações através de comparações, analises históricas e visões personalizadas. Esses sistemas proporcionam uma visão multidimensional dos dados mais fácil e intuitiva por meio de análises em diferentes perspectivas.
De acordo com Navathe (2005, p. 647), os sistemas DSS (Decision Support Systems – Sistemas de apoio à decisão), dão apoio aos líderes de uma organização, como exemplo, para tomadas de decisões complexas e importantes através de dados de alto nível. Já a data mining (mineração de dados) é utilizada para a descoberta de conhecimento, é o processo de busca de dados para o conhecimento não preditivo.
O data warehouse exige um modelo de dados apropriado que difere ele dos bancos de dados transacionais. O modelo de dados multidimensional encaixa-se bem com o OLAP e tecnologias de apoio a decisões. Diferente dos bancos de dados transacionais, os data warehouses dão apoio a análises de séries temporal e tendências, ambas requerem maior volume de dados históricos do que geralmente são mantidos em bancos transacionais. (NAVATHE, 2005, p. 647).
O modelo de um data warehouse envolve primeiramente recuperar os dados históricos de uma empresa, organização ou corporação. Após, é preciso projetar um banco de dados para armazenar todos estes dados com a finalidade de disponibilizar os dados históricos para o processo de extração, limpeza, transformação e carga de um data warehouse. Então estes processos devem ser executados e por fim utilizar ferramentas OLAP e DSS, conforme é possível visualizar na figura 9. (MACHADO, 2008b, p. 21).
Figura 9: Exemplos de transações no modelo de data warehouse
Segundo Machado (2008b, p. 22), o resultado obtido de um projeto de data warehouse possibilita:
Disponibilidade de informação para gestão; Visão de curvas de comportamento;
Agilidade de ferramentas para apoio a decisão; Segurança de informações para decisão; Maior abrangência de visão e indicadores;
3 DESENVOLVIMENTO E REPRESENTAÇÃO EM MYSQL DO BANCO
DE DADOS DO IRHC
A elaboração desse trabalho foi baseada na teoria da modelagem e implementação de bancos relacionais e nos dados do IRHC. Teve como objetivo modelar bancos de dados com estruturas distintas para os RHC e submeter estes bancos a testes de desempenho através das consultas SQL para avaliação e comparação dos dados resultantes deste estudo de caso.
Foram modelados dois bancos de dados com base nas informações coletadas pela ficha de registro de tumor, sendo este o meio de coleta de informações a partir do prontuário médico. Segundo o INCA (2010), desde 1995 esta ficha é elaborada com três conjuntos de itens obrigatórios, que são coletados por todos RHC. Também são disponibilizados itens opcionais que são escolhidos de acordo com os critérios do hospital, mas assim que forem optados, o preenchimento torna-se obrigatório. E por fim, os itens complementares são definidos por cada instituição para fim de atender demandas específicas.
A partir destes dados foram desenvolvidos primeiramente os modelos conceituais, abstraindo os dados da realidade para modelagem dos bancos de dados. Com base na estrutura destes modelos, foram gerados os modelos lógicos, que proporcionaram a base para o desenvolvimento dos modelos físicos, ou seja, o SQL dos bancos de dados. Conforme Heuser (2009, p. 29) explica: O projeto de um banco se dá em três etapas que permite diferentes abstrações ao desenvolvedor: a modelagem conceitual, o projeto logico e o projeto físico.
As ferramentas escolhidas para o desenvolvimento deste trabalho foram: BrModelo e o SGBD MySQL. Para modelagem conceitual e lógica, bem como suas representações gráficas utilizou-se o BrModelo e para o desenvolvimento da modelagem física, criação dos bancos e realização dos testes utilizou-se o MySQL.
3.1 MODELO CONCEITUAL
A modelagem conceitual dos bancos de dados, foi baseada nos dados requeridos para o preenchimento da ficha de registro de tumor. Estes são os dados que posteriormente são validados e inseridos nos bancos de dados do IRHC, de acordo com o processo seguido pelos registradores.
Seguindo a teoria de Guimarães (2003, p. 32), a modelagem conceitual consiste em mapear a visão externa dos dados, ou seja, descrever a realidade do problema afim de representar os diversos dados requeridos. É uma representação em alto nível de abstração que esconde os detalhes da implementação, mas proporciona esta posteriormente.
Desta forma, para criar os modelos conceituais foram utilizadas as informações contidas na ficha de registro de tumor para possibilitar a representação das regras de negócio dos dados. Com base na ficha foram considerados os grandes grupos de informações para assim modelar as principais entidades. Segundo o INCA (2010), os grandes grupos de informações são os itens de preenchimento obrigatório que abrangem:
Itens de identificação do paciente: Número do prontuário; Número do documento; Tipo do documento; Nome completo do paciente; Nome completo da Mãe.
Itens demográficos e culturais: Sexo do paciente; Data do nascimento do paciente; Idade do paciente na primeira consulta; Raça/cor da pele; Escolaridade do paciente na época da matricula; Ocupação principal do paciente; Procedência do paciente (código IBGE).
Itens de localização do paciente: Endereço permanente do paciente; Bairro de residência do paciente; Cidade de residência do paciente; Unidade da federação da residência do paciente; Telefone de referência do paciente; Código de endereçamento postal da residência do paciente; Correio eletrônico para contato com paciente.
Itens de caracterização do diagnóstico: Data da primeira consulta no hospital; Data do primeiro diagnóstico do tumor; Diagnóstico e tratamento anteriores; Base mais importante para o diagnóstico do tumor.
Itens de caracterização do tumor: Localização do tumor primário; Tipo histológico; Classificação do tumor maligno antes do tratamento (TNM); Estadiamento do
tumor; Outro Estadiamento clínico do tumor antes do tratamento (para sistemas de Estadiamento diferentes do TNM); Classificação dos tumores malignos, patológicos (pTNM); Localização de metástase a distância.
Itens de caracterização do primeiro tratamento: Clínica do início do tratamento no hospital; Data do início do primeiro tratamento específico para o tumor, no hospital; Principal razão para a não realização do tratamento antineoplástico no hospital; Primeiro tratamento recebido no hospital; Data do óbito; Relação do óbito do paciente com o câncer.
Itens de seleção do paciente para seguimento: Caso analítico; Indicação de realização de seguimento.
Item de identificação do registrador: Código de identificação do registrador. Os itens de preenchimento opcional são: Estado conjugal atual; Data da triagem; Histórico familiar de câncer; Histórico de consumo de bebida alcoólica; Histórico de consumo de tabaco; Origem do encaminhamento; Clinica de entrada do paciente no hospital; Exames relevantes para o diagnóstico e planejamento de terapêutica do tumor; Localização provável do tumor primário; Lateralidade do tumor; Ocorrência de mais de um tumor primário, Custeio do diagnóstico do tumor no hospital; Custeio do tratamento do tumor no hospital; Causa básica da morte do paciente.
Com base nos grupos dos itens obrigatórios e opcionais da ficha, foram criadas as principais entidades contidas nos dois bancos de dados, mas modeladas de formas distintas quanto as informações relacionadas a estas entidades:
Paciente – que abrange os Itens de identificação do paciente, Itens demográficos e culturais, Itens de localização do paciente e alguns dos Itens de preenchimento opcional;
Caso – esta entidade abrange todas as informações do diagnóstico juntamente com a caracterização do tumor, Itens de seleção do paciente para seguimento e alguns dos Itens de preenchimento opcional;
Tratamento – entidade que descreve todas as informações dos Itens de caracterização do primeiro tratamento.
Também foram criadas as seguintes tabelas de acordo com a necessidade de estruturar os dados:
CID – esta entidade lista todo o código do CID de acordo com a classificação do CID-O/3, sendo um dos itens contido nos Itens de caracterização do tumor;
Hospital e Clinica – Estas duas entidades foram criadas para identificar o local de diagnóstico e tratamento do paciente de acordo com os dados coletados, são informações encontradas nos itens de caracterização do primeiro tratamento e itens de preenchimento opcional;
Cidades IBGE e Estados IBGE – Ambas criadas para listar todas as cidades do país, seu código do IBGE e estados respectivos; para preencher os itens referente a procedência e local de nascimento do paciente, informações contidas nos itens demográficos e culturais e itens de localização do paciente;
CBO – essa entidade abrange toda a Classificação Brasileiro de Ocupações e suas descrições, sendo uma informação requerida nos Itens demográficos e culturais.
3.1.1 Primeiro Banco de Dados RHC1
A modelagem deste banco de dados tem como objetivo criar um banco com informações consistentes, impedindo que sejam adicionadas informações incoerentes com as que são padronizadas na ficha de registro de tumor. Na modelagem conceitual foram considerados os grandes grupos de informações para criar as entidades principais assim como citado. Já os itens que continham informações de múltipla escolha foram modelados como entidades relacionadas com as entidades principais, ao invés de atributos destas. Afim de evitar a inserção de valores que não correspondessem com a ficha, estas listas de informações abrangem itens como, por exemplo, o item 03 que traz uma opção de múltipla escolha conforme é possível visualizar na figura 10.
Figura 10: Ficha de Registro de Tumor
É apresentado na figura 11 o modelo ER do primeiro banco de dados, o RHC1, desenvolvido nesta etapa da modelagem conceitual. Através dele pode-se visualizar e compreender como foram estruturadas as relações dos dados e entidades modeladas, com base nas decisões citadas anteriormente.
Figura 11: Modelo ER do banco de dados RHC1
Fonte: Autoria Própria
Conforme é apresentado no modelo ER, os relacionamentos entre as entidades principais e as entidades secundárias foram considerados cardinalidades (1,1) para as informações que são obrigatórias conter na ficha de registro e (0,1) para as informações consideradas opcionais sobre o paciente, pois de acordo com Heuser (2009, p. 45), algumas restrições de integridade podem ser expressas diretamente no modelo ER através de restrições de cardinalidades. A Cardinalidade mínima 1 é considerada associação obrigatória, indicando que o relacionamento deve associar uma ocorrência de entidade para cada ocorrência da entidade em questão. Já a cardinalidade mínima 0 é considerada uma associação opcional.
3.1.2 Segundo Banco de Dados RHC2
Para o segundo banco de dados, considerou-se como objetivo criar um banco mais enxuto. O propósito é que o banco de dados apresente menor processamento ao executar as consultas SQL, pois possui menor quantidade de tabelas relacionadas.
A modelagem conceitual foi desenvolvida com base nas entidades principais definidas anteriormente. Mas ao contrário do primeiro modelo, todas as informações contidas nos itens obrigatórios e opcionais da ficha, foram modelados como atributos das entidades principais.
É apresentado na figura 12 o modelo ER do segundo banco de dados, o RHC2. Através deste é possível observar a diferença da estrutura modelada em comparação com o modelo ER do banco de dados RHC1.
Figura 12: Modelo ER do banco de dados RHC2
