BANCO DE DADOS

U1 - INTRODUÇÃO A BANCO DE DADOS

Introdução

Em primeiro lugar, apresentamos nossos cumprimentos e que tenhamos uma boa

parceria neste aprendizado sobre banco de dados.
Esta unidade lhe dará uma visão geral de assuntos como: o motivo porque o banco de
dados é um assunto relevante atualmente e a necessidade que as organizações têm
dessas tecnologias para informatização de seus processos. Questões como estas iniciam
nossa linha de raciocínio.
Na sequência, compreenderemos algumas definições sobre o que é um sistema
gerenciador de banco de dados, teremos a noção de quais os passos para a sua
construção, quais profissionais e usuários típicos, qual linguagem é bastante usada
(SQL) e como ela funciona internamente para prover conveniência e eficiência no trato
com dados.
Vamos em frente, e espero que desfrute deste momento de aprendizagem!
Sistemas de Informação e os Dados na Sociedade Atual.

Sistemas de informação e os dados na

sociedade atual

Assuntos relacionados ao tratamento de dados são relevantes, nos

dias de hoje, por conta do grande uso de informações em diversas
situações de nosso cotidiano. A sociedade atual está imersa em
dados e, para compreender esse fenômeno, vale pararmos e
pensarmos em alguns cenários de nosso dia a dia nos quais
informações são manipuladas das mais variadas formas. Por
exemplo, em uma rede social, inserimos o nosso perfil, fazemos
inserções de texto com opiniões, adicionamos fotos e registramos
nossos gostos e coisas com as quais não nos identificamos. Em
nossos celulares, estamos a todo momento recebendo e enviando
mensagens ou mesmo acessando nossa conta no banco para
consultar saldos.
Ainda explorando cenários, mas de forma mais orientada aos
processos, ao comprar uma passagem por um site de vendas da
companhia aérea, escolhemos os dados do vôo, realizamos o
pagamento que, por sua vez, acessará autorização e registrará
transações no site da operadora de cartão de crédito. Com as
informações da passagem aérea, podemos, então, no dia da viagem,
realizar o check-in para viajar. Além da esfera das pessoas, também
para as empresas e organizações é fácil identificarmos cenários
análogos. Um supermercado, ao perceber que as vendas de certo
produto baixam os seus estoques abaixo de um limite de tolerância,
podem requisitar uma nova encomenda ao fornecedor do produto
em questão, um iogurte ou uma barra de chocolate.

Enfim, diversas são as situações em que as nossas atividades são

auxiliadas por sistemas que possuem os dados como peças de
bastante relevância.

Sistemas de informação

Os cenários anteriores de alguma forma utilizam sistemas

informatizados para prover as suas funcionalidades ao usuário final.
Para usuários em geral, podemos ter diversos tipos de softwares
desde uma agenda de contatos em um celular até seus aplicativos
para acesso a banco ou troca de mensagens. Em geral, para
empresas, costumamos caracterizar o conjunto de softwares e de
equipamentos como sistemas de informação, conforme a
definição a seguir.

Um Sistema de Informação (SI) poder ser definido tecnicamente

como um conjunto de componentes inter-relacionados que
coletam (ou recuperam), processam, armazenam e distribuem
informações destinadas a apoiar a tomada de decisões, a
 coordenação e o controle de uma organização. (LANDON;
LANDON, 2010, p. 12).

A coordenação, o controle e a otimização dos processos em uma

organização podem ser explorados em um pequeno cenário.
Imagine que você deseja realizar uma compra pela internet. Diante
dessa necessidade, você usa seu computador e acessa o site da loja
na internet através do seu browser e consulta pelos produtos, analisa
os preços e adiciona os itens no seu carrinho de compras. Uma vez
escolhidos os produtos, você verifica quais as formas de pagamento
e, então, efetiva a sua compra. A loja, diante da sua compra, precisa
então acionar o pessoal do estoque para que os produtos sejam
retirados e disponibilizados para o setor de expedição que, por sua
vez, empacota e despacha a encomenda para a residência do
pedido. Durante o período de envio, você pode rastrear o pedido na
empresa de logística de encomendas. Para que os produtos sejam
consultados, a loja virtual precisou cadastrá-los previamente por
meio de algum responsável pelos cadastros básicos do sistema e,
para estarem disponíveis para a venda, algum setor de compras teve
que estabelecer uma negociação com o fornecedor do produto.
Enfim, perceba que há todo um conjunto de pessoas responsáveis
pelas ações, processos que são seguidos por essas pessoas e um
aparato tecnológico nesse cenário de uso de um sistema de
informação informatizado.

Reflita
Como foi dito, a sociedade hoje vive imersa em dados e em tecnologia de
informação. E, para você, qual sua opinião sobre esse fenômeno? Pare um
pouco e pense, quais benefícios você enxerga e quais pontos de atenção são
importantes para que estejamos alertas? No seu dia a dia, como você se
organiza para, em essência, fazer um bom uso da tecnologia e dos dados?
Dados, informação e conhecimento

Uma peça chave para o devido funcionamento do cenário exposto é

o que chamamos até o momento de dados ou de informações
manipuladas pelo sistema de informação. Apesar de serem, de fato,
termos que podem ser usados indistintamente, existe uma diferença
comumente tratada pelos autores entre dado, informação e
conhecimento, que é interessante para percebermos uma certa
escala de valor deles. Alguns autores ampliam essas distinções para
bits e bytes ou mesmo para sabedoria, para nós, vale ficarmos com
os três elementos.

Um dado pode ser considerado como um registro mais simples, sem

processamento e equiparação com outros registros, é o dado bruto
de certo evento como o nome de uma pessoa ou os dados de uma
venda em específico. A informação já envolve a combinação de
dados para prover alguma visão em um contexto um pouco maior,
por exemplo o valor de um produto de uma marca comparado com
de outra marca ou a totalização de vendas de um caixa. O
conhecimento já contextualiza de forma ainda mais abrangente a
informação com a cruzamento de outros fatos internos ou externos
à organização, como o aumento de vendas por conta das mais
variadas causas: feriados, visita de turistas à cidade ou outros. Em
geral, há no conhecimento alguma análise crítica e cooperação com
nossa habilidade humana de correlacionar fatos.

No nosso exemplo da compra de produtos em uma loja virtual, o

registro de um produto, o cadastro do cliente em si e mesmo de uma
determinada venda podem ser considerados como dados, pois são
básicos, ou seja, registros mais simples. Conforme os dados são
processados por totalizações, equiparações ou outras combinações,
por exemplo, para uma contabilização do volume de vendas de um
dia ou para comparação do estoque de um produto entre dois
períodos, enfim, ao se processar os dados mais simples gerando
resultados, assim pode-se dizer que estamos lidando com
informações. Ao correlacionar essas informações com outros fatos e
registros ou ao se cruzar informações e analisar criticamente todo
um cenário maior com análise crítica de responsáveis por tomadas
de decisões, pode-se dizer que a informação deu suporte ao
conhecimento mais abrangente. Por exemplo, ao se perceber que o
volume de vendas de produtos foi extraordinário, porque houve um
evento no bairro na semana que provocou a mobilização das
famílias para a compra do produto, podemos pensar que já
passamos para a esfera de conhecimento. E os negócios podem se
utilizar bem disso, se esse conhecimento for bem aplicado, com
decisões bem acertadas. No caso do supermercado, ações de
marketing podem ser feitas para alavancar ainda mais o volume das
vendas ou, ainda, o fornecedor pode ser acionado para evitar que
haja a falta do produto e a perda de oportunidades.

Vale perceber, nessa compreensão de dado, de informação e de

conhecimento, que podemos associar uma escala de valor, por
exemplo, o conhecimento tem um valor mais alto, pois está
fortemente relacionado às tomadas de decisões que agregam os
resultados para os negócios. Esse conhecimento foi baseado em
informações de contextos menores, setores em específico da
organização e cujo valor está mais associado àquela esfera. E, por
sua vez, a informação foi o resultado de um processamento de
dados mais simples, cujo valor está na possibilidade de ter um
melhor controle dos registros obtidos com melhor precisão,
qualidade de informação e agilidade. Em geral, essa escala de valor
permite também uma compreensão das necessidades de
informações dos níveis hierárquicos de uma empresa ao usuário de
um sistema de informação. Os dados são gerados a partir dos níveis
operacionais, as informações são manipuladas nos níveis táticos e
gerenciais e os níveis de direção e as tomadas de decisão mais
estratégicas transitam através do conhecimento mais abrangente do
negócio e sua relação com o ambiente de negócios externo.
Arquitetura e Funcionamento de um Sistema de Informação

A compreensão de Sistemas de Informação em nosso roteiro de um

cliente em sua compra na loja virtual permitiu identificar a
necessidade do que chamamos de aparato tecnológico, com seu
conjunto de equipamentos e de softwares para seu devido
funcionamento. Para essa ambientação no mundo de banco de
dados, uma arquitetura simples e um funcionamento típico de um
sistema de informação pode ser compreendido através da Figura
1.1. O usuário do sistema, em seu programa, realiza ações que são
convertidas em requisições para um servidor de banco de dados
responsável por manter os diversos bancos de dados da
organização. Esse servidor processa a requisição, recupera os dados
nos arquivos dos bancos de dados, prepara os resultados e envia de
volta para o usuário.

Figura 1.1 – Estrutura com alguns componentes em um SI com

ênfase para os componentes de BD Fonte:
Elaborada pelo autor.
Os dados dos bancos de dados estão
organizados e estruturados conforme um
modelo de dados, no caso um dos tipos de
modelo, o Modelo Relacional foi ilustrado.
Essa arquitetura é comumente chamada de
arquitetura cliente-servidor, pois um
determinado sistema-cliente que precisa de
um certo serviço, no caso para o trato de
dados, dispara as requisições para um
servidor responsável por prover o serviço.
Ela não é exclusiva para dados, visto que
esses mesmos conceitos podem ser usados
para outros serviços, como navegação na
internet por meio de requisições a
servidores Web (HTTP) ou a leitura de
mensagens enviadas e recebidas por meios
de servidores de correio eletrônico (e-mail).
Vale ainda destacar que outras arquiteturas
mais complexas e outros componentes
podem ser empregados. O propósito nesse
momento fica na compreensão desses
conceitos simples de arquitetura cliente-
servidor e será base para os assuntos
subsequentes de sistemas gerenciadores de
bancos de dados.

Os gerenciadores de bancos de dados

A compreensão da arquitetura cliente-servidor ligada aos sistemas

de informação permitiu perceber que um ponto central no conjunto
de componentes da infraestrutura para tais sistemas passa pelo
sistema gerenciador de banco de dados e pelos diversos bancos de
dados que eles gerenciam. Esses bancos de dados acomodam os
diversos registros das transações dos processos em uma certa
organização.

Portanto, nesse tópico, compreenderemos um pouco mais esses

componentes e outros assuntos que nos ajudarão a entender como
esses bancos de dados são construídos ou implementados.

Definições

Para Elmasri e Navathe (2011), um SGBD é definido da seguinte

forma:

Um Sistema Gerenciador de Banco de Dados (SGBD) (Database

Management System - DBMS) é uma coleção de programas que
 permite aos usuários criar e manter um banco de dados. O
SGBD é um sistema de software de uso geral que facilita o

processo de definição, construção, manipulação e

compartilhamento de bancos de dados entre diversos usuários
e aplicações. (ELMASRI; NAVATHE, 2011, p. 3).

Existem vários exemplos de servidores de bancos de dados (SGBD)

comerciais e comumente usados no dia a dia de empresas, dentre
eles: o SQL Server da Microsoft, o ORACLE e o MySQL da ORACLE,
além de outros.

Saiba mais

Como dito, existem diversos sistemas gerenciadores de banco de

dados ou simplesmente servidores de dados. Nesse curso,
usaremos o MySQL, que é bastante popular, portanto, haverá
muito material de apoio disponível e de fácil uso, além de ser
disponível gratuitamente. Dessa forma, o que acha de já
complementar os estudos dando uma olhada nele? Ambiente-se
com o site em que está disponível, faça o download para instalação,
siga as instruções e divirta-se. Aproveite para instalar o Workbench
também, pois é uma ferramenta que facilita a administração e
outras tarefas no servidor. Para saber mais, acesse o link.

Pela definição de um SGBD, percebe-se que os elementos

gerenciados são os bancos de dados, um termo que pode ter
diversas definições das mais abstratas e abrangentes às mais
concretas e específicas. Para nosso propósito, vale a seguinte
definição dos mesmos autores da definição anterior: “[...] um banco
de dados é uma coleção de dados relacionados. Com dados,
queremos dizer fatos conhecidos que podem ser registrados e
possuem significado implícito.” (ELMASRI; NAVATHE, 2011, p. 3).
A coleção de dados a que se refere à definição pode ser o conjunto
de vendas de nosso cenário da loja virtual. Esses registros
representam os fatos com significado implícito para a nossa loja
virtual, uma determinada venda foi uma transação, o fato ocorrido
na loja ainda que virtual. Essas coleções de dados são relacionadas
entre si e esse termo, relacionamento entre dados, é uma peça
importante quando vamos representar as informações do mundo
real. Por exemplo, as vendas possuem relações com os dados de
clientes, uma certa venda foi realizada para um certo cliente. As
vendas contêm os produtos que estão cadastrados que, por sua vez,
são fornecidos pelos fornecedores e todos esses registros são
coleções de dados que possuem essas relações entre si. Na
organização, o normal é que cada sistema de informação tenha o
seu banco de dados único e centralizado. Quando existem diversos
sistemas de informação para atender a demandas e setores
diferentes, podem existir outros bancos de dados cada um
associado ao seu sistema. Por exemplo, podem existir os sistemas e
bancos de dados que tratam dos registros sobre recursos humanos,
com dados de funcionários, de cargos e de salários, ou ainda, o
banco de dados de financeiro ou da contabilidade com registros de
contas a pagar, de contas a receber, de fluxo de caixa e de outros
dados relacionados.

Existem alguns tipos de bancos de dados: banco de dados relacional,

geográfico, orientador a objetos, NOSQL (Not Only SQL) e outros. O
banco de dados relacional é o foco desta disciplina e um dos mais
empregados nos diversos tipos de aplicações. Um dos componentes
principais desses bancos de dados são as tabelas, ou mais
formalmente chamadas de relações, por isso o nome banco de
dados relacional. As tabelas são os elementos que representam as
entidades do mundo real, representadas no banco de dados e
decompostas em atributos. Assim, uma tabela de VENDAS trata os
dados das vendas ocorridas na loja (mundo real) e possuem os
atributos de data, de valor, de cliente e de outros. O catálogo de
produtos pode estar contido em uma tabela PRODUTOS que
representa o registro dos produtos que são comercializados pela loja
e contém os atributos de código de barras, de descrição, de valor, de
dimensões e de outras características.

A “construção” de um banco de dados

A implementação ou construção de um banco de dados acontece,

em geral, dentro de um processo ou ciclo de desenvolvimento de um
software, que envolve um conjunto de atividades, métodos e
responsáveis organizados entre si para a realização de um produto
de software. Existem diversas metodologias e possíveis processos,
um deles é o modelo em cascata que possui atividades cuja essência
acaba existindo em outros processos.

Em um ciclo de desenvolvimento ou modelo em cascata, a primeira

fase é a de análise de requisitos para levantar as necessidades do
usuário e, na sequência, ocorre o projeto do software para arquitetar
a solução. Depois disso, a fase codificação ou implementação,
correspondente à construção do software em si que, uma vez
pronto, segue para a fase de testes. Com o software pronto, ocorre
a fase de instalação e, ao final do ciclo, há a fase de manutenção para
manter o software em adequada operação. A organização de um
ciclo de desenvolvimento de um software é importante para a
qualidade do produto final, a etapa de projeto em que, por exemplo,
o modelo de dados é contemplado com mais ênfase é um dos pilares
para o desenvolvimento de um sistema de informação que atende
bem aos requisitos.

Para explorar melhor esta ideia do ciclo de desenvolvimento do

software com ênfase para o trato do banco de dados, imagine o
desenvolvimento de software para uma empresa. Quando este
negócio ou um setor desta grande empresa, que denominaremos
aqui de cliente, identifica a necessidade de informatizar ou de
automatizar algo, ele aciona alguma empresa de desenvolvimento
de software para implementar o sistema baseado em banco de
dados. Esse cliente pode ser o dono de um negócio, como uma
pizzaria, ou o responsável por um setor em uma empresa, ou seja,
um setor, por exemplo, de recursos humanos.

No desenvolvimento do software, em geral, em uma etapa chamada

de projeto do software, uma das tarefas é a de estruturar as
informações, isto é, identificar e organizar os dados e como eles se
relacionam, seguindo a ideia das entidades ou das tabelas
comentadas anteriormente. Usando o exemplo da pizzaria, nessa
tarefa pode-se perceber que as informações necessárias para uma
entidade, item do cardápio, uma pizza, no caso, são: descrição da
pizza, detalhes sobre seus ingredientes e o seu valor. Além disso,
outras informações, como clientes com seus atributos de nome, de
endereço e de telefone, precisam ser cadastradas e que, ao comprar
uma pizza, a data da venda é uma informação relevante na venda.
Esse ato de estruturar as informações é chamado de modelagem
dos dados e o responsável que realiza essa tarefa é comumente
denominado de analista ou projetista de dados ou simplesmente
analista e projetista.

Após a modelagem dos dados, ocorre o processo de implantação do

