Modelagem de Banco de Dados Relacional

Prévia do material em texto

UNIDADE II
Modelos 
de Bancos 
de Dados 
Relacionais
Everton Gomede
Modelagem e Projeto de Banco de
Dados Relacional
Imagine como transformar a especi�cação de um problema do mundo real em um
projeto de banco de dados. Isso pode ser feito utilizando o modelo Entidade-
Relacionamento (E-R) que vamos estudar.
Ao �nal desta aula, você será capaz de:
ter uma visão geral do processo de design;
entender o modelo de relacionamento entre entidades;
aprender sobre restrições em bancos de dados.
Visão Geral do Processo de Design
Aula 01
Introdução
2
A tarefa de criar um aplicativo de banco de dados é complexa, envolvendo design do
esquema do banco de dados, design dos programas que acessam e atualizam os dados
e o design de um esquema de segurança para controlar o acesso aos dados. As
necessidades dos usuários desempenham um papel central no processo de design. O
design de um ambiente de aplicativo de banco de dados completo que atenda às
necessidades de uma organização que está sendo modelada requer atenção a um
amplo conjunto de questões. Esses aspectos do uso esperado do banco de dados
in�uenciam as opções de design nos níveis físico, lógico e de visualização (ELMASRI;
NAVATHE, 2016).
Fases de Design
Para pequenas aplicações, pode ser viável, para um designer de banco de dados que
entende os requisitos desta aplicação, decidir diretamente sobre as relações a serem
criadas, seus atributos e restrições nas relações. No entanto, esse estilo de design
tona o processo difícil para aplicativos do mundo real, já que estes geralmente são
altamente complexos. Muitas vezes, ninguém entende as necessidades completas de
dados de um aplicativo. O designer de banco de dados deve interagir com os usuários
do aplicativo para entender tais necessidades da aplicação, representá-las de uma
forma que possa ser entendida pelos usuários e, em seguida, traduzi-la para os
requisitos do modelo de dados. Um modelo de dados de alto nível atende ao designer
de banco de dados com uma estrutura conceitual na qual se pode especi�car, de
maneira sistemática, os dados e requisitos dos usuários do banco de dados, além de
uma estrutura de banco de dados que atenda aos requisitos.
A fase inicial do design do banco de dados tem como objetivo caracterizar as
necessidades dos usuários do banco de dados em potencial. O designer de banco
de dados precisa interagir com especialistas de domínio e usuários para realizar
esta tarefa. O resultado desta fase é uma especi�cação dos requisitos do
usuário. Geralmente, esta especi�cação pode ser feita textualmente ou via
técnicas mais apropriadas (SILBERSCHATZ et al., 2019).
Em seguida, o designer escolhe um modelo de dados e, aplicando os conceitos do
modelo de dados escolhido, traduz esses requisitos em um esquema conceitual
para o banco de dados. O esquema desenvolvido nesta fase de projeto
conceitual fornece uma visão geral detalhada do problema que está sendo
resolvido. O modelo entidade-relacionamento, que estudaremos no restante
desta unidade é tipicamente usado para representar o design conceitual.
Declarado em termos do modelo entidade-relacionamento, o esquema
especi�ca as entidades que são representadas no banco de dados, o atributo
3
das entidades, as relações entre as entidades e as restrições nas entidades e
relacionamentos. Normalmente, a fase de projeto conceitual resulta na criação
de um diagrama entidade-relacionamento que fornece um grá�co de
representação do esquema. O designer revisa o esquema para con�rmar que
todos os requisitos de dados estão, de fato, satisfeitos e não estão em con�ito
um com os outros. Ele também pode examinar o design para remover quaisquer
recursos redundantes. Seu foco, neste momento, está em descrever os dados e
seus relacionamentos, em vez de especi�car detalhes de armazenamento
(ELMASRI; NAVATHE, 2016).
Um esquema conceitual totalmente desenvolvido também indica as exigências
funcionais da instituição. Em uma especi�cação de requisitos funcionais, os
usuários descrevem os tipos de operações (ou transações) que serão executadas
em os dados. Exemplos de operações incluem modi�cação ou atualização de
dados, pesquisa para e recuperar dados especí�cos e excluir dados. Nesta fase
de design conceitual, o projetista pode revisar o esquema para garantir que ele
atenda aos requisitos.
O processo de passar de um modelo de dados abstrato para a implementação
do banco de dados prossegue em duas fases �nais de projeto.
Na fase de design lógico, o projetista mapeia o modelo conceitual de alto nível
para o modelo de dados de implementação do sistema de banco de dados que
será usado. O modelo de dados de implementação é tipicamente o modelo
relacional modelo de dados e esta etapa, normalmente, consiste em mapear o
esquema de�nido usando o modelo de entidade-relacionamento em um
esquema de relação.
Finalmente, o designer usa o esquema de banco de dados especí�co do sistema
resultante na fase subsequente chamada de projeto físico, na qual as
características físicas do banco de dados são especi�cadas. Esses recursos
incluem a forma de arquivo ou organização e escolha de estruturas de índices
(SILBERSCHATZ et al., 2019).
O esquema físico de um banco de dados pode ser alterado com relativa facilidade
após a aplicação construída. No entanto, as alterações no esquema lógico são
geralmente mais difíceis de realizar, pois elas podem afetar várias consultas e
atualizações por meio do código do aplicativo. Portanto, é importante realizar o
4
banco de dados na fase de design com cuidado, antes de criar o restante do aplicativo
de banco de dados (ELMASRI; NAVATHE, 2016).
Alternativas de design
Uma parte importante do processo de design do banco de dados é decidir como
representar os vários tipos de “coisas” como pessoas, lugares, produtos e transações.
Usamos o termo entidade para nos referir a qualquer item distintamente
identi�cável. Em um banco de dados universitário, exemplos de entidades incluiriam
professores, alunos, departamentos, cursos e ofertas de cursos. As várias entidades
estão relacionadas uns com os outros em uma variedade de maneiras, todas as quais
precisam ser capturadas no banco de dados desenhar. Por exemplo, um aluno
frequenta um curso, enquanto um professor ensina um curso; ensinar e frequentar
ATENÇÃO
O modelo físico de um banco de dados se refere à tradução do modelo lógico em
uma linguagem de de�nição de dados. Nesse modelo, o tipo de dados, tamanhos,
restrições e demais elementos são considerados.
Fonte: 14.13.1 On-line... (s.d.).
5
são exemplos de relacionamentos entre entidades. Ao projetar um esquema de
banco de dados, devemos evitar duas grandes armadilhas:
1. redundância: um design ruim pode repetir informações. Por exemplo, se armazenar o
identi�cador do curso e o título de um curso com cada oferta de curso, o título seria
armazenado de forma redundante (ou seja, várias vezes, desnecessariamente) com cada
oferta de curso. Bastaria armazenar apenas o identi�cador do curso com cada oferta de
curso e associar o título ao identi�cador do curso apenas uma vez, em uma entidade
curso. Redundância também pode ocorrer em um esquema relacional. Na Universidade,
o exemplo que usamos até agora, temos uma relação com as informações da seção e
uma relação separada com a informação do curso. Suponha que em vez disso temos uma
relação única onde repetimos todas as informações do curso (curso id, título, nome do
departamento, créditos) uma vez para cada seção (oferta) do curso. Claramente, as
informações sobre os cursos seriam armazenadas de forma redundante. O maior
problema com essa representação redundante de informações é que as cópias de uma
informação podem se tornar inconsistentes se as informações forem atualizadas sem
tomar precauções para atualizar todas as cópias da informação. Por exemplo, ofertas
diferentes de um curso podem ter mesmo identi�cador de curso, mas podem ter títulos
diferentes. Dessa forma, não �caria claro o curso a ser selecionado. Idealmente, ainformação deve aparecer exatamente em um lugar;
2. incompletude: um mau design pode fazer certos aspectos da empresa difícil ou
impossível de modelar. Por exemplo, suponha que, como no caso anterior, tínhamos
apenas entidades correspondentes à oferta de cursos, sem uma entidade
correspondente aos cursos. Equivalente, em termos de relações, suponha que temos
uma relação única em que repetimos todas as informações do curso mação uma vez
para cada seção que o curso é oferecido. Seria, então, impossível representar
informações sobre um novo curso, a menos que é oferecido. Podemos tentar nos
contentar com o projeto problemático e os valores nulos para as informações da seção.
Tal solução não é apenas desinteressante, mas pode ser impedida por restrições de
chave primária.
Evitar projetos ruins não é su�ciente. Como um exemplo simples, considere um
cliente que compra um produto. A venda deste produto é uma relação entre o cliente
e o produto? Alternativamente, a venda em si é uma entidade que está relacionada
tanto ao cliente quanto para o produto? Esta escolha, embora simples, pode fazer
uma importante diferença em que aspectos da empresa podem ser bem modelados.
Considerando que precisa fazer escolhas como essa para um grande número de
entidades e relacionamentos em uma empresa do mundo real, não é difícil ver que o
design do banco de dados pode ser um problema desa�ador (ELMASRI; NAVATHE,
2016).
6
INFOGRÁFICO INTERATIVO
Para consultar o Infográ�co Interativo, 
acesse a versão digital deste material
SAIBA MAIS
Projetos de bancos de dados é uma área de grande relevância para a construção
de aplicações de software. Geralmente, são a base ou a estrutura de dados dessas
aplicações.
Fonte: Takai, Italiano e Ferreira (2005).
7
O Modelo de Relacionamento Entre
Entidades
O modelo de dados entidade-relacionamento (E-R) foi desenvolvido para facilitar o
projeto de um banco de dados, permitindo a especi�cação de um esquema
corporativo que representa a estrutura lógica de um banco de dados. O modelo E-R é
muito útil no mapeamento dos signi�cados e interações de empresas do mundo real
em um esquema conceitual. Devido a essa utilidade, muitas ferramentas de design de
banco de dados utilizam conceitos do modelo E-R. O modelo de dados E-R emprega
três conceitos básicos: conjuntos de entidades, conjuntos de relacionamentos e
atributos. O modelo E-R também possui uma representação diagramática associada,
o diagrama E-R, que estudaremos mais adiante neste capítulo. Em nossos estudos,
vamos utilizar uma ferramenta conhecida como MySQL Workbench.
SAIBA MAIS
O MySQL Workbench é uma excelente ferramenta para administração e projetos
de bancos de dados baseados no MySQL.
Para saber mais, acesse: http://bit.ly/2JuQtyM.
8
http://bit.ly/2JuQtyM
Conjuntos de Entidades
Uma entidade é uma “coisa” ou “objeto” no mundo real que se distingue de todos os
outros objetos. Por exemplo, cada pessoa em uma universidade é uma entidade. Uma
entidade tem um conjunto de propriedades que podem ser exclusivos identi�car a
mesma. Por exemplo, uma pessoa pode ter uma propriedade CPF cujo valor identi�ca
exclusivamente essa pessoa. Assim, o valor 110.120.130-90 para o CPF da pessoa
identi�ca de forma única uma pessoa na universidade. Da mesma forma, cursos
podem ser pensados como entidades, e ID do curso identi�ca exclusivamente uma
entidade de curso em uma universidade. Uma entidade pode ser concreta, como uma
pessoa ou um livro, ou pode ser abstrata, como um curso, uma oferta de curso ou uma
reserva de voo (ELMASRI; NAVATHE, 2016).
No processo de modelagem usamos o termo entidade sem referir-se a um conjunto
particular de entidades individuais. Uma entidade é representada por um conjunto
de atributos. Atributos são descritivos propriedades possuídas por cada membro de
um conjunto de entidades. A designação de um atributo para um conjunto de
entidades expressa que o banco de dados armazena informações semelhantes sobre
cada entidade no conjunto de entidades; no entanto, cada entidade pode ter seu
próprio valor para cada atributo. Possíveis atributos do conjunto de entidades
professor são ID, nome, nome do departamento e salário. Na vida real, haveria outros
atributos, como rua, número, número do apartamento, estado, código postal e país.
Possíveis atributos do conjunto de entidades do curso são id do curso, título, nome do
departamento e créditos. Cada entidade tem um valor para cada um dos seus
atributos. Por exemplo, uma determinada entidade professor pode ter o valor 100
para ID, o valor “JOAO” para NOME, o valor “COMPUTACAO” para o nome do
DEPARTAMENTO e o valor "5000" para o SALARIO.
O atributo ID é usado para identi�car professores com exclusividade, pois pode
existir mais de um com o mesmo nome. No Brasil, muitas empresas acham
conveniente usar o número do CPF social de uma pessoa como atributo cujo valor
identi�ca exclusivamente a mesma. Em geral, a empresa teria que criar e atribuir um
identi�cador único para cada professor. Um banco de dados inclui uma coleção de
conjuntos de entidades, cada um contendo qualquer número de entidades do mesmo
tipo. A Figura 1 mostra parte de uma universidade banco de dados que consiste em
dois conjuntos de entidades: professor e aluno. Para manter a �gura simples, apenas
alguns dos atributos dos dois conjuntos de entidades são mostrados. Um banco de
dados para uma universidade pode incluir vários outros conjuntos de entidades. Por
exemplo, além de acompanhar os professores e os alunos, a universidade também
possui informações sobre os cursos, que são representados pelo curso conjunto da
9
entidade com identi�cação do curso de atributos, título, nome do departamento e
créditos. Em um ambiente real, uma universidade banco de dados pode manter
dezenas de conjuntos de entidades.
Relacionamento entre entidades
Um relacionamento é uma associação entre várias entidades. Considere os dois
conjuntos de entidades professor e aluno da Figura 1. Nós de�nimos o
relacionamento “orienta” para denotar a associação entre professores e estudantes.
A Figura 2 mostra essa associação. Como outro exemplo, considere os dois conjuntos
de entidades aluno e seção. Podemos de�nir que o conjunto de relacionamento leva a
denotar a associação entre um aluno e as seções do curso em que o aluno está
matriculado. Um relacionamento posição em um esquema E-R representa uma
associação entre as entidades nomeadas em uma empresa do mundo real que está
sendo modelada. Como os conjuntos de entidades que participam de um
relacionamento são geralmente distintos, os papéis estão implícitos e geralmente
não precisam ser especi�cados. No entanto, eles são úteis quando o signi�cado de
um relacionamento precisa de esclarecimento. Tal é o caso quando a entidade de�ne
que um conjunto de relacionamento não é distinto; ou seja, o mesmo conjunto de
entidades participa de um relacionamento de�nido mais de uma vez, em diferentes
funções. Neste tipo de conjunto de relacionamento, às vezes chamado de conjunto de
Figura 1 - O conjunto de professores de uma universidade e o conjunto de alunos
Fonte: Adaptada de Silberschatz et al. (2019).
10
relacionamento recursivo, nomes de funções explícitos são necessários para
especi�car como uma entidade participa de uma instância de um relacionamento
(ELMASRI; NAVATHE, 2016).
Um relacionamento também pode ter atributos chamados atributos descritivos.
Considere um relacionamento com conjuntos de entidades professor e aluno.
Poderíamos associar a data do atributo a essa relação para especi�car a data em que
o professor tornou-se o orientador de um aluno. A Figura 3 mostra o orientador do
conjunto de relacionamentos com uma data de atributo descritiva.
Figura 2 - O relacionamento entre o conjunto de professores de uma universidade e o
conjunto de alunos 
Fonte: Adaptada de Silberschatz et al. (2019).
11
Note que João orienta dois alunos (Pedro e Paulo) com duas datas diferentes de
início. Uma instância de relacionamento em um determinado conjunto de
relacionamento deveser identi�cada de suas entidades participantes, sem utilizar os
atributos descritivos. Para entender esse ponto, suponha que queremos modelar
todas as datas em que um professor se tornou um orientador de um determinado
aluno. A data do atributo de valor único pode armazenar apenas uma data. Não
podemos representar várias datas por múltiplas relações entre o mesmo professor e
um aluno, uma vez que o relacionamento não seria exclusivamente identi�cável
usando apenas as entidades participantes. A maneira correta de lidar com esse caso é
criar uma data de atributo de vários valores, que pode armazenar todas as datas. É
possível ter mais de um conjunto de relacionamentos envolvendo o mesmo conjunto
de entidades. Além disso, suponha que cada aluno deve ter outro professor que atua
como orientador de departamento (Graduação ou Pós-Graduação). Então, os
conjuntos de entidades de professor e aluno podem participar de outro conjunto de
relacionamento, conselheiro de departamento.
Figura 3 - O relacionamento entre o conjunto de professores de uma universidade e o
conjunto de alunos com a data de orientação 
Fonte: Adaptada de Silberschatz et al. (2019).
12
Atributos
Para cada atributo, há um conjunto de valores permitidos, chamado domínio ou valor
conjunto, desse atributo. O domínio do ID do curso pode ser os valores entre 0 e 100.
Da mesma forma, o domínio do atributo semestre pode ser {outono, inverno,
primavera, verão}. Formalmente, um atributo de um conjunto de entidades é uma
função que mapeia a entidade de�nida em um domínio. Como um conjunto de
entidades pode ter vários atributos, cada entidade pode ser descrita por um conjunto
de pares (atributo, valor de dados), um par para cada atributo do conjunto de
entidades. Por exemplo, uma entidade professor pode ser descrita pelo conjunto {(ID,
1), (nome, João), (nome do departamento, Computação), (salário, 5000)}, signi�cando
que a entidade descreve uma pessoa chamada João cujo ID de professor é 1, que é
um membro do departamento de Computação com salário de R$ 5.000. Nós
podemos ver uma integração do esquema abstrato com o real sendo modelado. Os
valores de atributos que descrevem uma entidade constituem uma porção
ATENÇÃO
No modelo E-R, o R refere-se ao relacionamento. Isso é muito importante para
de�nir como um modelo de banco de dados deve trabalhar para alcançar os
objetivos propostos.
Fonte: Faria (2018).
13
signi�cativa dos dados armazenados no banco de dados. Um atributo, como usado no
modelo E-R, pode ser caracterizado pelos seguintes tipos de atributos (ELMASRI;
NAVATHE, 2016):
atributos simples e compostos. Em nossos exemplos até agora, os atributos
foram simples; isto é, eles não foram divididos em subpartes. Atributos
compostos, por outro lado, podem ser divididos em subpartes (isto é, outros
atributos). Por exemplo, um nome de atributo pode ser estruturado como um
atributo composto que consiste em primeiro nome e sobrenome. Atributos
compostos nos ajudam a agrupar atributos relacionados, tornando a
modelagem mais limpa. Note também que um atributo composto pode aparecer
como uma hierarquia. Na entidade Endereço, o atributo composto Rua pode ser
dividido no número da rua, nome da rua e número do apartamento (VANIER et
al., 2019). A Figura 4 mostra esses exemplos de atributos compostos para o
conjunto de entidades professor;
atributos de valor único e valor múltiplo. Os atributos em nossos exemplos têm
um valor único para uma entidade particular. Por exemplo, o atributo de ID do
aluno para uma entidade estudantil especí�ca, refere-se a apenas um ID de
estudante. Tais atributos são ditos de valor único. Pode haver casos em que um
atributo tem um conjunto de valores para uma entidade especí�ca. Suponha
que adicionemos à entidade professor um atributo de número de telefone. Um
professor pode ter zero, um ou vários telefones, e professores diferentes
podem ter diferentes números de telefones. Esse tipo de atributo é considerado
de valor múltiplo. Como outro exemplo, nós poderíamos adicionar à entidade
professor um atributo nome do dependente listando todos os dependentes.
Este atributo seria multivalorado, uma vez que qualquer professor pode ter
zero, um ou mais dependentes. Para denotar que um atributo é de valor
múltiplo, o colocamos entre chaves, por exemplo {número de telefone} ou {nome
dependente}. Quando apropriado, os limites superior e inferior podem ser
colocados no número de valores em um atributo multivalorado. Por exemplo,
uma universidade pode limitar os números de telefones gravados para um único
professor para dois. Colocação limites, neste caso, expressa que o atributo de
número de telefone do professor conjunto de entidades pode ter entre zero e
dois valores (VANIER et al., 2019);
atributo derivado. O valor para este tipo de atributo pode ser derivado dos
14
valores de outros atributos ou entidades relacionadas. Por exemplo, digamos
que o conjunto de entidades professor tem um atributo que os alunos
recomendaram, que representa como muitos alunos que um professor orienta.
Podemos derivar o valor para este atributo contando o número de entidades
estudantis associadas a esse professor. Como outro exemplo, suponha que o
conjunto de entidades professor tenha um atributo idade que indica a idade do
professor. Se o conjunto de entidades professor também tiver atributo data de
nascimento, podemos calcular a idade a partir da data de nascimento. Assim, a
idade é um atributo derivado. Neste caso, a data de nascimento pode ser
referida como um atributo base ou um atributo armazenado. O valor de um
atributo derivado é não armazenado, mas é calculado quando necessário.
Um atributo recebe um valor nulo quando uma entidade não possui um valor para
ele. O valor nulo pode indicar "não aplicável" - isto é, que o valor não existe para a
entidade. Por exemplo, um professor pode não ter nome do meio. Nulo também pode
designar que um valor de atributo é desconhecido (HOFFER et al., 2019). Um valor
desconhecido pode ser ausente (o valor existe, mas não temos essa informação) ou
não é conhecido (não sabemos se o valor realmente existe ou não). Por exemplo, se o
valor do nome de um professor for nulo, assumimos que o valor está faltando, já que
todo professor deve ter um nome. Um valor nulo para o atributo de número de
apartamento pode signi�car que o endereço não inclui um número de apartamento
(não aplicável), que existe um número de apartamento, mas nós não sei o que é (falta),
ou que não sabemos se é ou não o número do apartamento faz parte do endereço do
professor (desconhecido).
15
Restrições
Um esquema E-R pode de�nir certas restrições às quais o conteúdo de um banco de
dados deve estar em conformidade. Nesta seção, examinamos as restrições de
cardinalidades e restrições de participação.
Figura 4 - Exemplo de atributos compostos 
Fonte: Adaptada de Silberschatz et al. (2019).
16
Restrições de Cardinalidades
Mapeamento das cardinalidades expressam o número de entidades a qual outra
entidade pode ser associada mediante um conjunto de relacionamento. As
cardinalidades de mapeamento são mais úteis na descrição de conjuntos de
relacionamentos binários, embora possam contribuir para a descrição dos conjuntos
de relacionamento que envolvem mais de dois conjuntos de entidades (ELMASRI;
NAVATHE, 2016). Nesta seção, vamos nos concentrar apenas no conjunto de
relacionamento binário. Para um relacionamento binário R entre os conjuntos de
entidades A e B, o mapeamento cardinalidade deve ser um dos seguintes:
um a um. Uma entidade em A está associada com no máximo uma entidade em
B, e uma entidade em B está associada com no máximo uma entidade em A. (Ver
Figura 5a);
ATENÇÃO
Restrições devem ser consideradas em projetos de banco de dados para manter a
consistência dos dados ao longo do tempo.
Fonte: Salamon (s.d).
17
um para muitos. Uma entidade em A está associada a qualquer número (zero ou
mais) de entidades em B. Uma entidade em B, no entanto, pode ser associada
com no máximouma entidade em A. (Veja a Figura 5b);
muitos para um. Uma entidade em A está associada com no máximo uma
entidade em B. A entidade em B, no entanto, pode ser associada a qualquer
número (zero ou mais) de entidades em A. (Veja a Figura 5c);
muitos para muitos. Uma entidade em A está associada a qualquer número
(zero ou mais) de entidades em B, e uma entidade em B está associada a
qualquer número (zero ou mais) de entidades em A. (Veja a Figura 5d).
A cardinalidade de mapeamento apropriada para um conjunto de relacionamento
especí�co, obviamente depende da situação do mundo real em que o conjunto de
relacionamentos é modelado. Como exemplo, considere o conjunto de
relacionamentos do orientador. Se, em uma universidade, um estudante pode ser
aconselhado por apenas um professor, e um professor pode orientar vários alunos,
então o relacionamento de�nido de professor para aluno é um para muitos (HOFFER
et al., 2019). Se um aluno pode ser orientador por vários professores, o conjunto de
relacionamento é muitos para muitos.
Figura 5 - Exemplo de atributos compostos
Fonte: Adaptada de Silberschatz et al. (2019).
18
Restrições de participação
A participação de um conjunto de entidades E em um conjunto de relacionamento R é
considerada total se a entidade em E participa em pelo menos um relacionamento em
R. Se apenas algumas entidades em E participar de relacionamentos em R, a
participação do conjunto de entidades E no relacionamento R é dito parcial. Na
Figura 5a, a participação de B no conjunto de relacionamentos é total, enquanto a
participação de A no conjunto de relacionamentos é parcial. Na Figura 5b, a
participação de A e B no conjunto de relacionamentos é total. Por exemplo,
esperamos que cada entidade estudantil esteja relacionada a pelo menos um
professor por meio do relacionamento de orientação. Portanto, a participação do
estudante na orientação do conjunto de relacionamento é total. Em contraste, um
professor não precisa orientar estudantes. Portanto, é possível que apenas algumas
das entidades professor estejam relacionadas para a entidade estudante de�nida
mediante o relacionamento de orientação, e a participação do professor no conjunto
de relacionamento de orientação é, portanto, parcial.
Chaves
Devemos ter uma maneira de especi�car como as entidades dentro de um
determinado conjunto de entidades são distintas (HOFFER et al., 2019).
Conceitualmente, entidades individuais são distintas; de uma perspectiva de banco
de dados, no entanto, as diferenças entre eles devem ser expressas em termos de
atributos. Portanto, os valores dos atributos de uma entidade devem ser tais que eles
podem identi�car exclusivamente a entidade. A noção de uma chave para um
esquema E-R aplica-se diretamente para conjuntos de entidades. Ou seja, uma chave
para uma entidade é um conjunto de atributos que bastam para distinguir as
entidades umas das outras (ELMASRI; NAVATHE, 2016). Os conceitos de super
chave, chave candidata e chave primária são aplicáveis aos conjuntos de entidades.
As chaves também ajudam a identi�car relações de maneira única e, portanto,
distinguem relações entre si. A chave primária de um conjunto de entidades nos
permite distinguir entre as várias entidades do conjunto. Precisamos de um
mecanismo semelhante para distinguir entre os vários relacionamentos de um
conjunto de relacionamento.
19
As chaves em banco de dados desempenham um papel importante nos mais variados
cenários. Vamos estudar algumas delas com algum exemplo de como utilizá-las.
Chave. Uma ou mais colunas em uma tabela de banco de dados que é usada para
classi�car e/ou identi�car linhas em uma tabela. Por exemplo, se você estivesse
classi�cando as pessoas pelo salário de campo, então o campo de salário é a
chave.
Chave primária. Uma chave primária é um ou mais campos que identi�cam
exclusivamente uma linha em uma tabela. A chave primária não pode ser nula
(em branco) e a chave primária é indexada.
Chave estrangeira. Uma chave estrangeira é uma relação entre colunas em duas
tabelas de banco de dados (uma das quais é indexada) projetada para garantir a
consistência de dados. Por exemplo, cada registro em uma tabela CLIENTE
ATENÇÃO
O conceito de chave primária é muito importante para a modelagem de bancos
de dados. Sempre que possível, utilize uma chave natural no lugar de uma chave
arti�cial.
Fonte: Macário e Baldo (2005).
20
contém o ID do gerente de contas desse cliente. Na tabela GERENTE, o ID
normalmente seria a chave primária (indexada, exclusiva, não nula). O campo
GERENTE_FK na tabela CLIENTE é a chave estrangeira; somente valores para
GERENTE.ID serão permitidos no campo CLIENTE.GERENTE_FK.
Chave Primária Composta. Uma chave primária composta por uma ou mais
colunas, por exemplo, uma tabela chamada PESSOA contém os campos
PRIMEIRO_NOME e ULTIMO_NOME para o primeiro e último nomes,
respectivamente. A chave primária pode ser formada usando os campos
(embora não seja muito recomendável).
Chave natural. Uma chave primária composta que é composta por atributos
(campos) que já existem no mundo real. Por exemplo, o número do CPF no
Brasil.
Chave substituta. Uma chave primária que é gerada internamente  (geralmente
valor inteiro autoincremental) que não existe no mundo real, isto é, ID = 1 para
o Cliente A e ID = 2 para o Cliente B serve para identi�car exclusivamente o
registro, mas não tem o próprio cliente e é um atributo que eles nunca precisam
saber.
Chave candidata. Uma chave candidata é uma coluna ou um grupo de colunas
que podem identi�car exclusivamente uma linha na tabela sem se referir a
nenhuma outra fonte. Em uma tabela com várias chaves candidatas, uma é
selecionada para ser a chave primária, por exemplo, você pode ter uma tabela
EMPREGADO com uma chave candidata usando NOME e outra usando
DATA_NASCIMENTO.
Chave composta. Uma chave composta consiste em dois ou mais campos que
descrevem exclusivamente uma linha em uma tabela. A diferença entre
composto e candidato é que todos os campos da chave composta são chaves
estrangeiras; na chave candidata, um ou mais dos campos podem ser chaves
estrangeiras (mas não é obrigatório). Você pode ter uma tabela EMPREGADO
com uma chave candidata usando NUMERO_PASSAPORTE e outra usando CPF.
Na exclusão, ambos podem identi�car uma linha de maneira exclusiva. Qualquer
um pode ser usado como uma chave primária (mas não ambos, já que uma
tabela pode ter apenas uma chave primária).
21
QUESTÃO OBJETIVA
Projetos de bancos de dados podem ser desa�adores. Ao
projetar um esquema de banco de dados, devemos evitar
duas grandes armadilhas. Neste caso, qual seria uma delas?
Redundância.
Retrabalho.
Refactor.
Reindexação.
Redimensionamento.
22
QUESTÃO OBJETIVA
Atributos que podem ser divididos em subpartes (isto é,
outros atributos), por exemplo, um nome que consiste em
primeiro nome e sobrenome pode ser chamado de:
atributo simples.
atributo incorreto.
atributo valorado.
atributo composto.
atributo externo.
23
Fechamento
O maior benefício de um bom modelo de banco de dados para um projeto é manter a
consistência dos dados ao longo do tempo. Como vimos, isso pode ser feito via o
modelo E-R.
Nesta aula, você teve a oportunidade de:
ter uma visão geral do processo de design;
entender o modelo de relacionamento entre entidades;
aprender sobre restrições em bancos de dados.
24
Linguagens de De�nição de Dados
Quando temos a necessidade de projetar um banco de dados, alguns fundamentos
precisam ser conhecidos. Primeiramente, devemos entender qual a técnica de
modelagem a ser utilizada. Segundo, precisamos entender os tipos de dados que
podem ser mapeados do mundo real para o modelo. E, por �m, entender a qual
linguagem de de�nição de dados pode ser aplicada.
Ao �nal desta aula, você será capaz de:
entender a modelagem de dados utilizando o modelo entidade-relacionamento
(E-R);
aprender os tipos de entidade, conjuntos de entidades, atributos e chaves;
aprender sobre os tipos de relacionamento, conjuntosde relacionamento,
funções e restrições estruturais;
entender sobre a Data De�nition Language.
Aula 02
Introdução
25
Modelagem de Dados Utilizando o
Modelo Entidade-Relacionamento (E-
R)
A modelagem conceitual é uma fase muito importante na criação de um aplicativo de
banco de dados bem-sucedido. Geralmente, o termo aplicativo de banco de dados se
refere a um banco de dados especí�co e programas associados que implementam as
consultas e atualizações do banco de dados. Por exemplo, um aplicativo de banco de
dados UNIVERSIDADE que gerencia os professores e alunos para orientações de
programas de mestrados pode ser modelado via E-R. Esses programas fornecem
interfaces grá�cas de usuário fáceis de usar, utilizando formulários e menus.
Portanto, uma parte importante do aplicativo de banco de dados exigirá o design, a
implementação e o teste desses programas de aplicativos. Tradicionalmente, o design
e o teste de programas aplicativos foram considerados como parte da engenharia de
software, e não do design do banco de dados. Em muitas ferramentas de design de
software, as metodologias de design de banco de dados e as metodologias de
engenharia de software estão interligadas, uma vez que essas atividades estão
fortemente relacionadas.
26
Neste estudo, seguimos a abordagem tradicional de concentração nas estruturas e
restrições durante o design conceitual do banco de dados. O design de programas de
aplicação é tipicamente coberto em cursos de engenharia de software. Apresentamos
os conceitos de modelagem do modelo Entidade-Relacionamento (ER), que é um
popular modelo de dados conceitual de alto nível. Esse modelo e suas variações são
frequentemente usados para o design conceitual de aplicativos de banco de dados, e
muitas ferramentas de design empregam seus conceitos. Descreveremos os conceitos
básicos de estruturação de dados e restrições do modelo de ER e discutiremos seu
uso no projeto de esquemas conceituais para aplicações de banco de dados. Também
apresentaremos a notação diagramática associada ao modelo ER, conhecida como
diagrama ER.
Processo de design de banco de dados
SAIBA MAIS
O desenvolvimento de software tem uma intersecção com os projetos de bancos
de dados. O banco de dados acomoda as estruturas de dados enquanto o
software fornece as funcionalidades.
Saiba mais, acessando: http://bit.ly/2XKtML8.
27
http://bit.ly/2XKtML8
A Figura 1 mostra uma visão geral e simpli�cada do processo de design do banco de
dados. A primeira etapa mostrada é a de�nição e análise de requisitos. Durante essa
etapa, os projetistas de bancos de dados entrevistam usuários em potencial para
entender e modelar seus requisitos de dados. O resultado dessa etapa é um conjunto
de requisitos de usuários redigidos de forma concisa. Esses requisitos devem ser
especi�cados da maneira mais detalhada e completa possível. Paralelamente à
especi�cação dos requisitos de dados, é útil especi�car os requisitos funcionais
conhecidos da aplicação. Eles consistem em operações de�nidas pelo usuário (ou
transações) que serão aplicadas ao banco de dados, incluindo recuperações e
atualizações. No design de software, é comum usar diagramas de �uxo de dados,
diagramas de sequência, cenários e outras técnicas para especi�car requisitos
funcionais. Não vamos discutir nenhuma dessas técnicas aqui; eles são geralmente
descritos em detalhes em textos de engenharia de software.
Depois que os requisitos foram de�nidos e analisados, a próxima etapa é criar um
esquema conceitual para o banco de dados, usando um modelo de dados conceitual
de alto nível. Essa etapa é chamada de design conceitual. O esquema conceitual é uma
descrição concisa dos requisitos de dados dos usuários e inclui descrições detalhadas
dos tipos de entidade, relacionamentos e restrições; estes são expressos usando os
Figura 1 - Projeto de banco de dados e de aplicativo de banco de dados
Fonte: Adaptada de Silberschatz et al. (2019).
28
conceitos fornecidos pelo modelo de dados de alto nível. Como esses conceitos não
incluem detalhes de implementação, eles geralmente são mais fáceis de entender e
podem ser usados para se comunicar com usuários não técnicos. O esquema
conceitual de alto nível também pode ser usado como referência para garantir que os
requisitos de dados de todos os usuários sejam atendidos e que os requisitos não
entrem em con�ito. Essa abordagem permite que os designers de banco de dados se
concentrem na especi�cação das propriedades dos dados, sem se preocupar com
detalhes de armazenamento e implementação. Isso facilita a criação de um bom
design de banco de dados conceitual.
Durante ou após o design do esquema conceitual, as operações básicas do modelo de
dados podem ser usadas para especi�car as consultas e operações de alto nível do
usuário identi�cadas durante a análise funcional. Isso também serve para con�rmar
que o esquema conceitual atende a todos os requisitos funcionais identi�cados.
Modi�cações no esquema conceitual podem ser introduzidas se alguns requisitos
funcionais não puderem ser especi�cados usando o esquema inicial.
SAIBA MAIS
Um bom modelo de dados deve representar bem o minimundo. Além disso, deve
ter os tipos de dados precisos (como inteiros, datas, monetários etc.). Isso
melhora muito o projeto de modelo de banco de dados.
29
O próximo passo no design do banco de dados é a implementação real do banco de
dados, usando um SGBD comercial. A maioria dos SGBDs comerciais atuais usa um
modelo de dados de implementação - como o modelo de banco de dados relacional
ou objeto-relacional - para que o esquema conceitual seja transformado do modelo
de dados de alto nível para o modelo de dados de implementação. Essa etapa é
chamada de design lógico ou mapeamento de modelo de dados. Seu resultado é um
esquema de banco de dados no modelo de dados de implementação do SGBD. O
mapeamento de modelo de dados é geralmente automatizado ou semiautomatizado
nas ferramentas de design do banco de dados.
A última etapa é a fase de design físico, durante a qual as estruturas de
armazenamento interno, organizações de arquivos, índices, caminhos de acesso e
parâmetros de design físico para os arquivos de banco de dados são especi�cados.
Paralelamente a essas atividades, os programas aplicativos são projetados e
implementados como transações de bancos de dados correspondentes às
especi�cações de transações de alto nível.
Usando Modelos de Dados Conceituais de Alto Nível
para Design de Banco de Dados
Nesta seção, descreveremos um aplicativo de banco de dados de amostra,
denominado UNIVERSIDADE, que serve para ilustrar os conceitos básicos do modelo
ER e seu uso no design do esquema. Listamos os requisitos de dados para o banco de
dados aqui e, em seguida, criamos seu esquema conceitual passo a passo à medida
que introduzimos os conceitos de modelagem do modelo ER. O banco de dados da
UNIVERSIDADE gerenciar os professores, departamentos e alunos de uma
universidade. Suponha que após a fase de de�nição e análise de requisitos, os
projetistas do banco de dados forneçam a seguinte descrição do minimundo - a parte
da universidade que será representada no banco de dados.
A universidade é organizada em departamentos. Cada departamento tem um
nome exclusivo, um número exclusivo e um professor especí�co que gerencia o
departamento. Acompanhamos a data de início em que o professor começou a
gerenciar o departamento.
Um departamento pode ter vários locais.
Um departamento pode gerenciar vários professores, cada um com um nome
exclusivo e um número exclusivo.
30
A universidade tem o gerenciamento dos alunos com um número de matrícula
exclusivo e com o e-mail também exclusivo.
Cada aluno é orientado por um único professor e cada professor pode orientar
muitos alunos.
A orientação é acompanhada da data de início e, quando �nalizada, pela data de
encerramento.
A Figura 2 mostra como o esquema para esse aplicativo de banco de dados pode ser
exibido por meio da notação grá�ca conhecida como diagrama ER. Este valor será
explicado gradualmenteà medida que os conceitos do modelo ER forem
apresentados. Descrevemos o processo passo a passo de derivar este esquema dos
requisitos declarados - e explicar a notação diagramática do ER - à medida que
introduzimos os conceitos do modelo ER.
Figura 2 - Modelo de entidade-relacionamento do aplicativo
Fonte: Elaborada pelo autor.
31
Tipos de Entidade, Conjuntos de
Entidades, Atributos e Chaves
O modelo ER descreve os dados como entidades, relacionamentos e atributos. Na
Seção 2.1, introduziremos os conceitos de entidades e seus atributos. Discutiremos
os tipos de entidade e atributos-chave na Seção 2.2.
Entidades e Atributos
O objeto básico que o modelo ER representa é uma entidade, que é uma coisa no
mundo real com uma existência independente. Uma entidade pode ser um objeto
com uma existência física (por exemplo, uma determinada pessoa, carro, casa ou
professor) ou pode ser um objeto com uma existência conceitual (por exemplo, uma
universidade, um emprego ou um curso universitário). Cada entidade possui
atributos - as propriedades particulares que descrevem. Por exemplo, uma entidade
PROFESSOR pode ser descrita pelo nome, idade, endereço, salário e departamento.
Uma entidade particular, ou registro, terá um valor para cada um dos seus atributos.
Os valores de atributos que descrevem cada entidade tornam-se uma parte
importante dos dados armazenados no banco de dados.
32
Vários tipos de atributos ocorrem no modelo ER: simples versus composto, valor
único versus valor múltiplo e armazenado versus derivado. Os atributos compostos
podem ser divididos em subpartes menores, que representam atributos mais básicos
com signi�cados independentes. Atributos compostos são úteis para modelar
situações em que um usuário às vezes se refere ao atributo composto como uma
unidade, mas em outros momentos se refere especi�camente a seus componentes.
Se o atributo composto é referenciado apenas como um todo, não é preciso
subdividi-lo em atributos de componente. Por exemplo, se não houver necessidade
de se referir aos componentes individuais de um endereço (CEP, rua e assim por
diante), o endereço completo poderá ser designado como um atributo simples. Na
entidade ENDERECO optamos por um atributo composto para representar a rua
(NOME_RUA e NUMERO_RUA).
Adicionalmente, temos os atributos de valor único versus multivalorado. A maioria
dos atributos possui um valor único para uma entidade especí�ca; esses atributos são
chamados de valor único. Por exemplo, UF é um atributo de valor único de um
SAIBA MAIS
Sempre que possível evite atributos com valores nulos. Quando existir essa
necessidade, tente aplicar uma das formas normais. Valores nulos em banco de
dados trazem muitos problemas como tuplas espúrias e eventuais consultas com
agregações.
33
ENDERECO. Em alguns casos, um atributo pode ter um conjunto de valores para a
mesma entidade - por exemplo, um atributo Cores para um carro ou um atributo
Títulos para uma pessoa. Tais atributos são chamados de valores múltiplos. Um
atributo multivalorado pode ter limites inferiores e superiores para restringir o
número de valores permitidos para cada entidade individual. Por exemplo, o atributo
Cores de um carro pode ser restrito a ter entre um e três valores, se assumirmos que
um carro pode ter três cores no máximo. Em nosso modelo, os atributos são de
valores únicos.
Temos também os atributos armazenados versus derivados. Em alguns casos, dois (ou
mais) valores de atributos estão relacionados - por exemplo, os atributos IDADE e
DATA_NASCIMENTO de uma pessoa. Para uma entidade de pessoa especí�ca, o
valor de Idade pode ser determinado a partir da data atual (de hoje) e do valor da
data de nascimento dessa pessoa. O atributo IDADE é, portanto, chamado de um
atributo derivado e é dito derivável do atributo DATA_NASCIMENTO, que é
chamado de atributo armazenado. Alguns valores de atributos podem ser derivados
de entidades relacionadas; por exemplo, um atributo QUANTIDADE_PROFESSORES
ATENÇÃO
Grande parte dos atributos em bancos de dados são multivalorados. De�nir
limites superiores e inferiores para eles, via restrições, são uma boa prática.
34
de uma entidade DEPARTAMENTO pode ser derivado contando o número de
professores relacionados a (trabalhando para) este departamento.
Em alguns casos, uma entidade especí�ca pode não ter um valor aplicável para um
atributo. Por exemplo, o atributo DATA_ENCERRAMENTO de uma orientação se
aplica somente a orientações que estão concluídas. Para tais situações, um valor
especial chamado NULL é criado. O primeiro signi�cado do tipo NULL pode ser “não
é aplicável”, enquanto o segundo pode ser “desconhecido”. A categoria desconhecida
de NULL pode ser classi�cada em dois casos. O primeiro caso surge quando se sabe
que o valor do atributo existe, mas está ausente. O segundo caso surge quando não
se sabe se o valor do atributo existe.
Por �m, temos os atributos complexos. Observe que, em geral, os atributos
compostos e multivalorados podem ser aninhados arbitrariamente. Podemos
representar o aninhamento arbitrário agrupando componentes de um atributo
composto entre parênteses () e separando os componentes com vírgulas e exibindo
atributos de valores múltiplos entre chaves {}. Tais atributos são chamados de
atributos complexos. Por exemplo, se um professor tem mais de um endereço e cada
endereço tem vários telefones, um atributo ENDERECO_TELEFONE para uma
pessoa pode ser especi�cado como atributo complexo. Em nosso modelo não
utilizamos esse tipo de atributo.
Tipos de Entidades, Conjuntos de Entidades, Chaves
e Conjuntos de Valores
Um banco de dados geralmente contém grupos de entidades semelhantes. Por
exemplo, uma universidade que emprega centenas de professores pode querer
armazenar informações semelhantes sobre cada um deles. Essas entidades de
professores compartilham os mesmos atributos, mas cada entidade possui seus
próprios valores para cada atributo. Um tipo de entidade de�ne uma coleção (ou
conjunto) de entidades que possuem os mesmos atributos. Cada tipo de entidade no
banco de dados é descrito pelos seus nomes e atributos. A Figura 3 mostra dois tipos
de entidades: PROFESSOR e ALUNO, e uma lista de alguns dos atributos de cada um.
Algumas entidades individuais de cada tipo também são ilustradas, juntamente com
os valores de seus atributos. A coleção de todas as entidades de um determinado tipo
de entidade na base de dados em qualquer momento é chamada de conjunto de
entidades; o conjunto de entidades é geralmente referido usando o mesmo nome que
o tipo de entidade. Por exemplo, PROFESSOR refere-se a um tipo de entidade, bem
como ao conjunto atual de todas as entidades do professor no banco de dados.
35
Uma restrição importante nas entidades de um tipo de entidade é a restrição de
chave ou exclusividade nos atributos. Um tipo de entidade geralmente possui um ou
mais atributos cujos valores são distintos para cada entidade individual no conjunto
de entidades. Esse atributo é chamado de atributo-chave e seus valores podem ser
usados para identi�car cada entidade de maneira exclusiva. Às vezes, vários atributos
juntos formam uma chave, o que signi�ca que a combinação dos valores dos atributos
deve ser distinta para cada entidade. Se um conjunto de atributos possui essa
propriedade, a maneira correta de representá-lo no modelo E-R que descrevemos
aqui é de�nir um atributo composto e designá-lo como um atributo-chave do tipo de
entidade. Observe que essa chave composta deve ser mínima; ou seja, todos os
atributos do componente devem ser incluídos no atributo composto para ter a
propriedade unicidade. Atributos supér�uos não devem ser incluídos em uma chave.
Especi�car que um atributo como chave de um tipo de entidade signi�ca que a
propriedade de exclusividade anterior deve ser mantida para cada conjunto de
entidades do tipo de entidade. Portanto, é uma restrição que proíbe que duas
entidades tenham o mesmo valor para o atributo-chave ao mesmo tempo. Não é a
propriedade de um determinado conjunto de entidades;em vez disso, é uma
restrição em qualquer conjunto de entidades do tipo de entidade em qualquer
momento. Esta restrição chave (e outras restrições que discutiremos mais adiante) é
derivada das restrições do minimundo que o banco de dados representa.
Figura 3 - Atributos das entidades PROFESSOR e ALUNO
Fonte: Elaborada pelo autor.
36
Cada atributo simples de um tipo de entidade é associado a um conjunto de valores
(ou domínio de valores), que especi�ca o conjunto de valores que podem ser
atribuídos a esse atributo para cada entidade individual. Por exemplo, se a faixa de
idades permitidas para os alunos estiver entre 18 e 70, podemos especi�car o
conjunto de valores do atributo DATA_NASCIMENTO de ALUNO para ser o conjunto
de números inteiros resultantes entre 18 e 70. Da mesma forma, podemos
especi�car o conjunto de valores para o atributo NOME ser o conjunto de caracteres
alfabéticos separados por caracteres em branco e assim por diante. Conjuntos de
valores não são exibidos em diagramas E-R e são normalmente especi�cados usando
os tipos de dados básicos disponíveis na maioria das linguagens de programação,
como integer, string, boolean, �oat, tipo enumerado e assim por diante. Tipos de dados
adicionais para representar tipos comuns de banco de dados, como data, hora e
outros conceitos, também são empregados.
SAIBA MAIS
A utilização de restrições em atributos de bancos de dados é uma boa maneira de
manter a consistência do banco de dados.
Saiba mais, acessando: http://bit.ly/30DBAjN.
37
http://bit.ly/30DBAjN
Tipos de Relacionamento, Conjuntos
de Relacionamento, Funções e
Restrições Estruturais
Na Figura 2, existem vários relacionamentos implícitos entre os tipos de entidade. De
fato, sempre que um atributo de um tipo de entidade se refere a outro tipo de
entidade, existe algum relacionamento. Por exemplo, o atributo CURSO_FK de
ALUNO refere-se a um curso que o aluno participa; o atributo DEPARTAMENTO_FK
do PROFESSOR se refere ao departamento que gerencia o professor; e assim por
diante. No modelo E-R, essas referências não devem ser representadas como
atributos, mas como relações, que são discutidas nesta seção. No design inicial dos
tipos de entidade, os relacionamentos são tipicamente capturados na forma de
atributos. À medida que o design é re�nado, esses atributos são convertidos em
relacionamentos entre tipos de entidade.
38
Tipos de Relacionamento, Conjuntos e Instâncias
Um tipo de relacionamento R entre n tipos de entidades E1, E2, ..., En de�ne um
conjunto de associações (ou um conjunto de relacionamentos) entre entidades
desses tipos de entidade. Quanto ao caso de tipos de entidade e conjuntos de
entidades, um tipo de relacionamento e seu conjunto de relacionamentos
correspondente são costumeiramente referenciados pelo mesmo nome, R.
Informalmente, cada instância de relacionamento ri em R é uma associação de
entidades, onde a associação inclui exatamente uma entidade de cada tipo de
entidade participante. Cada instância de relacionamento ri representa o fato de que
as entidades participantes de ri estão relacionadas de alguma forma na situação do
minimundo correspondente. Por exemplo, considere um tipo de relacionamento
TRABALHA_PARA entre os dois tipos de entidade PROFESSOR e DEPARTAMENTO,
que associa cada professor ao departamento para o qual trabalha. Cada instância de
SAIBA MAIS
Um relacionamento de tabela é representado por uma linha de relacionamento
desenhada entre as tabelas na janela Relacionamentos. Um relacionamento que
não aplica a integridade referencial aparece como uma linha �na entre os campos
comuns que suportam o relacionamento.
Saiba mais, acessando: http://bit.ly/2SaGNfP.
39
http://bit.ly/2SaGNfP
relacionamento no conjunto de relacionamento TRABALHA_PARA associa uma
entidade PROFESSOR e uma entidade DEPARTAMENTO. A Figura 4 ilustra este
exemplo, onde cada instância de relacionamento ri é mostrada conectada às
entidades PROFESSOR e DEPARTAMENTO que participam de ri. No minimundo
representado pela Figura 4, os professores p1, p3 e p6 trabalham para o
departamento d1; professores p2 e p4 trabalham para o departamento d2; e os
professores p5 e p7 trabalham para o departamento d3.
4. Data De�nition Language
A seguir, podemos ver o script DDL gerado pelo nosso modelo. Esse script contém
alguns elementos especí�cos do banco de dados utilizados no estudo chamado
MySQL. Vamos ver o script linha a linha e entender o que está sendo feito em cada
situação.
DROP DATABASE UNIVERSIDADE;
Figura 4 - Exemplo de relacionamentos 
Fonte: Adaptada de Silberschatz et al. (2019).
40
CREATE DATABASE UNIVERSIDADE;
USE UNIVERSIDADE;
CREATE TABLE ENDERECO (
       ID INT NOT NULL PRIMARY KEY,
   NOME_RUA VARCHAR(50) NOT NULL,
   NUMERO_RUA VARCHAR(10) NOT NULL,
   CEP VARCHAR(8) NOT NULL,
   BAIRRO VARCHAR(50) NOT NULL,
   CIDADE VARCHAR(50) NOT NULL,
   UF CHAR(2) NOT NULL
) ENGINE=INNODB;
CREATE TABLE DEPARTAMENTO (
ID INT NOT NULL PRIMARY KEY,
   NOME VARCHAR(50) NOT NULL
) ENGINE=INNODB;
CREATE TABLE PROFESSOR (
ID INT NOT NULL PRIMARY KEY,
   NOME VARCHAR(50) NOT NULL,
   DEPARTAMENTO_FK INT NOT NULL,
ENDERECO_FK INT NOT NULL,
   FOREIGN KEY (DEPARTAMENTO_FK)
       REFERENCES DEPARTAMENTO(ID)
41
       ON DELETE CASCADE,
   FOREIGN KEY (ENDERECO_FK)
       REFERENCES ENDERECO(ID)
       ON DELETE CASCADE
) ENGINE=INNODB;
CREATE TABLE CURSO (
ID INT NOT NULL PRIMARY KEY,
   NOME VARCHAR(50) NOT NULL
) ENGINE=INNODB;
CREATE TABLE ALUNO (
ID INT NOT NULL PRIMARY KEY,
   NOME VARCHAR(50) NOT NULL,
   DATA_NASCIMENTO DATE NOT NULL,
   CURSO_FK INT,
   FOREIGN KEY (CURSO_FK)
       REFERENCES CURSO(ID)
       ON DELETE CASCADE
) ENGINE=INNODB;
CREATE TABLE ORIENTACAO (
PROFESSOR_FK INT,
ALUNO_FK INT,
   DATA_INICIO DATE,
42
   DATA_ENCERRAMENTO DATE,
   FOREIGN KEY (PROFESSOR_FK)
       REFERENCES PROFESSOR(ID)
       ON DELETE CASCADE,
   FOREIGN KEY (ALUNO_FK)
       REFERENCES ALUNO(ID)
       ON DELETE CASCADE
) ENGINE=INNODB;
A linguagem de consulta estruturada (SQL) é a linguagem de banco de dados que
podemos realizar determinadas operações no banco de dados existente e também
podemos usar essa linguagem para criar um banco de dados. O SQL usa certos
comandos como Criar, Descartar, Inserir etc., para executar as tarefas necessárias.
Esses comandos SQL são, principalmente, categorizados em quatro categorias,
conforme discutidas a seguir.
Figura 5 - Classi�cação dos comandos SQL
Fonte: Elaborada pelo autor.
43
A primeira categoria, chamada de DDL (Linguagem de De�nição de Dados) consiste
nos comandos SQL que podem ser usados para de�nir o esquema do banco de dados.
Ele simplesmente lida com descrições do esquema do banco de dados e é usado para
criar e modi�car a estrutura de objetos de banco de dados no banco de dados.
Exemplos de comandos DDL:
CREATE - é usado para criar o banco de dados ou seus objetos (como tabela,
índice, função, visualizações, procedimento de armazenamento e gatilhos).
DROP - é usado para excluir objetos do banco de dados.
ALTER - é usado para alterar a estrutura do banco de dados.
TRUNCATE - é usado para remover todos os registros de uma tabela, inclusive
todos os espaços alocados para os registros são removidos.
COMMENT - é usado para adicionar comentários ao dicionário de dados.
RENAME - é usado para renomear um objeto existente no banco de dados.
Os comandos DDL são muito úteis no início do projeto do banco, quando as
de�nições estão sendo feitas. Já na DML (Data Manipulation Language), os comandos
SQL que lidam com a manipulação de dados presentes no banco de dados pertencem
a DML ou Data Manipulation Language e isso inclui a maioria das instruções SQL.
Alguns exemplos de DML:
SELECT - é usado para recuperar dados do banco de dados.
INSERT - é usado para inserir dados em uma tabela.
UPDATE - é usado para atualizar os dados existentes em uma tabela.
DELETE - é usado para excluir registros de uma tabela de banco de dados.
Adicionalmente, a DCL (DataControl Language) inclui comandos como GRANT e
REVOKE, que lidam principalmente com os direitos, permissões e outros controles do
sistema de banco de dados. Alguns exemplos de comandos DCL:
GRANT - dá privilégios de acesso do usuário ao banco de dados.
REVOKE - retira os privilégios de acesso do usuário usando o comando GRANT.
44
A TCL (Transaction Control Language) lida com a transação dentro do banco de dados.
Alguns exemplos de comandos do TCL:
COMMIT - con�rma uma transação.
ROLLBACK - reverte uma transação no caso de ocorrer algum erro.
SAVEPOINT - de�ne um ponto de salvamento dentro de uma transação.
SET TRANSACTION - especi�ca características para a trans
SAIBA MAIS
A W3Schools apresenta uma classi�cação da SQL para o MySQL. Você pode
aprender mais no link a seguir.
Acesse: http://bit.ly/32lyrXi.
45
http://bit.ly/32lyrXi
QUESTÃO OBJETIVA
Uma fase muito importante na criação de um aplicativo de
banco de dados bem-sucedido é aquela que mapeia as
entidades do mundo real para um modelo. Esse modelo
tem o objetivo de relacionar as entidades uma com as
outras para entender como elas funcionam no mundo real.
Neste contexto, qual o nome dessa modelagem?
Modelagem conceitual.
Modelagem lógica.
Modelagem física.
Modelagem estrutural.
Modelagem comercial.
46
QUESTÃO OBJETIVA
Depois que os requisitos foram de�nidos e analisados, a
próxima etapa é criar um esquema para o banco de dados,
usando um modelo de dados de alto nível. Esse esquema é
uma descrição concisa dos requisitos de dados dos
usuários e inclui descrições detalhadas dos tipos de
entidade, relacionamentos e restrições. Qual o nome dessa
etapa?
Design alternativo.
Design arquitetural.
Design de modelo.
Design lógico.
Design conceitual.
47
Fechamento
O maior benefício ao se projetar um banco de dados é o entendimento de
fundamentos que possam ser aplicados em vários cenários. Primeiramente,
entendemos qual a técnica de modelagem a ser utilizada. Segundo, compreendemos
os tipos de dados que podem ser mapeados do mundo real para o modelo. E, por �m,
aprendemos a qual linguagem de de�nição de dados pode ser aplicada.
Nesta aula, você teve a oportunidade de:
aprender a modelagem de dados utilizando o modelo Entidade-Relacionamento
(E-R);
entender os tipos de entidade, conjuntos de entidades, atributos e chaves;
aprender sobre os tipos de relacionamento, conjuntos de relacionamento,
funções e restrições estruturais;
entender sobre a Data De�nition Language.
48
Linguagens de Manipulação e
Consulta de Dados
Recuperação de dados é uma parte fundamental de um bom projeto de banco de
dados. Dessa forma, utilizar boas técnicas de consulta pode ser um grande diferencial
no momento do projeto e da operação do banco de dados.
Ao �nal desta aula, você será capaz de:
entender a visão geral da linguagem SQL Query;
aprender sobre a estrutura básica de consultas SQL;
aprender sobre as consultas em uma única relação;
entender as consultas sobre Múltiplas Relações.
Aula 03
Introdução
49
Visão Geral da Linguagem SQL Query
Há um número de linguagens de consulta de banco de dados em uso, seja
comercialmente ou experimentalmente. Vamos estudar a linguagem de consulta
amplamente utilizada: Structured Query Language (SQL). Embora nos referimos à
linguagem SQL como uma “linguagem de consulta”, ela pode fazer muito mais do que
apenas consultar um banco de dados. Pode ser utilizada para de�nir a estrutura de
dados, modi�car dados no banco de dados e especi�car restrições de segurança. Não
é nossa intenção fornecer um guia completo para o SQL. Pelo contrário, nós vamos
apresentar construções e conceitos fundamentais da SQL. Implementações
individuais de SQL podem diferir em detalhes, ou podem suportar apenas um
subconjunto da linguagem completa (SILBERSCHATZ et al., 2019).
SAIBA MAIS
A linguagem de programação SQL foi desenvolvida pela primeira vez na década
de 1970 pelos pesquisadores da IBM Raymond Boyce e Donald Chamberlin. A
linguagem de programação, conhecida então como SEQUEL, foi criada após a
publicação do artigo de Edgar Frank Todd, "Um modelo relacional de dados para
grandes bancos de dados compartilhados", em 1970.
Saiba mais, acessando: http://bit.ly/2Jxu8kr.
50
http://bit.ly/2Jxu8kr
A IBM desenvolveu a versão original da SQL, originalmente chamada de Sequel,
como parte do Projeto System R no início dos anos 70. A linguagem Sequel evoluiu
desde então, e seu nome foi alterado para SQL (Structured Query Language). Muitos
produtos agora suportam a linguagem SQL. A SQL estabeleceu-se claramente como
padrão de linguagem de banco de dados relacional. Em 1986, o Instituto Nacional de
Padrões Americanos (ANSI) e a Organização Internacional de Normalização (ISO)
publicou um padrão SQL, chamado SQL-86. O ANSI publicou um padrão estendido
para SQL, SQL-89, em 1989. A próxima versão a partir da norma foi o padrão SQL-92,
seguido de SQL: 1999, SQL: 2003, SQL: 2006, e mais recentemente SQL: 2008. A
linguagem SQL possui várias partes (VANIER et al., 2019):
linguagem de de�nição de dados (DDL). A DDL fornece comandos para de�nir
esquemas de relação, excluindo relações e modi�cando esquemas de relação;
linguagem de manipulação de dados (DML). A DML fornece a capacidade de
consultar informações do banco de dados e inserir tuplas, excluir tuplas e
modi�car as tuplas no banco de dados;
integridade. A DDL inclui comandos para especi�car a integridade das
restrições que os dados armazenados no banco de dados devem satisfazer.
Atualizações que violam restrições de integridade não são permitidas;
controle de transações. A SQL inclui comandos para especi�car o início e �nal
de transações;
SQL incorporado e SQL dinâmico. SQL incorporado e dinâmico de�ne como as
instruções SQL podem ser incorporadas em linguagens de programação, como
C, C ++ e Java;
autorização. A DDL inclui comandos para especi�car direitos de acesso às
relações e pontos de vista.
Neste estudo, apresentamos uma pesquisa de DML básica e os recursos de DDL do
SQL. Os recursos descritos aqui fazem parte do padrão SQL desde o SQL-92.
Posteriormente, forneceremos uma cobertura mais detalhada da linguagem de
consulta SQL, incluindo (a) várias expressões de junção; (b) visões; (c) transações; d)
integridade das restrições; e) sistema de tipos; e (f) autorização. Embora a maioria
das implementações SQL suporte os recursos padrão, você deve estar ciente de que
existem diferenças entre a implementação. Por exemplo, um banco de dados como o
MySQL pode implementar de uma forma e o Oracle de outra (VANIER et al., 2019).
51
Linguagem de Manipulação de dados
A Linguagem de Manipulação de Dados (DML) é usada para recuperar, inserir e
modi�car informações do banco de dados. Esses comandos são usados por todos os
usuários do banco de dados durante a operação de rotina do banco de dados.
INSERT. O comando INSERT no SQL é usado para adicionar registros a uma
tabela existente. Por exemplo, imagine que nosso departamento de RH precisa
adicionar um novo professor ao banco de dados. Você poderia usar um
comando semelhante a este:
INSERT INTO PROFESSOR values('João','Silva',12345,5000);
Observe que há quatro valores especi�cados para o registro. Eles correspondem aos
atributos da tabela na ordem em que foram de�nidos.
SELECT. O comando SELECT é o comando mais usado no SQL. Ele permite que
os usuários do banco de dados recuperem as informações especí�cas que
desejam de um banco de dados operacional. Dê uma olhada em alguns
exemplos, novamente usando a tabela professor do banco de dados da
Figura 1 - Visão geral do SQL 
Fonte: Weerapat Wattanapichayakul / 123RF.
52
universidade. O comando mostrado, a seguir, recupera todas as informações
contidas na tabela PROFESSOR. Observe que o asterisco é usado como curinga
no SQL. Isso signi�ca literalmente "Selecione tudo na tabela professor".
SELECT * FROM PROFESSOR;
Como alternativa, os usuários podem querer limitar os atributos recuperados do
banco de dados. Por exemplo, o departamentode Recursos Humanos pode exigir
uma lista dos sobrenomes de todos os funcionários da empresa. O seguinte comando
SQL recuperaria apenas essa informação:
SELECT NOME FROM PROFESSOR;
A cláusula WHERE pode ser usada para limitar os registros recuperados àqueles que
atendem aos critérios especi�cados. O reitor pode estar interessado em revisar os
registros de pessoal de todos os professores altamente remunerados. O comando, a
seguir, recupera todos os dados contidos em PROFESSOR para registros que
possuem um valor de salário maior que $ 5.000:
SELECT * FROM PROFESSOR WHERE SALARIO > $5000;
53
UPDATE. O comando UPDATE pode ser usado para modi�car as informações
contidas em uma tabela, em massa ou individualmente. Suponha que a empresa
conceda a todos os funcionários um aumento de 3% no custo de vida do salário
anualmente. O seguinte comando SQL pode ser usado para aplicar isso
rapidamente a todos os funcionários armazenados no banco de dados:
UPDATE PROFESSOR SET SALARIO = SALARIO * 1.03;
Quando o novo funcionário, João Silva, demonstra um desempenho acima e além do
dever, a administração deseja reconhecer suas realizações estelares com um
aumento de $ 5.000. A cláusula WHERE poderia ser usada para destacar João para
este aumento:
UPDATE PROFESSOR SET SALARIO = SALARIO + 5000 WHERE ID = 12345;
SAIBA MAIS
O comando SELECT é um dos mais utilizados da SQL e dessa forma vale a pena
entender melhor o seu funcionamento. Existem várias cláusulas que podem ser
utilizadas neste comando.
Saiba mais, acessando: http://bit.ly/2JuoNu66.
54
http://bit.ly/2JuoNu6
DELETE. Finalmente, vamos dar uma olhada no comando DELETE. Você verá que
a sintaxe deste comando é semelhante a dos outros comandos DML.
Infelizmente, nosso último relatório de ganhos corporativos não atendeu às
expectativas e o João foi demitido. O comando DELETE com uma cláusula
WHERE pode ser usado para remover seu registro da tabela PROFESSOR:
DELETE FROM PROFESSOR WHERE ID = 12345;
Agora que você tem um contexto de como manipular os dados via DML, vamos
analisar esses comandos com mais detalhes a seguir.
SAIBA MAIS
O UPDATE possui algumas cláusulas que são comuns ao SELECT. Deve-se tomar
cuidado para não atualizar linhas que não sejam as desejadas.
Saiba mais, acessando: http://bit.ly/2YLvzRk.
55
http://bit.ly/2YLvzRk
De�nição de Dados SQL
O padrão SQL suporta uma variedade de tipos integrados. Esses tipos podem ser
utilizados para melhorar a modelagem do minimundo e, melhorando assim, a forma
como o banco de dados resolve o problema, incluindo:
char(n): uma cadeia de caracteres de comprimento �xo com comprimento
especi�cado pelo usuário n;
varchar(n): uma cadeia de caracteres de tamanho variável com o máximo
especi�cado pelo usuário comprimento n. A forma completa, com caráter
variável, é equivalente;
int: um inteiro (um subconjunto �nito dos inteiros que é dependente da
máquina). A forma completa, inteiro, é equivalente;
SAIBA MAIS
O DELETE possui algumas cláusulas que são comuns ao SELECT. Deve-se tomar
cuidado para não remover as linhas que não sejam as desejadas.
Saiba mais, acessando: http://bit.ly/2Si9g3q.
56
http://bit.ly/2Si9g3q
smallint: um inteiro pequeno (um subconjunto dependente da máquina do tipo
inteiro);
numeric(p, d): um número de ponto �xo com precisão especi�cada pelo usuário.
O número ber consiste em p dígitos (mais um sinal), e d dos p dígitos estão à
direita de o ponto decimal. Assim, numérico (3,1) permite que 44,5 sejam
armazenados exatamente, mas nem 444,5 ou 0,32 podem ser armazenados
exatamente em um campo desse tipo;
double: ponto �utuante e ponto �utuante de precisão dupla números com
precisão dependente da máquina;
�oat(n): um número de ponto �utuante, com precisão de pelo menos n dígitos.
SAIBA MAIS
Os tipos que podem ser utilizados para as colunas fazem com que os modelos de
dados possam ser melhor estruturados. Saiba quais são os tipos suportados pelo
banco que você está utilizando acessando: http://bit.ly/30u1uGj.
57
http://bit.ly/30u1uGj
Estrutura Básica de Consultas SQL
A estrutura básica de uma consulta SQL consiste em três cláusulas: select, from e
where. A consulta toma como entrada as relações listadas na cláusula from, opera
neles, conforme especi�cado nas cláusulas where e select, e produz uma relação como
resultado. Introduzimos a sintaxe SQL por meio de exemplos e descreveremos a
estrutura geral de consultas SQL mais tarde.
Consultas em uma Única Relação
Vamos considerar uma consulta simples usando nosso exemplo da universidade:
“Encontre os nomes de todos os professores”. Nomes de professores são
encontrados na relação professor, então colocamos essa relação na cláusula from. O
Figura 2 - Tipos de dados 
Fonte: Piotr Trojanowski / 123RF.
58
nome do professor aparece no nome atributo, então colocamos isso na cláusula
select.
SELECT `PROFESSOR`.`NOME`,
FROM `UNIVERSIDADE`.`PROFESSOR`;
O resultado é uma relação que consiste em um único atributo com o nome do
cabeçalho. E se a relação de professor é mostrada na Figura 1, então a relação que
resulta da consulta anterior é mostrada na Figura 2. Agora, considere outra consulta,
"encontre os nomes dos departamentos de todos os professores" que pode ser
escrito como:
SELECT
   `DEPARTAMENTO`.`NOME`
