1 Resumo

2 Introdução

Banco de dados é uma coleção organizada de dados com regras de gestão automatizadas. No sistema de saúde brasileiro existem centenas de aplicações de coleta de dados de vigilância, atenção, logística, infraestrutura e força de trabalho. O acesso mais comum aos dados, infelizmente, não ocorre diretamente ao banco de dados, mas à dados em tabelas de disseminação. Dessa forma, para realizar consultas e filtros os usuários devem baixar e organizar os dados, seja de forma artesanal em planilhas de cálculo ou em estruturas organizadas e automatizadas com algoritmos validados.

O projeto R é poderoso para transformação de dados, porém, a gestão de dados apresenta ferramenta específica, o Sistema Gerenciador de Banco de Dados (SGBD). A manipulção constante e de forma compartilhada de dados que crescem com o tempo requer a boa prática do uso de SGBD para evitar erros e ofertar reprodutibilidade e segurança. Dentre as vantagens do SGBD destacam-se

Existem bancos de dados estruturados e não estruturados. Os bancos de dados não estruturados gerenciam dados de forma flexível, usualmente conteúdo em linguagem natural de documentos e vídeos. Por sua vez, bancos de dados estruturados apresentam estruturas rígidas, codificadas, usualmente com tabelas relacionadas umas às outras cujo registro distinto é armazenado em uma linha e cada atributo é disposto em uma coluna com domínio previamente especificado. Devido à estrutura em linhas e colunas é comum haver a confusão entre dados armazenados em planilhas de cálculo e banco de dados. Vamos assumir aqui que a diferença entre um conjunto de dados (do inglês, dataset) e o banco de dados é que o segundo apresenta uma gestão formal e automatizada de dados por uma aplicação gerenciadora, embora ambos possam ser coleções de dados organizados.

Em organizações mais estruturadas, com dezenas de pessoas ou mais acessando constantemente o mesmo banco de dados é estabelecido formalmente quem é (ou quais são) o DBA - administrador de banco de dados (do inglês, data base administrator), preferencialmente um profissional especializado na ferramenta gerenciadora escolhida.

Porém, ainda que sua coordenação, departamento ou grupo de pesquisa contenha menos que dez pessoas, o uso de gerenciador de dados viabiliza estabelecer uma cultura de dados com processos e padrões no tratamento dos dados ainda que existam mudanças constantes nos quadros de colaboradores e parceiros.

O presente capítulo discorre acerca de bancos de dados estruturados, também chamados de bancos de dados relacionais. A maioria das aplicações do SUS armazenam informações em bancos de dados relacionais desenvolvidos sob o modelo Entidade-Relacionamento. Cada entidade (p.ex., usuário, estabelecimento, procedimento, gestor) apresenta um dado relacionamento no mundo real para realizar tarefas (p.ex., diagnósticos, laudos, atendimentos, dispensações) cuja comunicação deve ser organizada para satisfazer necessidades reprodutíveis ao longo do tempo.

Os bancos de dados estruturados podem ser transacionais ou analíticos. Os bancos de dados das aplicações (p.ex. para dados ambulatoriais, hospitalares, mortalidade, leitos, equipamentos, profissionais) são transacionais, isto é, organizados para a transação, a memória do ato de comunicação cujo processo administrativo é mediado por um SIS - sistema de informação da saúde. A partir de extrações dos bancos de dados transcionais são gerados os bancos de dados analíticos, os quais alimentam as bases de disseminação mais comuns do SUS voltadas para facilitar o Monitoramento e Avaliação de políticas públicas.

O foco do capítulo é a modelagem de dados relacionais (estruturados) e analíticos com sistemas gerenciadores de bancos de dados e técnicas de bancos de dados massivos (do inglês, big data) para consultas que alimentam relatórios gerenciais, por exemplo, indicadores de saúde ou artifícios de logística, métodos estatísticos e epidemiológicos (p.ex., para estudos observacionais) e de aprendizado de máquina (do inglês, machine learning) no universo da simulação in silico (métodos de descoberta de conhecimento não trivial ou KDD - knowledge discovery in databases) e da automação de decisões com inteligência artifical.

2.1 Sobre o capítulo

O objetivo do capítulo é introduzir o gestor do SUS ou o pesquisador em saúde coletiva acerca da modelagem e gestão de dados com SGBD - Sistema Gerenciador de Banco de Dados com foco na tomada de decisão direcionada por dados disseminados pela Secretaria Executiva do Ministério da Saúde - SE/MS via Departamento de Informática do SUS do Ministério da Saúde - Datasus/SE/MS e pelo Departamento de Monitoramento e Avaliação do Sistema Único de Saúde - DEMAS/SE/MS.

O capítulo foi escrito com abordagem da prática para a teoria, isto é, são trazidos exemplos práticos de dados disseminados
via ftp://ftp.datasus.gov.br (no bojo da estratégia do TabWin, acesse https://datasus.saude.gov.br/transferencia-de-arquivos/ para mais informações) e https://opendatasus.saude.gov.br/. Os exemplos são aplicados aos conceitos das Ciências da Computação e Informação acerca da modelagem relacional.

Os exemplos integram o ambiente de programação do projeto R com a linguagem estruturada de consulta SQL (do inglês, structured query language). Porém, ainda que o sanitarista não queira implementar código-fonte (programar) nessas linguagens, a leitura do capítulo é recomendada para quem deseja obter vocabulario de informática em saúde e ciência de dados para atuar em equipe com estatísticos, analistas de BI e cientistas de dados.

Os exemplos foram codificados em R versão 4.1.2 e PostgreSQL (psql) 14.2 (Ubuntu 14.2-1.pgdg20.04+1). Pequenas adaptações podem ser necessárias caso o usuário possua ambientes diferentes, porém, sem prejuízo à aprendizagem dos conceitos.

2.2 Banco de dados

Definição

  • Banco de dados: Coleção de dados relacionados.
  • Dados: Fatos que podem ser gravados e que contenham significado implícito

Exemplos e contraexemplos

  • Agenda
  • Dados armazenados em formato de planilha de cálculo
  • Esse material (conjunto de palavras que formam uma frase e pode ser visto como dados de significado implícito que estão relacionados…)

Um banco de dados representa um aspecto do mundo real, sendo chamado as vezes minimundo. As mudanças no minimundo são refletidas em um banco de dados.

Um banco de dados é uma coleção lógica e coerente de dados com algum significado inerente (eu incluiria consistente). Uma organização de dados ao acaso (randômica), não pode ser corretamente interpretada como banco de dados.

Um banco de dados é projetado, construído e povoado por dados, atendendo a uma proposta específica. Possui um grupo de usuários definidos e algumas aplicações pré-concebidas, de acordo com o interesse desse grupo de usuários.

