A Camada de Abstração do Sistema de Gerenciamento de Banco de Dados do Sistema Odontológico da UNIOESTE

Transcrição

1 ISSN: A Camada de Abstração do Sistema de Gerenciamento de Banco de Dados do Sistema Odontológico da UNIOESTE Anderson Zanardo Dias 1, Anselmo Luiz Éden Battisti 1, Rafael Voltolini 1, Claudia Brandelero Rizzi 1, Jorge Bidarra 1, Fabiana Scarparo Nalfel 2, Mariângela Monteiro de Melo Baltazar 2, Marina Berti 2, Alexandre Almeida Webber 2 1 Curso de Bacharelado em Informática Centro de Ciências Exatas e Tecnológicas (CCET) Universidade Estadual do Oeste do Paraná (UNIOESTE) Caixa Postal Cascavel PR Brasil 2 Curso de Odontologia Centro de Ciências Biológicas e da Saúde (CCBS) Universidade Estadual do Oeste do Paraná (UNIOESTE) Caixa Postal Cascavel PR Brasil {anderzd, anselmobattisti}@yahoo.com.br, {macael_, claudia_rizzi}@hotmail.com, jbidarra@unioeste.br, biberes@terra.com.br, mmmwgb@uol.com.br, {marina_berti2004, alexandrewebber}@yahoo.com.br Abstract. The increase in the amount of information produced currently and its constant valorization becomes important the ways in which such information are stored and as they are manipulated. Being thus, this work intend to present some examples and concepts of layers of abstraction of Databases, with emphasis in the tool used in project SISO (Sistema Odontológico), also displaying the functioning of the same and as such tool was used in order to provide portability between Database Management System. Resumo. O aumento na quantidade de informações produzidas atualmente e sua constante valorização pela sociedade requerem dos projetistas de software, em geral, e em particular dos programadores de Banco de Dados (BDs), uma análise criteriosa não só sobre como esses dados precisam ser armazenados, como também manipulados. Com essa preocupação e motivação, este trabalho visa apresentar alguns exemplos e conceitos de camadas de abstração de BD, com ênfase na abstração de SQL (Structured Query Language), na ferramenta utilizada no desenvolvimento do projeto SISO (Sistema Odontológico). Também são mencionados o funcionamento do sistema em questão, bem como o uso da ferramenta acima, como forma de garantir ao SISO a portabilidade desejada, particularmente no que diz respeito aos Sistemas Gerenciadores de Bases de Dados. 1. Introdução Na sociedade atual, é um fato que a valorização da informação como ferramenta indispensável de trabalho vem obrigando, por parte dos projetistas de bancos de dados, uma mudança de comportamento bastante acentuada. Para dar conta das atuais exigências dos usuários e também das grandes empresas, os projetistas de BDs precisam se preocupar, cada vez mais, com o desenvolvimento de sistemas que de fato 38

