Banco de Dados Pular Página inicial principal

para o conteúdo Lição 1 Lição 2 Liçãopara

Pular 3 Lição 4
a navegação Lição 5 Lição 6 Lição 7

PDF - VERSÃO DE IMPRESSÃO

Otimização e Visões

objetivo
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á?
 problematização
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.

case
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.
O case o(a) deixou curioso(a)? Assista ao vídeo, a seguir, para conhecer um pouco mais sobre essa história:
 Conceitualização
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.

Figura 1: Esquema gráfico padrão de entrada ( input ), processamento ( processing ) e saída ( output ). / Fonte : o autor.

#PraCegoVer – diagrama com uma seta vermelha, com a inscrição “entrada”, apontando para a esquerda, em sentido de um retângulo preto, onde
está inscrito “processamento”. À direita do retângulo, há uma outra seta laranja, apontando para a esquerda, com a inscrição “saída”.

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).
Chave Secundária
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:
Tabela 1 - Tabela de Funcionários / Fonte : o autor.

#PraCegoVer – tabela com 6 linhas e 7 colunas. Na primeira linha, estão identificadas as colunas, destacadas em negrito, sendo na primeira coluna
“codigoemp”, na segunda coluna “nome”, na terceira coluna “codigodepto”, na quarta coluna “catfuncional”, na quinta coluna “cpf”, na sexta
“salário” e na sétima “datademissão”. Na segunda linha temos, na primeira coluna, destacado em negrito “E1”, na segunda coluna “Maria”, na
terceira coluna “D1”, na quarta coluna “C5”, na quinta coluna “123456”, na sexta “1500” e na sétima coluna “03/09/2020”. Na terceira linha, na
primeira coluna, destacado em negrito “E2”, na segunda coluna “José”, na terceira coluna “D1”, na quarta coluna “C2”, na quinta coluna “345678”,
na sexta “1250” e na sétima coluna “01/10/2020”. Na quarta linha, na primeira coluna, destacado em negrito “E3’, na segunda coluna “Antônio”, na
terceira coluna “D2”, na quarta coluna “C5”, na quinta coluna “365478”, na sexta “1300” e a sétima coluna está em branco. Na quinta linha na
primeira coluna, destacado em negrito “E4”, na segunda coluna “Marcos”, na terceira coluna “D3”, na quarta coluna “C1”, na quinta coluna
“765432”, na sexta “1200” e a sétima coluna está em branco. Na sexta linha, na primeira coluna, destacado em negrito “E5”, na segunda coluna
“José”, na terceira coluna “D2”, na quarta coluna “C3”, na quinta coluna “345678”, na sexta “1350” e a sétima coluna está em branco.

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.

Visão
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.
Ficou interessado(a) sobre esse tema? Clique no play, a seguir, e assista ao vídeo:
 saiba aplicar
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:
Tabela 2 - Departamentos / Fonte : o autor.

#PraCegoVer – tabela com 5 linhas e 3 colunas. Na primeira linha, estão identificados os nomes das colunas, em negrito; na primeira coluna está
escrito “codigodepto”, na segunda “nome” e na terceira “filial”. Na segunda linha, temos os valores, sendo, na primeira coluna, destacado em
negrito “D1”, na segunda “Recursos Humanos”, na terceira “Curitiba”. Na terceira linha, temos na primeira coluna destacado em negrito “D2”, na
segunda “Contabilidade”, na terceira “Cascavel”. Na quarta linha, temos na primeira coluna destacado em negrito “D3”, na segunda “Marketing”, na
terceira “Curitiba”. Na quinta linha, temos na primeira coluna destacado em negrito, D4, na segunda “Financeiro”, na terceira “Maringá”.
Tabela 3 - Categorias Funcionais / Fonte : o autor.

#PraCegoVer – tabela com 6 linhas e 3 colunas. Na primeira linha, estão identificados os nomes das colunas, em negrito; na primeira coluna, está
escrito “cat_funcional”, na segunda “categoria” e na terceira “nível”. Na segunda linha temos os valores, sendo na primeira coluna destacado em
negrito “C1”, na segunda “Assistente Administrativo I” e na terceira coluna “Técnico”. Na terceira linha, temos na primeira coluna destacados em
negrito “C2”, na segunda “Assistente Administrativo II” e na terceira coluna “Técnico”. Na quarta linha, temos na primeira coluna destacados em
negrito “C3”, na segunda “Auxiliar Administrativo I” e na terceira coluna “Operacional”. Na quinta linha, temos na primeira coluna destacado em
negrito “C4”, na segunda “Auxiliar Administrativo II” e na terceira coluna “Operacional”. Na sexta linha, temos na primeira coluna destacado em
negrito “C5”, na segunda “Gerente” e na terceira coluna “Gestão”.

Teríamos, em um nível conceitual, o seguinte diagrama:

Figura 2 - Diagrama Entidade Relacionamento / Fonte : o autor.

#PraCegoVer – a imagem contém, da esquerda para a direita, um retângulo, no qual está escrito “Departamento 1”, ligado a ele há um losango em
que está escrito “aloca N”, ligado a ele um outro retângulo onde está escrito “Funcionário N”, ligado a ele há mais um losango com a inscrição
“mantém 1” e, por fim, outro retângulo em que está escrito “Categoria”.

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:

Tabela 4 - Visão 1: Funcionários de uma Filial / Fonte : o autor.

#PraCegoVer – tabela com 3 linhas e 7 colunas. Na primeira linha, estão identificadas as colunas, destacadas em negrito, sendo na primeira coluna
“codigoemp”, na segunda coluna “nome”, na terceira coluna “codigodepto”, na quarta coluna “Depto”, na quinta coluna “catfuncional”, na sexta
“cpf” e na sétima “datademissão”. Na segunda linha temos, na primeira coluna destacado em negrito “E1”, na segunda coluna “Maria”, na terceira
coluna “D1”, na quarta coluna “Recursos Humanos”, na quinta coluna “C5”, na sexta “123456” e na sétima coluna “03/09/2020”. Na terceira linha
temos, na primeira coluna destacado em negrito “E4”, na segunda coluna “Marcos”, na terceira coluna “D3”, na quarta coluna “Marketing”, na
quinta coluna “C1”, na sexta “765432” e a sétima está em branco, sem valores.

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!
.
REFERÊNCIAS
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.

MENU PDF - VERSÃO DE IMPRESSÃO