banco de dados em si. Partindo do pressuposto que um servidor de
banco de dados já está instalado, um responsável, chamado
administrador de banco de dados (ou DBA, do inglês, Database
Administrator), captura o modelo fornecido pelo analista e cria o
banco de dados no servidor com seus componentes, dentre eles: as
tabelas, os campos, as chaves para identificar os registros, os índices
e outros componentes, que veremos posteriormente neste curso.
Seguindo nosso exemplo, é nesse momento que uma tabela de
CLIENTES com seus atributos de CODIGO, de NOME e de ENDERECO
é criada junto com outras como: ITENS_CARDAPIO, PEDIDOS,
ITENS_PEDIDOS e assim por diante. A Figura 1.2 ilustra brevemente
o modelo com algumas das tabelas mencionadas e juntamente a um
exemplo de comando para a criação de uma das tabelas. Assim,
pode-se ter uma noção de como seria essa transição da modelagem
para a implantação do banco de dados via comandos para a criação
de tabelas.

Figura 1.2 – Exemplo simplificado de modelo de dados

com comando de criação de tabela Fonte:
Elaborada pelo autor.
Perceba que, nesse momento de criação, as tabelas e o banco de
dados estarão vazios, apenas o seu “esqueleto” e sua estruturação
foram criados no servidor, não havendo ainda os registros ou linhas
das tabelas. Além de sua criação, o administrador de banco de dados
é também responsável por tarefas como instalação de servidores,
configuração de usuários e permissões de acesso aos dados, por
realizar backup e restauração dos bancos de dados e outras ações
administrativas.

Depois de modelado e implantado, o banco de dados pode então ser

acessado pelos seus usuários, que são capazes de envolver os
desenvolvedores e programadores, os usuários dos dados em si e os
sistemas que utilizam seus dados. Os desenvolvedores são os
responsáveis por programar os softwares que justamente permitem
que os usuários desempenhem suas tarefas ativando as operações
no sistema. Essas operações embutidas no software, quando
acionadas por seus usuários, vão disparar comandos de consulta, de
inserção, de alteração e de exclusão dos dados. Por exemplo, o
desenvolvedor, ao criar uma tela de “Registrar Pedidos”, deve
programar que o usuário, ao efetivar um pedido, tenha os dados da
tela inseridos na tabela de PEDIDOS no banco de dados. Dessa
forma, por meio de uma tela mais amigável, as várias manipulações
nos dados podem ocorrer de forma mais fácil para o usuário final.

Ao final do processo de construção que passa pela modelagem e

pelo desenvolvimento do software, o banco de dados fica, então,
disponível para os usuários finais. Esses usuários serão os
envolvidos na alimentação dos dados em si. O gerente da pizzaria ou
usuário encarregado por ele cadastrará os itens do cardápio
abrigados na tabela PRODUTOS; um cliente realizará seu cadastro,
que gerará um registro na tabela de CLIENTES e, depois, poderá
realizar seus pedidos através do sistema que vai originar os dados
na tabela PEDIDOS. Além de acesso ao banco de dados através das
telas amigáveis do sistema, outras formas de acesso ao banco de
dados são previstas, em geral, por ferramentas de manipulação
direta das tabelas. Por exemplo, um desenvolvedor responsável por
realizar manutenção no software, seu respectivo banco de dados,
pode acessar o servidor por meio dessas ferramentas
administrativas. Outros usuários não desenvolvedores, mas
também capacitados para extraírem informações diretamente do
banco de dados, também podem acessar o servidor e realizar suas
consultas.

Essa visão geral detalhada anteriormente, permite sintetizar os

momentos e os responsáveis envolvidos na construção de um banco
de dados. A modelagem dos dados é feita pelo analista ou projetista
de dados que prepara o modelo e os scripts para a instalação e a
configuração do banco de dados pelo administrador de banco de
dados. Com o banco instalado, o desenvolvimento dos softwares é
feito pelos desenvolvedores e programadores para que, por fim, os
usuários finais utilizem e manipulem suas informações. Esses
usuários finais usam as telas amigáveis do sistema para disparar as
manipulações internas sobre os dados e alguns usuários mais
habilitados podem realizar consultas diretamente no banco de
dados. Enfim, esse é um ciclo de vida do banco de dados, desde sua
concepção até o seu uso final.

Utilização de um banco de dados e a linguagem SQL

Todos os envolvidos citados anteriormente precisarão lidar direta ou

indiretamente, em algum grau, com uma linguagem específica para o
trato com Banco de Dados, a comumente denominada SQL. SQL é um
acrônimo de Structured Query Language que, em português, refere-se
à linguagem de consulta estruturada, mas que, na comunidade de
banco de dados, tratamos simplesmente como SQL. Essa linguagem
apresenta um conjunto de comandos com suas respectivas sintaxes
para que operações sejam disparadas para o servidor de banco de
dados. O SGBD, enquanto um servidor para processar as consultas do
seu requisitante, interpreta a consulta e dispara internamente as
ações no banco de dados.

Exemplos de comandos

Para exemplificar, imagine que um administrador do banco de

dados precisa criar um banco de dados e, neste banco de dados,
criar uma tabela de CLIENTES. Neste caso, ele precisa usar o
comando “CREATE DATABASE” para o banco de dados e precisa
também do comando de “CREATE TABLE” para criação da tabela. No
exemplo abaixo, estes comandos são demonstrados. Para a tabela
VENDAS, apenas os campos de código, de nome e de contato foram
considerados e outros detalhes do comando foram abstraídos para
simplificar a explicação neste momento.
 Figura 1.3 – Exemplo de comando DDL Fonte:
Elaborada pelo autor.

Com a tabela criada e ainda nesse sentido de compreender a

natureza dos comandos em SQL, caso um usuário queira inserir um
dado nessa tabela ou queira consultar os dados da tabela, ele pode
usar os comandos de INSERT e SELECT, respectivamente. Eles estão
expostos na sequência:

Figura 1.4 – Exemplo de comando DML Fonte:

Elaborada pelo autor.

Esses são apenas alguns exemplos de comandos para

compreendermos esta unidade de introdução que trata da natureza
na linguagem SQL quando lidamos com nosso banco de dados. Vale
também destacar a simplicidade dos comandos. Ainda sem
aprofundar, creio que você, enquanto aluno, deve ter conseguido
obter uma noção do que os comandos devem provocar nas
respectivas tabelas.

Definição e manipulação de dados (DDL e DML)

Os comandos da linguagem SQL podem ser classificados quanto ao

seu propósito diante do banco de dados. Perceba que o primeiro
comando de “CREATE TABLE” criou e, portanto, definiu uma parte da
estrutura no banco de dados. Os outros dois comandos permitem
que os dados da tabela possam ser manipulados com inserção e
alteração. Essa distinção entre definir a estrutura do banco de dados
e manipular os dados de suas tabelas é uma classificação comum
dos comandos de SQL em subconjuntos. O primeiro refere-se a um
subconjunto de comandos - chamado de DDL, acrônimo de Data
Definition Language que, em português, significa linguagem de
definição dos dados. Nesse grupo estão comandos justamente para
criar tabelas, alterar seus atributos, excluir elementos, definir as
restrições sobre os dados, como chaves primárias e outras.

Outro subconjunto essencial de comandos é denominado de DML,

do inglês Data Manipulation Language e, em português, linguagem de
manipulação de dados. Seus comandos permitem inserir, alterar,
excluir e consultar dados através de comandos INSERT, UPDATE,
DELETE e SELECT, respectivamente. Algumas bibliografias ainda
apresentam o subconjunto DCL de Data Control Language, em
português, linguagem de controle dos dados, que, em geral, possui
comandos para criação de usuários e configuração de permissões,
os comandos CREATE USER e GRANT, respectivamente.
Arquitetura interna de um SGBD

A linguagem SQL com seus subconjuntos torna fácil a operação com

os bancos de dados, depois de se acostumar com sua sintaxe, é
muito simples disparar os comandos e já avaliar os resultados via
uma ferramenta administrativa. O SGBD, portanto, torna bastante
conveniente lidar com os dados e, além disso, ainda procura fazer
isso com eficiência, pois é necessário manipular milhares e, em
muitos casos, milhões de registros com tempo de resposta aceitável.

Enfim, o SGBD pode ser visto como um assistente eficiente que torna
o trabalho de acesso a dados conveniente por meio de comandos
simples em SQL.

No entanto, como esse “assistente” é organizado e funciona

internamente? Quando ele é acionado através de um comando em
SQL, quais subcomponentes internos são acionados e integrados
entre si para produzir o efeito desejado para o usuário? Para
responder a essas questões, precisamos entender uma arquitetura
típica de um SBGB. Uma arquitetura aponta como um determinado
software, no nosso caso, o SGBD, é quebrado em partes e como
estas se articulam para funcionar conforme seu propósito. A Figura
1.5 a seguir apresenta uma arquitetura típica de um SGBD.
Essa Figura 1.5 – Arquitetura Interna de um Sistema Gerenciador de
Banco de Dados
Fonte: Adaptado de Elmasri e Navathe (2011, p. 5).
Na Figura 1.5, é possível identificar três grandes módulos, o
processador de consultas na interface com os usuários responsável
por compilar as consultas, o gerenciador de transações para
controlar os acessos aos dados nos arquivos e os arquivos, que
podem conter o dicionário de dados e os dados em si das tabelas
organizados nos arquivos de dados e índices.

Para compreender a integração das partes, vale iniciar com a parte

de DDL. Quando um comando CREATE TABLE é acionado, existe um
módulo interno que visa interpretar, isto é, identificar o que o
usuário quer fazer, qual o nome da tabela que será criada, quais
atributos e quais os seus tipos e assim por diante. Após a
interpretação, a tabela é criada com o seu registro no que chamamos
de dicionário de dados, que funciona como um catálogo indicando
quais tabelas são armazenadas no servidor, além de outras
informações. O termo metadados é muito comum de ser atribuído a
essas informações do dicionário ou do catálogo de dados e o prefixo
“meta” indica que são dados que falam a respeito ou especificam os
dados.

Se as tabelas foram criadas e estão catalogadas no dicionário de

dados, elas podem ser então manipuladas pelos usuários. Dessa
forma, quando uma consulta DML é enviada para o SGBD, ela deve
ser compilada. A compilação é o processo que converte o que a
consulta realmente quer: se for um “SELECT * FROM CLIENTES”, o
usuário deseja selecionar e recuperar todos os dados do cliente. O
compilador precisa converter esse comando legível para os usuários
em instruções internas que permitam a consulta ser processada
internamente pelo processador ao acionar os discos nos quais a
tabela está armazenada, bem como outras instruções internas
necessárias. Com esse conjunto de instruções compilado, o módulo
de “controle de execução” gerenciará a execução da consulta, que
aciona o “gerenciador de arquivos”, o qual, para recuperar os dados,
acessa os arquivos e os índices que compõem a tabela. Com os
dados recuperados, estes são organizados e disponibilizados para o
usuário.

Durante a execução da consulta, um sistema de “controle de

concorrência” é acionado e seu papel é manter a consistência dos
dados em acessos concorrentes. Acessos concorrentes ocorrem
quando dois ou mais usuários disparam comandos para uma
mesma parte do banco de dados, isto é, dois usuários solicitam para
alterar os dados de um mesmo registro. Nesse caso, qual deles a
alteração primeiro, quem precisará esperar a efetivação do outro
para então prosseguir com as alterações? Esse tipo de controle é
feito por esse módulo de concorrência.

Esses são alguns dos módulos principais que regem o

funcionamento interno do SGBD, outros podem ser melhor
aprofundados em uma referência detalhada disponível ao final
desta unidade. Com os módulos explicados, já se consegue ter uma
visão interna de como o SGBD, acionando seus diversos
componentes, consegue fornecer serviços de tratamento de dados
aos usuários do servidor.

Conclusão

Esta unidade permitiu ter uma visão geral sobre banco de dados. A linha de raciocínio no início
foi focar na necessidade atual de lidar com dados e informações em uma época denominada
como a era do conhecimento.
Percebemos que os sistemas de bancos de dados são partes relevantes em sistemas de
informação e daí partimos para compreender algumas definições como: SGBD, banco de dados,
entidades, tabelas, atributos e outras. O processo de construção também foi abordado. A
modelagem pelo projetista, depois a implantação pelo DBA e, por fim, o uso por
programadores e usuários finais, que são os marcos desse processo.
Uma breve apresentação da linguagem SQL para uma noção, nesse momento, de como os
dados são manuseados foi apresentada. Além disso simplificadamente vimos como um servidor
funciona internamente. Finalmente, concluímos esta unidade e espero que tenhamos
construído uma boa visão geral sobre bancos de dados!

Projeto

Os usuários e seu trato com dados nas empresas

Conforme Laudon e Laudon (2010), com o advento da Tecnologia de

Informação, os negócios não são mais os mesmos. Ele levanta algumas
questões como “O que torna os sistemas de informação tão essenciais
hoje? Por que empresas investem tanto em tecnologias e sistemas?”.
Ele aponta alguns objetivos mais gerais como a intenção das empresas
em atingir seis importantes objetivos organizacionais: excelência
operacional; novos produtos, serviços e modelos de negócio;
relacionamento mais estreito com clientes e fornecedores; melhor
tomada de decisões; vantagem competitiva e sobrevivência.
Uma determinada empresa, para atingir estes objetivos, avalia e
reformula seus processos de negócios e um insumo importante para
os processos é o dado ou informação. Estes dados e informações
podem servir, por exemplo, para a execução das tarefas em si e, assim,
agilizar e melhor operacionalizar os fluxos de trabalhos. Além disso,
com as informações devidamente capturadas, armazenadas,
processadas e analisadas os níveis gerenciais e táticos acabam tendo
melhores condições de fazer uma gestão das áreas e do negócio como
um todo. Os vários elementos que compõem o sistema de informação:
as pessoas, os processos, as tecnologias ficam todos orquestrados de
maneira mais eficaz e eficiente.

Uma tecnologia importante na arquitetura de um banco de dados é o

SGBD, que é o grande responsável por abrigar os dados do negócio de
forma conveniente, eficiente e segura. Através de diversos tipos de
softwares e equipamentos de clientes, por exemplo, programas em
computadores, aplicativos em celulares, browser da web, os usuários
acessam e manipulam as informações na execução de seus processos.

Para exemplificar, imagine um negócio de Pizzaria que resolveu

ampliar a sua empresa com a venda de pizzas pela internet.
Acompanhe a descrição a seguir:

“Para o site iniciar a operação para a pizzaria on-line, um funcionário

da pizzaria, responsável pelo cardápio, cadastrou todas as pizzas,
outros pratos, bebidas e sobremesas que estariam disponíveis para o
usuário. Com o cardápio cadastrado, um cliente interessado pode
agora acessar o site, realizar o cadastro e registrar os itens do cardápio
em seu pedido e daí efetivar o seu pedido. Uma vez solicitado, a
cozinha já é sinalizada automaticamente assim que o pedido ocorre,
ela, então, produz a pizza que segue para a entrega. Um responsável
pela entrega, algum motorista equipado com moto ou similar,
providencia a entrega e coleta o dinheiro para o pagamento, caso este
não tenha sido feito ainda por cartão de crédito. Ao retornar, o caixa
finaliza o pedido. Diante de todas as informações do processo, o
gerente consegue obter relatórios e realizar pesquisas para que tudo
corra bem na pizzaria. Além disso, o pessoal do marketing pediu a lista
de clientes e preferências para, através de um algoritmo de
aprendizagem de máquina, mapear os padrões de consumo dos
clientes da pizzaria e daí propor campanhas de marketing.”

Enfim, este cenário ilustra um pouco como um negócio de uma

pizzaria online pode operar com seus processos apoiados e
dinamizados com o uso de tecnologia de informação e com os dados
auxiliando no fluxo de trabalho e gestão do negócio.

Vamos Praticar

Bom, você conseguiu compreender o contexto e a importância da TI

nos negócios? Então vamos refinar esta compreensão e daí um
convite. Faça uma releitura do cenário exposto e identifique quais as
pessoas envolvidas no processo e qual papel ou responsabilidade
possuem no processo, por exemplo, vimos que há o cozinheiro e que
ele faz as pizzas? Quais os outros? Com os responsáveis
identificados, avalie qual a necessidade de informação de cada um,
por exemplo, o cozinheiro usado como exemplo precisa saber quais
pizzas estão na fila para produção e para cada pedido, quais itens da
receita. Por fim, ainda para cada responsável enumere quais os itens
de tecnologia (computadores, smartphones, sistemas e outros) cada
usuário usa diante do sistema e onde deve estar o SGBD com a
armazenagem destes dados?

Esperamos, assim, que você perceba como um negócio usou a TI em

seus processos. Caso queira ir além, imagine agora um outro
cenário, uma startup de mobilidade ou uma locadora de
automóveis. Que tal descrever o processo e responder às mesmas
questões? Fique a vontade!

Ao final disponibilize seu trabalho no fórum da seção

 BANCO DE DADOS
U2 - MODELAGEM DE DADOS

Introdução

Bom, vamos começar mais uma trajetória, e se você é daqueles que gostam de analisar
cenários, avaliar e representar soluções com esquemas, esta unidade, que trata de Modelagem
de Dados, é do que precisa.
No início, daremos uma visão geral mais abrangente acerca de modelagem, e faremos uma
introdução sobre o assunto.
Depois, abordaremos a modelagem em si, com entidades e relacionamentos, cuja ênfase será
mais próxima do mundo real, com um cenário a resolver. No Modelo Relacional, o foco é
materializar a representação do mundo real em um banco de dados relacional, comumente
encontrado em nosso dia a dia.
No final, um assunto mais técnico de normalização dos dados será discutido para melhorar a
qualidade no trato das informações.
É isso, relaxe a mente, porque é hora de observar o mundo, modelar seus elementos, e
transformar nossa análise em um banco de dados!