2 contribuam não apenas para o armazenamento dos dados nas bases e informações geradas, mas também com o próprio gerenciamento e manipulação dessas informações, conforme as demandas surgidas. É neste contexto que a Ciência da Computação pode e muito tem contribuído, com soluções que gerenciem dados e informações, eficientemente [Ceccotti 2002]. Na área específica de sistemas odontológicos, o que se acabou de dizer se mostra de uma forma muito clara. Em meados dos anos 80, a ADA (American Dental Association) apresentou, pela primeira vez, um sistema computadorizado voltado especificamente para os dentistas. Um dos resultados daquela iniciativa foi a revisão geral, por parte da ADA, da nomenclatura dos códigos utilizados, até então, nos procedimentos odontológicos, com o principal objetivo de facilitar o trato computacional dos dados para processamento [Novelli 1991]. Embora, atualmente, os sistemas odontológicos não sejam exatamente uma novidade, no Brasil, estima-se que até 1986 apenas mil cirurgiões dentistas faziam uso de computadores em seus consultórios, cujo emprego, quase que exclusivamente, estava voltado para o apoio a tarefas administrativas [Cauduro Neto 1989]. Em 1991 J. W. Bobb publicou um artigo considerado visionário. Nele, o autor afirmava que o uso de computadores na odontologia era uma realidade irreversível e de impacto profundo. Isto porque, em primeiro lugar os computadores eram fundamentais para a otimização e gerenciamento de informações e, em segundo lugar, porque ampliavam a perspectiva de progresso na atividade odontológica, até então, em vários aspectos, inviável. Entretanto, alertava para o fato de que os softwares a serem utilizados pelos cirurgiões dentistas deveriam ser fáceis de usar e totalmente integrados à realidade da clínica, contendo bases de dados que permitissem aos profissionais terem acesso às informações sobre os seus clientes de forma eficiente e com consistência. Alertava também, que durante o processo de informatização da clínica estariam presentes fatores relativos à falta de familiaridade dos cirurgiões dentistas com a Informática [Bobb 1991]. Em artigo também de 1991, Ribas e Miranda já apontavam para características interessantes dos softwares, citando que os mesmos aumentam a produtividade, agilizam serviços, geram informações que auxiliam na tomada de decisões, dentre outras funcionalidades. Na odontologia, os autores citaram algumas aplicações gerais de interesse dos cirurgiões dentistas, tais como agenda de atendimento, cadastro de pacientes, lista de preços, orçamentos, prontuário clínico do paciente. Tratava-se de manipulação básica de dados que necessitam ser acessados e mantidos de maneira rápida, segura e eficiente [Ribas e Miranda 1991]. Na área comercial, atualmente existem vários sistemas computacionais para fins odontológicos. A maioria deles, voltados para o mercado de clínicas odontológicas particulares que atendem a diversas especialidades. A título de ilustração, citam-se o Dental Office [Dental Office], o DentalPro [DentalPro], o BioDente [BioDente], o EasyDental [EasyDental], dentre outros. Apesar das muitas soluções disponíveis no mercado, há pouco ou quase nenhum investimento na construção de sistemas que tenham como finalidade a viabilização de sistemas dedicados à administração e operacionalização de Clínicas Odontológicas voltadas ao ensino e a aprendizagem de alunos de odontologia e ao atendimento à comunidade. Tais sistemas, diferentemente daqueles comerciais, apresentam 39

3 particularidades que não são contempladas por esses últimos. Das poucas referências existentes, um exemplo é o Sistema de Informatização de Clínicas da Faculdade de Odontologia de Ribeirão Preto (FORP), unidade avançada da Universidade de São Paulo (USP), batizado de Romeu. O Sistema Romeu foi desenvolvido com o objetivo de centralizar as informações pessoais e de tratamento dos pacientes atendidos pela FORP num servidor de banco de dados. Isto porque, em 2003, existiam 197 consultórios odontológicos instalados em sete clínicas, que recebiam alunos de graduação, pós-graduação e estagiários. Naquele ano, a FORP realizou atendimentos em pacientes [Finco, Mercantil e Albuquerque]. Algumas das tecnologias utilizadas no sistema Romeu foram: o DIA, para criação de diagramas UML (Unified Modeling Language); o PostgreSQL como servidor de banco de dados; o tedia2sql para converter o modelo gerado no Dia em script SQL para o PostgreSQL; os aplicativos phppgadmin e pgadmin para execução do script gerado; a linguagem de programação PHP; a biblioteca para abstração de banco de dados para PHP ADOdb[ADOdb]; o editor de textos Vim para codificação em PHP. Finco, Mercantil e Albuquerque relatam que com a implantação do Romeu, as informações cadastrais e de atendimento dos pacientes, anteriormente espalhadas por diversos pontos de atendimento a pacientes, tornaram-se disponíveis on-line a todos os usuários com acesso à rede de computadores da FORP. O sistema permitiu maior transparência com relação à documentação dos atendimentos odontológicos realizados e pagos pelo Sistema Único de Saúde (SUS). Segundo eles, o custo para o desenvolvimento do sistema, apesar de se tratar de uma ferramenta complexa, foi baixo, tendo em vista que para a sua implementação foram utilizados softwares livres [Finco, Mercantil e Albuquerque]. Seguindo a mesma linha do Sistema Romeu, a equipe do Núcleo de Inovações Tecnológicas (NIT), juntamente com o Colegiado do Curso de Odontologia e a Divisão de Recursos de Informática (DRI) da UNIOESTE, propõe o SISO (Sistema Odontológico), cujos detalhes são apresentados nas próximas seções, começando pela caracterização do ambiente no qual o sistema estará em funcionamento. 2. A Clínica Odontológica e a motivação para o desenvolvimento do SISO A Clínica Odontológica (CO) da UNIOESTE se destaca no contexto da área de Saúde, pela sua dimensão acadêmico-social. Nas suas diversas atuações, busca estabelecer uma articulação forte entre os três eixos de formação do acadêmico, quais sejam o ensino, a pesquisa e a extensão. De outro lado, procura contribuir para a melhoria da qualidade da saúde bucal da população da região oeste do Estado do Paraná. A CO atende acadêmicos de graduação, aperfeiçoamento e especialização e possibilita aos mesmos o acesso a um conhecimento teórico acompanhado de um intenso treinamento prático; o que tem sido possível graças à integração entre alunos, professores e comunidade. A CO iniciou suas atividades em Atualmente, ela é composta por cinco Clínicas Especializadas, um Centro Cirúrgico, um Centro de Especialidades, uma Clínica do Bebê e um setor de Atendimento de Urgências, cujos serviços são prestados à comunidade de forma contínua, inclusive nos períodos de recesso acadêmico e férias. Nos serviços prestados pela CO, estão incluídos não só os procedimentos de dentística e 40

