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.

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).

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. 

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:

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.

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!