Até o momento, aprendemos sobre os modelos de Banco de Dados com foco especial na entrada de dados e armazenamento. Preocupamo-nos com o processo de levantamento de necessidades e com a estruturação do projeto.
A fim de obter um projeto mais eficiente, a partir dos três níveis da arquitetura de Banco de Dados, nós detalhamos cada nível, partindo das necessidades encontradas no mundo real do usuário, até chegarmos próximo ao nível dos dados, dentro do Banco de Dados. Nesse nível, vimos como podemos manter a integridade dos dados formalmente.
Agora, chegou o momento de pensarmos em como vamos extrair os dados de forma eficaz e devolvê-los ao usuário, por meio das informações. O objetivo dessa lição é estudar como podemos organizar melhor o Banco de Dados para otimizar as pesquisas que os usuários farão, diariamente, e aumentar a eficácia da saída de informações processadas. Vamos lá?
Como você já deve ter visto em outras disciplinas, tudo o que desenvolvemos em informática tem sempre três preocupações básicas: entrada, processamento e saídas. Afinal, de que adianta possuir diversos dados, armazená-los corretamente e não serem úteis para nada?
Você já se perguntou como ocorre o acesso aos dados, que se transformarão em informações úteis para a tomada de decisão? Se essa pergunta já passou por sua cabeça, fique tranquilo(a), pois, nesta lição, você vai descobrir!
Quando citamos entradas de dados, estamos nos referenciando a tudo que o usuário vai informar ao sistema, sejam dados digitados, coletados por sensores, imagens ou áudio. Para nós, em Banco de Dados, isto está vinculado diretamente ao minimundo do usuário, que é a “fatia” do mundo real, a qual foi separada para análise e transformação em dados armazenados.
Em um segundo momento, nós nos preocupamos com a parte de processamento, que é como iremos organizar os dados dentro da base, ou seja, em um SGBD-R (Sistema Gerenciador de Banco de Dados Relacional).
Vamos armazenar os dados em tabelas relacionadas, por meios de chaves primárias-estrangeiras, que permitirão a composição das informações, a partir de vários caminhos. Eles podem ser caminhos já previstos junto ao usuário; caminhos que serão criados junto ao sistema desenvolvido; caminhos ad-hoc, que surgem pela necessidade do usuário e não são previstos durante o projeto, mas, na realidade cotidiana, surgem conforme os problemas do “minimundo” se desenvolvem.
Ciente desta realidade, o projetista deve prever, no Banco de Dados, formas que otimizem as saídas de informações, ou consultas, e possibilitem o acesso às informações de forma rápida e segura. Para resolver essa necessidade na prática, são definidas, dentro do Banco de Dados, as Chaves Secundárias, ou índices de acesso, e Visões de Acesso.
Esses dois temas serão explicados em detalhes na seção de conceitualização, na qual vamos entender o porquê é necessário melhorar a eficiência dos Bancos de Dados, por meio de processos de organização de dados secundários.
Uma empresa muito famosa, no Brasil, disponibilizou um concurso público para preencher 10 vagas em seu quadro de funcionários, aberto a todas as pessoas. Com a divulgação da oportunidade, milhares de pessoas acessaram o sistema da empresa, via Internet, para preencher a ficha de inscrição e enviar seus currículos em formato PDF (digitalizados).
A área de Recursos Humanos da empresa esperava que cerca de 100 a 200 pessoas se candidatassem aos cargos, mas a divulgação das vagas tomou uma proporção tão grande que mais de 50.000 pessoas se candidataram às vagas. E, agora, o que fazer quando existem mais de 50.000 documentos para serem lidos e analisados manualmente?
Podemos observar, nesse caso, que houve uma grande falha na definição do problema, ou seja, quando definiram sobre a divulgação das vagas, não previram que poderiam ser escritas milhares de pessoas e que a empresa não teria recursos (funcionários) suficientes para processar as entradas (documentos) e gerar o retorno às pessoas (saídas), dentro do prazo determinado para preenchimento das vagas.
Esse é um problema real, que poderia ter sido evitado com o uso de tecnologias, ou seja, um analista de sistemas poderia ter sido consultado para desenvolver um sistema de suporte a recrutamento e seleção. Nesse sistema, as pessoas poderiam preencher os principais dados estratégicos de seus currículos para armazenamento em um Banco de Dados.
Mas, mesmo assim, ainda, continuaríamos com um problema delicado: como processar (analisar) os dados de cerca de 50.000 pessoas, classificando-as de acordo com critérios isonômicos (igualdade) e de forma ágil, sem comprometer os demais sistemas computacionais da empresa?
Um bom projeto de banco de dados relacional pode ajudar, e muito, nesse processo, pois, além de ter o vínculo dos dados efetuado de forma coerente, possibilita que os administradores do banco definam chaves de acesso alternativas. Essas chaves organizarão os dados de forma diferente à organização natural, realizada pela chave primária, agilizando a recuperação das informações por outros atributos.
Elas, também, podem criar visões de acesso às informações, que seriam, de forma simplificada, a união de atributos, criando “tabelas” virtuais, que, na verdade, não existem fisicamente no Banco de Dados, mas que são disponibilizadas aos usuários para atender às suas necessidades. As “tabelas” podem respeitar a realidade e requisitos apresentados por outros setores da empresa, que, em geral, consomem apenas as saídas do sistema, ou melhor, irão ter acesso a consultas e relatórios, para tomada de decisão.
Esse é o caso do exemplo anterior, no qual o setor de RH da empresa não irá fazer entrada de dados no sistema (que será realizado pelos candidatos), mas terá que tomar decisões com base nos dados informados e de forma ágil e segura.
Na próxima seção, aprofundaremos mais sobre o assunto e trabalhar os conceitos que dão suporte a essas necessidades.
Antes de iniciarmos, especificamente, o assunto sobre otimização de acesso aos dados no banco, é importante recuperarmos o conceito básico de tudo o que é feito dentro da área de Tecnologias da Informação (TI), ou seja, o conceito de Entrada, Processamentos e Saídas.
Sempre que pensarmos em qualquer coisa no mundo da tecnologia, pensaremos, basicamente, nesses três pilares que sustentam o mundo digital. Cito basicamente, pois existem outros componentes que poderiam ser considerados, como o feedback, mas, se tivermos segurança no básico, conseguiremos compreender e desenvolver os demais itens, posteriormente.
Então, apenas, para relembrar, entrada é tudo o que vamos inserir no sistema, sejam dados digitados, coletados por biometria (reconhecimento facial, coleta de digital, leitura de íris dos olhos etc.), fala, leitura de sensores (sensores de temperatura, pressão atmosférica, velocidade etc.), seja, até mesmo, o fornecimento de dados enviado por outro sistema. Quando pensamos em Banco de Dados, as entradas são os dados e as informações que os usuários irão informar ao sistema, de acordo com o levantamento realizado.
Conforme podemos observar na Figura 1, na outra extremidade, temos a saída, que é o resultado que o usuário espera obter, após o processamento da(s) entrada(s).
Como exemplo de saída, podemos ter muitas coisas, como o saldo bancário, quando você consulta sua conta corrente, uma informação sobre o horário de uma sessão de cinema, o preço de um produto, um relatório de vendas de um determinado período, entre diversas outras informações, ou até ações que os sistemas informatizados podem realizar.
O que, porém, ocorre dentro do processamento?
A parte de processamento — podemos dizer — que é o coração de tudo o que é feito dentro da área de TI, mas é uma caixa preta. É onde os desenvolvedores, analistas, administradores de banco de dados atuam, criando rotinas, processos, algoritmos, programas que irão receber as entradas, transformá-las em informação e formatar a saída esperada pelo usuário.
Para o usuário comum, essa etapa é considerada a “caixa preta”, pois poucos sabem o que ocorre dentro desta fase. Na etapa de processamento, podem estar as diversas linguagens de programação, acesso a sistemas operacionais, que é o software que gerencia todos os equipamentos computadorizados, manipulação de banco de dados, entre tantas outras atividades que podem ocorrer, sem qualquer conhecimento do usuário acerca das tecnologias e técnicas envolvidas, pois, para o usuário comum, o importante é ter o resultado adequado, de forma rápida e confiável.
Imagine, agora, que você entrou em um app, no seu celular, para solicitar um transporte, ou uma refeição. Quando você faz a solicitação, está passando as entradas para o sistema, por exemplo, onde você está, quem é você, a forma como vai pagar pelo serviço e, principalmente, qual é o serviço solicitado.
Neste momento, há uma nova entrada no sistema, respondendo a sua solicitação. O sistema irá processar essa informação e, com base nos dados geoprocessados (sua localização e localização do prestador), é estimado um tempo de atendimento. Essa rotina segue até que o seu serviço seja finalizado e entregue, ou até que uma das partes do processo force o encerramento, cancelando o atendimento.
Essa introdução foi feita para relembrar que, quando estamos atuando em Banco de Dados, trabalhamos diretamente na etapa de processamento, ou seja, recebemos as demandas dos usuários e temos que devolver as informações desejadas, mas isso deve ser feito sempre de forma segura e ágil.
Até o momento, trabalhamos bastante com a segurança dos dados, mantendo a preocupação com a integridade e com a certeza de que tudo o que está armazenado dentro do Banco de Dados é confiável.
Dentro da área de TI, porém, um dos principais desafios é ser rápido, além de seguro. Temos que ser rápidos em gerar as informações aos usuários, pois, na maioria das vezes, a saída esperada do sistema vai permitir a tomada de decisão ou o desenvolvimento de alguma ação.
Quando trabalhamos com o nível físico de dados, aprendemos que temos que definir as chaves primárias de cada tabela, que, além de permitir o acesso aos dados armazenados, vai fazer a organização primária desta tabela. Porém, em muitas oportunidades, esta chave não é uma chave natural, ou, até mesmo, não é a chave que o usuário utiliza na maior parte do tempo para fazer acesso às informações.
Então, essa chave é muito eficiente para a integridade, porém pode não ser eficiente para a agilidade no processamento. Com base nisso, os SGBDs possibilitam aos Administradores de Banco de Dados a definição de outras formas de acesso, como chaves secundárias e a criação de visões específicas dos dados organizados pela forma mais popular de acesso (DATE, 2004).
Em um Banco de Dados Relacional, já vimos que a estruturação das informações é realizada por meio de chaves primárias com chaves estrangeiras, ou melhor, sempre que vamos gerar uma informação ao usuário, podemos fazê-lo utilizando combinações de chaves para estruturar todo o processo. No entanto, muitas vezes, precisamos acessar os dados armazenados por outro caminho que, necessariamente, não precisa ser a chave primária.
Vamos considerar que temos um cadastro de funcionários, com a seguinte tabela:
Como podemos observar na Tabela 1, temos como chave primária a coluna “codigoemp”, que identifica todos os funcionários da empresa, porém este não é um dado natural do funcionário, como o “nome” ou o “CPF”.
Vamos considerar que temos, nesta tabela, mais de 20.000 funcionários cadastrados e que precisamos acessá-los com frequência. Qual seria a coluna que você acredita ser mais próxima do usuário final? Com certeza o “nome” ou o “CPF”, pois são dados que os funcionários já trazem consigo e, por isso, são a eles comuns.
Todavia, nenhuma das duas colunas poderiam ser chaves primárias, pois não são chaves únicas. Observe que o “CPF” se repete, pois, na regra de negócio, a empresa pode recontratar uma mesma pessoa após a sua demissão e, por uma questão legal e de histórico, os dados de cada período que a pessoa foi funcionária da empresa devem ser preservados.
Observe, no exemplo da Tabela 1, as informações do funcionário José. Pelo CPF, conseguimos saber que se trata da mesma pessoa, que foi demitida em 2020 e voltou a trabalhar na empresa em outro setor e com outro cargo, logo, o CPF não pode ser a chave primária de acesso, porém, por se tratar de uma chave natural da pessoa, ela pode ser utilizada para recuperar a chave primária.
Agora, vamos considerar que precisamos consultar, com frequência, a relação nominal de funcionários. Essa é uma consulta que, naturalmente, é organizada alfabeticamente, porém, já sabemos que a tabela de funcionários está organizada naturalmente pela chave primária, ou melhor, pela coluna codigoemp.
Cada vez que alguém solicita a relação de funcionários, o sistema manda uma solicitação ao banco de dados, que retorna com a relação de todos os funcionários e, em tempo real, o sistema ordena-os alfabeticamente.
Imagine que você tenha que fazer essa organização manualmente. Quanto tempo demoraria? Como o computador é bem mais eficiente que nós, humanos, quase não percebemos o tempo de organização, porém ele existe e é, proporcionalmente, semelhante ao que faríamos manualmente, ou seja, quanto mais dados para organizar, a complexidade será maior e, consequentemente, o tempo gasto também será maior.
Ao falar em tempo gasto, estamos tratando os recursos computacionais, que, em geral, são compartilhados por todas as pessoas que estão utilizando o mesmo sistema. Desta forma, quando um único usuário deseja ver a relação de funcionários, pode estar consumindo um recurso computacional, que poderia ser utilizado para outra finalidade dentro do sistema.
Para atender a essa necessidade, é muito comum criarmos dentro do banco de dados chaves secundárias, ou índices, que vão consumir apenas espaço físico de armazenamento, mas, no momento de recuperação dos dados, não farão uso de muitos recursos computacionais (de processamento), pois já estarão organizados e o sistema apenas terá que os ler e imprimi-los para o usuário.
Apenas para resumir, as chaves secundárias são, então, uma forma de organizar os dados de uma tabela por um conjunto de colunas (uma ou mais), que, diferente da chave primária, pode se repetir e servem, especificamente, para a criação de índices de acesso, com o intuito de reduzir a carga de processamento de dados nos computadores e agilizar a entrega da informação ao usuário.
Como você deve ter observado, quando falamos de chave secundária, referimo-nos sempre a apenas uma tabela, ou seja, vamos ter a chave secundária, facilitando o acesso aos dados, mas sempre de apenas uma tabela.
No entanto, será que não é possível melhorar o acesso dentro dos relacionamentos? Ou melhor, será que conseguimos melhorar o processo para buscarmos dados que estão em mais de uma tabela? Dessa forma, podemos compor as informações a partir de tabelas que armazenam grande volume de dados.
A resposta é sim, os SGBD-Rs possibilitam que sejam criadas tabelas virtuais, que na verdade não existem no modelo físico, mas que virtualmente existem para atender a situações específicas dos usuários. A essas tabelas virtuais, damos o nome de visão, pois elas não criam novas tabelas, apenas organizam a forma como o usuário vai visualizar os dados dentro do sistema.
Além de agilizar as consultas, uma visão pode melhorar a segurança dos dados, filtrando quais os dados que determinados usuários podem visualizar e, até, como os dados podem ser visualizados. Fazendo, assim, um pré-processamento interno, que reduz a necessidade de processamento dentro do sistema (DATE, 2015).
Para exemplificar, poderíamos criar uma visão com base na Tabela 1, que vimos anteriormente, retirando a coluna de salário. Desta forma, podemos permitir o acesso do usuário a visão dos dados de funcionário, porém este não visualizaria o valor dos salários dos funcionários.
Trabalhar com visões e chaves secundárias é bem simples, pois elas servem como forma de organização dos dados dentro do Banco de Dados, sendo, na maioria das vezes, criadas para atender às especificações do usuário ou para atender a uma necessidade específica.
Para exemplificarmos um pouco mais, vamos observar as duas tabelas abaixo, que estão relacionadas à Tabela 1, que analisamos anteriormente:
Teríamos, em um nível conceitual, o seguinte diagrama:
Vamos, agora, aos problemas que precisamos resolver:
Precisamos classificar todos os funcionários, considerando o CPF e data de demissão, sendo que os funcionários ativos (com data de demissão em branco) devem aparecer primeiro.
Queremos classificar todas as categorias funcionais agrupadas por nível.
Nosso cliente solicitou que cada pessoa consiga visualizar, apenas, os funcionários de uma determinada filial, sem, no entanto, visualizar o salário.
O que vamos precisar para atender a cada uma dessas demandas?
A primeira necessidade é bem simples, basta criar uma chave secundária na tabela de funcionários (Tabela 1), utilizando os campos “CPF” e “DataDemissão”, sendo que, naturalmente, o campo em branco (atual) vai aparecer em primeiro e as datas, posteriormente, organizadas cronologicamente.
Por se tratar de uma só tabela envolvida e não haver nenhuma necessidade de ocultação de dados, apenas a chave secundária já atenderá a esta solicitação.
A segunda necessidade, também, é bem simples e, apenas, com a definição de uma chave secundária na coluna “Nível” já é possível atender à solicitação de classificação.
Já a terceira necessidade é um pouco mais complexa, pois envolve as tabelas de Departamento e Funcionário, havendo, ainda, a necessidade de omissão de dados. Dessa forma, o administrador de banco de dados deve criar uma visão, que vai trazer apenas os funcionários que estão alocados em departamentos da filial selecionada, omitindo o salário. O resultado da visão, considerando a filial de Curitiba, seria:
Antes de analisarmos a visão criada, apenas é bom reforçar que essa é uma tabela virtual, que fisicamente não existe no Banco de Dados, serve apenas para criar uma visão específica dos dados solicitados, que, no caso, são apenas os funcionários que estão alocados na filial de Curitiba.
Observe, também, que trouxemos o nome do “Depto” para dentro da visão, pois será importante para que o sistema apresente os resultados ao usuário. Além disso, observe também que, na visão, não é possível ter acesso ao valor dos salários dos funcionários. Isso garante a performance nas pesquisas e a garantia de que as pessoas que têm acesso a essa visão não visualizam os salários. Dessa forma, não é necessário dar acesso de tabela aos usuários, eles devem acessar apenas a visão.
Como você deve ter observado, o uso de chaves secundárias e visões aumenta o poder dos bancos de dados e auxilia a garantir que os usuários terão resultados seguros, consumindo menos recursos computacionais.
Na próxima lição, iremos trabalhar com mais um conceito importante, no momento do processamento das informações, que é o conceito de transação. Até a nossa próxima lição!
DATE, C. J. Introdução aos Sistemas de Banco de Dados. 8. ed. São Paulo: GEN LTC, 2004.
DATE, C. J. Projeto de Banco de Dados e Teoria Relacional: formas normais e tudo mais. 1. ed. São Paulo: Novatec, 2015.