4 cirurgia básicas, bem como tratamentos preventivos individuais, procedimentos de periodontia, endodontia, odontologia cirúrgica e traumatologia buco-maxilo-facial. Além desses serviços, a CO oferece assistência básica à saúde bucal, com procedimentos cobertos pelos credenciamentos obtidos junto ao Sistema Único de Saúde (SUS). Atua efetivamente em programas governamentais voltados para a atenção básica e especializada, sendo membro integrante das entidades que participam do Programa Brasil Sorridente, mantendo em funcionamento o Centro de Especialidades Odontológicas (CEO). Recentemente, a CO passou também a ser credenciada pelo Laboratório de Prótese, o que significa que todos os procedimentos por ela executados, a partir de então, são financiados pelo Ministério da Saúde, através do Programa Brasil Sorridente. Considerando o aumento crescente das atividades que vêm sendo desenvolvidas pela CO, constatou-se a necessidade de se construir um sistema automatizado de controle e gerenciamento das ações executadas, visando dessa forma, superar problemas que interferem na rotina de trabalho e atendimento atualmente oferecidos. Um dos principais problemas da CO é o fato de que todos os procedimentos, tanto os de ordem administrativa (e relativos às especialidades de cada clínica que compõe a CO), quanto os de acompanhamento dos mesmos, são feitos manualmente. Isso faz com que exista, além de redundância de informações, dificuldade em obtê-las. Informações básicas como definir dia e hora para atendimento, acompanhamento de listas de espera, identificação de procedimentos vinculando-os a atendimentos financiados ou não por entidades/projetos, hoje dificultadas pelo controle manual, com o SISO passam a ser feitas automaticamente e com maior eficiência, sem contar o conforto proporcionado tanto aos funcionários, professores e alunos, quanto para a própria população que recorre aos serviços das clínicas odontológicas da universidade. 3. As principais funcionalidades do SISO O objetivo geral do SISO é contribuir para a melhoria na qualidade do atendimento operacional e administrativo oferecido pela CO a seus pacientes e aos seus funcionários administrativos, alunos, professores e funcionários das clínicas, os quatro principais usuários e beneficiários do SISO (Figura 1). Cabe ao Funcionário Administrativo executar as ações (adicionar, editar e remover credenciamentos, procedimentos e atividades, assim como definir o conjunto de procedimentos que compõem uma atividade; manter informações sobre clínicas, vincular atividades e vincular professores às clínicas, adicionar, editar e excluir dentistas, professores, turmas, duplas de trabalhos, monitores e alunos) que garantam o funcionamento administrativo da CO. Aos Alunos vinculados à CO compete executar as ações (cadastrar dados e o plano de tratamento do paciente, confirmar sua agenda de atendimento e também emitir formulários, como por exemplo, o formulário de procedimentos pagos pelo SUS) que garantam que as informações sobre o atendimento ao paciente cheguem ao SISO. 41