Introdução à modelagem de dados

A implementação de um banco de dados começa com a sua

modelagem pelo analista ou projetista de dados, ou,
simplesmente, analista. Nesta etapa, com base nos requisitos do
sistema a serem tratados, o analista identifica o modo de
estruturar entidades, atributos ou campos, e relações, e assim
especificar o banco de dados que será implantado para prover as
informações aos sistemas e seus usuários.

Uma pergunta que podemos nos fazer é: por que modelar os dados?
Para compreender as vantagens de se criar um bom modelo de
dados, podemos nos inspirar em outras áreas, por exemplo, na
engenharia civil ou na engenharia elétrica/eletrônica. Um
engenheiro civil, diante do objetivo de construir um prédio, antes,
precisa criar as denominadas plantas, por exemplo, a planta baixa,
que apresenta a posição de paredes, portas e etc., e que serve de
suporte para as outras plantas, como a elétrica e a hidráulica. Na
engenharia elétrica ou eletrônica, antes de os dispositivos
eletrônicos serem construídos, precisam ser diagramados. As
Figuras 2.1 e 2.2 ilustram alguns desses “modelos”: uma planta baixa
e um circuito eletrônico:

Figura 2.1 – Exemplos de modelos de outras áreas

Equivalente aos diagramas anteriores para suporte às suas

respectivas áreas, no caso da modelagem de dados, o nosso
“protagonista” é um modelo relacional. Um exemplar é
representado na Figura 2.2. O foco, nesta unidade, será sabermos
como construir um desses diagramas, com as suas várias decisões
de projeto.
 Figura 2.2 – Modelo Relacional de um Sistema de Compras

O ato de modelar, nas diversas áreas, permite uma visão preliminar

do que será construído e apresenta algumas vantagens no processo
de sua construção. Para software, em específico, Booch (2012)
apresenta uma visão bem interessante e abrangente. As vantagens
de uma boa modelagem com os seus diagramas, em em suas
diversas áreas e contextos, englobam:

Melhor compreensão do que está sendo concebido

observe que o diagrama desenhado, no ato de modelar, é uma

representação, isto é, expressa o produto final a ser construído. Portanto,
durante a sua elaboração, o projetista enfrentará algumas dúvidas, precisará
entender melhor situações e tomará decisões para expressar no diagrama.
Essas atividades aprofundam a compreensão do projetista quanto ao mundo
real que está sendo retratado.

Comunicação entre partes interessadas

pare e pense um pouco, olhando para um dos esquemas da Figura 2.1: o que
é mais fácil de compreender? Aquela Figura 2.1 em si ou um texto que
descreveria o projeto desta maneira: a sala é composta por 8 mesas
redondas à direita, 4 escrivaninhas à esquerda e um balcão de atendimento
próximo à porta de entrada”? É fácil percebermos que o diagrama
apresentará melhor essas informações, e ainda com uma série de outros
dados, como medidas da mesa, distância da janela, largura da porta etc. No
nosso caso, de trato com dados, o diagrama já expressa suas tabelas, os
campos e relacionamentos mais facilmente do que se tratados em texto.

Especificação para construção

complementando a comunicação, o diagrama da modelagem acaba

ajudando a quem depois vai precisar de construir o artefato em questão. Um
mestre de obras saberá a largura da janela e a posição na parede, sem a
necessidade de o engenheiro estar todo o tempo disponível para esclarecer
as dúvidas. Para o nosso caso de dados, o analista não precisa, a todo o
momento, dizer quais os campos e tipos de dados da tabela. O
desenvolvedor pode consultar o diagrama ou modelo para entender de que
modo os dados estão estruturados.

Automatização do processo

um diagrama bem especificado pode servir para gerar, automaticamente, via

ferramentas, outros produtos para a construção do sistema. Por exemplo,
diante de um modelo relacional, uma ferramenta já pode gerar todos os
comandos de SQL para a criação das tabelas e, ainda, outras ferramentas
podem ajudar a gerar outros códigos para a programação do software.

Reflita
Existe um dito popular que diz que “uma figura vale mais do que
1000 palavras!”. Pare e pense em ocasiões, sejam do cotidiano ou
em áreas como Engenharia e Tecnologia de Informação, enumere
situações em que um esquema torna muito mais simples e intuitiva
a comunicação.
Cenário de Exemplo

Uma forma de desenvolvermos nossa habilidade de modelar é por

meio de um exemplo da exploração de um cenário prático. Imagine,
portanto, que nós fazemos parte de uma empresa de
desenvolvimento de software, e uma loja gostaria de abrir a sua
versão virtual para venda on-line na Internet. Em uma conversa com
o cliente, surgiu a seguinte descrição do sistema:

“Quando um cliente deseja um produto, ele acessa o site da loja, na

internet. Na primeira tela, pode consultar produtos e analisar
características como Descrição e Preço. Conforme interesse,
adiciona os produtos em seu ‘carrinho de compras’. Ao final do
processo de escolha dos produtos, o usuário pode, então, efetivar a
compra. Acessa uma seção para conferir o carrinho, depois faz o
login no sistema para se autenticar, e daí efetiva o pagamento da
compra”.

Diante desse cenário, quais são os produtos finais da modelagem?

Uma primeira visão está na versão de Modelo de
EntidadeRelacionamento, da Figura 2.3, e o Modelo Relacional do
sistema é o diagrama que já foi apresentado na Figura 2.2. Algumas
concepções estão abstraídas, e a ideia, neste momento, é termos
uma visão dos produtos que construiremos no decorrer do
aprendizado.
Figura 2.3 – Modelo de Entidade e Relacionamento do Sistema de
Compras

Modelo Conceitual, Modelo Lógico e Modelo Físico

Nas fases para a implementação de um banco de dados, o nível de

abstração ou detalhe varia desde uma visão mais próxima do
mundo real e da sua representação conceitual até a forma como os
dados serão concretizados no armazenamento em disco no SGBD.
Esse caminho, com variação na profundidade, origina a distinção
entre Modelos Conceitual, Lógico e Físico, um conteúdo muito
comum sobre o tema banco de dados.

Conforme Amadeu (2019), o modelo conceitual de dados representa

as informações que existem no contexto do negócio, com maior foco
nos processos. Esse modelo utiliza termos e linguagem próprios do
negócio mais adequados ao dia a dia do segmento envolvido no
projeto. Perceba que, dessa forma, o modelo conceitual é o mais
próximo do mundo real, não há ainda preocupações sobre como os
dados serão representados por tipos de dados, como inteiro ou
varchar. Para exemplificar, em um consultório poderia ser mapeada
a existência de alguns médicos disponíveis, compostos de
informações como nome e CRM. Esses médicos possuem uma
agenda com os dias da semana e horários em que atende e os
clientes podem realizar as consultas. Não é necessário, nesse nível
de abstração, perceber que nome não pode ter mais do que 50
caracteres. Concentra-se em um nível mais alto de representação
dos dados.

No nível lógico, começa a preocupação com a tecnologia com que o

modelo conceitual vai “ganhar vida” para a solução. Por exemplo, o
tipo de banco de dados deve ser identificado. É muito comum
usarmos os bancos de dados relacionais comerciais. Mas existem
alguns outros, como os bancos de dados hierárquicos, em rede e
ainda os mais recentes, como os bancos orientados a objetos ou os
bancos NOSQL (not only SQL). Além do tipo de banco, questões como
quais os nomes das entidades e dos campos, agora em uma
linguagem mais próxima da programação e menos do mundo real.

Descendo ainda mais o nível de abstração, o projetista precisa

definir questões do armazenamento físico dos dados, de como os
dados serão implementados em uma solução computacional. De
acordo com o tipo de banco de dados, as especificidades, como
nomes de tabelas, campos, quais tipos de dados de cada campo e,
ainda, restrições de integridade serão codificadas.

A Figura 2.4 permite compreender essa transição entre os modelos

com seus respectivos níveis de detalhes. Perceba que o modelo
conceitual está mais próximo dos processos de negócio. Na parte
lógica e física, os modelos interagem com a aplicação e o modelo
externo (parte baixa à direita). Por exemplo, nesse ponto estão os
softwares clientes, que acessam os dados.
 Figura 2.4 – Contextualização dos Modelos Conceitual, Lógico e
Físico

Modelagem de entidade e relacionamento

Em cada um dos níveis de abstração explorados no tópico anterior,

um determinado modelo pode ser aplicado, e dois deles são muito
comuns: o Modelo de Entidade e Relacionamento, que é muito
usado para os níveis de modelo conceitual, e o Modelo Relacional,
popularmente empregado para o nível lógico e físico.

Conforme Puga (2013), o Modelo de Entidade-Relacionamento (MER)

foi proposto por Peter Chen, nos anos 1970, e visa apresentar uma
perspectiva do mundo real como constituído de um conjunto de
objetos, entidades que se relacionam entre si. Ainda em Puga (2013),
uma entidade representa uma categoria de elementos relevantes
para um negócio, podendo ser, por exemplo, os clientes,
fornecedores, vendas, contratos, pagamentos, registro de
funcionários, entre outros. Sobre esses objetos são realizadas as
regras do negócio, como “Cadastrar um cliente” ou “Efetivar uma
venda”. Essas entidades, portanto, representam um conjunto de
dados que precisam ser armazenados e que são manipulados pelas
aplicações que informatizam o negócio.

Uma entidade é formada por atributos que apresentam alguma

característica ou informação da entidade. Por exemplo, um cliente
pode ser formado pelos atributos como nome, endereço, telefone,
data de nascimento e outros. Uma transação financeira em um
banco pode ter os atributos de data e hora da ocorrência, o valor e
o tipo de transação, de crédito ou débito na conta. Um
relacionamento indica uma relação que existe entre as entidades,
por exemplo, um cliente realiza uma compra no site ou uma
transação financeira é realizada em uma determinada conta
corrente. Assim, no primeiro caso, existe um relacionamento entre
as entidades cliente e compra e, no segundo caso, transação e conta
corrente estão relacionados.

Diagrama de Entidade e Relacionamento

Modelagem e diagrama são dois conceitos intimamente

relacionados: a modelagem é o ato de refletir sobre como
representar, e o diagrama é o esquema ou desenho que especifica
o que está sendo modelado. Muitas vezes, o termo modelo e
diagrama são usados indistintamente. Os conceitos de entidades,
atributos e relacionamentos são o “coração” do diagrama de
entidade e relacionamento (DER), e a Figura 2.5 ilustra uma parte de
um diagrama para visualização desses conceitos:
 Figura 2.5 – Exemplo de parte de um diagrama de entidade e
relacionamento

Note que, em texto, o que estamos dizendo é: “um cliente realiza

uma compra e é formado pelos atributos CPF, Nome e Endereço, e
a entidade compra é composta de Número, Data, Status e Valor”.
Quando estamos modelando, o que fazemos é o oposto: em geral,
temos uma compreensão do mundo real muitas vezes em texto e
daí traduzimos para o formato de diagrama. Verificamos também
que entidade é desenhada como um retângulo; o relacionamento,
como um losango e os atributos, como círculos, todos eles ligados
por linhas. Essa maneira de desenhar os componentes de um
diagrama é denominada notação, uma “linguagem” para expressar
o que estamos representando, e é útil, pois como todo diagrama
DER, ou mesmo um diagrama de outra natureza é desenhado da
mesma forma. Qualquer projetista de dados conhecerá a
“linguagem” usada e, portanto, o que está sendo representado.

Um primeiro exemplo
A melhor forma para aprender a modelar e a diagramar algo é
praticando. Depois de passados alguns conceitos, vamos refinar o
cenário de exemplo descrito nesta unidade para ser mais específico
com o trato de informações, e assim nos auxiliar nesta modelagem.
O texto é o seguinte:

“Para o site da Loja Virtual funcionar, é necessário que os produtos

sejam cadastrados com suas informações de Código de Barras,
Descrição e Valor. Quando um Cliente acessa o site, ele se cadastra
com seus dados de CPF, Nome, Endereço e Telefone. O Endereço, na
verdade, é um conjunto de campos ou atributos, dentre eles, Rua e
Número, Complemento, Bairro, Cidade, UF e CEP. Uma vez
cadastrado, o cliente pode realizar as suas compras, que, enquanto
transação, precisam do registro de seu Número, Data, Valor e Status.
O Status indica se a compra já foi entregue, se está em andamento
etc. E, para finalizar nossa compreensão, as Compras contêm os
produtos que o Cliente escolheu para comprar”.

Para construir uma primeira versão do diagrama DER com base no

texto, basicamente, três ações serão necessárias: identificar as
entidades, mapear os seus atributos e estabelecer os
relacionamentos entre as entidades. Nessa diagramação,
ferramentas são empregadas e, no nosso caso, está sendo usado o
BrModelo, uma ferramenta muito simples e usada, sobretudo, para
o contexto didático de modelagem ER.

Saiba mais
Para a modelagem de entidade e relacionamento, existe uma
ferramenta bastante usada, que é o BrModelo. O link,
disponibilizado a seguir, fala sobre esse projeto, como ele surgiu e
como a ferramenta pode ser utilizada.
A visão de como representar o cenário pode ter algumas variações
de projetista para a projetista. Uma primeira versão para expressar
o cenário descrito no texto está na Figura 2.6. Perceba que as
entidades identificadas foram Produtos, Clientes e Compras, e
dentre os atributos de Produtos, foram diagramados Código,
Descrição e Valor, e existem dois relacionamentos entre
ClientesCompras e entre Compras-Produtos. Outras especificações
podem ser vistas no próprio diagrama. Para efeito didático, algumas
questões do mundo real foram abstraídas, por exemplo, um
produto pode ter outras informações, como fotos, um Cliente pode
ter muitos outros dados associados, e assim por diante.

Figura 2.6 – Versão inicial de um DER para o cenário de exemplo

(Loja Virtual) :

Reflita
Pense em três cenários de sistemas comuns em nosso dia a dia: uma
papelaria, uma padaria ou uma agenda no celular. Identifique as
entidades nesses sistemas, como se relacionam, e, caso seja
possível, esquematize de que modo você desenharia um modelo de
entidade e relacionamento.
Outras Características: Atributos e Cardinalidade

Perceba que, no diagrama, existem alguns atributos que estão

marcados ou pintados. São os atributos identificadores, isto é,
podem identificar, exclusivamente, a entidade. Dessa forma, o CPF é
um atributo identificador de Cliente, pois não existem dois clientes
que possuem o mesmo CPF, ou seja, um número de CPF é único,
identifica unicamente o Cliente. O mesmo ocorre para Produtos, que
são identificados pelo atributo Código de Barras, e a entidade
Compras, que é identificada pelo atributo Número. Esses atributos
serão, depois, tratados como chaves primárias no banco de dados.

Ainda, é possível visualizar, no modelo, alguns números (0,1), (0,n)

ou (1,n) junto aos relacionamentos nas entidades, representando a
cardinalidade. A cardinalidade indica quantos objetos de uma
entidade podem se relacionar com objetos de outra entidade. No
nosso exemplo, um Cliente pode se relacionar com (0,n) Compras, o

que indica que um Cliente pode fazer nenhuma compra ou até n

compras. Por outro lado, uma Compra tem uma relação (1,1) com
Cliente, isto é, ela precisa estar associada a um Cliente, e somente a
um Cliente. Não é possível, por exemplo, ter uma compra sem um
cliente associado.

Do mesmo modo, uma compra pode conter N produtos e deve ter,

pelo menos, um produto (relação (1,n) ), e um produto pode estar
registrado em N compras, mas pode também não ser associado a
uma compra, por exemplo, um tipo de produto novo que não foi
vendido ainda. Dessa forma, com os vários tipos de cardinalidade
são estabelecidas as regras sobre a quantidade de itens envolvidos
nos relacionamentos.

Além das citadas, existem situações em que relações 1:1 (1 para 1)

que não foram representadas em nosso exemplo. Nesse caso, um
objeto se relaciona com apenas um, de outra entidade. Por exemplo,
em um sistema, imagine que um Funcionário só pode ocupar um
computador em uma estação de trabalho; assim, existe uma relação
1:1 entre eles. Ou ainda, imagine que, em uma empresa, um só
funcionário pode chefiar um departamento, que só é chefiado por
um funcionário.

O quadro a seguir, resume alguns dos tipos de relacionamentos,

conforme a cardinalidade. Os valores de 0 no lugar de 1 indicariam
que um objeto pode não se relacionar com o outro objeto da outra
entidade:

Quadro 2.1 – Exemplos de relacionamentos em um MER

Outras Situações Importantes

Além das situações e elementos citados até agora, mais comuns em

modelos ER, existem outras situações importantes, que podem, por
vezes, ocorrer: autorrelacionamento, generalização e o conceito de
entidades fortes e fracas.

No autorrelacionamento, há um relacionamento de uma entidade

para ela mesma. Por exemplo, em um sistema, uma Pessoa pode ser
cônjuge de outro elemento que é também da entidade Pessoa, ou
um Funcionário pode ter como supervisor um outro elemento, que
também é Funcionário. A Figura 2.7 representa um desses
autorrelacionamentos:

Figura 2.7 – Exemplo de autorrelacionamento

A generalização ocorre quando uma entidade engloba