FROM `UNIVERSIDADE`.`PROFESSOR`
   INNER JOIN `UNIVERSIDADE`.`DEPARTAMENTO`
         ON `PROFESSOR`.`DEPARTAMENTO_FK` = `DEPARTAMENTO`.`ID`;
Como mais de um professor pode pertencer a um departamento, um nome de
departamento pode aparecer mais de uma vez na relação de professor. O resultado
da consulta é uma relação contendo os nomes dos departamentos, mostrada na
Figura 3. Na de�nição formal e matemática do modelo relacional, uma relação é um
conjunto. Assim, as tuplas duplicadas nunca apareceriam nas relações. Na prática,
duplicar a eliminação é demorada. Portanto, o SQL permite duplicatas em relações,
bem como nos resultados de expressões SQL. Assim, a lista resultante da consulta
SQL exibe o nome de cada departamento uma vez para cada tupla em que aparece o
nome do professor na relação (SILBERSCHATZ et al., 2019). Nos casos em que
queremos forçar a eliminação de duplicatas, inserimos a palavra-chave distinta
depois de selecionar. Podemos reescrever a consulta anterior como:
SELECT DISTINCT
       `DEPARTAMENTO`.`NOME`
FROM `UNIVERSIDADE`.`PROFESSOR`
   INNER JOIN `UNIVERSIDADE`.`DEPARTAMENTO`