5 Figura 1: Funcionalidades do SISO às Clínicas Cabe aos Professores executar ações (confirmar o plano de tratamento proposto bem como sua execução, além de garantir pacientes para os alunos) que garantam que as atividades discentes sejam supervisionadas e validadas junto ao SISO. É da responsabilidade dos Funcionários da Clínica garantir que as informações decorrentes das atividades administrativas específicas da clínica alimentem o SISO (através do gerenciamento das informações sobre o paciente, gerar carteirinha, manter a agenda dos alunos, gerenciar as filas de espera, efetuar as chamadas através das filas de espera e emitir os documentos pertinentes). Dentre as particularidades do SISO estão as funções que viabilizam o controle do CEO. O CEO é um programa governamental cujo principal objetivo é viabilizar à população tratamentos odontológicos de média complexidade. Os pacientes do CEO são originários de postos de saúde da abrangência de Cascavel e Região. Os atendentes do CEO são cirurgiões dentistas, e, portanto, não há participação de alunos neste tipo de prestação de serviço, o que requer controle administrativo e funcional específico. Neste módulo do SISO, existe apenas um ator interagindo com o sistema, o funcionário do CEO, cujas ações estão ilustradas na Figura 2. É função desse funcionário (através do gerenciamento das informações sobre o paciente, gerar carteirinha, manter a agenda dos profissionais, gerar relatórios e emitir os documentos pertinentes) que garante o funcionamento adequado do sistema, assim como a manutenção da integridade de todos os dados armazenados na base. Figura 2: Funcionalidades do SISO para o CEO 42

6 Atualmente o SISO está em fase de desenvolvimento, com algumas ferramentas já em pleno uso, dentre elas o controle de versão, editores web, ferramentas UML (Unified Modeling Language) e clientes de banco de dados. As figuras ilustram, respectivamente, a tela principal do sistema (Figura 3), a tela de cadastro de procedimentos (Figura 4), a tela por onde determinada atividade é vinculada a uma clínica (Figura 5) e a tela usada para dar suporte cadastro de uma nova clínica (Figura 6). Figura 3: Tela Principal Figura 4: Cadastro de Procedimentos Figura 5: Vincular Atividade à Clínica Figura 6: Cadastrar Clínica 4. A camada de abstração do SGBD do SISO Apesar dos padrões sugeridos pela ANSI (American National Standards Institute) serem adotados por todos desenvolvedores de SGBD, poucos são os SGBDs que apresentam portabilidade total entre si. Existem diversas razões para que isto aconteça. 1. o padrão ANSI é muito extenso e por isto muitas vezes não é completamente implementado; 2. o padrão deixa a critério dos desenvolvedores decisões importantes sobre pontos críticos como, por exemplo, índices; 3. grandes sistemas possuem bases de dados consolidadas e a adoção do padrão sugerido pela ANSI pode causar incompatibilidade; 4. o padrão ANSI pode ir contra a filosofia de desenvolvimento da organização. 43