características de outras entidades subjacentes. A entidade mais
“alta” generaliza os conceitos subjacentes. Um exemplo típico de
uma entidade Pessoa, em um sistema, pode ser uma Pessoa Física
ou uma Pessoa Jurídica, ou uma determinada entidade Usuário, que
pode ser um Funcionário, um Professor ou um Estudante, em uma
biblioteca da universidade. No caso, o conceito Pessoa é mais geral,
generaliza os conceitos de Pessoa Física e Pessoa Jurídica. Da mesma
forma todo Funcionário, Professor e Estudante são um Usuário da
biblioteca da universidade. Portanto, Usuário generaliza os outros
elementos. Um exemplo de generalização pode ser visto na Figura
2.8:
 Figura 2.8 – Exemplo de relacionamento de generalização

Uma entidade fraca é uma entidade cuja existência depende da

existência de outra entidade, no caso, uma entidade forte. Para
exemplificar, imagine que um sistema de Recursos Humanos precisa
ter uma entidade de Dependentes. A existência de um dependente
só faz sentido se estiver vinculada a um elemento da entidade
Funcionário. Em geral, a identificação da entidade fraca depende de
um atributo identificador da entidade forte. Em dependente, para
ser identificado, ele poderia ter um número, juntamente com a
identificação do funcionário, isto é, a tupla Identificação do
Funcionário e número do dependente identifica o Dependente. A
Figura 2.9 ilustra outro exemplo de relacionamento entre uma
entidade fraca e uma entidade forte. Uma Agência só faz sentido de
existir relacionada a um Banco, e sua identificação será pelo número
da agência em conjunto com a identificação do banco.

Figura 2.9 – Exemplo de relacionamento entre entidade forte e

entidade fraca

Modelagem relacional
Vamos relembrar aqui o que foi abordado: no modelo de entidade e
relacionamento, o foco é “estar mais próximo” do mundo real,
representando-o em uma perspectiva conceitual com
independência quanto à tecnologia que seria empregada. Por
exemplo, o mesmo modelo vale para implementar nos diversos
tipos de bancos de dados (hierárquico, rede e outros). Para tratar a
forma como as informações serão implementadas, efetivamente,
em um banco de dados, com tipos de dados, codificações, arquivos
e outras questões mais tecnológicas de implementação (e menos
conceituais), é necessário utilizar uma modelagem do nível Lógico e
Físico, e para bancos de dados relacionais utiliza-se o Modelo
Relacional.

Consoante Elmasri (2011), existe uma boa e histórica introdução ao

modelo relacional, que diz:

O modelo de dados relacional foi introduzido inicialmente

por Ted Codd, da IBM Research, em 1970, em um artigo
clássico (Codd, 1970), que atraiu atenção imediata devido à
simplificidade e base matemática. O modelo usa o conceito
de relação matemática – que se parece com uma tabela de
valores – como seu bloco de montagem básico, e sua base
teórica reside em uma teoria de conjuntos e lógica de
predicado de primeira ordem. (ELMASRI, 2011, p.
38).

Saiba mais
Além dos bancos de dados relacionais, existem outros, tais como os
históricos em rede e os hierárquicos. Existem os Bancos Orientados
a Objetos e, ultimamente, muito tem se falado sobre os bancos
NoSQL. Para saber mais, acesse o link.
Em termos práticos, neste momento, é feita uma conversão da
modelagem ER em uma modelagem relacional. Na verdade, será
muito comum encontrar equipes de desenvolvimento, que inicia o
trabalho com banco de dados com base no modelo relacional, já que
existe forte equivalência entre eles. E o que vai mesmo determinar
como as aplicações vão trabalhar com dados são as tabelas (ou
relações) no banco de dados. Para nós, que tivemos a compreensão
do MER antes, aprenderemos o Modelo Relacional justamente
fazendo uma equivalência do que foi representado no MER e sua
conversão para esse novo modelo. E, além disso, como nesse nível
lógico e físico, novos detalhes tecnológicos são tratados.
Aprenderemos também o que é necessário acrescentar no modelo.

Relações ou Tabelas

Conforme Elmasri (2001), o bloco básico de montagem do modelo

relacional e, por conseguinte, do banco de dados relacional, é o
conceito de relação. Os termos relação e tabela são equivalentes: em
geral, relação é usado com mais frequência no campo teórico, e
tabela será o jargão adotado no dia a dia.

Mas, por ora, entenderemos as definições de relação, tuplas,

atributos e outros, e, para isso, a Figura 2.10 pode ser bem útil. Uma
relação é um conjunto de tuplas (ou linhas de uma tabela), que, por
sua vez, é um conjunto de valores com o respectivo valor referente
a um atributo. Esses valores pertencem a um domínio, ou são de um
tipo de dados (inteiro, conjunto de caracteres, real e outros), e
podem, ainda, ter um valor NULL, que indica sem valor.
 Figura 2.10 – Exemplo de relação

Com essa compreensão, percebe-se que uma primeira equivalência,

e conversão a ser feita, é o conceito de relação com base em uma
entidade do modelo MER. As entidades acabarão se constituindo em
relações ou tabelas, no modelo relacional.

Um Pouco de Prática e como Aprender

Na prática, veremos que nosso modelo será o apresentado a seguir

(Figura 2.11). Note que é fácil ver algumas entidades convertidas
aqui, nas relações, e também a ocorrência de outros elementos.
Para criar modelos relacionais, existem diversas ferramentas, e duas
foram base para criação dos modelos aqui: o DBDesigner e o MySQL
Workbench.
 Figura 2.11 – Modelo Relacional do Cenário de Exemplo

Saiba mais
Conheça algumas ferramentas que podem ser usadas para fazer
modelagem relacional, na prática. Duas que eventualmente serão
usadas no texto são o DBDesigner 4 e o MySQL Workbench.

Recomendamos este último, pois é bastante popular na comunidade

de MySQL. Mas vale perceber que o mais relevante é o modelo em
si, como os dados foram representados. Para saber mais, acesse os
links disponíveis a seguir.

- Artigo sobre ferramentas de modelagem:

<https://becode.com.br/diagramas-er-ferramentas/>. Acesso em:

26 abr. 2019.

- Sobre o MySQL Workbench:

Atributos, Tipos, Obrigatoriedade e Chaves Primárias

Cada um dos atributos equivalentes aos atributos no MER – precisa

ser associado a um tipo de dados, que, na teoria, é associado ao
conceito de domínio, pois indica qual domínio de valores o atributo
pode assumir, domínio dos números inteiros, dos números reais ou
outros. O Quadro a seguir mostra alguns dos tipos de dados mais
usados.

Tipo de Dados Descrição Exemplos

INTEGER Números inteiros 23, 341, 899

CHAR (N) “Palavras” ou sequências de caracteres “Joana”, “Marcos”

que são armazenados com um tamanho
fixo de N caracteres

VARCHAR(N) Nesse caso, o banco de dados pode Idem anterior, a

otimizar, variando o armazenamento mudança é no
conforme necessidade até o máximo de N armazenamento
caracteres interno

NUMERIC(P,D) Muito usado para números reais. A 347,20 480,21

Precisão P indica quando dígitos podem ter
o número e a quantidade de decimais;
D indica quantas casas decimais. Por
exemplo, NUMERIC(5,2) seria um número
como 432,21

DATE Para campos do tipo data 22/03/2019

 BLOB Usado para dados binários, por exemplo, -
caso seja necessário armazenar um arquivo
de imagem ou de vídeo no banco
de dados

Quadro 2.2 – Tipos de Dados

Algumas restrições podem ser associadas a um atributo, por

exemplo, a obrigatoriedade. Um atributo obrigatório é aquele que
precisa, necessariamente, ter um valor, que não pode ser NULL. Por
exemplo, se um novo aluno está sendo cadastrado, não faz sentido
ele não ter o seu nome preenchido.

Alguns atributos podem identificar uma tupla, linha da tabela ou

entidade. Esses são aqueles atributos identificadores discutidos na
modelagem de entidade e relacionamento. Aqui no modelo
relacional, esses atributos são tratados como chaves. O atributo que
identifica a tupla é considerada chave primária, e outros eventuais
atributos, que também identificam a tupla, podem ser considerados
chaves candidatas. Uma chave pode ser composta, isto é, pode
conter mais de um atributo. Assim, em uma entidade ALUNO, a sua
matrícula pode ser considerada a chave primária, o CPF, uma chave
candidata, e os campos CI e UF (carteira de identidade e estado),
também chave candidata, porém chave composta.

A Figura 2.12 a seguir mostra como nossa entidade PRODUTO, do

modelo de entidade e relacionamento de nosso modelo de loja, foi
convertido para sua tabela equivalente no modelo relacional, com
seus atributos, tipos de dados e sinalização da chave primária:
Figura 2.12 – Exemplo de relação ou tabela no Modelo Relacional

O quadro a seguir ilustra com mais detalhes as definições dos

atributos da tabela:

Atributo Descrição Tipo Obrigatório Chave

COD_PRODUTO Código do produto INTEGER SIM SIM

DCR_PRODUTO Descrição do produto VARCHAR(50) SIM -

 VLR_PRODUTO Valor do Produto NUMERIC(9,2) NÃO -

Quadro 2.3 – Definição dos campos na tabela Produtos

Relacionamentos e Chaves Estrangeiras

Um conhecimento típico, nessa transição do modelo de entidade e

relacionamento, é o trato com os relacionamentos, pois a forma de
fisicamente representá-los em um modelo relacional é transpondo
a chave primária de uma tabela para a outra tabela, que passa a ser
chamada chave estrangeira, nome dado justamente para referenciar
uma chave em outra tabela.

Um exemplo pode nos ajudar a compreender melhor essa

conversão, e vamos relembrar de nosso cenário. Em nosso modelo,
um CLIENTE realiza COMPRA com cardinalidade, em que um cliente
pode estar associado a diversas compras, e uma compra só pode
estar associada um CLIENTE. Nesse caso, a chave primária de
CLIENTE passa a incorporar a tabela COMPRA, e na tabela de compra
é denominada chave estrangeira por referenciar um elemento da
tabela de CLIENTE. A Figura 2.13 ilustra essa conversão muito
comum em relacionamentos 1:N:
 Quadro 2.13 – Transposição de chave estrangeira em
relacionamento 1:N

Assim como há esse tratamento no relacionamento 1:N, os outros

tipos precisam também de ser tratados. Outra situação muito
comum é a do relacionamento N:N, por exemplo, no nosso exemplo,
a relação que existe entre COMPRA e PRODUTO, pois uma COMPRA
pode conter diversos produtos, e um PRODUTO pode estar em
diversas compras. Nesse caso, surge uma tabela associativa, isto é,
uma nova tabela, que faz a associação com as outras duas. A Figura
2.14 representa melhor essa situação. Na esquerda, o
relacionamento N:N, e na direita, a tabela associativa equivalente,
PRODUTO_COMPRA.
 Figura 2.14 – Conversão de relação N:N em tabela associativa

Os outros relacionamentos também apresentam uma forma de

conversão para sua versão equivalente no modelo relacional. Note
que a forma como as chaves primárias são transpostas para as
tabelas relacionadas é que determina essa forma de conversão. O
Quadro 3.X, a seguir, mostra a conversão que resta, do
relacionamento 1:1 e do relacionamento de generalização:
 Quadro 2.4 – Descrição da forma de determinar as chaves
estrangeiras nos relacionamentos

Normalização

Ao analisar o que vimos anteriormente, sobre modelagem, usando

como base o modelo relacional, inferimos que cada informação
possui a sua tabela, o seu local de ser armazenado, evitando, desse
modo, redundâncias e algumas inconsistências ao manipular os
dados. De maneira informal, essa pode ser a explicação para o que,
em banco de dados, chamamos normalização.

Elmasri trata normalização da seguinte maneira:

A normalização de dados pode ser considerada um processo

de analisar os esquemas de relação dados com base em suas
dependências funcionais e chaves primárias para conseguir as
propriedades desejadas de (1) minimização de redundância e
(2) minimização de anomalias de inserção, exclusão e
atualização. Ele pode ser considerado um processo de
filtragem ou purificação que faz com que o modelo tenha
qualidade cada vez melhor. (ELMASRI, 2011, p. 348).
A dependência funcional referida, ao referir à normalização, diz
respeito à dependência entre dois atributos. Diz-se que um atributo
B depende, funcionalmente, de A quando duas tuplas com mesmo
valor para A, necessariamente, devem apresentar o mesmo valor
para B. Veja o exemplo de relação a seguir. Verifique que
misturamos os valores de clientes com compras, e existem algumas
diferenças em relação ao que fizemos até agora (CPF mudou para o
campo COD). Obviamente, essa “mistura” não é interessante, apenas
será útil para nossa compreensão de normalização.

Voltando ao conceito de dependência funcional, note que, para cada

duas tuplas que possuem o mesmo código, têm, necessariamente,
o mesmo Nome. As tuplas com valor 1 possuem nome “João”; as
tuplas com valor 2, “Maria”, e as tuplas com COD igual a 4, “Joana”.
Portanto, podemos dizer que o atributo Nome depende
funcionalmente de COD.

COD NOME NUM_COMPRA DATA VALOR

1 João 10 07/04/2019 35,60

1 João 11 12/04/2019 35,60

2 Maria 12 25/03/2019 42,20

2 Maria 14 02/04/2019 28,50

4 Joana 19 19/03/2019 56,80

4 Joana 21 10/04/2019 62,90

Tabela 2.1 – Uma tabela “desnormalizada” para exemplificar a

normalização
Na normalização, algumas dessas dependências serão checadas ou
testadas de forma que se encontre uma melhor forma de separar as
informações. Para cada tipo de teste, de acordo com uma situação,
podemos dizer que o conjunto de dados foi normalizado conforme
a primeira, segunda ou terceira forma normal, as mais comuns.

Primeira Forma Normal (1FN)

Na primeira forma normal (1FN), os atributos não podem, para uma

mesma entidade ter valores diferentes ou atributos possuindo mais
de um valor, o que significa que não é permitido ter, na mesma
relação, atributos multivalorados. No nosso exemplo anterior,
observe o campo Telefone. Para uma mesma pessoa existem valores
diferentes, e na segunda linha o campo possui dois valores.
Portanto, Telefone é um atributo multivalorado.

Para tratar essa situação, da primeira forma normal, deve-se

identificar a chave primária e o atributo multivalorado e separá-los
(o atributo multivalorado), em uma outra relação ou tabela, e utilizar
a chave primária da entidade como chave estrangeira na nova
relação. A decomposição da relação ficaria conforme figura, a seguir:

TELEFONE
COD
(FK)

1 996542331

1 997218765
1 998831245

2 322284129

2 344567881

4 987221015

4 987221015

COD NOME NUM_COMPRA DATA VALOR

1 João 10 07/04/2019 35,60

1 João 11 12/04/2019 35,60

2 Maria 12 25/03/2019 42,20

2 Maria 14 02/04/2019 28,50

4 Joana 19 19/03/2019 56,80

 4 Joana 21 10/04/2019 62,90

Tabela 2.2 – Tratamento da primeira forma normal (1FN)

Segunda Forma Normal (2FN)

Na segunda forma normal (2FN), os atributos que não compõem a

chave devem depender unicamente da chave primária da tabela, e,
além disso, os atributos que não são dependentes dessa chave
devem ser realocados em uma nova tabela, utilizando esses dados.

No nosso caso, perceba que o atributo Nome depende unicamente

de COD (no caso Código do Cliente) os atributos de NUM_COMPRA,
DATA e VALOR não possuem essa dependência funcional, pois duas
tuplas com valores diferentes estão associadas ao mesmo valor de
código. Isso ocorre porque misturamos os valores de Compras junto
aos valores de Clientes.

Antes de seguir para a decomposição, vale comentar que as formas

normais devem ser acumulativas. Portanto, para uma relação
obedecer à segunda forma normal, (2FN), deve, previamente, ter
atendido à primeira forma normal (1FN) dos atributos
multivalorados.

No caso da decomposição da segunda forma normal, a tarefa é

identificar a chave primária, os atributos dependentes e os atributos
não dependentes. Desse modo, separam-se os atributos não
dependentes em uma outra relação e faz-se o relacionamento
através da chave estrangeira.
 COD NOME

1 João

2 Maria

4 Joana

NUM_COMPRA DATA VALOR

COD
(FK)

1 10 07/04/2019 35,60

1 11 12/04/2019 35,60

2 12 25/03/2019 42,20

2 14 02/04/2019 28,50

4 19 19/03/2019 56,80
 4 21 10/04/2019 62,90

Tabela 2.3 – Tratamento da segunda forma normal (2FN)

Terceira Forma Normal (3FN)

Para estar na terceira forma normal (3FN), a relação, primeiramente,

deve estar na segunda forma normal. Lembre-se de que as formas
normais são acumulativas, e, para estar em uma forma normal
“maior”, devem-se ter atendido as formas normais “menores”. Para
a 3FN, em específico, é preciso eliminar os campos que podem ser
obtidos a partir de um cálculo, ou de alguma lógica aplicada a outro
campo.

Imagine que, na nossa relação de compras, tivesse um atributo

chamado VLR_IMPOSTO, que diz respeito a um cálculo do imposto,
calculado sobre o valor da compra. Portanto, o valor do imposto não
precisa, necessariamente, ser armazenado. Nesse caso, o atributo,
ou campo, pode ser retirado da relação, e os valores são calculados
via regras de negócio da aplicação, isto é, o programa, quando
manipulasse os dados de valor, faria os cálculos de imposto via
alguma parte do programa.

Normalização, Desnormalização e Performance