59
         ON `PROFESSOR`.`DEPARTAMENTO_FK` = `DEPARTAMENTO`.`ID`;
Como a retenção duplicada é o padrão, não usaremos todos em nossos exemplos.
Para garantir a eliminação de duplicatas nos resultados de nossas consultas de
exemplo, devemos usar distinto sempre que necessário. A cláusula select também
pode conter expressões aritméticas envolvendo os operadores +, -, ∗ e / operando em
constantes ou atributos de tuplas. Por exemplo, a consulta:
SELECT
        `PROFESSOR`.`NOME`,
   `DEPARTAMENTO`.`NOME`,
       (`PROFESSOR`.`SALARIO_MENSAL`),
   (`PROFESSOR`.`SALARIO_MENSAL`)*1.1
FROM `UNIVERSIDADE`.`PROFESSOR`
   INNER JOIN `UNIVERSIDADE`.`DEPARTAMENTO`
        ON `PROFESSOR`.`DEPARTAMENTO_FK` = `DEPARTAMENTO`.`ID`;
Essa consulta retorna uma relação que é o mesmo que a relação de professor, exceto
o atributo salário que é multiplicado por 1.1. Isso mostra o que resultaria se
déssemos um aumento de 10% para cada professor; observe, entretanto, que isso
não resulta em nenhuma alteração na relação professor. A SQL também fornece tipos
de dados especiais, como várias formas do tipo de data, e permite que várias funções
aritméticas operem nesses tipos. A cláusula where nos permite selecionar apenas as
linhas na relação de resultados da cláusula from que satisfaz um predicado
especi�cado. Considere a consulta “encontre o nomes de todos os professores do
departamento de Ciência da Computação que têm salário maior que $ 70.000”. Esta
consulta pode ser escrita em SQL como:
SELECT
        `PROFESSOR`.`NOME`,
   `DEPARTAMENTO`.`NOME`,
        `PROFESSOR`.`SALARIO_MENSAL`