7 A migração de bases de dados não é rotina para os desenvolvedores. No entanto, especialmente em decorrência da crescente disponibilidade de ferramentas e vantagens financeiras decorrentes do uso de software livre, migrar bases de dados tornou-se uma atividade real e concreta. No entanto, ela implica em condições que apresentam certo grau de complexidade, como quando da adaptação das SQL da aplicação para a nova base de dados. Na implementação do SISO foi necessário, devido aos padrões adotados pela UNIOESTE, que seu SGBD fosse o SQLServer. No entanto, considerando as tendências em software livre, e a possibilidade de deixar o SISO facilmente adaptável a SGBDs gratuitos, foram utilizados frameworks - conjunto de classes que incorporam uma abstração de soluções para uma família de problemas semelhantes - que funcionam como modelo padrão de programação que pode ser utilizado com uma ampla variedade de tipos de bancos de dados, encapsulando as diferenças e facilitando a migração de bases de dados, fornecendo uma camada de abstração para acesso a dados, ou seja, uma camada intermediária entre os processos da aplicação e do SGBD, a fim de proporcionar portabilidade. Como exemplo, tem-se a ADOdb, que nasceu da iniciativa de portar a sintaxe da Microsoft ADO ao mundo PHP e Python, tornando portável todo o código escrito com ela para todos os bancos de dados suportados, a citar MySQL, Oracle, Microsoft SQLServer, Sybase, Sybase SQL Anywhere, Informix, PostgreSQL, FrontBase, SQLite, Interbase (Firebird e variantes Borland), Foxpro, Access, ADO, DB2, SAP DB e ODBC. Por ser uma ferramenta livre e de código aberto, várias pessoas ao redor do mundo contribuem com drivers para dar suporte a outras bases de dados. Vários softwares populares a utilizam, como os gerenciadores de conteúdo PostNuke [PostNuke], Xaraya [Xaraya], Mambo [Mambo] e a solução de groupware egroupware [egroupware]. O funcionamento ocorre através da instanciação de classes pré-definidas e acessos a métodos/funções que são responsáveis pela manipulação dos dados conforme o banco de dados escolhido, substituindo a sintaxe padrão de consulta como mysql_query() no PHP, própria para MySQL por sintaxes específicas do framework, que se adequam conforme a base de dados escolhida, bastando a aplicação apenas acessar o driver ODBC (Open Database Connectivit) que este último se encarrega da comunicação com o banco adjacente. Como exemplo de sua portabilidade, disponibiliza em seu objeto fruto da conexão métodos como SelectLimit(), para que não se escreva uma instrução SQL SELECT que contenha a maneira como o SGBD escolhido trabalha com consultas limitadas (LIMIT x OFFSET y, PostgreSQL, LIMIT y, x no MySQL ou SELECT TOP x *, no MS SQLServer, por exemplo), leftouter(), rightouter() e ansiouter() para variações de JOINs, dentre outros. A abstração de SGBD não é uma necessidade absoluta e a conseqüência natural do uso desta camada é a degradação do desempenho, tornando o processo mais lento e custoso para o servidor do que nativamente. Sendo assim, há dois pontos que devem ser analisados: a importância do desempenho do sistema e a portabilidade e conhecimento único aplicável a um grande leque de SGBDs. No primeiro caso, o acesso direto e a preocupação com os mínimos detalhes da API (Application Programming Interface) 44

8 nativa do SGBD se tornam mais eficientes, já no segundo caso, vale a pena investir na abstração. Exemplos de portabilidade seriam campos auto-incrementáveis, em que cada SGBD trata a sua maneira, e funções de conversão de dados que possam sofrer mudanças de representação de um banco para outro, como strings, datas, horas, pontos flutuantes e booleanos. Além da ADOdb, existem outras ferramentas que se dispõem a fazer a camada de abstração entre o SGBD e a aplicação, tais como PDO, Creole SPL, DBX, Metabase, Creole JDBC, DB, MDB2, entre outras Abstração de SQL Os frameworks de abstração de dados diminuem, mas não eliminam a necessidade do desenvolvedor identificar se a SQL criada irá ou não ser compatível com todas as bases de dados. Sendo assim, quando SQLs específicas são criadas pelos desenvolvedores, incompatibilidades podem ser agregadas. Isto é potencialmente perigoso, pois o erro apenas se manifestará quando houver necessidade de migrar a base de dados. Como exemplo tem-se o SGBD SQLServer Algumas de suas características são: 1. É case insensitive; 2. As SQLs de inserção de dados permitem que qualquer valor possa ser colocado entre aspas simples. Supondo que a tabela representada pela Figura 7 seja manipulada por este banco seguindo estes dois princípios, a execução da SQL abaixo resultaria na inserção de um novo registro. INSERT INTO ALUNO ( cod, nome, idade) VALUES ( 1, José da Silva, 14 ); Figura 7: Estrutura de uma tabela que armazena dados de alunos. Caso esta mesma SQL seja executada em uma base de dados PostgresSQL o resultado não seria o mesmo, e dois erros seriam detectados: 1. A tabela ALUNO não seria localizada, pois PostgresSQL é case sensitive; 2. Valores do tipo inteiro não podem ser referenciados entre aspas simples, este erro ocorre tanto na coluna cod quanto na coluna idade. A construção correta da SQL para o PostgresSQL seria: INSERT INTO aluno ( cod, nome, idade) VALUES (1, José da Silva, 14); É interessante observar que se a segunda SQL for executada no SQLServer, o registro seria inserido com sucesso, ou seja, a portabilidade de SQL pode ser unidirecional. Outro ponto interessante é que o padrão SQL ANSI não define se o SGBD deve ou não ser case sensitive, sendo assim, o fabricante do SQLServer optou por produzir um banco não case sensitive. Esta opção do fabricante pode ser comprovada visto que o sistema operacional que executa o SQLServer é o Windows que 45