Um BD possui fontes das quais os dados são derivados, alguns níveis de interação com eventos do mundo real e um público efetivamente interessado em seus conteúdos. Gerencia pesquisa, recuperação, atualização e eliminação de dados (CRUD acrônimo de Create, Read, Update e Delete na língua Inglesa [https://pt.wikipedia.org/wiki/CRUD]).

O SGBD - Sistema Gerenciador de Banco de Dados é uma coleção de programas que permitem aos usuários criar e manter um banco de dados. Possibilita armazenar os metadados, ou seja as características da tabela e dos campos/atributos.

Exemplo do metadado sexo:

  • Domínio: S = [F, M]
  • Rótulo: Sexo do paciente
  • Nome: sexo
  • Formato: Char (1)

SGBD é um sistema de programa eletrônico de propósito geral que facilita os processos de definição construção manipulação e compartilhamento de bancos de dados entre vários usuários e aplicações.

Definir um BD implica em especificar tipos de dados, estruturas e restrições para os dados a serem armazenados em um banco de dados.

Construir um BD implica em especificar mídia apropriada para armazenamento, funções de manipulação (pesquisa, p.Exemplo) e compartilhamento (acesso concorrente de múltiplos usuários).

Manter um BD implica em Proteção contra mau funcionamento, falhas no hardware/programa eletrônico e segurança de acesso manutenção por longos períodos. Acompanhar a evolução dos requisitos

Caption for the picture.

Abordagem tradicional vs banco de dados:

  • Natureza auto-descritiva do sistema de Banco de dados.
  • Isolamento entre programas e os dados, e a abstração dos dados.
  • Suporte para as múltiplas visões dos dados.
  • Compartilhamento de dados e processamento de transações multiusuários.

Natureza autodescritiva do sistema de Banco de dados:

  • Completa definição ou descrição da estrutura desse banco de dados e suas restrições
  • É armazenada no catálogo do SGBD
  • É chamada de metadados.
  • Um SGBD deve ser capaz de trabalhar com vários bancos de dados, o que não ocorre com soluções específicas que possuem as próprias definições dos dados.

2.2.1 Isolamento entre programas e os dados, e a abstração dos dados

No processamento tradicional de arquivos a estrutura está embutida no programa de aplicação. Qualquer mudança na estrutura pode exigir alterações de todos os programas que acessam esse arquivo. Num SGBD uma alteração na estrutura dos dados geralmente não implica em alterações na implementação. Isso permite a abstração dos dados, onde usuários e programadores não necessitam de conhecer detalhes de implementação para saber um que uma operação faz. Isso é possível graças à implementação genérica de acesso ao catálogo.

2.2.2 Suporte para as múltiplas visões dos dados

  • Usuários diferentes querem enxergar o banco conforme sua perspectiva.
  • Dados visualizados podem ser diferentes dos dados armazenados. P.Exemplo data, dados codificados (procedimentos de apac, CID, ATC)
  • Dados identificados de pacientes devem ser restringidos mediante o perfil do usuário

2.2.3 Compartilhamento de dados e processamento de transações multiusuários

  • programa eletrônico de controle de concorrência:
    • Dois usuários não podem alterar o mesmo registro ao mesmo tempo
  • O Controle de Transação garante
    • Isolamento: cada transação possa ser efetuada de forma isolada de outras
    • Atomicidade: todas as operações em um BD serão executadas ou nenhuma

2.2.4 Papéis

  • Administrador de banco de dados – DBA: Autorização de acesso ao banco, Coordenação de monitoração do seu uso, Adquirir recursos de programa eletrônico e hardware, lida com problemas com brechas de segurança e Tempo de resposta
  • Projetista de banco de dados: Identificação dos dados a serem armazenados, Escolha da estrutura apropriada, Coletar os requisitos, Desenvolver visões do BD.
  • Usuários casuais: Acesso direto ao banco com linguagem de consulta pois precisam de informações diferentes a cada acesso
  • Iniciantes ou parametrizáveis: Usam transações customizadas
  • Usuários sofisticados: Engenheiros, cientistas, analistas de negócios que se familiarizaram com as facilidades do SGBD para implementar aplicações que atendam às suas solicitações complexas
  • Usuário autônomo: Mantém bancos de dados pessoais por meio de pacotes ou programas prontos que possuem interfaces gráficas baseadas em menus fáceis de usar

2.3 Vantagens em acessar diretamente o SGBD

  • Sua pesquisa sempre estará com a última versão da base
  • Você poderá obter atributos criados por outros pesquisadores. Por exemplo, uma última atualização do IPCA, ou se ele pertence a um determinado estudo (ou coorte) ou não.
  • Não se restringirá a uma tabela única simplificada

3 Bases de dados analíticas a partir dos dados disseminados do SUS

Os dados disseminados pelo datasus são detalhados no capítulo 17 Acesso aos Dados agregados e microdados do SUS. O interesse aqui é apenas apresentar de forma sumária os dados disponíveis e um recorte a título ilustrativo. O conhecimento da estrutura e conteúdo de disseminação é fundamental para a modelagem relacional e repectiva gestão do bancos de dados resultante.

A estratégia TabWin utiliza arquivos em formato DBF, compactados em formato DBC os quais são descompactados e concatenados pelo programa eletrônico TabWin, mais precisamente pelo programa dbf2dbc.exe, livre, porém de código fechado, sem possibilidade de ser aprimorado pela comunidade sem engenharia reversa (quebra do código). O processo de concatenação emprega domínios de dados (p.ex, tabelas de diagnósticos, municípios), usualmente em formato CNV, e metadados (definições dos rótulos dos atributos, tipos e restrições) em formato DEF. A tabela 3.1 resume o conteúdo disponível no braço de disseminação via estratégia TabWin.

Table 3.1: Sumário dos dados disseminados pelo DataSUS/SE/MS via estratégia TabWin.
sistema arquivos registros mes inicial mes final no mantenedor ds url
CIH Comunicação de Internação Hospitalar 868 7.676.888 01/2008 04/2011 SAES/MS [url]CIH/200801_201012/Dados
CIHA Comunicação de Informação Hospitalar e Ambulatorial 3.368 184.922.056 01/2011 12/2021 SAES/MS [url]CIHA/201101_/Dados
CNES Cadastro Nacional de Estabelecimentos de Saúde 63.521 925.102.283 08/2005 02/2022 SAES/MS [url]CNES/200508_/Dados/
SIA Sistema de Informações Ambulatoriais do SUS a partir de 2008 39.774 6.137.520.194 01/2008 02/2022 SAES/MS [url]SIASUS/200801_/Dados/
SIA* Sistema de Informações Ambulatoriais do SUS de 1994 a 2007 4.374 596.416.686 07/1994 12/2007 SAES/MS [url]SIASUS/199407_200712/Dados/
SIGTAP Sistema de Gerenciamento da Tabela de Procedimentos, Medicamentos e OPM do SUS 172 793.149 01/2008 04/2022 SAES/MS ftp://ftp2.datasus.gov.br/pub/ sistemas/tup/downloads/ TabelaUnificada_*
SIH Sistema de Informações Hospitalares do SUS a partir de 2008 17.149 1.901.968.093 01/2008 02/2022 SAES/MS [url]SIHSUS/200801_/Dados/
SIH* Sistema de Informações Hospitalares do SUS de 1992 a 2007 9.132 853.529.012 01/1992 12/2007 SAES/MS [url]SIHSUS/199201_200712/Dados/
SIM Sistema de Informações de Mortalidade 777 36.349.670 12/1996 12/2020 SVS/MS [url]SIM/CID10/DORES/
SINAN Sistema de Informação de Agravos de Notificação 804 38.435.335 12/2000 12/2020 SVS/MS [url]SINAN/DADOS/FINAIS/
SINASC Sistema de Informações sobre Nascidos Vivos 787 96.968.941 12/1994 12/2020 SVS/MS [url]SINASC/1996_/Dados/DNRES
SISAB Sistema de Informação em Saúde para a Atenção Básica (CMD - conjunto mínimo de dados) 1.509 2.420.091.846 01/2017 04/2019 SAPS/MS [url]CMD/DadosSISAB/
SISPRENATAL Sistema de Informação do Pré-natal 944 5.591.213 01/2012 12/2014 SVS/MS [url]SISPRENATAL/201201_/Dados
Note:
url = ftp://ftp.datasus.gov.br/dissemin/publicos. Elaboração própria.

Considerando apenas a estratégia TabWin, o dataSUS disponibilizou, em abril/2022, 13.205.365.366 de registros em 143.179 arquivos de formato CSV ou DBC com dados entre 01/1992 e 04/2022. Um disco rígido de 4 terabytes é ainda suficiente para armazenar esse volume de dados em um SGBD. Porém, caso apresente a necessidade de consolidar todos os dados dissemnados são necessários, ao menos, 10tb para espaço de download e extrações para uso analítico.

Logo, para obter dados hospitalares nacionais entre 01/2008 e 02/2022 deverão ser extraídos, transformados e carregados 17.149 arquivos DBC e organizado o armazenamento de 1.901.968.093 registros. A tabela 3.2 mostra características de arquivos DBC sortidos.

Table 3.2: Amostra de arquivos DBC disponíveis no repositório do DataSUS
no dbc subsistema registros dt dbc
CHAGBR06.dbc SINAN CHAG - Doença de Chagas 3.582 2022-03-28
CIHABA1810.dbc CIHA CIHA - Sistema de Comunicação de Informação Hospitalar e Ambulatorial 66.156 2022-02-09
DCGO1903.dbc CNES DC - Dados Complementares 87 2019-04-15
DIFTBR16.dbc SINAN DIFT - Difteria 4 2021-11-23
DOEXT09.DBC SIM DOE - Declarações de Óbitos por causas externas 138.697 2020-01-31
DOFET04.dbc SIM DOF - Declarações de Óbitos Fetais 36.214 2020-01-31
EEMG1104.dbc CNES EE - Estabelecimento de Ensino 19 2014-06-04
EFPE0911.dbc CNES EF - Estabelecimento Filantrópico 19 2014-06-04
EPPB2005.dbc CNES EP - Equipes 3.005 2020-07-15
EQPI1011.dbc CNES EQ - Equipamentos 4.883 2014-06-04
FTIFBR13.dbc SINAN FTIF - Febre Tifóide 95 2021-11-23
HANTBR08.dbc SINAN HANT - Hantavirose 1.144 2021-11-23
IEXOBR12.dbc SINAN IEXO - Intoxicação exógena 82.195 2021-10-08
LEIVBR09.dbc SINAN LEIV - Leishmaniose Visceral 8.953 2021-11-08
LEPTBR11.dbc SINAN LEPT - Leptospirose 21.822 2021-11-23
LTMT1003.dbc CNES LT - Leitos 1.198 2014-06-04
LTANBR15.dbc SINAN LTAN - Leishimaniose Tegumentar Americana 20.975 2021-11-08
MENIBR12.dbc SINAN MENI - Meningite 30.578 2021-11-23
PESTBR11.dbc SINAN PEST - Peste 17 2021-11-23
PFRO1901.dbc CNES PF - Profissional 32.011 2019-03-14
PFANBR14.dbc SINAN PFAN - Paralisia Flácida Aguda 479 2021-11-23
PRBA1702.dbc CMD PR - Procedimentos Realizados 4.146.928 2019-03-22
RCMA1702.dbc CNES RC - Regra Contratual 251 2017-03-16
RJDF2104.dbc SIH RJ - AIH rejeitada 380 2022-04-11
SPRR0109.dbc SIH SP - Serviços Profissionais 5.057 2013-10-31
STAL0508.dbc CNES ST - Estabelecimentos 1.276 2014-06-05
TETABR14.dbc SINAN TETA - Tetano Acidental 501 2021-11-23
TETNBR16.dbc SINAN TETN - Tetano Neonatal 1 2021-11-23
TUBEBR01.dbc SINAN TUBE - Tuberculose 88.665 2021-11-23
VIOLBR13.dbc SINAN VIOL - Violência Interpessoal ou Autoprovocada 188.728 2021-10-15

Usualmente os arquivos DBC disseminados a partir de sistemas de informação em saúde mantidos pela Secretaria de Atenção Especializada à Saúde - SAES/MS apresentam a estrutura básica subsistema|UF|ano|mes. Os dados mantidos pela Secretaria de Vigilância em Saúde - SVS/MS frequentemente são nomeados com subsistema|UF ou BR|ano. O formato de data apresentado na tabela 3.2 é o mesmo aceito pelos SGBD, a saber, ano com quatro dígitos, mês com dois dígitos e dia com dois dígitos separados por hífen ou yyyy-mm-dd.

A tabela na tabela 3.3 exemplifica um sistema de informação completo, o SIA - sistema de informações ambulatoriais, com os demais subsistemas. Para ilustrar a modelagem relacional no decorrer do capítulo foi selecionado o subsistema laudo de medicamentos.

Table 3.3: Sumário dos arquivos DBC segundo o SIA - sistema de informações ambulatoriais
subsistema arquivos registros mes inicial mes final
PA - Produção Ambulatorial 4.708 7.871.180.026 01/2008 01/2022
BI - Boletim Individual 4.563 1.768.000.864 01/2008 01/2022
AM - Laudo de Medicamentos 4.522 233.148.547 01/2008 02/2022
PS - Psicossocial 2.937 93.210.045 11/2012 01/2022
AD - Laudos Diversos 4.588 42.608.184 01/2008 02/2022
AQ - Laudo de Quimioterapia 4.529 41.501.281 01/2008 01/2022
ATD - Laudo de Tratamento Dialítico 2.425 9.593.555 08/2014 01/2022
AN - Laudo de Nefrologia 2.145 6.534.272 01/2008 10/2014
SAD - Atenção Domiciliar 1.088 3.524.141 04/2012 10/2018
AR - Laudo de Radioterapia 4.110 3.330.346 01/2008 01/2022
ACF - Laudo de Confecção de Fístula 2.357 249.332 08/2014 02/2022
AB - Laudo de Acompanhamento à Cirurgia Bariátrica 544 211.252 01/2008 04/2017
AMP - Laudo de Acompanhamento Multiprofissional 315 18.362 03/2016 01/2022

Quem desejar conhecer o número de usuários, a idade e sexo, o município de residência e atendimento, e, finalmente, a composição das dispensações de medicamentos do CEAF - componente especializado da assistênca farmacêutica, Grupo 1A - medicamentos com aquisição centralizada pelo MS, deverá lidar com dados entre 01/2008 e 02/2022, processando 4.522 arquivos DBC e organizado o armazenamento de 233.148.547 registros.

Contudo, os dados presentes no subsistema laudo de medicamento são relacionados ao registros presentes nos arquivos SIA PA, os quais contem o corpo da guia APAC - Autorização de Procedimentos Ambulatoriais e Alta Complexidade/Custo. Dessa forma, é necessário reunir informações de ambos os subsistemas.

A tabela 3.4 aponta o volume anual de dados a serem processados para se obter um conjuto de dados útil. O número de arquivos SIA PA pode ser maior, pois uma vez excedido certo tamanho, por exemplo, um bilhão de registros, o mesmo é particionado em duas ou três partes. Atualmente, apenas os arquivos do estado de São Paulo apresentam esta situação.

Table 3.4: Arquivos DBC ao ano segundo o SIA - sistema de informações ambulatoriais de medicamentos (AM) e conjunto contemplando os dos demais procedimentos (PA)
nu ano arquivos am registros am arquivos pa registros pa
2008 322 9.370.092 324 151.251.933
2009 319 10.939.550 324 174.550.989
2010 320 11.204.084 324 187.492.201
2011 320 12.254.573 325 216.549.358
2012 321 13.188.988 324 224.615.965
2013 323 13.840.326 336 244.920.784
2014 320 15.929.560 336 267.366.357
2015 324 17.366.565 336 281.996.872
2016 320 17.834.962 336 305.468.759
2017 320 18.869.561 336 365.332.874
2018 321 19.801.812 336 358.566.228
2019 321 21.409.138 346 389.240.109
2020 321 23.369.376 348 324.172.486
2021 321 25.685.917 348 411.080.459
2022 29 2.084.043 29 32.984.639

Complementando a informação anterior, Quem desejar conhecer a totalidade de dispensações de medicamentos do CEAF - componente especializado da assistênca farmacêutica, incluindo informações complementares como a quantidade aprovada para cada dispensação, deverá lidar adicionalmente com 4.708 arquivos PA, processando 3.935.590.013 registros PA. O total de processamento corresponde a 9.230 que contem 4.168.738.560 registros.

4 Modelagem Relacional de Dados do SUS

Modelo é uma abstração estruturada de dado aspecto da realidade, aqui chamado minimundo, com o objetivo de organizar a comunicação entre os atores envolvidos e tornar atividades reprodutíveis.

A especificação é a construção de modelos precisos, sem ambiguidade e completos (Booch, Rumbaugh, and Ivar 2005). No desenvolvimento habitual de programa eletrônico, ocorre entre o projetista, usualmente um analista de sistemas, e o cliente, geralmente leigo em tecnologia da informação.

A literatura recomendada para modelagem de bancos de dados, a qual inspira a sessão 4.

4.1 Modelagem de dados legados do SUS

O desenvolvimento de soluções na área da saúde pública é diferente do usual na área de tecnologia de informação, pois os bancos de dados partem, com frequência, de formulários estruturados por sanitaristas. Por exemplo, existem dezenas de formulários de notificação do SINAN - Sistema de Informação de Agravos de Notificação, historicamente elaborados com técnicas de registro da informação que antecedem o advento das ciências da informação em bancos de dados eletrônicos integrados. A ficha a seguir (BRASIL 2006b) é um dentre centenas de exemplos que levou à modelagem de banco de dados ad hoc, isto é formulados individualmente, sem uma estratégia de saúde digital articulada, para cada tipo de doença ou agravo de notificação. Como resultado, existe uma dificuldade desnecessária para o cruzamento entre notificações do mesmo sistema de informação com dados clínicos presentes prontuários eletrônico e outros SIS - Sistemas de Informação em Saúde.

Ao contrário da orientação dos programa eletrônicos focada no serviço, a modelagem adequada de bancos de dados administrativos em saúde deve partir do prontuário eletrônico focado no usuário, assumindo um conjunto mínimo de dados de identificação e padrões para dados sociodemográficos e clínicos. O ponto de partida deve ocorrer de um modelo de dados comum para os diversos Prontuários Eletrônicos e sistemas de informação administrativos, como ocorreu no sumário de alta e registro de atendimento clínico (RAC) elaborado de forma tripartite para orientar o desevolvimento e integração de programas eletrônicos.

Torna-se necessário, portanto, tanto na vigilância, quanto na atenção à saúde, unir esforços para a integração de dados históricos e interoperar os atuais sistemas de informação desenvolvidos com finalidades específicas os quais não contemplaram, no ato da modelagem, a utilização fora da área gestora do dado.

Ficha do SINAN.

Figure 4.1: Ficha do SINAN.

O exemplo que vamos trabalhar ao longo do capítulo é a dispensação de medicamentos. Na figura 4.2 encontra-se a ficha de solicitação de medicamentos. A solicitação de medicamentos de alto custo deve incluir o laudo que atesta o cumprimento do respectivo PCDT - Protocolos Clínicos e Diretrizes Terapêuticas da doença em tratamento.

A título de exercício, observe os fomulários das figuras 4.1 e 4.2. Supondo que deseja conhecer as dispensações de medicamentos para a doença a qual faz vigilância em saúde. Como integraria os dois bancos? O títulos dos campos são os mesmos? Qual título utilizaria? Existem campos afins como sexo, data de nascimento? Existem campos diferentes? Como estão estruturados os atributos? Consegue identificar domínios de atributos exclusivamente numéricos? Consegue identificar domínios de atributos exclusivamente em formato de data? Consegue identificar domínios de atributos delimitados por dada lista? Quais outras bases de dados seriam necessárias para assegurar a referência ao usuário, município, doença, medicamento?

Ficha da Assistência Farmacêutica.

Figure 4.2: Ficha da Assistência Farmacêutica.

Antes da PNIIS - Política Nacional de Informação e Informática em Saúde (BRASIL 2021), a modelagem de programa eletrônico partia de regras tradicionalmente definidas à revelia de uma dada Estratégia de Saúde Digital, uma vez que focam em atender estritamente o escopo dos atos normativos do poder legislativo (câmara dos deputados, câmara do senado, câmara de vereadores) ou executivo (SMS - Secretarias Municipais de Saúde, SES - Secretarias Estaduais de Saúde e MS - Ministério da Saúde).

4.1.1 Requisitos

Logo, o profissional de tecnologia da informação além de se inteirar dos processos de trabalho de modo a estabelecer os requisitos funcionais, para atuar na saúde, deve se inteirar dos do conhecimento legado e dos padrões atuais de informática em saúde para desenhar os requisitos não funcionais.

Requisitos funcionais são atribuições do que o programa eletrônico faz. Por exemplo, todo valor de exame laboratorial deve ser acompanhado do respectivo parâmetro clínico.

Requisitos não funcionais são requisitos de qualidade, isto é, desempenho, segurança, confibilidade e impõe restrições acerca do funcionamento do programa eletrônico. Por exemplo, o programa eletrônico deve funcionar em tablet e dispositivos móveis, o programa eletrônico deve apresentar camada de interoperabilidade em HL7 FHIR.

Ao modelar os requisitos do programa eletrônico devem ser contemplados

  • usabilidade
  • eficiência (número de transações por unidade de tempo)
  • confiabilidade (disponibilidade em 99% do tempo)
  • portabilidade
  • implementação (linguagem, banco de dados)
  • padrões (interoperabilidade, sistema operacional)
  • éticos
  • legais

Dessa forma, o profissional conseguirá conciliar as operações e transações com os itens definidas em lei. A dificuldade no desenvolvimento de programa eletrônico e a explicação para diversos desenvolvimentos mal sucedidos na gestão da saúde pública deve-se à pouca margem para construir o processo de programa eletrônico conjuntamente com o do negócio (notificação, atendimento, etc).

4.2 O modelo Entidade-Relacionamento

4.2.1 Entidades

Entidades são representações de algo existente no mundo real, podendo ser atores, como usários, trabalhadores e gestores do SUS, bem como objetos e operações, por exemplo, medicamentos, órteses, próteses, estabelecimentos, procedimentos e diagnósticos. As entidades usualmente constituem tabelas nos bancos de dados e são descritas por atributos, a exemplo dos campos dos formulários das figuras 4.1 e 4.2.

As entidades são instâncias do mundo real que não se repetem. Logo, estamos falando do conjunto de estabelecimentos, onde cada tupla ou registro representa um dado estabelcimento, por exemplo, a Santa Casa de Misericórdia no município X. Quando falamos do banco de medicamentos estamos nos referindo ao ácido acetil salicílico 100mg, o qual, não pode repetir neste banco, a não ser em outro que estabeleça a apresentação, itens por embalagem e fabricante, a depender se na modelagem foi definido o uso do termo genérico (comum para prescição no SUS) ou a necessidade para fins logísticos (controle de validade numa farmácia da atenção básica) sendo assegurada a univocidade incluindo lote e frabricante.

A garantia da univocidade, ou unicidade, isto é, que dado registro não venha a se repetir, ocorre com a definição dos atributos que definem o objeto de dada classe a qual, na modelagem, pode ser uma derivada de uma entidade ou uma relação.

4.2.2 Atributos

Atributo é uma qualidade, uma característica que diferencia objetos da mesma classe. Por exemplo, o atributo dosagem pode diferenciar o medicamento se no minimundo for necessária a diferenciação, no caso do ácido acetilsalicílico, haverá um registro para 100mg e outro para 500mg. Outro atributo pode ser a apresentação em gotas ou comprimidos.

Os atributos que definem o objeto devem ser modelados conforme o problema do minimundo. Por exemplo, se a tarefa for avaliar interações medicamentosas não relacionadas à dose, apenas o princípio ativo é necessário. Portanto, na modelagem devem ser removidos os atributos dosagem e apresentação de modo a evitar duplicidades. Da mesma forma, medicametos com mais de um princípio ativo devem ser segmentados, por exemplo, o medicmento que contem codeína e paracetamol no mesmo comprimido devem se tornar dois registros no banco de dados em questão.

OS campos dos formulários das figuras 4.1 e 4.2 devem ser devidamente transpostos em linguagem de banco de dados para correto registro e recuperação das informações. Cada atributo deve ser avaliado e classificado conforme as seguintes categorias:

  • Possibilidade de subdivisão:
    • simples (e.g., sexo, idade,);
    • composto (e.g., endereço, nome, composição de princípio ativo do medicamento e data de internação).
  • Número de valores admitidos:
    • monovalorados (sexo, data de nascimento, fabricante, data de internação);
    • multivalorados (cor para um carro, títulos acadêmicos, sintomas).
  • Derivação:
    • primários ou armazenados (data de nascimento);
    • derivados, pois são obtidos a partir dos dados armazenados (e.g., idade calculada a partir data de Nascimento, número de atendimentos de dado usuário do SUS).

Na prática, os dados são armazenados em bancos de dados SQL na forma de

  • Datas, em geral no formato Ano-Mês-Dia (yyyy-mm-dd), por exemplo, 2002-12-25;
  • Data e hora, por exemplo 2002-12-25 12:59:25;
  • Números inteiros, por exemplo, 53254;
  • Números decimais, sempre separados por ponto, por exemplo, 53254.23;
  • Booleanos, quando apenas duas opções são aceitas, por exemplo, false ou true, 0 ou 1;
  • Caracteres, por exemplo, Joana da Silva
  • Listas, quando é aceito apenas um dentre do conjunto delimitado de valores, por exemplo, gestante não gestante, trimestre 1, trimestre 2, trimestre 3, ignorado, não se aplica;
  • Vetores, frequentemente para atributos multivalorados como diagnóstico, por exemplo, a posoríase é caracterizada pelos diagnósticos, segundo a CID-10 - Classificação Internacional de Doenças L400 L401 L404 L408.

Em PostgreSQL, os tipos de dados mais comuns são apresentados na tabela 4.1. Use os tipos de dados elencados ou consulte o manual quando for criar tabelas (PostgreSQL 2022).

Table 4.1: Tipos de dados do PosgreSQL
tipo nome armazenamento descrição intervalo
numérico smallint 2 bytes inteiro de menor intervalo -32.768 a +32.767
numérico integer 4 bytes inteito de intervalo intermediário -2.147.483.648 a +2.147.483.647
numérico bigint 8 bytes inteiro de maior intervalo -9.223.372.036.854.775.808 a 9.223.372.036.854.775.807
numérico decimal variable exatidão decimal definida pelo usuário até 131.072 dígitos após a casa decimal; até 16.383 dígitos após a casa decimal.
character varchar(n) variável texto com número máximo de caracteres definidos pelo usuário
character char(n) variável texto que armazena sempre o número de caracteres definidos pelo usuário
character text ilimitado texto com possibilidade ilimitada de armazenagem
temporal timestamp 8 bytes data e hora sem fuso horário definido 4713 a.C.
temporal date 4 bytes data no formado ano-mes-dia (yyyy-mm-dd) 4713 a.C.
booleano boolean 1 byte estado verdadeiro ou falso

A motivação para escolher tipos com escopo deliminato é moderar o armazenamento e otimizar a busca. A gestão de dados, sobretudo contendo milhões de registros com possibilidade ampliação da escala, isto é, do volume de dados, implica em definir corretamente os tipos.

Logo, para idade, código de raça/cor, código de sexo, o atributo smallint é suficiente. Para código de município, dotado de 6 ou 7 dígitos, o tipo integer é adequado. Porém, para o documento de indentificação do usuário com CNS - Cartão Nacional de Saúde ou CPF - Certidão de Pessoa Física, deve ser usado o tipo de dado bigint.

O byte é uma unidade de informação. Note que o primeiro tipo acima consome 2 bytes, o segundo 4 bytes e o terceiro 8 bytes. Embora possa optar por utlizar bigint para os três atributos, o espaço consumido em disco do valor armazenado duplicará ou quadruplicará. Para conhecer mais acerca do que significa a medida byte leia o verbete na enciclopédia livre (Wikipedia 2022).

Da mesma forma, para armazenar a data em formato dia/mês/Ano deve ser usado o tipo CHAR(10) ou VARCHAR(10), uma vez que não está no formato de data Ano-Mês-dia padronizado no SGBD. Observe que para cada casa da cadeia de caracteres são aceitos qualquer elemento do alfabeto, número e caractere especial (por exemplo, $#@%()!,;[]]}{), cada posição ocupa 8 bytes, portanto, teoricamente, o total ocupado será 80 bytes para cada valor de data armazenada no formato texto. Por esta razão, recomenda-se transpor a data para o formato DATE, desse modo será gasto apenas 4 bytes para cada valor.

A otimização será apresentada a seguir quando falarmos de índices, porém, é possível intuir que uma busca de dado com intervalo esperado menor é mais rápida que num intervalo com escopo maior de. Em outras palavras, é mais fácil identificar a idade ou posição de alguém numa lista de aprovados no vestibular do que procurando pelo seu CPF.

Além da restrição quanto ao tipo, é possível definir o domínio de dados. Domínio é o conjunto de valores que um atributo pode assumir segundo a modelagem do munimundo. Exemplos:

  • O domínio de sexo é {feminino, masculino, ignorado}.
  • O domínio de idade corresponde aos valores de 0 a 130.
  • O domínio de código de diagnósticos corresponde aos códigos da CID-10 - Classificação Internacional de Doenças.
  • O domínio do nome do usuário do SUS compreende 50 caracteres, sendo permitido o conjuto do alfabeto e espaço, hífen e apóstrofe.
  • O domínio do valor do procedimento deve ser registrado com até oito dígitos antes da casa decimal e dois após a casa decimal.

Os domínios podem ser estabelecidos na determinação do tipo de dado, com cláusulas SQL de restrição, ou com referência mandatoria a uma tabela de domínio. No decorrer do capítulo serão ilustrados ambos os casos utilizando-se a linguaguem SQL e a ferramenta PostgreSQL.

A título de exercício, tente modelar com um diagrama as entidades e atributos derivados dos formulários das figuras 4.1 e 4.2. Desenhe um retângulo para cada entidade e enumere abaixo cada atributo que conseguir identificar, com o respectivo tipo de dado e domínio.

4.2.3 Relacionamentos

Nesse ponto o leitor deve ter intuido que uma entidade é registrada no banco de dados por meio de um conjunto específico (aqui também chamado de classe). No banco de dados em saúde, são comumente definidos como conjuntos separadados usuário do SUS, trabalhador, estabelecimento e procedimento, portanto, cada objeto da classe é relacionado em tabelas à parte. Em bancos de dados estruturados, o formato mais comum é o de tabela, com linhas, ou tuplas, representando cada instância, isto é, o usuário do SUS x, trabalhador y, estabelecimento z e o procedimento w e colunas representando cada atributo respectivo.

Relacionalmento é a forma de registrar e controlar a interação entre as entidades. Em outras palavras, ocorre um relacionamento quando um atributo de dada entidade apresenta referência necessária a outra entidade.

A relação trabalha para é um relacionamento entre trabalhador e estabelecimento.

A prescrição é um relacionamento entre usuário do SUS, trabalhador, procedimento e estabelecimento.

A dispensaçaõ é um relacionamento entre usuário do SUS, trabalhador, procedimento e estabelecimento.

Note que a descrição de prescrição e dispensação implica em modelar a diferença entre trabalhador prescritor e trabalhador dispensador, bem como estabelecimento de prescrição e estabelecimento de dispensação. Nas leis brasileiras o estabelecimento de prescrição pode ser nulo, caso o médico seja profissional independente. Da mesma forma, no minimundo a dispensação deve ocorrer obrigatoriamente num dado estabelecimento, não aceitando-se valores nulos na restrição de domínio.

Na gestão de banco de dados também são definidas restrições de relacionamento, conhecidas como cardinalidade ou grau da relação.

Cardinalidade é o máximo de instâncias que podem ocorrer em dado relacionamento.

Por exemplo, na relação trabalha para é exigida dedicação exclusiva na empresa, logo a cardinalidade é 1:1 (um para um), pois o trabalhador trababalha para uma e apenas uma empresa.

No caso do relacionamento entre trabalhador e usuário do SUS a cardinalidade é N:M (N para M ou muitos para muitos). Em outras palavras, um usuário do SUS pode se relacionar com um ou mais trabalhadores e um trabalhador pode se relacionar com um ou vários usuários do SUS.

A título de exercício, tente modelar os relacionamentos identificados a partir dos formulários das figuras 4.1 e 4.2. Trace uma linha entre os retângulos desenhados para cada relacionamento e intitulando cada um.

A relação de muitos para muitos é decomposta em relação de um para um ou de um para muitos de modo a tornar viável a gestão de bancos de dados estruturados. A relação entre trabalhador e usuário é sempre especificada em dado contexto, por exemplo, a relação prescreve para ou dispensa para. Dessa forma, a classe dispensação e a classe prescrição torna-se uma tabela relacional a qual define a relação entre diferentes entidades. No caso, a tabela relacional prescrição apresenta cardinalidade 1:1, pois um trabalhador prescreve a um e somente um usuário. Na prescrição, a relação entre trabalhador e procedimento é de um para muitos, pois em dada prescrição um trabalhador pode prescrever um ou muitos procedimentos.

A nomenclatura do SUS de usuário, trabalhador e gestor aqui adotada é comum no ambiente do controle social. A exemplo de atos normativos (BRASIL 2006a, 2009), particularmente a adoção do termo usuário do SUS na modelagem do sistema universal evita a palavra paciente, uma vez o SUS lida tanto com a promoção quanto com a recuperação da saúde. De fato, em 2021 com a campanha de vacinação contra a Covid-19, a maioria dos usuários do SUS atendidos não estavão doentes, ao contrário, permaneceram saudáveis, não sendo adequado chamá-los de pacientes do SUS.

4.2.3.1 Grau de um tipo de relacionamento

Número de entidades que participam desse relacionamento p.Exemplo

  • TRABALHA_PARA é grau 2
  • FORNECE é grau 3

4.2.3.2 Restrições de relacionamentos

Cardinalidade

Em relações binárias especificam o número máximo de instâncias de relacionamento na qual uma entidade pode participar.

Exemplo: - TRABALHA_PARA 1:N - GERENCIA 1:1

Cardinalidades possíveis:

  • 1:1
  • 1:N
  • N:1
  • M:N

Toda vez que tiver uma situação cuja cardinalidade for M:N, elaborar tabela relacional

4.2.3.3 Restrições de participação

Dependência de existência

Determina se a existência de uma entidade depende da existência de outra entidade relacionada. Também chamada de restrição de cardinalidade mínima

Exemplo: Se a empresa determinar que nem todo funcionário precisa estar vinculado a um departamento temos 0:N

5 A linguagem SQL

SQL vem da sigla inglesa Structured Query Language ou Linguagem de Consulta Estruturada. A linguagem SQL viabiliza a consulta, manipulação, definição e controle de acesso aos dados. Cada operação será descrita nas seções 5.3, 5.4, 5.5 e 5.6.

Fundamentalmente, a linguagem SQL é utiizada para manipular dados registrados em tabelas.

Planilhas de cálculo são comuns para gestão manual de dados quando o volume em número de linhas e colunas não é expressivo, isto é, em torno de dezenas e milhares, respectivamente. Bancos de dados com gestão automatizada em SGBD também podem trabalhar no formato de tabela. Numa analogia com dados em planilhas de cálculo, podemos supor que cada aba do arquivo XLSX ou ODS seja uma tabela e o arquivo inteiro contendo várias tabelas relacionadas entre si possa ser chamado de banco de dados, desde que a primeira linha de cada tabela contenha o título da coluna, aqui chamado de campo ou atributo. O cruzamento de dados entre tabelas requer uma forma específica para referênciá-los. No exemplo da gestão manual de dados em planilha de cálcuo as referências para cruzar células são as respectivas linhas, colunas e planilhas.

Na linguagem SQL existem os mesmos elementos. Deve-se referenciar o banco, tabela e campo para cada operação. Para isso existem termos e sintaxe específicas.

A estrutura básica da linguagem SQL requer que sejam informados:

  1. O(s) banco(s) de dados relacionados à operação, quando mais de um são tratados na mesma consulta.
  2. A(s) tabela(s) relacionadas à operação.
  3. Os campos que serão manipulados e a referência a qual tabela pertencem.
  4. A operação, isto é, o que deseja fazer (inserir, atualizar, selecionar, etc)
  5. A restrição dos campos, isto é, os filtros ou condições. Se nada for informado, a operação será realizada em todos os registros das tabelas referenciadas.

Antes de falar da linguagem propriamente dita vamos abordar as ferramentas de modo que possam ser identificadas e instaladas para tornar mais produtiva a fixação dos conceitos com a prática.

Existem materiais gratuitos na internet. Recomenda-se a leitora do livro aberto https://pt.wikibooks.org/wiki/SQL.

5.1 Ferramentas para gestão de bancos de dados

A linguagem SQLé comum em diversos SGBD - Sistemas Gerenciadores de Banco de Dados.

Existem SGBD aptos a serem instalados em máquinas comuns ou servidores. Usualmente os SGBD podem ser instalados nos sistema operacional Microsoft Windows®, MACmacOS da Apple ou nas diversas versões de Linux existentes. Basta procurar no buscador, baixar e instalar uma das ferramentas MySQL, PostgreSQL, Firebird, Oracle e Microsoft SQL Server. Todos os SGBD citados fazem parte do SUS com aplicações ligadas a essas ferramentas.

Porém nem todos os SGBD são gratuítos, portanto, recomenda-se a instalação do MySQL ou PostgreSQL para uso pessoal ou na sua instituição, uma vez que ambos são utilizados em grandes corporações e são capazes de lidar com milhões, ou até bilhões de registros a depender dos recursos de armazenamento, memória e processador disponíveis.

Existe plataforma de bancos de dados em núvem, a qual basta ser contratada junto ao fornecedor, por exemplo, a SQL Azure da Microsoft® e a google Cloud SQL.

Aprender SQL significa falar o mesmo idioma praticado em dezenas de lugares, porém, com diversas variações. Assim como é possível aprender espanhol básico e falar em diversos países, é desejável especializar na variação praticada em Buenos Aires, Madri ou Guadalajara, caso venha a se comunicar frequentemente com a linguagem local.

5.2 Ferramentas para interface com o usuário

Existem ferramentas, chamadas de cliente dos SGBD, que facilitam a interação com o usuário. Assim como ocorre com R Commander, a interação padrão do usuário com a linguagem é por meio de um terminal com interação praticamente exclusiva via teclado, onde são digitados os comandos e executados, sendo mostrado o resultado em forma de texto simples (figura 5.1).

Terminal do PostgreSQL.

Figure 5.1: Terminal do PostgreSQL.

Da mesma forma que existe o RStudio, plataformas oferecem mais recursos, inclusive com utilização online e diretamente do navegador, isto é, podem ser acessadas remotamente sem que o SGBD e a plataforma estejam instaladas na máquina em uso. As plataformas facilitam o gerenciamento e desobrigam o uso de linhas de comando para tudo, contendo vários recursos abertos à interação com o mause.

Dentre as ferramentas que rodam em navegador, destacam-se:

pgAdmin.

Figure 5.2: pgAdmin.

Exemplos de ferramentas com plataforma visual própria que são baixadas e instaladas na máquina (stand alone):

DBeaver.

Figure 5.3: DBeaver.

Para os exercícios a seguir recomenda-se instalar o PostgreSQL e o DBeaver.

Se você não possui o PostgreSQL instalado, pode praticar na plataforma https://pgexercises.com/ (figura 5.4)

Ficha da Assistência Farmacêutica.

Figure 5.4: Ficha da Assistência Farmacêutica.

Antes de iniciar as práticas em SQL é importante se familiarizar com a sintaxe e elementos básicos.

5.3 Consulta em SQL

A Linguagem de Consulta de Dados DQL, do inglês, Data Query Language é constituída por apenas um comando, o SELECT, associado às cláusulas dispostas na seção 5.3.2.

A sintaxe básica envolve as palavras reservadas

  • SELECT sucedida dos atributos selecionados, utilizando-se asterisco * para todos os atributos,
  • FROM sucedido das tabelas cujos atributos pertencem,
  • WHERE, opicional, para estabelecer as condições.

5.3.1 Seleção de registros

SELECT tabela_1.campo_1,
       tabela_1.campo_2,
       tabela_2.campo_3,
       tabela_x.campo_n
  FROM bd_1.tabela_1,
       bd_2.tabela_2,
       bd_x.tabela_x
 WHERE condição_1,
       condição_2

O exemplo do comando SELECT * FROM bd_teste.tm_teste , observado na figura 5.1, pode ser reescrito.

Observe que não foi apresentada cláusula WHERE na tabela 5.1, sendo selecionado todos os registros. Na tabela 5.2, contudo, foi selecionado apenas o registro do sexo feminino.

SELECT id_usuariosus,
       no_usuariosus,
       sg_sexo,
       dt_nascimento,
       co_municipio_ibge
  FROM bd_teste.tm_teste;
Table 5.1: Registros da tabela tm_teste presente no banco bd_teste.
id_usuariosus no_usuariosus sg_sexo dt_nascimento co_municipio_ibge 
SELECT *
  FROM bd_teste.tm_teste
 WHERE sg_sexo = 'F';
Table 5.2: Registros da tabela tm_teste presente no banco bd_teste.
id_usuariosus no_usuariosus sg_sexo dt_nascimento co_municipio_ibge

5.3.2 Cláusulas

As cláusulas são condições para restringir os registros que deseja selecionar ou dados que deseja atualizar. As principais são listadas a seguir.

  • FROM especifica a tabela cujos registros serão selecionados.
  • WHERE condição de seleção dos registros intercalada pelos operadores lógicos apontados na seção 5.3.3.
  • GROUP BY agrupa os registros segundo os atributos especificados.
  • HAVING condição de seleção dos grupos.
  • ORDER BY define o ordenamento dos registros com ASC para ascendente e DESC para decrescente.
  • DISTINCT seleciona tuplas (conjuntos de registros) sem repetição.
  • UNION para unir o resultado de duas consultas cujos registros apresentam os mesmos atributos respectivamente.

5.3.3 Operadores lógicos

  • AND para o E lógico, conjunção \(\wedge\), ou seja, verdadeiro quando ambas as condições devem ser satisfeitas.
  • OR para o OU lógico, disjunção \(\vee\), ou seja, verdadeiro quando ao menos uma das conções é satisfeita.
  • NOT para negação lógica \(\neg\), ou seja, inverte o valor da expressão.

5.3.4 Operadores relacionais

A comparação de valores segue a notação a seguir:

  • símbolos matemáticos igual =, diferente <>, menor <, maior >, menor ou igual <= e maior ou igual >=.
  • BETWEEN para valores num dado intervalo.
  • LIKE para consulta aproximada de texto, por exemplo, iniciando com silv%, terminando com %estre ou contendo %silvestre% ao procurar no campo nome_do_usuario.
  • IN para busca em dada lista, por exemplo co_municipio_ibge in (334501, 521250)

5.3.5 Operadores e funções matemáticas

  • operadores: + adição, - subtração, * multiplicação \(\times\), / divisão \(\div\), ^ exponenciação \(x^{n}\).
  • ABS para o valor absoluto, isto é, remove o sinal negativo.
  • ROUND(x, n) para arredondar o número \(x\) com \(n\) casas decimais.
  • CEIL para arredondar para o próximo número inteiro.
  • FLOOR para arredondar para o número inteiro anterior.
  • SQRT para raiz quadrada.
  • LOG para logarítmo na base 10.

5.3.6 Funções matemáticas e estatísticas

Existem funções que podem ser utilizadas para avaliar a tabela inteira ou associadas à cláusula GROUP BY, por exemplo:

  • COUNT para frequência.
  • SUM para somatório \(\sum\).
  • MIN para obter o valor mínimo.
  • MAX para obter o valor máximo.
  • AVG para média.
  • STDDEV para o desvio padrão.
  • VARIANCE para a variância.

5.3.7 Junções

O cruzamento entre duas tabelas é realizado com comandos de junção, o qual apresenta uma tabela derivada das tabelas de origem.

Fundamentalmente, o cruzamento pode ser feito utilizando-se as tabelas na cláusula WHERE, separadas por vírgula , ou utilizando as variantes JOIN.

Um exemplo de join é apresentado a seguir:

SELECT * FROM tb_usuario JOIN tb_municipio ON co_municipio_ibge = co_ibge;

Aqui, a tabela tb_municipio contem um campo co_ibge contendo os seis dígitos do código de município da tabela mantida pelo Instituto Brasileiro de Geografia e Estatística - IBGE.

  • INNER JOIN, ou simplemente JOIN, \(A\bigcap B\), retorna todas as linhas de várias tabelas em que a condição de junção é atendida.
  • LEFT OUTER JOIN, ou simplemente LEFT JOIN, \(A-B = A\bigcap B^{c}\), retorna registros da tabela à esquerda cuja condição junção é atendida.
  • RIGHT OUTER JOIN, ou simplemente RIGHT JOIN, \(B-A = B\bigcap A^{c}\), retorna todas registros da tabela à direita cuja condição de junção é atendida.
  • FULL OUTER JOIN, ou simplemente FULL JOIN, \(B \bigcup A\), registros das tabelas relacionadas apresentando valor nulo onde a condição de junção não foi atendida.

Exemplos práticos serão apontados na seção @ref(prática).

5.4 Manipulação de registros em SQL

A Linguagem de Manipulação de Dados DML (do inglês, Data Manipulation Language) constitui as operações de atualização, inserção de novo registro e remoção de registro, respectivamente com UPDATE, INSERT e DELETE.

5.4.1 Atualização de registros

O comando UPDATE apresenta a estrutura mínima UPDATE tabela SET campo_a_atualizar WHERE condição, sendo WHERE opcional.

No exemplo a seguir, a data de nascimento é atualizada para o usuário com identificador 1.

UPDATE bd_teste.tm_teste SET dt_nascimento = '1928-12-22' WHERE id_usuariosus = 1;

Quando a atualização envolve duas ou mais tabelas utiliza-se a cláusula FROM para indicar a origem dos dados que atualizará a tabela:

UPDATE tabela_a_ser_atualizada
   SET campo_atualizado1=valor_campo_origem1, 
       campo_atualizado2=valor_campo_origem2
  FROM tabela_com_valor_de_origem   
 WHERE condição_1 
   AND/OR condição_2

A sintaxe com FROM ocorre no Oracle e no PostgreSQL. No MySQL as tabelas são elencadas sempre após UPDATE não havendo a clásula FROM. Portanto, é importante compreender a lógica geral de operação e consultar manuais e foruns para a respectiva sintaxe da ferramenta adotada.

5.4.2 Estrutura básica para inserção de registros

Existem várias formas para fazer carga de dados no SGBD. A forma mais comum é fazer a carga de um arquivo tabulado, usualmente com separador de vírgula , ou ponto e vírgula ; em formato CSV.

A carga de grande quantidade de registros será vista mais adiante.

Contudo, o mecanismo mais seguro é utilizar o comando INSERT. A sintaxe básica é

INSERT INTO bd_1.tabela_1 (campo1, campo2)
VALUES (valor_campo1, valor_campo2)

Exemplo:

INSERT INTO bd_teste.tm_teste 
            (id_usuariosus, no_usuariosus, sg_sexo, 
            dt_nascimento, co_municipio_ibge)
     VALUES (3, 'Jussara Lemos', 'F','1999-02-28', 354850);

Note que, ao contrário da figura 5.1, os campos foram elencados. Isso significa que é possível suprimir o nomes dos campos na sintaxe, desde que a ordem de inserção corresponda à ordem dos campos na tabela.

A variante a seguir, com campos suprimidos e ordenados de forma diferente, funcionaria da mesma forma, desde que a posição dos nomes dos campos corresponda com a posição dos valores.

INSERT INTO bd_teste.tm_teste 
            (sg_sexo, dt_nascimento, 
            co_municipio_ibge, no_usuariosus)
     VALUES ('M','1971-05-19', 354850, 'Marcelo Moura');

5.4.3 Estrutura básica para eliminar registros

A remoção de registros segue a estrutura DELETE FROM nome_da_tabela WHERE condição. Todos os registros serão removidos caso não seja utilizado WHERE.

Exemplo:

DELETE FROM bd_teste.tm_teste WHERE id_usuariosus = 2

5.5 Definição de dados em SQL

Uma vantagem da gestão de dados com SGBD é a definição do tipo de dados, o que impede, por exemplo, que um texto seja armazenado num campo numérico ou um número num campo de data.

A Linguagem de Definição de Dados - DDL, do inglês, Data Definition Language, apresenta os seguintes comandos:

  • CREATE para criação de tabelas.
  • DROP para eliminação de tabelas.
  • ALTER para modificação ou inserção de campos em tabelas.
  • TRUNCATE para eliminar todos os regitros da tabela.

5.5.1 Criar tabela

DROP TABLE MEDICAMENTO;

CREATE TABLE `MEDICAMENTO` (
  `ID` int(1) DEFAULT NULL,
  `DCB` varchar(10) DEFAULT NULL,
  `FORMA_FARMACEUTICA` varchar(10) DEFAULT NULL,
  `CONCENTRACAO` varchar(10) DEFAULT NULL,
  `UNIDADE_DE_MEDIDA` varchar(10) DEFAULT NULL
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

5.5.2 Remover tabela

5.5.3 Alterar tabela

5.6 Controle

A Linguagem de Controle de Dados DCL, do inglês, Data Control Language é utilizada para controle de leitura e escrita em bancos e tabelas.

CREATE USER para criar usuários. GRANT para conceder privilégios. REVOKE para revogar privilégios.

Exemplos:

-- cria usuário e senha
create user joana with encrypted password 'senhaboa123';

-- cria usuário e senha com data e hora de expiração
CREATE USER tiago WITH PASSWORD 'uma_senha_bem_boa123' 
       valid until '2021-12-03 15:23:00.533249+00';
       
-- concede privilégios sobre um banco de dados       
grant all privileges on database teste to joana;
GRANT USAGE ON SCHEMA bd_geral TO teste;
GRANT USAGE ON SCHEMA bd_teste TO tiago;

-- concede privilégios sobre todas as tabelas de banco de dados
GRANT select ON ALL TABLES IN SCHEMA bd_geograficos TO tiaho;
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA bd_documento TO mariana;

-- concede privilégios sobre uma tabela
GRANT ALL ON TABLE bd_teste.tm_teste TO mariana;

-- revoga privilégios sobre uma tabela
REVOKE TRUNCATE ON TABLE bd_teste.tm_teste FROM mariana;

6 Prática de SQL com PostgreSQL e R

6.1 Configuração do ambiente PostgreSQL em R

Existem várias formas de integrar R com outras linguagens.

O presente capítulo de livro foi realizado unindo o código em SQL e R, utilizando-se o chunk sql no RMarkdwon.

Os códigos abaixo funcionarão se você acessar o PostgreSQL a partir de uma máquina local ou remota. Para instalar o PostgreSQL procure a versão mais recente em seu buscador favorito.

Uma vez instalado e configurado o PostgreSQL, basta fornecer os parâmetros ao cliente SQL. Alguns clientes foram exemplificados na seção 5.2. Aqui utilizaremos o próprio R como cliente do PostgreSQL.

Utilize o código-fonte abaixo, modificando os parâmtros que configurou em sua máquina. OS parâmetros são análogos aos demais SGBD listados na seção 5.1. Basta identificar o respectivo pacote e driver para conectar o cliente.

library("RPostgreSQL") # pacote para a conexao com SGBD
conexao <- DBI::dbConnect(dbDriver(drvName = "PostgreSQL"),
           dbname="teste", # nome do banco de dados
           host="localhost", # servidor, podendo ser o IP, ex., 123.456.78.9
           port=5432, # porta, pot padrao usa-se 5432 para o PostgreSQL
           user = 'joana', # usuario que criou ao configurar o PostgreSQL
           password = "senhaboa123") # senha

Os principais comandos do pacote RPostgreSQL são:

  • dbConnect, para realizar conexção com o SGBD, por exemplo, conexao=dbConnect("PostgreSQL", "joana", "senhaboa123", "teste").
  • dbGetQuery, para ler uma tabela persistida no SGBD, podendo carregar como variável no R, por exemplo, dataframe_r=dbGetQuery(conexao, "SELECT * from bd_teste.tm_teste").
  • dbWriteTable, para persistir uma tabela do R no SGBD, por exemplo, dbWriteTable(conexao, "bd_teste.tm_teste2", dataframe_r).

Os três comandos do R acima são suficientes para a manipulação diária de dados geridos em SGBD no R.

7 Legibilidade do código-fonte

7.1 Comentários

7.2 Identação

7.3 Nomenclatura

Atenção ao nomear as colunas para evitar problemas de importação do arquivo do Excel para o MYSQL. O melhor é padronizar usando apenas maiúsculas, ou minúsculas, ou primeira letra maiúscula. Para o nome do campo também não é recomendado começar com número.

  • Caracteres proibidos: @, #, ~, ^, <, >, =, !, espaço
  • Caracteres permitidos: de A - Z de 0 a 9 e underline

Evitar caracteres especiais também no título do arquivo.

Caso use espaço no nome da coluna, deve fazer entre aspas, exemplo: ´nome da coluna´.

Recomenda-se que a primeira coluna seja “ID,” se tiver várias planilhas no mesmo arquivo, é melhor usar, por exemplo, o nome da tabela _id, exemplo: MEDICO_ID Assim, quando for cruzar, não ficam vários campos com o mesmo nome.

Outro aspecto importante, quando forem colunas derivadas, interessante ter nomes associados, por exemplo, data_de_nasc; data_de_nasc_ano.

A equipe pode criar abreviações padronizadas, como:

  • NM = nome
  • DT = data
  • QT = quantidade
  • NASC = nascimento

Ou adotar uma, por exemplo, a do DATASUS - (MAD – Metodologia de Administração de Dados)[http://datasus1.saude.gov.br/estrutura-mad/norma-mad-menu]

7.3.1 Regras gerais de nomenclatura do DATASUS

  1. O nome do objeto deve apresentar clareza, de forma a indicar a sua finalidade no negócio a que está vinculada. Não deve ferir a norma culta da língua portuguesa.
  2. O nome de um objeto de banco de dados deverá ser formado por uma ou mais palavras com todas as letras em maiúsculas e no singular, cada uma separada pelo caractere separador do underscore (_). A sequencia das palavras deve ser lógica de tal forma que dê um significado preciso em Português.
  3. Para a formação de cada palavra de um nome, deve-se sempre considerar a portabilidade entre SGBD´s, sendo assim utilize apenas os caracteres alfabéticos não acentuados e numéricos.
  4. Para o caso de abreviações, as seguintes regras devem ser observadas:
  5. Utilize abreviações ou siglas somente quando o nome completo ultrapassar o tamanho máximo estipulado e nestas situações, somente se for de aceitação e conhecimento geral do órgão;
  6. A palavra principal que compõe o nome de um elemento de dado não deve ser abreviada;
  7. Na abreviação de palavras, siga as regras definidas no item 4 deste documento.
  8. Palavras em outro idioma não serão permitidas. As exceções deverão ser tratadas caso a caso.
  9. Nome de qualquer tipo de objeto e colunas de tabelas deve possuir a formação Prefixo_NomeObjeto. O prefixo para o caso de tabelas e colunas define uma categorização para cada um, sendo que no caso de colunas não é indicado tipo e tamanho que deve estar associado, pois isso depende do negócio, mas é importante observar o bom senso nesse tipo de definição, por exemplo, para colunas cujo tamanho é de informações conhecidas como CPF ou CNPJ deve-se utilizar o tipo e tamanho de acordo com a definição existente.
Table 7.1: MAD – Metodologia de Administração de Dados do DATASUS
SG_ABREVIATURA TP_ABREVIADO DS_CATEGORIA DS_ABREVIATURA DS_PADRAO
AU campo Coluna de Controle de Tabela de Auditoria Coluna que é incluída na geração da tabela de auditoria de colunas utilizadas para armazenamento de informações de controle que permitem o rastreamento da operação na tabela origem. AU_+[ NOME DA COLUNA]
CO campo Código Coluna cujo conteúdo expresse um código, cujo conteúdo não é obtido de uma sequence. Também é utilizada essa regra quando a coluna é uma FK, isto é, coluna herdada de outra tabela, e cuja PK é uma coluna CO_+SEQ_+[NOME DO ATRIBUTO] . CO_+[NOME DA COLUNA]
NU campo Número Coluna cujo conteúdo é representado por algarismos, não significando, necessariamente, que o tipo do campo tenha que ser possuir datatype de natureza numérica. NU_+[NOME DA COLUNA]
ST campo Situação ou Status Coluna cujo conteúdo expressa a situação ou o status do registro ou de algum atributo. Deve ter uma lista de valores atrelada, que pode ser uma tabela de domínio ou uma check constraint. Obs.: Esta categoria de registro deve expressar um código, seja numérico ou alfanumérico, nunca um conteúdo por extenso/ discursivo. ST_+[NOME DA COLUNA]
CO_SEQ campo Código com Sequence Coluna cujo conteúdo expresse um código obtido de uma sequence. O datatype deve ser de natureza numérica ou SERIAL (para o Postgres). A descrição de colunas desse tipo deve ser: - Para sequence específica para a tabela: “Representa a chave primária sequencial da tabela, que é controlada pela sequence [NomeSequence] do banco de dados específica para a tabela.” - Para sequence NÃO específica para a tabela: “Representa a chave primária sequencial da tabela, que é controlada sequence [NomeSequence] do banco de dados.” - Para coluna com datatype SERIAL no Postgres: “Representa a chave primária sequencial da tabela, que é controlada pelo banco de dados através do dadatype desta coluna SERIAL.” CO_+SEQ_+[NOME DA COLUNA]
DT campo Data Coluna cujo conteúdo expresse uma data do calendário civil. DT_+[NOME DA COLUNA]
DS campo Descrição Coluna cujo conteúdo é livre e em forma discursiva independente do tipo e tamanho utilizado (texto). DS_+[NOME DA COLUNA]
QT campo Quantidade Coluna cujo conteúdo expressa um quantitativo. O datatype deve ser de natureza numérica. QT_+[NOME DA COLUNA]
NO campo Nome Coluna cujo conteúdo é de natureza alfanumérica e expressa um nome por extenso sendo composta de palavras, abreviaturas ou ambas. NO_+[NOME DA COLUNA]
TP campo Tipo Coluna cujo conteúdo expressa o tipo do registro ou de algum outro atributo. Deve ter uma lista de valores atrelada, que pode ser uma tabela de domínio ou uma check constraint. Obs.: Esta categoria de registro deve expressar um código, seja numérico ou alfanumérico, nunca um conteúdo por extenso / discursivo. TP_+[NOME DA COLUNA]
SG campo Sigla Coluna cujo conteúdo expressa uma Sigla representativa de algo. O datatype deve ser de natureza alfnumérica. SG_+[NOME DA COLUNA]
VL campo Valor Coluna cujo conteúdo expressa um valor numérico. O datatype deve ser de natureza numérica. VL_+[NOME DA COLUNA]
IM campo Imagem Coluna cujo conteúdo expresse uma binária como imagens, vídeo, audio, bem como qualquer outro tipo de multimidia ou dados em geral IM_+[NOME DA COLUNA]
QTD campo
CD campo
TB tabela Tabela de Sistema Tabela utilizada para armazenar dados de aplicação. TB_+[NOME DA TABELA]
AU tabela Tabela Auditoria Tabela utilizada para armazenar os dados das operações de usuários realizadas no esquema do padrão da GAAD. Exemplo de operações: insert, update, delete. Para estas tabelas a alimentação dos dados será feito por uma trigger e os usuários possuirão somente priviliégio de SELECT (uso exclusivo da GAAD). AU_+[NOME DA TABELA ORIGEM,] onde o nome da tabela é com o prefixo da tabela origem, mas sem o caracter separador _ entre as palavras. Ultrapassando o tamanho máximo de caracteres para nome (30), a última palavra será truncada no 30º caracter.
RL tabela Tabela de Relacionamento (Associativa) Tabela que resolve relacionamentos “N para N” entre duas tabelas. RL_+[NOME DA TABELA1]+ _+[NOME DA TABELA2]
TM tabela Tabela Temporária Tabela utilizada em rotinas dos sistemas para armazenamento temporário de dados. TM_+[NOME DA TABELA]
TH tabela Tabela de Histórico Tabela utilizada para armazenar os dados históricos de uma determinada funcionalidade, podendo ter vida útil para os dados. TH_+[NOME DA TABELA]
LOG tabela
TL tabela Tabela Log de Operações Tabela utilizada para armazenar os dados das operações de usuários realizadas no esquema. Exemplo de operações: insert, update, delete. Este tipo de tabela somente pode ser utilizado para log´s alimentados cuja responsabilidade é da Equipe de Desenvolvimento de Sistemas. TL_+[NOME DA TABELA]

7.4 Interface do usuário dom SGBD

Existem diversos aplicativos para auxiliar na administração do SGBD.

Sçao exemplos o phpMyAdmin MySQL Workbench e DBeaver.

8 Desambiguação de dados de usuários.

Caption for the picture.

8.1 Pareamento probabilístico onde não há integridade referencial

Na integridade referencial há univocidade do dado.

  • Elementos para Deduplicação / Pareamento
  • Verificação dos dados, avaliação da semântica
  • Deduplicação / Pareamento determinístico
  • Deduplicação / Pareamento probabilístico
  • Caracterização e escolha de campos de cruzamento
  • Determinação da pontuação e escolha do ponto de corte
  • Geração de identificador único

–>

–>

9 Bigdata

https://tecnetit.com.br/as-10-melhores-ferramentas-de-big-data-de-codigo-aberto-para-2020/

10 Referências

Booch, Grady, James Rumbaugh, and Jacobson Ivar. 2005. UML: Guia Do Usuário. Edited by Fábio Freitas da Silva and Cristina de Amorim Machado. Elsevier.
BRASIL. 2006a. Decreto Nº 5.839, de 11 de Julho de 2006. Dispõe Sobre a Organização, as Atribuições e o Processo Eleitoral Do Conselho Nacional de Saúde - CNS e dá Outras Providências. Diário Official da União, Casa Civil.
———. 2006b. “SINANWEB - Notificações.” http://portalsinan.saude.gov.br/images/documentos/Agravos/NINDIV/Notificacao_Individual_v5.pdf.
———. 2009. Portaria Nº 2.871 de 19 de Novembro de 2009. Constitui o Comitê Nacional de Promoção Da Saúde Do Trabalhador Do Sistema Único de Saúde - SUS. Diário Official da União, Ministério da Saúde.
———. 2021. “Portaria GM/MS Nº 1.768, de 30 de Julho de 2021. Altera o Anexo XLII Da Portaria de Consolidação GM/MS Nº 2, de 28 de Setembro de 2017, Para Dispor Sobre a Polı́tica Nacional de Informação e Informática Em Saúde (PNIIS).” Ministério Da Saúde, Diário Oficial de União.
PostgreSQL. 2022. “Chapter 8. Data Types.” https://www.postgresql.org/docs/current/datatype.html; The PostgreSQL Global Development Group.
Wikipedia. 2022. “Byte.” https://pt.wikipedia.org/w/index.php?title=Byte&oldid=63073823.