60
FROM`UNIVERSIDADE`.`PROFESSOR`
   INNER JOIN `UNIVERSIDADE`.`DEPARTAMENTO`
  ON `PROFESSOR`.`DEPARTAMENTO_FK` = `DEPARTAMENTO`.`ID`
WHERE `DEPARTAMENTO`.`NOME` = 'Computação'
   AND `PROFESSOR`.`SALARIO_MENSAL` > 7000;
Se a relação de professor é mostrada na Figura 1, então a relação que resulta da
consulta anterior é mostrada na Figura 4. O SQL permite o uso de conectivos lógicos
e/ou não no local onde há cláusula. Os operandos dos conectivos lógicos podem ser
expressões envolvendo os operadores de comparação <, <=,>,> =, = e <>. O SQL nos
permite usar os operadores de comparação para comparar strings e expressões
aritméticas, bem como tipos especiais, como tipos de data. Vamos explorar outras
características dos predicados da cláusula where mais adiante neste estudo.
Consultas sobre Múltiplas Relações
As consultas geralmente precisam acessar a informação de múltiplas relações. Um
exemplo: suponha que queremos responder à consulta “recuperar os nomes de todos
os professores, juntamente com seus nomes de departamento". Olhando para o
esquema da universidade, percebemos que podemos obter o nome do departamento
por meio da relação PROFESSOR. Para responder à consulta, cada tupla na relação
de professor deve ser correspondida com a tupla em relação ao departamento cujo
valor do nome do departamento corresponde ao valor do ID do departamento da
tupla de professor, chamada de DEPARTAMENTO_FK. No SQL, para responder à
consulta anterior, listamos as relações que precisam ser acessadas na cláusula from e
especi�cando a condição correspondente na cláusula where. A consulta anterior
pode ser escrita em SQL, como:
SELECT
        `PROFESSOR`.`NOME`,
   `DEPARTAMENTO`.`NOME`