A normalização, como vimos, permite que os dados fiquem melhor

estruturados, e isso tem uma motivação: consegue-se melhor
integridade e qualidade da informação. Por exemplo, imagine que a
nossa relação desnormalizada, em que existem várias tuplas com os
mesmos nomes e códigos, concentra na primeira e segunda linha,
que possui o valor de COD igual a 1, e NOME igual a “João”. Suponha
que gostaríamos de alterar o nome do cliente de “João” para “João
Manoel”, e fizéssemos isso apenas na primeira linha. Teríamos,
dessa forma, uma inconsistência ou anomalia nos dados, uma tupla
de cliente com código 1 e nome “João”, e outra também com código
1, porém com nome “João Manoel”. Portanto, a normalização dos
dados permite encontrar um esquema, ou estruturação, que
garante melhor a qualidade das informações armazenadas, que
ficam mais imunes a essas distorções.

Por outro lado, um banco muito normalizado pode causar alguns

impactos de performance. Retomemos o caso da 3FN, do cálculo de
imposto. A todo o momento que a compra for manipulada, um
processamento deve ser feito para realizar o cálculo do imposto. Se
formos ainda mais a fundo em nosso modelo, desde o início
colocamos um campo de Valor da Compra, porém esse valor pode
ser processado a partir da soma dos valores dos itens presentes na
Compra. Mas note que, toda vez que uma compra for recuperada, a
tabela de itens precisa ser processada para se calcular o total da
compra para se ter o total da compra. Isso requer maior
processamento para tratar dos dados.

Dessa forma, em algumas situações o projetista de dados pode

tomar decisões quanto à normalização ou não dos dados, tendo a
devida cautela para especificar bem, no caso de algumas
desnormalizações, as regras de negócios a fim de que os dados
sejam mantidos com boa consistência.

Saiba mais
As consistências das informações em um banco de dados dependem
das regras estabelecidas no próprio banco de dados e das regras de
negócios que são implementadas de outra forma, via alguma lógica
ou procedimentos no próprio banco de dados ou, ainda, outras
camadas na arquitetura do software. O link disponibilizado a seguir
permite entender mais as regras de negócios e decisões de projetos
sobre esse assunto.

Conclusão

A modelagem de dados é uma atividade de suma relevância na construção de bancos

de dados, sobretudo para “domar a complexidade” de sistemas maiores. Analisar os
cenários numa visão conceitual e construir uma lógica de representação de um banco
de dados será um pilar para outras decisões na engenharia de software.
Por isso, os assuntos estudados agregam bastante valor para a área, e serão essenciais
para o estudante que pretende internalizar o papel de um Projetista de Dados.
Seja em uma modelagem ER, ou na modelagem relacional, habilidades de identificar
elementos, ter visão sistêmica, organizar e esquematizar um diagrama, tomar decisões
de projeto, com domínio no trato com tabelas e elementos de um banco relacional,
são competências que podem ser refinadas, quando aprofundados os assuntos
abordados nesta unidade.

Projeto

MODELAGEM DE DADOS DE UM SISTEMA

O ato de modelar previamente algo que deverá ser construído, em
diversas áreas, permite uma visão preliminar, e agrega diversas
vantagens no processo e na qualidade ao produto final. Na Engenharia
Civil, existem diversos tipos de plantas, e na Engenharia Elétrica, por
exemplo, os esquemáticos são exemplos de modelos e diagramas
frutos de uma modelagem. Na computação, especificamente no trato
com dados, os modelos de entidades-relacionamento (MER) e o
modelo relacional são nossos exemplos.
Dentre as vantagens de uma modelagem, Booch (2012) comenta sobre a
possibilidade de melhorar a compreensão do que está sendo concebido,
a melhor comunicação entre as partes, a especificação para a construção
e a automatização de tarefas subsequentes.

Imagine que você foi destacado para ser o projetista de dados do cenário
de uma pizzaria na internet e precisa realizar a modelagem de dados. Uma
breve descrição do cenário seria: “o cardápio da pizzaria possui itens de
cardápio, que são as pizzas, bebidas e sobremesas, e cada item apresenta
um código para identificação, a descrição e o seu valor. Um cliente, ao
acessar o site, realiza seu cadastro com Nome, Endereço, Telefone e
outros, e daí pode fazer seu pedido. Ao pedir, ele adicionará os itens do
cardápio que deseja, indicará a quantidade e, ao final, faz o pagamento
via cartão de crédito. Diante do pedido, a pizzaria prepara a pizza e,
conforme passa pelos estágios de produção, o status do pedido é
modificado para o cliente acompanhar seu pedido”.

Essa é uma descrição simplificada, mas típica, que pode constar em uma
ata de reunião ou documento equivalente, e que permite que um
projetista de dados realize as tarefas de modelagem. São momentos
iniciais no processo de desenvolvimento do software.

Vamos Praticar

Diante da descrição exposta, convido você a instalar uma

ferramenta de modelagem de dados, que pode ser o BrModelo para
o MER e o MySQL para o WorkBench. Uma vez instaladas, realize a
modelagem de entidade e relacionamento do cenário e depois faça
a modelagem relacional equivalente. Ao final, disponibilize seu
trabalho no fórum da seção.
 BANCO DE DADOS
U3 - LINGUAGEM SQL, DEFINIÇÃO E
MANIPULAÇÃO DE DADOS

INTRODUÇÃO

Com um servidor de dados disponível e com a estruturação de tabelas e outros elementos

obtidos na modelagem, um banco de dados pode ser manipulado. Para esta manipulação,
existe uma linguagem própria que chamamos de SQL (Structured Query Language), ou
Linguagem de Consulta Estruturada.
O foco desta unidade são os princípios da SQL. No início, veremos os fundamentos com os
quais ela foi concebida, a Álgebra Relacional. Depois, começaremos com um comando muito
importante, o Select, para recuperação de dados. Na sequência, veremos os comandos para
inserção, alteração e exclusão de dados e, por fim, os comandos para criação de tabelas serão
nosso foco.
Enfim, é hora de “brincar” com os dados, e este assunto tem uma visão bem prática.
Aproveite!

INTRODUÇÃO À SQL E ÁLGEBRA RELACIONAL

Durante a implementação de um banco de dados, de início, a

modelagem é feita e, a partir daí, é necessário criar o banco de dados
em si em um sistema gerenciador de banco de dados (SGBD). A
forma como as tabelas foram estruturadas e os diversos outros
elementos identificados na modelagem, chaves primárias, chaves
estrangeiras, tipos de dados e outros, tudo isso deve ser instalado
para que os usuários possam enfim usar o banco de dados para
abrigar seus registros.

A SQL (Structured Query Language) é uma linguagem própria para o

trato com os dados e pode ser empregada de forma bem variada ao
operar com os componentes em um banco de dados. Ela é dividida
em grupos ou subconjuntos de comandos, entre os quais dois deles
serão focados neste nosso estudo, a DDL e a DML. A DDL, que no
português seria linguagem para definição de dados (no inglês, Data
Definition Language), contém comandos para operações como
criação, alteração e exclusão de tabelas, alterações em campos,
manipulação em índices, chaves e outros. Enfim serve para indicar
como os dados estão estruturados no banco de dados. A DML,
linguagem de manipulação de dados (do inglês, Data Manipulation
Language), contém os comandos para operar com os registros das
tabelas, por exemplo, para recuperar, inserir, alterar ou excluir
dados em uma tabela de clientes no banco de uma loja virtual. Para
concretizarmos melhor, o Quadro 3.1 apresenta alguns exemplos
de comandos de DML, o primeiro para inserção de um registro na
tabela de CLIENTES e o segundo recuperar NOME e CONTATO da
tabela de CLIENTES.

Exemplos de comando de DML

- Comando para inserção de um novo registro em uma tabela:

INSERT INTO CLIENTES (CODIGO, NOME, CONTATO)
VALUES (10, ‘José Silva’, ’71
977123412’)

- Comando para consulta ou recuperação de registros em uma tabela:

SELECT NOME, CONTATO
FROM CLIENTES

Quadro 3.1 – Exemplos de comando DML

Operações sobre uma Tabela

Para termos uma compreensão mais interessante do que os
comandos de SQL fazem, vamos pensar um pouco antes. Imagine
que você está diante da necessidade de organizar os registros de
clientes e para isso você usa uma tabela, um elemento chave em um
banco de dados. Esta tabela teria um formato análogo ao mostrado
na Figura 3.1 a seguir. Quais operações você imagina que poderia
fazer sobre estes dados? Um determinado usuário poderia
recuperar os clientes com idade inferior a 40, daí apenas as linhas
em amarelo seriam recuperadas. Caso outro usuário queira focar
apenas em nome e cidade dos clientes, apenas as colunas em verde
seriam recuperadas. Enfim, em uma visão bem simplificada, as
operações sobre os dados terão de dar conta de como tratar as
colunas e as linhas de uma tabela, considerando-se que uma tabela
é um dos elementos centrais de um banco de dados.

Cod Nome Sexo Idade Cidade

2 Ademar M 22 São Paulo

1 Fabrício M 41 Salvador

5 Joelma F 60 Rio de Janeiro

4 Carlos M 21 São Paulo

3 Adriana F 30 Curitiba

Quadro 3.2 – Operações típicas em um exemplo de tabela de

CLIENTES

Álgebra Relacional
Um banco de dados relacional tem este nome, pois, conforme
Elmasri (2011), relação é o bloco básico na qual este tipo de banco
de dados funciona. A álgebra relacional, conforme Puga (2013), é
uma linguagem formal de alto nível para expressar as operações
sobre tabelas, suas linhas e colunas. Ela engloba operações de
conjuntos por exemplo: união, interseção, produto cartesiano e
diferença de conjuntos; e operações chamadas relacionais de
projeção, seleção, junção e divisão.

A Álgebra Relacional é a fundamentação que permite entender como

a linguagem SQL foi concebida, o que nos dá maior propriedade
para compreendermos os comandos de SQL. Veremos, dessa
maneira, que envolverá bastante do que discutimos anteriormente,
sobre o trato com linhas e colunas de tabelas.

Operação de SELEÇÃO (σ) para filtrar linhas

Vamos então compreender os comandos de álgebra relacional. O

primeiro deles é o de Seleção, que visa filtrar linhas da tabela
conforme uma condição. Lembrando nosso exemplo anterior de
selecionar os clientes com idade inferior a 40, a escrita em álgebra
relacional está exposta a seguir. A letra sigma (σ) é o símbolo que
representa a operação de seleção. O resultado desta operação são
as linhas amarelas já apresentadas na Figura 1.1.

σ idade<40 (CLIENTE)
Quando falamos de comandos no mundo da computação, é comum
estabelecermos a sintaxe, isto é, a regra com que um comando deve
ser escrito. Para este comando de seleção em álgebra relacional, a
sintaxe é a exposta a seguir e indica que o comando é escrito com o
símbolo σ seguido da condição e depois da relação a qual a operação
se aplica.

σ <condição> (<Relação>)

Essa operação de seleção pode ter condições combinadas com

operadores lógicos como os operadores E e OU. Por exemplo, a
sentença abaixo fará a seleção de linhas de pessoas com idade
acima de 40 anos e que moram no Morumbi. O operador E escrevese
com “^” e o operador ou se escreve com “ ̌ “ (“circunflexo invertido”).

σ ((idade > 40) ^ (Cidade= ‘Salvador’ ))

(CLIENTE)

Operação de Projeção (π) para escolher colunas

Assim como é possível escolher as linhas, a operação de projeção

permite escolher as colunas de uma determinada relação ou tabela
e é representada pela letra grega Pi (π) . Também com base em
nosso exemplo, para escolher as colunas de Nome e Cidade na
tabela de clientes, o comando está exposto a seguir. O resultado
serão as colunas destacadas em verde na tabela de CLIENTE.

π NOME, CIDADE (CLIENTE)

Enquanto comando, a sintaxe da projeção é:

 π <lista de atributos> (<Relação>)

Combinação de operações

A álgebra relacional permite a combinação de operações, isto é, o

resultado para uma determinada consulta é obtido pela execução
de operações combinadas por meio de parênteses. No exemplo a
seguir, primeiro é feita a operação de seleção (σ) para filtrar as linhas
de CLIENTE. Depois é realizada a de projeção (π) para escolher as
colunas que devem ser apresentadas.

π NOME, CIDADE ( σ idade<40 (CLIENTES))

Ao aplicar estas operações sobre a tabela mostrada em nosso

exemplo CLIENTES, o resultado será o mostrado no Quadro 3.3 .

Nome Cidade

Ademar São Paulo

Carlos São Paulo

Adriana Curitiba

Quadro 3.3 – Resultado da combinação de operações de álgebra

relacional
Alguns livros, como em Puga (2013), a notação está registrada
conforme o que foi escrito até aqui, mas poderá ser encontrada
também a escrita de comandos em álgebra relacional nos quais as
condições ou campos das diversas operações são escritas em
subscrito como a seguir.

π NOME, CIDADE ( σ idade<40 (CLIENTES))

Outras operações

Além dessas operações básicas, a Álgebra Relacional dispõe de

diversas outras com variadas finalidades no trato com as relações.
Puga (2013) e Elmasri (2011) apresentam detalhes destas operações.
A Figura 3.2a seguir é uma adaptação de Puga (2013) com algumas
outras operações relevantes de álgebra relacional presentes.
Perceba que há muitos aspectos em comum com conceitos
matemáticos, de teoria de conjuntos e relações. Esta é a base na qual
os comandos de SQL foram concebidos.

Símbolo Significado Finalidade Sintaxe

𝝈 Seleção, Extrair linhas que atendam a uma 𝝈

(sigma) restrição ou determinada condição <condiç
ão de seleção>
select
(R)

𝝅 (pi) Projeção ou Extrair colunas específicas. 𝝅 <lista de

project atributos> (R)
 x Produto Combinar cada linha de uma (R) x (R)
cartesiano ou tabela, com cada linha de
cartesian product outra tabela.

⨝ Junção natural Extrair linhas de duas ou mais (R) ⨝ (R)

ou natural join tabelas com nome e tipo de
dados iguais.

∪ União ou union Extrair e combinar todas as (R) ∪ (R)

linhas de uma ou mais
consultas compatíveis

∩ Intersecção ou Extrair apenas as linhas (R) ∩ (R)

intersect presentes em duas tabelas.

- Diferença ou Extrair todas as linhas da (R) - (R)

minus primeira tabela, que não estão
presentes na segunda tabela.

Quadro 3.2 – Operações típicas em um exemplo de tabela de

CLIENTES

Saiba mais
A compreensão de Álgebra Relacional, neste texto, permite uma
introdução a sua forma de tratar relações ou tabelas e nos permite
perceber quais os fundamentos base da concepção da SQL. Na
prática cotidiana com banco de dados, uma boa competência com
SQL já é interessante, mas caso queira saber mais sobre Álgebra
Relacional, uma leitura mais aprofundada pode ser encontrada em
livros mais densos sobre bancos de dados, como o capítulo 3 de
Puga (2013) e o capítulo 6 de Elmasri (2011), que se encontram
disponíveis no link.

DATA DEFINITION LANGUAGE (DDL)

Aprenderemos agora sobre os grupos de comandos divididos em

três ênfases: os comandos de definição de dados (DDL) como o
CREATE TABLE, a recuperação via SELECT e, por fim, inserção,
alteração e exclusão via comandos como INSERT por exemplo.

Existem duas sequências que podem ser empregadas. Uma das

abordagens envolve seguir a ordem natural com que os comandos
acontecem no ciclo de vida de um banco que envolve modelagem,
criação, inserção dos registros e depois recuperação e outras
manipulações. Seguindo esta linha, o início ocorre com os comandos
de DDL para criar a estrutura do banco, depois as manipulações,
como inserção e outros, e somente no fim a operação via SELECT.

Outra forma de abordagem consiste em começarmos pelos

comandos mais simples, irmos nos ambientando com o jeito e a
lógica de pensar os comandos e daí ir incorporando os outros
comandos. Nesta linha, o início seria realizado com o comando mais
simples, o SELECT, para recuperação dos dados. Depois pode-se
então tratar as manipulações e como as tabelas foram criadas.

Nesta seção, seguiremos uma trajetória que envolve a criação das

tabelas, depois o comando SELECT e, por fim, as manipulações. É
uma sequência comum de se encontrar em planos de ensino, mas
que pode ser alterada conforme a escolha do leitor; fique à vontade.
Preparando o ambiente MySQL e MySQL
Workbench
No decorrer do curso, utilizaremos como servidor de banco de
dados o MySQL, um servidor “open source” e popular, o que torna
possível sua instalação e o acesso a um vasto material de suporte. A
operação com o banco de dados pode ser feita via linha de
comandos (prompt) ou via ferramentas administrativas; o MySQL
provê as duas formas.

O MySQL Workbench é a ferramenta administrativa disponibilizada

pelo fornecedor e sua visão típica está representada pela Figura 3.3.
Na parte superior, estão o menu e a barra de tarefas ou comandos.
À esquerda está a parte “Navegador”, interessante por permitir
visualizar os diversos objetos presentes no servidor, sobretudo os
bancos de dados para o nosso caso. Na parte central, o usuário pode
realizar as tarefas e, no nosso caso, estamos com consultas abertas
para digitar os comandos. Os resultados da execução dos
comandos, por sua vez, podem ser visualizados na parte inferior.
 Figura 3.1 – Ferramenta administrativa MySQL Workbench

Apesar de ter usado o WorkBench, uma ferramenta específica de um