9 é não case sensitive, ao passo que o PostgreSQL é case sensitive pois originalmente foi desenvolvido para ser executado sobre a plataforma UNIX que é case sensitive. As SQL podem ser dividas em duas categorias, seleção e manipulação. 1. Seleção: apenas retorna o conjunto de registro(s) que satisfaçam a condição da seleção, exemplo: SELECT * FROM aluno. Esta SQL irá retornar todos os registros da tabela aluno; 2. Manipulação: realiza alguma modificação no estado do SGBD, elas podem ser de inserção, atualização ou remoção. As SQL de seleção apresentam apenas problemas de portabilidade quanto à diferença entre caracteres maiúsculas e minúsculas, ao passo que as SQLs de manipulação apresentam problemas mais graves quanto à portabilidade. Na Figura 8 pode-se observar o modelo utilizado para minimizar o problema das SQLs de manipulação. A aplicação pode comunicar-se com o banco de dados utilizando a camada de abstração de dados apenas para SQL de seleção, quando houver necessidade de SQL de manipulação a aplicação deve solicitar que a camada de abstração de SQL faça a comunicação com a base de dados. Figura 8: Modelo de abstração em duas camadas A camada de abstração de SQL é composta basicamente por quatro métodos: salvar, atualizar, remover e executar. Os três primeiros métodos criam a SQL em função dos parâmetros que recebem. O resultado de cada um destes métodos é enviado para o método executar, o método executar chama a camada de abstração de dados que por sua vez faz a comunicação com a base de dados. 5. Considerações finais Neste artigo, foi possível apresentar, ainda que sucintamente, o Sistema Odontológico SISO, para controle da Clínica Odontológica da UNIOESTE. Atualmente, o SISO está em fase de desenvolvimento e algumas ferramentas já estão sendo utilizadas e testadas. Mais especificamente, o objetivo deste trabalho foi mostrar alguns exemplos e conceitos de camadas de abstração de Bancos de Dados, com ênfase na ferramenta utilizada no SISO discutindo como esta ferramenta foi utilizada a fim proporcionar portabilidade entre Sistemas Gerenciadores de Bases de Dados. Neste contexto, pontuou-se que assim como existem drivers específicos para cada SGBD, também podem existir camadas de abstração de SQL específicas. A grande vantagem quanto ao seu uso é a minimização do impacto que a mudança do SGBD causa sobre o código fonte e com aumenta a portabilidade do sistema. 6. Referências ADOdb. Disponível em: 46

10 BioDente. Disponível em: Bobb, J. W. (1991). Where are we going with clinical computing? In: PRESTON, J.D. (ed.) Computers in clinical dentistry. Chicago: Quintessence, p Cauduro Neto, R. (1989). O computador na odontologia. RGO. Porto Alegre, v.37, n.3, p , maio/jun. Ceccotti, H. M. Sistema Integrado de Informação da Área de Ortodontia da FOP/UNICAMP. Disponível em: Dental Office. Disponível em: Dentalpro. Disponível em: EasyDental. Disponível em: egroupware. Disponível em: Elmasri, Ramez; Navathe, Shamkant. Sistemas de Banco de Dados, 4ª Edição, Addison- Wesley, Março de Finco, L. L. Mercantil, J. P. Albuquerque, R.F. Software Livre: a Experiência da FORP/USP no Desenvolvimento de um Sistema de Informatização de Clínicas. Disponível em: Mambo. Disponível em: Novelli, M. D. (1991). Análise e perspectivas da aplicação de computadores na odontologia. Revista da Associação Paulista de Cirurgiões Dentistas. São Paulo, v.45, n.6, p , nov./dez. PostNuke. Disponível em: Ribas, M.; Miranda, C.C. (1991). A informática na odontologia. Revista da Associação Paulista de Cirurgiões Dentistas. São Paulo, v.45, n.4, p , jul./ago. Xaraya. Disponível em: 47