FROM `UNIVERSIDADE`.`PROFESSOR`, `UNIVERSIDADE`.`DEPARTAMENTO`
WHERE `PROFESSOR`.`DEPARTAMENTO_FK` = `DEPARTAMENTO`.`ID`;
61
Restringindo tuplas com a cláusula Where
Uma cláusula WHERE ausente indica nenhuma condição na seleção da tupla;
portanto, todas as tuplas da relação especi�cada na cláusula FROM quali�cam e são
selecionadas para o resultado da consulta (SILBERSCHATZ et al., 2019). Se mais de
uma relação for especi�cada na cláusula FROM e não houver cláusula WHERE, o
produto cartesiano - todas as combinações de tupla possíveis - dessas relações serão
selecionadas. Por exemplo, a consulta a seguir seleciona todos os professores de
todos os departamentos associando cada professor a um departamento.
SELECT * FROM `UNIVERSIDADE`.`PROFESSOR`,
`UNIVERSIDADE`.`DEPARTAMENTO`
É extremamente importante especi�car todas as condições de seleção e associação
na cláusula WHERE; se qualquer dessas condições for negligenciada, podem resultar
relações incorretas e muito grandes. Se especi�carmos todos os atributos de
PROFESSOR e DEPARTAMENTO, obteremos o produto cartesiano real (exceto para
eliminação duplicada, se houver). Para recuperar todos os valores de atributos das
tuplas selecionadas, não precisamos listar os nomes de atributos explicitamente em
SQL; nós apenas especi�camos um asterisco (*), que signi�ca todos os atributos. Por
exemplo, a consulta anterior recupera todos os valores de atributo de qualquer
PROFESSOR que trabalhe em qualquer DEPARTAMENTO.
Tabelas como conjuntos no SQL
Como mencionamos anteriormente, o SQL geralmente trata uma tabela não como
um conjunto, mas como um multiconjunto; tuplas duplicadas podem aparecer mais
de uma vez em uma tabela e no resultado de uma consulta. O SQL não elimina
automaticamente as tuplas duplicadas nos resultados das consultas, pelos seguintes
motivos:
a eliminação duplicada é uma operação cara. Uma maneira de implementá-la é
classi�car as tuplas primeiro e depois eliminar as duplicatas;
o usuário pode querer ver tuplas duplicadas no resultado de uma consulta;
quando uma função agregada é aplicada a tuplas, na maioria dos casos, não
queremos eliminar duplicatas.
Uma tabela SQL com uma chave é restrita a ser um conjunto, uma vez que o valor da
chave deve ser distinto em cada tupla. Se quisermos eliminar as tuplas duplicadas do
resultado de uma consulta SQL, usamos a palavra-chave DISTINCT na cláusula
62
SELECT, signi�cando que apenas as tuplas distintas devem permanecer no resultado.
Em geral, uma consulta com SELECT DISTINCT elimina duplicatas, enquanto uma
consulta com SELECT ALL não. Especi�car SELECT sem ALL nem DISTINCT - como em
nossos exemplos anteriores - é equivalente a SELECT ALL. Por exemplo, na consulta
que recupera o salário de todos os funcionários, se vários funcionários tiverem o
mesmo salário, esse valor salarial aparecerá tantas vezes no resultado da consulta. Se
estivermos interessados apenas em valores salariais distintos, queremos que cada
valor apareça apenas uma vez, independentemente de quantos funcionários
recebem esse salário, usando a palavra-chave DISTINCT, conseguimos isso. O SQL
incorporou diretamente algumas das operações do conjunto da teoria dos conjuntos
matemáticos, que também fazem parte da álgebra relacional. Existem operações de
união (UNION), diferença de conjunto (EXCEPT) e interseção (INTERSECT). As
relações resultantes dessas operações de conjunto são conjuntos de tuplas; isto é, as
tuplas duplicadas são eliminadas do resultado. Essas operações de conjunto aplicam-
se apenas a relações compatíveis com o sindicato, portanto, devemos nos certi�car
de que as duas relações nas quais aplicamos a operação possuem os mesmos
atributos e que os atributos apareçam na mesma ordem em ambas as relações
(SILBERSCHATZ et al., 2019). O próximo exemplo ilustra o uso de UNION.
SELECT * FROM `UNIVERSIDADE`.`CURSO`
UNION ALL
SELECT * FROM `UNIVERSIDADE`.`DEPARTAMENTO`;
A primeira consulta SELECT recupera os cursos da universidade e o segundo recupera
os departamentos da mesma. Observe que apesar de serem entidades diferentes do
ponto de vista lógico, elas são idênticas do ponto de vista físico, ou sejam possuem as
mesmas colunas com a mesma tipagem. O SQL também possui operações multiset
correspondentes, que são seguidas pela palavra-chave ALL (UNION ALL, EXCEPT ALL,
INTERSECT ALL). Seus resultados são multisets (as duplicações não são eliminadas).
Basicamente, cada tupla - seja ela duplicada ou não - é considerada como uma tupla
diferente ao aplicar essas operações.
63
Correspondência de Padrões de Subconjunto e Operadores Aritméticos
Nesta seção, discutiremos vários outros recursos do SQL. O primeiro recurso
permite condições de comparação em apenas partes de uma cadeia de caracteres,
usando o operador de comparação LIKE. Isso pode ser usado para correspondência
de padrões de sequência de caracteres. Strings parciais são especi�cadas usando dois
caracteres reservados % que substitui um número arbitrário de zero ou mais
caracteres, e o sublinhado (_) substitui um único caractere. Por exemplo, considere a
seguinte consulta:
SELECT * FROM `UNIVERSIDADE`.`CURSO`
WHERE `CURSO`.`NOME` LIKE '%II%';
Ela recupera todos os cursos que tenham a sequência de caracteres “II” em qualquer
posição da coluna NOME. O operador LIKE pode ser aplicado no início, no �nal ou em
ambas partes da coluna. Existe ainda a possibilidade de aplicar em mais de um local,
por exemplo, a consulta a seguir.
SELECT * FROM `UNIVERSIDADE`.`CURSO`
WHERE `CURSO`.`NOME` LIKE '%Banco%II%';
Figura 3 - Tabelas em bancos de dados 
Fonte: Semisatch / 123RF.
64
Para recuperar todos os professores que tenham a sequência “ria” iniciando na
segunda posição da coluna NOME, podemos utilizar uma variação do operador LIKE,
como na consulta a seguir.
SELECT `ALUNO`.`ID`,
  `ALUNO`.`NOME`,
  `ALUNO`.`DATA_NASCIMENTO`,
  `ALUNO`.`CURSO_FK`
FROM `UNIVERSIDADE`.`ALUNO`
WHERE `ALUNO`.`NOME` LIKE '__ria';
SAIBA MAIS
A cláusula LIKE geralmente consome muito processamento e precisa de um
índice adequado para ela.
Saiba mais, acessando: http://bit.ly/2xGRSfc.
65
http://bit.ly/2xGRSfc
Se um sublinhado ou % for necessário como um caractere literal na string, o caractere
deve ser precedido por um caractere de escape, que é especi�cado após a string,
usando a palavra-chave ESCAPE. Por