servidor, vale destacar que esta é uma visão geral comum em
diversas ferramentas administrativas de outros bancos. Elas em
geral apresenta uma parte superior para disparar tarefas por menu
e barra de comandos, uma parte lateral esquerda para navegação
pelos objetos e a parte central para a operação com o servidor em
si.

Saiba mais
Ferramentas administrativas para bancos de dados, como o
Workbench para o MySQL, em geral apresentam funcionalidades
comuns: visualizar os objetos no banco, criar consultas, ver
resultados. Caso você queira comprovar, analise alguma outra de
algum outro banco de sua preferência. Por exemplo, no SQL Server
existe o SQL Server Management Studio. Experimente observar
(não precisa instalar, apenas ler algo sobre a ferramenta), ler um
tutorial e veja se de fato apresentam funções análogas. Claro que
os bancos serão diferentes, existirão diferenças, mas perceba que
algumas tarefas são equivalentes. A propósito, se não se mobilizou
ainda, é uma boa hora para instalar o servidor e o Workbench. Para
saber mais, acesse o link disponível.

A visão da ferramenta na Figura 3.3 mostra também informações

dos elementos que serão usados como ambiente para nosso
aprendizado. O script, conjunto de comandos no centro, cria um
schema “Loja” e, na sequência, a tabela CLIENTE, que será explicada
nos tópicos a frente. Perceba que o schema está expandido na parte
de navegação com a tabela CLIENTE em questão.

Este é um bom momento para entendermos schemas. No decorrer

da unidade, sempre falamos de bancos de dados como um
componente abrigado em um servidor onde estão as tabelas e
outros elementos. Podemos dizer que este conceito de banco de
dados corresponde ao de schema em nosso ambiente, é nele que
estarão “pendurados” os elementos de banco de dados do nosso
sistema “Loja”.

Uma vez com o ambiente de trabalho compreendido, podemos

então entender a sua operação via comandos.

Criação de tabelas (CREATE TABLE)

Durante a modelagem, as tabelas foram definidas com os seus

atributos como visto na Figura 3.4 para a tabela CLIENTE. A
propósito, esta será a tabela que exploraremos como exemplo base
para nosso aprendizado; é simples e didática. Entretanto fica o
convite, sempre que um novo comando ou operação for explicado,
que o aluno, por analogia, experimente fazer em um exemplo
próprio, imaginando outras tabelas.

Figura 3.2 – Tabela (CLIENTE) exemplo para aprendizado do SQL

Para criar esta tabela em um banco de dados, usa-se o comando

CREATE TABLE e, para o nosso caso, ele será operado da seguinte
forma (Quadro 2.1).

Exemplo de comando: CREATE TABLE

 CREATE TABLE CLIENTE (
CODIGO INTEGER NOT
NULL
AUTO_INCREMENT,
NOME VARCHAR(50) NOT NULL, CPF
CHAR(11) NULL,
CONTATO VARCHAR(20) NOT NULL,
DATA_NASC DATE NULL,
SEXO CHAR(1) NULL,
BAIRRO VARCHAR(50) NULL,
PRIMARY KEY(CODIGO)
)

Quadro 3.4 – Exemplos do comando CREATE TABLE

Vale percebermos que cada campo está associado ao seu tipo de

dados, isto é, quais valores que são possíveis de serem atribuídos
aos campos. Por exemplo, o campo CODIGO só pode ter valores
inteiros. Nome e CPF podem armazenar caracteres. No caso de
Nome, o tipo VARCHAR permite que o espaço de valores que não
usarem todos os 50 caracteres seja melhor gerenciado
internamente. Já para o caso CPF, sempre 11 caracteres serão
reservados para o dado. E assim, outros campos possuem seus
domínios de valores.

Cada campo também possui o indicativo de NULL / NOT NULL, que

indica se o campo deve ter obrigatoriamente um valor ou não, isto
é, NULL (sem valor). Vemos que para cadastrar um cliente é
necessário ter pelo menos os campos Código, Nome e Contato.

Em algumas situações, pode ser conveniente que um determinado

campo tenha seus valores obtidos incrementados de forma
automática; o banco de dados gerencia esta geração automática.
Neste caso, usa-se a sentença “CODIGO INTEGER NOT NULL
AUTO_INCREMENT” com a palavra “AUTO_INCREMENT”.

Ao final do comando CREATE TABLE, percebe-se que foi criado um

comando para adicionar a chave primária que é o campo CODIGO.
Isso é interessante, pois permite compreender que uma tabela não
é apenas um conjunto de campos, ela possui um conjunto de
restrições sobre as tabelas, dentre as principais, as chaves primárias
e estrangeiras.

Neste momento, vale sinalizar que a sintaxe que será usada no texto
será baseada no banco MySQL, usado como exemplo no decorrer da
unidade. Cada banco de dados apresenta algumas variações em
torno de um padrão, o chamado padrão ANSI SQL. Por isso,
dependendo do SGBD que você usar, MySQL, ORACLE, SQL Server,
além de outros, vale conhecer o seu guia de referência dos
comandos para tratar de eventuais adaptações.

Reflita
Pare um pouco e pense. Você gosta de seguir padrões? Por que
você acha que o SQL teve sucesso em sua jornada? Definição de
padrões é uma estratégia importante em tecnologia e em outras
áreas também, porque permite melhor integração de diversos
fabricantes e tecnologia. Por exemplo, existem vários servidores de
bancos de dados, entretanto, se um profissional domina o SQL, o
esforço dele para se adaptar a algum servidor específico é menor,
uma vez que o servidor “obedece àquele padrão” que um conjunto
ou consórcio de empresas estabeleceu.

A propósito, para o SQL existe o ANSI SQL, padrão gerenciado pela

American National Standards Institute (ANSI). Os servidores possuem
algumas peculiaridades, mas mantêm boa compatibilidade com o
padrão. Portanto, vale refletir, qual o papel dos padrões em
Tecnologia de Informação? Quais vantagens e desvantagens em
usá-los?

Todo comando tem uma sintaxe formal, isto é, uma especificação

mais formal sobre como escrever o comando. Apesar de ser mais
fácil aprendermos pelo exemplo, a cada comando maior,
apresentaremos uma visão breve da sintaxe. No caso do CREATE
TABLE, uma breve sintaxe está representada no Quadro 3.5. Perceba
que para criar uma tabela é necessário ter o Nome_Tabela e a
especificação das colunas e das restrições. Para uma coluna, é
necessário especificar o Nome da Coluna, o Tipo de Dados e a
obrigatoriedade (NULL, NOT NULL).

Sintaxe de comando: CREATE TABLE

CREATE TABLE Nome_Tabela (

<Lista_Colunas>,

<Restrições>
)

Coluna : < Nome_Coluna Tipo_dado [NULL/NOT NULL]

>

Restrição : <Tipo_Restrição> <Especificação>

Quadro 3.5 – Sintaxe de comando CREATE TABLE

Alteração e Exclusão de tabelas

Assim como uma tabela pode ser criada, ela pode ser modificada e

excluída. Na verdade, estas operações de criar, alterar e excluir são

típicas em componentes de banco de dados. O Quadro 3.6 mostra
os exemplos destes comandos. No primeiro, de alteração da tabela,
será adicionado um campo COD_CIDADE do tipo inteiro. O segundo
exclui uma coluna DATA_NASC da tabela e, por último, o terceiro
comando exclui a tabela. Importante alertar que estes dois últimos
devem ser usados com muito cuidado, pois podem ocasionar perda
de dados.

Exemplos de Comando: ALTER TABLE / DROP TABLE

ALTER TABLE CLIENTE

ADD COLUMN COD_CIDADE INTEGER NULL

ALTER TABLE CLIENTE DROP COLUMN DATA_NASC

DROP TABLE CLIENTE

Quadro 3.6 – Exemplos para alteração e exclusão de tabela

Restrições de Chave Primária e Chave

Estrangeira
Uma tabela, além dos campos, possui as restrições que estabelecem
algumas regras para os valores que são atribuídos aos campos. As
chaves primárias e chaves estrangeiras são dois exemplos destas
restrições. As chaves primárias identificam um certo registro e as
chaves estrangeiras são campos que só podem ser preenchidos com
valores que existem em uma outra tabela referenciada.

Assim como no caso de adicionar colunas, para restrições é também

usado o comando ALTER TABLE com a especificação das restrições. O
Quadro 3.5 mostra exemplos do comando para manipular as chaves
primárias. Vale lembrar que a chave primária pode ser criada dentro
do próprio comando CREATE TABLE como já foi visto, além de existir
diversas outras formas. É necessário indicar qual tabela está sendo
alterada, o tipo de restrição, que é a PRIMARY KEY a ser adicionada, e
a especificação da restrição, que, no caso, é o campo. No primeiro
comando, dá-se um nome para esta restrição, o PK_CLIENTE, e ‘PK’,
de primary key, chave primária em inglês. No segundo comando, usa-
se também um formato por meio do
CONSTRAINT, indicando que é uma restrição; os dois comandos são
equivalentes, são só formas diferentes de escrever. E o último
comando é um exemplo para a exclusão da chave.

Exemplos de Comando: Chave Primária

ALTER TABLE CLIENTE

ADD PRIMARY KEY PK_CLIENTE (CODIGO)

ALTER TABLE CLIENTE

ADD CONSTRAINT PK_CLIENTE
PRIMARY KEY (CODIGO)

ALTER TABLE CLIENTE DROP PRIMARY KEY

Quadro 3.7 – Exemplos de comandos para chaves primárias

Para as chaves estrangeiras, os exemplos estão mostrados no

Quadro 3.7 . Perceba que basta indicar qual o campo é chave
estrangeira e qual chave primária de outra tabela ela referencia.

Exemplos de Comando: Chave Estrangeira

 ALTER TABLE CLIENTE
ADD CONSTRAINT
FK_CLIENTE_CIDADE
FOREIGN KEY (COD_CIDADE)
REFERENCES CIDADE(COD_CIDADE)

ALTER TABLE CLIENTE

DROP FOREIGN KEY FK_CLIENTE_CIDADE

Quadro 3.8 – Exemplos de comandos para manipular chave

estrangeira

MANIPULAÇÃO DE DADOS (DML) – COMANDO SELECT

Um comando muito importante na manipulação de dados é o

comando Select, pois com ele conseguimos recuperar as
informações que estão contidas nas tabelas e com muitos recursos
para especificar e sofisiticar como querecemos esta recuperação.
Podem ser usados os filtros de diversas formas, ordenação, colunas
podem ser escolhidas ou abstraídas, consultas podem conter
subconsultas, enfim, isso é só para comentar que o SELECT é um
comando muito versátil.

Neste momento, veremos as formas mais básicas de realizar as

consultas com o Select. Uma vez com as tabelas criadas no banco de
dados, o foco agora é consultar seus dados.

Dados de exemplos
Para que possamos compreender o comando, vamos considerar a
tabela CLIENTE que apresenta os seguintes registros do Quadro 3.9.
CODIG O NOME CPF CONTAT DATA_NA SEX O BAIRRO
O SC

71
Adriana 011203899 1987-02-

1 9822134 F Barra

Araújo 21 03
55

Renato 11
982203799 1977-07- Morum

2 Nogueir 9333219 M

31 09 bi

a 99

11 Vila
Viviane 435173865 1995-11-

3 9877120 F Madale Sales 02

21 22 na

71
Marcela 992203772 1980-01-

4 9735144 F Barra

Campos 21 19
98

Rodrigo 21
721775899 1992-05-
5 Gonçalv 9861219 M Centro

91 10

es 42

11
Jorge 831446199 1990-06- Morum

6 9954398 M

Marinho 76 07 bi
12

71
Rodrigo 735204219 1985-08-

7 9723188 M Centro

Vieira 29 27
72

21
Vanessa 762110387 1972-02-

8 9332113 F Centro

Aquino 39 15
46

11 Vila
Fabiana 311603199 1985-04-

9 9332167 F Madale

Moreira 71 13

58 na

Maria 21
824103999 1999-07-

10 Conceiç 9544192 F Centro

 21 10

ão 57

Quadro 3.9 – Dados de exemplos para os comandos

Vale comentar que são dados de uma tabela simples, talvez em uma
situação real os dados podem ser bem mais complexos do que estes
e com uma estrutura diferente; talvez, em vez de tratar “Bairro”
como um VARCHAR, ele seria uma chave estrangeira para uma
tabela de bairros. O propósito, neste momento, é apenas ter alguns
dados para compreender as variações de comandos Select que
vamos estudar.

Primeiro exemplo: SELECT simples para

colunas e linhas
Para começar, consideremos um formato bem simples de SELECT em
que especificamos algumas colunas que nos interessam e
estabelecemos um filtro para algumas linhas. A necessidade é de
recuperar “os clientes, especificamente nome, contato e data de
nascimento dos clientes do sexo feminino”, e o comando está
exposto no Quadro 3.10. A coluna mostra a forma, a sintaxe de
escrever o comando.

Exemplo de Comando: SELECT simples Sintaxe

 SELECT NOME, CONTATO, DATA_NASC SELECT < colunas >
FROM CLIENTE FROM < tabela >
WHERE SEXO = 'F' WHERE < filtros >

Quadro 3.10 – Exemplo de um comando simples de SELECT

O resultado da consulta acima deve ser o da Figura 3.6. Perceba que,

ao observar os nossos registros de exemplo (Figura 3.11), apenas as
linhas com os códigos 1, 3, 4, 8, 9 e 10 satisfazem a condição de
“SEXO = 'F'”, isto é, clientes do sexo feminino. E quanto às colunas,
apenas NOME, CONTATO e DATA_NASC foram mostradas.

NOME CONTATO DATA_NASC

Adriana Araújo 71 982213455 1987-02-03

Viviane Sales 11 987712022 1995-11-02

Marcela Campos 71 973514498 1980-01-19

Vanessa Aquino 21 933211346 1972-02-15

Fabiana Moreira 11 933216758 1985-04-13

 Maria Conceição 21 954419257 1999-07-10

Figura 3.11 – Resultado da consulta inicial com Select

Operadores para refinar os filtros das

linhas
A partir deste exemplo simples, é possível refinar a forma de
expressão das sentenças que representam nossa necessidade sobre
os dados em condições. Essas condições compõem os filtros
(cláusula WHERE) da consulta e apenas as linhas que satisfazem as
condições são apresentadas no conjunto de resultados.
Por exemplo, como recuperar os Clientes que nasceram entre 2000
e 2005? Como selecionar os Clientes do sexo masculino que moram
no Bairro Barra? E como capturar um cliente em específico que se
chama “Viviane”? Enfim, neste momento de consultas básicas, o foco
é desenvolver esta habilidade de traduzir uma necessidade sobre os
dados e os seus filtros correspondentes.

O Quadro 3.12 a seguir apresenta algumas operações que podem

ser realizadas na edição dos filtros. Os filtros envolvem operações
de comparação para valores como números e datas. Existem outras
operações comuns e também os operadores lógicos que permitem
combinar condições compondo filtros maiores.
 Operador Comentário

Igual: = Permitem a comparação de valores. O

Maior e menor: > < operador igual (‘=’) é muito usado em
diversos tipos de campos. Os outros
Com igual: >= <=
são mais comuns em campos com
Diferente: <> !=
valores numéricos, de data em que a
relação “maior” e “menor” faz mais
sentido

Exemplo:
CODIGO >= 10

like Usado para reconhecer padrões ou

subpalavras em campos textos.
- Para ver se o nome possui a palavra
“Viviane”,
- o % indica “qualquer caractere”

Exemplo:
NOME LIKE ‘%Viviane%’

betweeen
Verifica se os valores estão entre um
limite inferior e um limite superior

Exemplo:

CODIGO BETWEEN 3 AND 20

Quadro 3.12 – Operadores para compor condições em comandos
SQL
Para melhorar a compreensão, o interessante é observar alguns
exemplos. Os quadros a seguir mostram alguns e comentam outros
recursos comuns na escrita de consultas.

Quadro 3.13 – Operadores para compor condições em comandos SQL

Quadro 3.13 mostra um exemplo de comandos de comparação e

alguns comentários sobre o uso de campos do tipo data. Um recurso
muito útil e rápido com consultas é o uso do asterisco (‘*’) no lugar
das colunas. Ele indica que deseja recuperar todas as colunas.

O Quadro 3.14 mostra um exemplo de comandos com o uso do LIKE.

 Exemplos de Comandos: SELECT com operador LIKE

- Para recuperar os clientes que apresentam Viviane

no nome
SELECT NOME, CONTATO
FROM CLIENTE
WHERE NOME LIKE '%Viviane%'

- Comentários:
- O ‘%’ indica “qualquer caractere
- Com apenas 'Viviane%', seriam consideradas as
linhas que começam com o nome Viviane

Resultado

NOME CONTATO

Viviane Sales 11 987712022

Quadro 3.14

No exemplo do Quadro 3.15, os clientes nascidos em determinado

período de tempo são processados com o operador BETWEEN.
 Exemplos de Comandos: SELECT com operador BETWEEN

- Para recuperar os clientes que nasceram entre 1990 e 1995

SELECT NOME, CONTATO, DATA_NASC
FROM CLIENTE
WHERE DATA_NASC BETWEEN '1990-01-01' AND
'1995-12-31 23:59'

- Comentários:
- Perceba que a data final foi tratada com hora para incluir os
clientes nascidos naquele dia de 31/12/1995

Resultado

NOME CONTATO DATA_NASC

Viviane Sales 11 987712022 1995-11-02

Rodrigo 21 986121942 1992-05-10

Gonçalves

Jorge Marinho 11 995439812 1990-06-07

Quadro 3.15
Operadores lógicos AND, OR e NOT

Além dos operadores de comparação, os operadores lógicos

permitem expressar filtros com recursos mais avançados,
combinando condições com operação de E, OU e NÃO. Um operador
lógico permite combinar situações, por exemplo, ao se consultar
clientes do sexo feminino E que moram na Barra; o conectivo “E” faz
com que apenas clientes que satisfaçam às duas condições sejam
considerados no resultado. Para o OU, se apenas uma das condições
forem satisfeitas, a linha é considerada. Por exemplo, para clientes
que nasceram depois de 1995 OU que sejam do sexo feminino,
linhas que satisfizerem pelo menos uma das condições serão
consideradas.
O Quadro 3.16 apresenta como expressar as consultas com o
operador lógico E (AND).

Exemplos de Comandos: SELECT com operador

lógico E

- Para recuperar os clientes do sexo feminino e

que moram na Barra
SELECT NOME, SEXO, BAIRRO
FROM CLIENTE
WHERE SEXO = 'F' AND BAIRRO =
'Barra'

- Comentários:
- Perceba que no resultado a seguir os dois
campos apresentam valores que satisfazem a
condição.
 Resultado

NOME SEXO BAIRRO

Adriana
F Barra Araújo

Marcela F Barra
Campos

Quadro 3.16

O Quadro 3.16 apresenta exemplo de consulta com o operador

lógico OU (OR).

Exemplos de Comandos: SELECT com operador lógico OU

- Para recuperar os clientes que nasceram até 1980 ou que

sejam do sexo masculino
SELECT NOME, DATA_NASC, SEXO
FROM CLIENTE
WHERE DATA_NASC < '1980-01-01' OR
SEXO = 'M'

- Comentários:
- Perceba que no resultado a última linha (sexo = ‘F’) só foi
considerada porque a data de nascimento é inferior a
1980, uma das condições foi satisfeita.
- Por outro lado, perceba que Jorge Marinho nasceu em
1990 porém foi considerado por conta de ser do sexo
masculino, satisfez uma das condições.
- Já Renato foi considerado porque satisfez as duas
condições.
 Resultado

NOME DATA_NASC SEXO

Renato
1977-07-09 M
Nogueira

Rodrigo 1992-05-10 M
Gonçalves

Jorge Marinho 1990-06-07 M

Rodrigo Vieira 1985-08-27 M

Vanessa
1972-02-15 F
Aquino

Quadro 3.17

Ainda existe o operador NOT que recupera uma linha quando ela não
satisfaz certa condição, por exemplo, imagine que queiramos os
clientes que não moram na Barra. O Quadro 3.18 exemplifica este
caso.

Exemplos de Comandos: SELECT com operador

lógico
NOT
- Para recuperar os clientes que não moram na Barra
SELECT NOME, SEXO, BAIRRO
FROM CLIENTE
WHERE NOT (BAIRRO = 'Barra')

- Comentários:
- Perceba que nenhum dos registros apresentam o
Bairro igual a Barra
- O filtro é equivalente a escrever WHERE BAIRRO <>
'Barra'
- Isto é, considerar linhas cujo bairro seja diferente
(NOT igual) a Barra
 Resultado

NOME SEXO BAIRRO

Renato M Morumbi
Nogueira

Viviane Sale F Vila Madalena

Rodrigo M Centro
Gonçalves

Jorge Marinho M Morumbi

Rodrigo Vieira M Centro

Vanessa F Centro
Aquino

Fabiana F Vila Madalena

Maria F Centro
Conceição

Quadro 3.18

INSERÇÃO, ALTERAÇÃO E EXCLUSÃO DE DADOS

Parte dos grupos de comandos de DML realiza alterações nas

tabelas de dados. Por exemplo: um novo registro pode ser criado
(INSERT), um registro existente pode ter dados alterados (UPDATE) e
linhas podem ser excluídas (DELETE). Juntamente com o SELECT, esses
comandos formam as operações que são comuns de serem feitas
por usuário em sistemas. Imagine, por exemplo, um carrinho de
compras, em uma loja virtual, no qual itens podem ser adicionados,
retirados e um item, já no carrinho, pode ter a quantidade alterada.
Além disso, para visualizar os dados do carrinho, uma consulta com
SELECT deve ter sido feita antes.

Inserção (INSERT)
No comando INSERT, para cada um dos campos da tabela, um
determinado valor deve ser estabelecido. O Quadro 3.19 mostra
alguns destes comandos que originaram as duas primeiras linhas de
nosso conjunto de dados na tabela de CLIENTE. Perceba que cada
campo é listado logo após o nome da tabela e, na cláusula VALUES,
cada valor é especificado obedecendo à ordem dos campos.
 Exemplos de Comandos: INSERT

Quadro 3.19 – Comando INSERT para inserção de dados

Dos exemplos, podemos perceber que a sintaxe do comando

INSERT pode ser resumida conforme o Quadro 3.20.
 Sintaxe do comando INSERT

INSERT INTO < Nome da tabela > ( < Lista de

campos> )
VALUES ( < Lista
de
valores, na mesma ordem dos campos> )

Quadro 3.20 – Sintaxe do comando INSERT

Alteração (UPDATE)
Para a alteração dos registros, naturalmente eles já devem estar
contidos nas tabelas. O comando precisa portanto de indicar quais
campos receber novos valores e em geral é especificado um filtro
(semelhante ao que foi visto no SELECT) para selecionar quais linhas
devem sofrer as alterações. O Quadro 3.21 mostra dois exemplos
de comandos UPDATE. Vale ressaltar que estes comandos de
UPDATE, assim como o de DELETE devem ser usados com cuidado
pois podem ocasionar perda de dados.
 WHERE CODIGO = 10

Comentários
- Perceba que a coluna Bairro na linha 10 está com valor Nova Barra.
- Apenas o último exemplo foi processado para exemplificar os resultados a seguir.

Vanessa Aquino 76211038739 21 933211346 1972-02-15 F

Fabiana Moreira 76211038739 11 933216758 1985-04-13 F Vila M

Maria Conceição 82 410399921 21 954419257 1999-07-10 F Nov

Exemplars de Comandos: UPDATE

- Para modificar o nome do bairro ‘Barra’ para ‘Nova Barra’

UPDATE CLIENTE
SET BAIRRO = 'Nova Barra'
WHERE BAIRRO = 'Barra'

- Para modificar o bairro do cliente de código 10 para 'Nova Barra'

UPDATE CLIENTE
SET BAIRRO = 'Nova Barra'
Quadro 3.21 – Comando UPDATE
Dos exemplos, podemos perceber que a sintaxe do comando de
UPDATE pode ser resumida conforme o Quadro 3.22.

Sintaxe do comando UPDATE

UPDATE < Nome da tabela >

SET < Nome do campo > = < novo valor
>,
< Nome do campo > = < novo valor
> , ...
WHERE < Filtros>

Quadro 3.22 – Sintaxe do comando UPDATE

Exclusão (DELETE)
A exclusão dos dados ocorre com o comando DELETE e sua sintaxe
também deve apresentar um filtro que indica quais linhas devem ser
afetadas pela exclusão. O Quadro 3.23 apresenta alguns exemplos
de comandos de exclusão de registros.

Exemplos de Comandos: DELETE

- Para modificar o nome do bairro ‘Barra’ para ‘Nova Barra’

DELETE FROM CLIENTE

WHERE BAIRRO = 'Barra'

- Para excluir o cliente de código 7

DELETE FROM CLIENTE

WHERE CODIGO = 7
Quadro 3.23 – Comando DELETE

Dos exemplos, podemos perceber que a sintaxe do comando

UPDATE pode ser resumida conforme o Quadro 3.24.
 Sintaxe do comando DELETE

DELETE FROM < Nome da tabela >

WHERE < Filtros >

Quadro 3.24 – Sintaxe do comando DELETE

CONCLUSÃO

Esta unidade abordou as habilidades necessárias para operar um banco de dados depois de ter
sido modelado.
De início, vimos como criar o banco de dados em si, refletindo as definições do modelo, além
de como os comandos DDL permitiam criar as tabelas com suas colunas, restrições,
características dos campos e outros.
A partir daí, o foco foi em como manipular os registros destas tabelas, se os registros estão
presentes, como recuperá-los com o comando SELECT. Caso precisem ser modificados, como
fazer inserções, alterações e exclusões com os comandos INSERT, UPDATE e DELETE,
respectivamente.
E tudo isso tentando mostrar exemplos. Esta parte prática com comandos SQL e seus
resultados é interessante ao aprender sobre banco de dados.
Espero que tenha aproveitado!

Projeto

ADMINISTRANDO E MANIPULANDO BANCOS DE

DADOS COM FERRAMENTAS GRÁFICAS
Em banco de dados relacional o SQL é uma linguagem usada para
definição e manipulação de dados, tarefa relevante para os mais
variados profissionais (PUGA< 2013). Programadores usam essa
linguagem para codificar as funções de suas telas, o Administrador de
Banco de Dados usa para suas tarefas administrativas e mesmo para
ajustes na estrutura das tabelas e dos dados.

Por ser um padrão em bancos de dados relacionais, esta linguagem é

empregada em diversos SGBD’s, ORACLE, SQL Server, FireBird e MySQL,
por exemplo. Enfim, é uma linguagem bastante ampla e de essencial uso
quando se fala em banco de dados.

Imagine que uma Loja Virtual possui seu sistema na Internet e você foi o
responsável por gerenciar o módulo de Cadastro dos Clientes. O
Projetista explicou a você que o modelo de dados dessa parte é
mostrado a seguir (Figura 1) e que você ficará responsável por manter os
dados e atender eventuais demandas por relatórios. Por exemplo,
quando o marketing precisar de uma lista de clientes para alguma
campanha, você será acionado para emitir essa lista junto ao banco de
dados.
 Figura 1 - Modelo de Dados do Módulo de Clientes

Vamos Praticar

Bom, diante do cenário, o primeiro passo é montar seu ambiente,

portanto instale o seu servidor MySQL com o WorkBench para você
executar suas tarefas.
Com ambiente montado, analise a especificação presente no
modelo de dados que o projetista te passou (Figura 1) e digite os
comandos de DDL (create table, alter table, e outros) para a criação
das tabelas com suas chaves primárias e estrangeiras.
Com as tabelas criadas, crie um script em que você faz uma inserção
de pelo menos 20 registros na tabela de CLIENTE e 5 registros na
tabela CIDADE.
Por fim, já prepare algumas consultas sobre os clientes que podem
em alguma hora ser úteis para o departamento de marketing. Por
exemplo, vamos pensar em algumas situações:
Como recuperar os clientes de determinado sexo e que moram em
certo bairro?
Como recuperar os clientes cujo DDD seja de São Paulo (11)?
Pare um pouco e pense pelo menos em mais de 20 situações que
envolvam Inserção, Alteração e Exclusão de dados, além de
Consultas que podem ser feitas neste banco de dados. Para cada
uma escreva o comando SQL equivalente.
Por fim, é isso programador (SQL), assuma seu posto de responsável
pelo módulo de Clientes do sistema da Loja Virtual e sucesso!
 BANCO DE DADOS
U4 - CONSULTAS AVANÇADAS E VISÕES
(VIEWS)

INTRODUÇÃO

Quando estamos estudando banco de dados, ao iniciar com consultas exploramos os recursos
do comando SELECT para os primeiros resultados que em geral já são interessantes.

Esta unidade visa evoluir a construção de consultas com recursos mais avançados associados a
este comando de SELECT. Serão vistos tópicos como junções, comandos para ordenação e
agrupamento dos dados, uso de funções de agregação como somatórios e contabilizações e
por fim como criar visões (views) para tornar mais fácil e prático a manipulação de consultas.

Todos estes recursos são bem úteis em tarefas cotidianas de produzir relatórios e atender
demandas de usuários que precisam extrair informação e conhecimento mais apurado a partir
do banco de dados.

Vamos em frente!

JUNÇÕES

Em um primeiro momento no aprendizado com comandos de DML

como o SELECT o foco é selecionar os dados de uma tabela, por
exemplo, quais os clientes do sexo feminino, entretanto é mais
comum precisarmos de dados que estão presentes em diversas
tabelas. Se a estruturação dos dados divide cada registro em sua
respectiva tabela, Clientes, Compras, Cidades, Produtos, ao
recuperar estes dados é preciso de alguma forma para juntá-los.

Vamos analisar um exemplo que envolve uma loja virtual, com seus
dados de clientes, cidades e de compras. Parte do modelo está
exposto a seguir na Figura 4.1. Imagine que haja a necessidade de
saber quais clientes (Nome e Contato) com suas respectivas Cidades
(Dcr_Cidade) e que realizaram compras no mês de abril (campo
Data_Compra em Compras), talvez para fazer um contato e saber se
o cliente está satisfeito com a compra. Perceba que Nome e Contato
estão na tabela Cliente, a descrição da cidade está em Cidade e Data
e Valor estão na tabela de Compras. Fica então a questão, como
colocar estes dados juntos?

Figura 4.1 - Parte de modelo de exemplo do cenário de Loja

Virtual
Fonte: Elaborado pelo autor (2019).
Um primeiro raciocínio é partirmos da ideia da chave estrangeira, ao
estudar sobre a modelagem dos dados elas surgem como forma de
representar os relacionamentos entre entidades (no Modelo de
Entidade e Relacionamento) e tabelas (no Modelo Relacional),
servem como elo entre as duas tabelas em que há um
relacionamento 1:N por exemplo. Portanto, as chaves estrangeiras
desempenham um papel chave para fazer as junções dos dados.
Primeiro exemplo de junção (Inner Join)

Para compreender melhor este uso das chaves estrangeiras, vamos

para um exemplo. Observe a Figura 4.2, do lado esquerdo temos um
conjunto de resultados provenientes da tabela Cliente. À direita
encontram-se as cidades cadastradas na tabela Cidade. Como
transformar, na linha com nome ‘Adriana Araújo’, o valor de código
da cidade 1 na descrição da Cidade ‘Salvador’? É necessário um
mecanismo que faça com que a chave estrangeira 1 seja consultada
(via junção) na tabela de cidade. Aproveite esta lista de clientes para
perceber que existem valores que não possuem a cidade associada
(valores NULL), no caso os clientes ‘Rodrigo Vieira’ e ‘Fabiana
Moreira’, eles não devem conseguir participar da junção pois não
terão valores correspondentes na outra tabela.

Figura 4.2 - Exemplo de duas tabelas dissociadas Fonte:

Elaborado pelo autor (2019).
O mecanismo para resolver esta necessidade é a junção entre
tabelas, e um primeiro tipo é a junção interna ou “inner join” cuja
sentença está escrita no Quadro 4.1. A ideia é para cada código de
cidade em Cliente buscar na tabela de Cidade a linha que contém o
mesmo código, isto é, o campo Cod_Cidade serve como elo entre as
duas tabelas.

Quadro 4.1 - Exemplo de Inner Join Fonte:

Elaborado pelo autor.

O resultado deste comando de junção pode ser visualizado a seguir

na Figura 4.3, compare com as tabelas Cliente e Cidade dissociadas
da Figura 4.2, cada registro tem agora a descrição da cidade
equivalente ao código que foi usado na junção. O registro de
‘Adriana Araújo’ com código de cidade 3, foi associado ou juntado
com a descrição ‘Salvador’ vinda da tabela de Cidade. Perceba
também que apenas 8 linhas foram recuperadas e existem 10
clientes, o que ocorre é que os clientes sem valores no campo cidade
(NULL) não conseguem fazer a junção.
 Figura 4.3 - Resultado da junção entre as duas tabelas
Fonte: Elaborado pelo autor (2019).

A sintaxe do comando para junção está mostrada a seguir conforme

descrito em (PUGA, 2013, p226).

Quadro 4.2 - Sintaxe da junção entre tabelas Fonte:

PUGA (2013, p. 229).
Os termos em ‘[‘ indicam que apresentam opções ou podem ser
suprimidos. Perceba que na sintaxe não foi explicitado a palavra
chave ‘INNER’, em alguns casos ela é considerada como padrão ao
fazer a junção.
Tipos de Junções

Nosso primeiro caso de junção visto anteriormente é denominada

de junção interna (inner join) e no caso os campos usados para fazer
a junção precisam ter valores nas duas tabelas para que a junção
ocorra. Existem outros tipos de junções, por exemplo as junções
externas em que não necessariamente devem existir valores
correspondente nas duas tabelas.

Para compreender esta questão, vamos reconsiderar nosso

exemplo, observe a Figura 4.4 com os dados. Perceba que na
esquerda, na tabela Cliente, as linhas com código 7 e 9 não
apresentam valores de cidade, por isso não foram consideradas na
junção anterior. Por outro lado, na tabela de Cidade à direita,
existem as cidades de Manaus, Porto Alegre e Campo Grande
(códigos 4, 5 e 6 respectivamente) que não possuem nenhum cliente
associado na tabela de clientes, por isso não apareceriam em uma
junção como foi feita (e de fato, confira os resultados na Figura 4.3,
só aparecem as cidades São Paulo, Rio de Janeiro e Salvador).

Figura 4.4 - Exemplo de duas tabelas dissociadas Fonte:

Elaborado pelo autor (2019).
As junções externas (outer) podem ser de dois tipos principais, pela
esquerda (left outer join) e pela direita (right outer join). No caso da
esquerda, os registros na tabela da esquerda que não possuírem
correspondentes aparecem mesmo assim no resultado final. No
caso da direita, os registros da tabela da direita que não possuírem
correspondentes são mostrados nos resultados. Usar figuras com a
ideia de conjuntos pode ajudar a entender estas junções. Vale
destacar que esquerda e direita são definidos pela ordem com que
as tabelas aparecem na junção, a primeira que aparece é
considerada esquerda e a segunda é direita.

Quadro 4.3 - Tipos de junções

Fonte: Elaborado pelo autor (2019).

Saiba mais
Para aprofundar sobre o uso de junções, vale mencionar duas
dicas de leitura, um link para um artigo sobre os diversos tipos de
junção, simples, direto e prático. A outra dica é do livro de Puga
(2013), interessante também..

Bom, já que entendemos o funcionamento dos ‘outer joins’ vamos

aos exemplos. Antes de entender o exemplo, relembre os dados de
clientes e cidades, quais clientes não possuem cidade associada e
quais cidades não possuem clientes associados.

Para a junção pela esquerda (left join) o comando e os resultados

seriam os mostrados no Quadro 4.4 a seguir, perceba que neste caso
as linhas antes suprimidas aparece mas os campos da tabela Cidade
são preenchidos com NULL.

Quadro 4.4 - Junção externa - Esquerda (left outer join)

Fonte: Elaborado pelo autor (2019).

Já para a junção pela direita (right outer join) o exemplo está

mostrado no Quadro 4.5 a seguir.
 Quadro 4.5 - Junção externa - Direita (right outer join)
Fonte: Elaborado pelo autor (2019).

Neste caso as cidades (tabela da direita) que não possuírem

correspondentes em clientes aparecem nos resultados e as colunas
da tabela da esquerda (Cliente) ficam sem valores (null).

Subconsultas

No comando SELECT, em uma certa consulta é possível usar como

parte de suas cláusulas uma outra consulta com um comando
completo de SELECT. Elmasri (2011), as chama de consultas
aninhadas e também são comumente chamadas de subconsultas.
Existem várias formas e com vários outros operadores, o exemplo a
seguir no Quadro 4.6 apresenta um destes exemplos.
 Quadro 4.6 - Exemplo de subconsultas Fonte:
Elaborado pelo autor (2019).

No exemplo é recuperado os clientes que não possuem nenhuma

compra na loja, que pode ser útil para fazer contato e verificar
porque os clientes não finalizaram nenhuma compra.

Saiba mais
Existem várias formas de se criar consultas, com alguns outros
operadores. Para saber mais sobre subconsultas, o livro de Elmasri,
capítulo 5 sobre consultas complexas pode ser uma boa fonte e
para uma leitura mais prática, vale olhar também o link sugerido.
ORDENAÇÃO

Enquanto um comando bastante versátil, o SELECT permite ainda

que os registros sejam organizados para melhor visualização
ordenada dos dados ou ainda permite contabilizações e
agrupamentos. Para entendermos essas necessidades, no nosso
exemplo de loja Virtual, em alguma hora podemos querer ver os
Clientes ordenados por nome, para achar mais fácil um cliente na
lista pelo seu nome. Mas considere que o objetivo é processar
ligações para os clientes e organizados por cidade, neste caso pode
ser melhor ordenar por Cidade. Estes dois exemplos estão
organizados a seguir (Quadros 4.8 e 4.9).

Quadro 4.8 - Ordenação por ordem crescente de nome do cliente

Fonte: Elaborado pelo autor (2019).

Para o exemplo de ordenação pela cidade (Quadro 4.9) a seguir

podemos entender outras facetas da cláusula order by. Ela pode
conter mais de um campo e para ordem ascendente ou decrescente
pode-se usar as palavras ASC e DESC junto aos campos.

Quadro 4.9 - Ordenação com várias colunas e uso de ASC e DESC

Fonte: Elaborado pelo autor (2019).

Perceba que ordenamos por cidade em ordem crescente e por nome

em ordem decrescente, apenas para ilustrar.

FUNÇÕES DE AGREGAÇÃO E AGRUPAMENTO DE LINHAS

Uma vez com os dados armazenados em um banco de dados,

existe um grande potencial de transformar estes dados em
informação e conhecimento. Um primeiro passo pode vir por
contabilizações, por exemplo, qual o total de vendas de certo mês,
quantos produtos temos em um determinado estoque por
produto, além de outros. Para compreender como faremos estas
consultas vamos agora trabalhar com um conjunto de dados
diferente, os registros são de clientes e suas compras e estão
mostrados a seguir (Figura 4.6).

Figura 4.5 - Exemplo de dados com Clientes e Compras

Fonte: Elaborado pelo autor (2019).

Analisando os dados, imagine como calcular o total de compras? E

como avaliar a quantidade de compras por cliente? Questões assim
podem ser expressas pelas funções de agregação que veremos
adiante.

Funções de Agregação

As funções de agregação são funções que permitem calcular o total

(sum), contar (count), avaliar o maior (max) e assim por diante.
Imagine que se deseja obter o valor total de compras de nosso
exemplo e quantas compras foram realizadas. O exemplo a seguir
(Quadro 4.10) mostra como elas podem ser utilizadas.
 Quadro 4.11 - Exemplo com função de agregação
Fonte: Elaborado pelo Autor (2019).

O Quadro 4.11 mostra o conjunto de funções de agregação que

podem ser utilizadas nas consultas.

Função Descrição

count Conta quantos registros no

resultado da consulta

sum Calcula o total dos valores

no campo

max Avalia qual o valor máximo

no campo
 min Avalia qual o valor mínimo
no campo

avg Calcula a média dos valores

no campo

Quadro 4.12 - Conjunto de Funções de Agregação

As funções usadas até agora foram aplicadas a todo o conjunto de

resultado do SELECT mas o mais comum é elas servirem para
cálculos em agrupamentos, por exemplo, em vez de calcular o total
de todas as compras, ao agrupar o cálculo seria do total de todas as
compras por cliente.

Agrupamentos

As contabilizações e totalizações são comuns de ocorrerem junto

com agrupamentos. Um agrupamento ocorre quando um conjunto
de linhas são combinadas com base em um mesmo grupo de
valores. Por exemplo, ao se calcular o total de vendas por Cidade, os
registros são agrupados conforme o valor de Cidade. As cidades são
base para agrupar os registros que possuem o mesmo valor de
cidade.

O exemplo exposto no Quadro 4.12 permite entender como a

cláusula “group by” responsável pelos agrupamentos é empregada.
No exemplo é possível agrupar as compras por Nome do cliente e
assim saber o total de compras, quantas compras cada um fez e qual
o valor da maior compra. Perceba que o campo que aparece na
cláusula group by deve aparecer na lista de campos de SELECT e
ainda, que os campos que não constam na cláusula group by
precisam estar com uma função de agregação para se ter um valor
resumo. Isso é necessário justamente para saber qual operação
(total, contagem, maior) será feita ao agrupar o conjunto de valores
de um mesmo grupo.

Quadro 4.13 - Ordenação com várias colunas e uso de ASC e DESC

Bom, para fixar a ideia, fica o convite para olhar os dados originais
(Figura 4.6) e conferir se os valores conferem. Perceba que lá,
“Rodrigo” realizou duas compras nos valores de R$57,80 e R$31,00 o
que confere com os resultados de 2 compras, num total de R$88,80
e com o maior valor de R$57,80.
Filtros em Agrupamentos (having)

Quando se aprende o SELECT, na cláusula WHERE é possível filtrar

apenas algumas tuplas que satisfazem certa condição. O comando
WHERE continua podendo filtrar tuplas para o agrupamento porém
para filtrar os campos com as funções agregadas é necessário usar
o comando “having”. A partir disso, as condições são aplicadas sobre
as totalizações e contabilizações. Veja o exemplo no Quadro 4.13.

Quadro 4.14 - Exemplo de filtros em agrupamentos com o

“HAVING”
.
Na consulta anterior foi escrita uma condição apenas para o
somatório de compras, mas filtros com estes campos calculados
combinados com os operadores lógicos de AND e OR por exemplo
podem ser expressos, de forma análoga a forma como os filtros da
cláusula WHERE são feitos.
VISÕES
Um banco de dados é formado por diversos outros componentes
além das tabelas, que indiscutivelmente é a “protagonista” já que
abriga nosso principal insumo, o dado. Entretanto existem ainda as
visões, os procedimentos armazenados, os gatilhos e outros que em
um estudo mais extenso, além do escopo desta unidade, podem ser
explorados.

Neste tópico vamos explorar o conceito de visões que tem forte

relação com o que vimos até agora sobre como sofisticar nossas
consultas. Conforme Elmasri (2011)

“Uma view em terminologia SQL é uma única tabela que é

derivada de outras tabelas. Essas outras tabelas podem ser
tabelas da base ou views previamente definidas. Uma view não
necessariamente existe em forma física, ela é considerada uma
tabela virtual, ao contrário das tabelas de base, cujas tuplas
sempre estão armazenadas fisicamente no banco de dados. Isso
limita possíveis operações de atualização que podem ser
aplicadas às views, mas não oferece quaisquer limitações sobre
a consulta de uma view.“ (ELMASRI, 2011, p.88).
Portanto uma view não apresenta dados em si, como mencionado
por Elmasri, ela é uma “tabela virtual”, ela apenas se utiliza das
outras tabelas e outras views. Isso traz algumas vantagens em seu
uso mas primeiro vamos entender como este mecanismo funciona.
Imagine o nosso exemplo de modelo que possui Cidades, Clientes e
Compras. Para realizarmos uma consulta que tenha a descrição da
cidade, dados do cliente e dados de compra, precisaríamos fazer
uma consulta mais complexa que envolve três joins e tudo o mais.
Imagine também que esta consulta é bastante utilizada, várias vezes
são requisitados relatórios com base nestes dados. Para facilitar,
neste cenário pode ser criada uma view conforme o Quadro 4.14 a
seguir.

Quadro 4.15 - Criação e exemplo de uso de uma view

Existem variações para o comando anterior, por exemplo, no

cabeçalho podem ser adicionados os nomes dos campos que
inclusive pode ter nomes diferentes, mais intuitivos, do que os
usados nas tabelas de base.

Exemplo de comando: Definição dos nomes no cabeçalho da visão

(view)
 CREATE VIEW `COMPRAS_CLIENTES_VW2`
(NOME, BAIRRO, DATA_NASC,
SEXO,

COD_CIDADE, DCR_CIDADE, DATA_COMPRA, VLR

_COMPRA) AS ...

Quadro 4.16 - Uso de nomes dos campos no cabeçalho de criação da

View

Vale destacar que uma vez criada, a visão (view) funciona como
uma tabela e daí pode ser usada com todos os comandos vistos até
aqui, por exemplo, ela pode participar de visões, sofrer funções de
agregação, group_by, order by e outros comandos usados para
consultas via Select. Em alguns bancos são permitidas algumas
operações de manipulação (INSERT, UPDATE e DELETE) sobre views
porém com limitações.

Para compreender as vantagens e o uso de views, observe a

consulta usada na criação da view (com os três joins) e a consulta
usada depois já com a view criada, no caso o “select * from
compras_clientes_vw”. Qual delas é mais simples de usar? É fácil
perceber que a segunda opção é mais fácil, e esta é uma das
grandes vantagens no uso de visões. Elas reduzem a complexidade
de compreender e manipular os dados “mais internos” das tabelas
de base. Não é necessário entender todos os relacionamentos, teor
de todos os campos, como realizar os diversos joins e criar uma
consulta grande e complexa. Tudo fica sintetizado pela view.

Isso pode ser útil em alguns cenários. Por exemplo, para os

próprios desenvolvedores ao criar relatórios e precisar de
consultar o banco de dados, usar uma view é mais prático. Um
usuário final mais ambientado com consultas a dados via
ferramentas de relatórios ou pelo próprio SQL pode usar as views
para suas próprias consultas. E ainda, quando é necessário integrar
dois sistemas, uma view pode ser criada para que o fornecedor de
outro sistema tenha acesso aos dados com maior facilidade sem
precisar entender o modelo interno do sistema. Além de diminuir a
complexidade para consultar dados, as views são úteis ainda no
gerenciamento de segurança de acesso aos dados e outras, mas as
principais vantagens dessa redução na complexidade no trato com
dados.

Reflita
Nesta unidade tivemos contato com recursos que nos permitem
realizar consultas mais complexas sobre os dados, para extrair o
dado e compor informações mais refinadas para que estas ofereçam
melhor suporte à tomada de decisões nos negócios.

Isso tem sido cada vez mais usado, por exemplo, reflita sobre um
caso. Em seu dia a dia por exemplo, ao pesquisar por um livro em
uma livraria, como o site consegue sugerir outros livros relacionados
com sua pesquisa?

O mais curioso é que este estudo de consultas mais avançadas em

SQL é apenas um ponto de partida para esta compreensão de
fenômenos que pode ser extraída a partir dos dados. Áreas inteiras
foram desenvolvidas a partir neste contexto, por exemplo, a área de
Business Intelligence, KDD (Knowledge Discovery On Data), Data
Mining, Data Science e Aprendizagem de Máquina.

Daí vale a reflexão, qual a essência base nestas áreas? Parece ser
obter conhecimento sobre dados. E como estas áreas estão hoje e
para onde elas podem crescer! É uma boa visão para onde evoluir o
conhecimento desta unidade.
CONCLUSÃO

Vimos nesta unidade como sofisticar as consultas feitas com o comando SELECT. Estes recursos
junto com os mais básicos de filtros nas cláusulas WHERE e outros oferecem um leque bastante
interessante de comandos que atendem às mais variadas demandas por informação a partir
dos dados de um negócio.

Em se tratando de uma conclusão, vale comentar que estes comandos podem ser um ponto de
partida para o que hoje é chamada a área de Ciência de Dados. Os resultados dos comandos
aprendidos aqui já permitem boas primeiras análise e podem também servir de insumos para
análises mais sofisticadas, servir de entrada para algoritmos de aprendizagem de máquina e
inteligência artificial. Enfim, são os dados operacionais do negócio podendo sofrer análise em
diversos níveis de sofisticação para prover informações e conhecimento ao seus gestores.

São áreas bem interessantes caso pretenda evoluir neste assunto, espero que a dica seja útil!

Projeto
CONSULTAS AVANÇADAS COM SQL E SEU
SUPORTE PARA RELATÓRIOS

Segundo Laudon (2015), Sistemas de Informação (SI) possuem

componentes que tratam de variadas maneiras a informação para o
apoio à tomada de decisão em uma empresa. Um desses
componentes, o banco de dados, serve para manipulações de nível
operacional, o registro de uma compra, por exemplo, como para
níveis gerenciais e estratégicos, ao ser fonte para transformar dados
em informação com os relatórios, por exemplo, qual o volume de
vendas em determinado mês.

Compreender um modelo de dados e, a partir de consultas

avançadas, extrair informações úteis é uma tarefa comum no
suporte à geração de relatórios ou demandas específicas. E isso tem
ganhado cada vez mais relevância nos dias atuais por conta das
áreas de ciência de dados, aprendizagem de máquina, Big Data. Em
uma análise breve, como, a essência da aprendizagem de máquina
é extrair conhecimento ou aprender coisas a partir de dados e esses
dados “nascem”, sendo que uma de suas fontes são os bancos de
dados.

Imagine um cenário de uma pizzaria ou de uma loja on-line. Em um

primeiro nível, pense em como estas consultas podem servir de base
para relatórios, gerando o volume de movimentação no dia, os itens
mais vendidos, os elementos com menor nível de estoque. Em um
nível mais avançado, como essas consultas podem gerar dados que
podem vir a ser utilizados por algoritmos que descobrem padrões
de clientes, quais deles gostam mais de pizzas doces, quem compra
mais produtos eletrônicos, dentre outras. E tudo isso para suporte
às tomadas de decisões de marketing e de melhoria do negócio. Os
dados e as consultas são insumos importantes neste processo.

Vamos Praticar
Imagine que você foi destacado para dar suporte às demandas por
relatórios e outras informações para uma determinada diretoria.
Além disso, a equipe de marketing está em um projeto o qual
envolve aprendizagem de máquina, assim, para isso, requer, por
vezes, a extração de alguns dados para suas tarefas de mapeamento
de padrões sobre os clientes.

Em determinada semana, surgiram algumas demandas que você

deve tratar, dentre elas emitir os seguintes dados:

a) Relatório contendo uma lista com todos as categorias de produtos

e a quantidade de produtos em cada categoria. Isso será útil para a
equipe de vendas tentar diversificar o catálogo, e ordenados por
nome da categoria.

b) Relatório com o volume de compras (quantidade de compras e

valor total de compras) organizados por mês. Isso servirá de base
para a Diretoria Comercial verificar fatos nos meses de maior e de
menor volume de vendas.

c) Relatório com todos os clientes com suas características de sexo,

data de nascimento ou idade, bairro em que mora e o total de
compras nos últimos dois meses. Para total de compras, considere
quantidade de compras, o valor e média de valor por compra. Essa
consulta servirá de dados para um projeto de aprendizagem de
máquina que visa mapear os padrões de consumidores da loja.
Como esta demanda será frequente, prepare uma Visão (view) para
esse caso e analise as vantagens nessa produção de consultas sob
demanda.

O modelo de dados do sistema está exposto a seguir.

Além destes sugeridos, imagine outros 5 relatórios que podem ser

emitidos a partir do modelo, discuta qual utilidade para o negócio e
depois crie visões (views) para eles.
Enfim, é hora de dar suporte às demandas por informação a partir
de suas consultas mais avançadas usando group by, order, joins e
outros. Bom trabalho!