aula 01 - banco de dados relacionais

Prévia do material em texto

Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
Aula 01 
2 Banco de dados relacionais. 2.1 Conceitos e 
características. 2.3 Tabelas, visões (views) e 
índices. 2.4 Chaves e relacionamentos 
Análise de Dados e Informações para o 
TCE RJ 
Prof. Arthur Mendonça 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Sumário 
TEORIA DA AULA .................................................................................................................................................... 3 
O MODELO RELACIONAL .................................................................................................................................................... 3 
Relações ........................................................................................................................................................................ 4 
Tuplas ............................................................................................................................................................................ 6 
Atributos ..................................................................................................................................................................... 10 
CHAVES ............................................................................................................................................................................ 15 
Chave Primária ............................................................................................................................................................ 16 
Chave Estrangeira ....................................................................................................................................................... 20 
RELACIONAMENTOS ......................................................................................................................................................... 23 
Modelando relacionamentos um para um (1:1) ........................................................................................................... 23 
Modelando relacionamentos um para muitos (1:N) .................................................................................................... 26 
Modelando relacionamentos muitos para muitos (M:N) ............................................................................................. 27 
Modelando autorrelacionamentos .............................................................................................................................. 30 
Modelagem de relacionamentos (Resumo) ................................................................................................................. 31 
INTEGRIDADE .................................................................................................................................................................. 33 
Categorias ................................................................................................................................................................... 34 
VIEWS (VISÕES) .................................................................................................................................................................. 36 
ÍNDICES ............................................................................................................................................................................. 39 
AS 12 REGRAS DE CODD .................................................................................................................................................... 43 
1) A regra da informação ............................................................................................................................................. 44 
2) A regra do acesso garantido .................................................................................................................................... 44 
3) Tratamento sistemático dos valores nulos ............................................................................................................... 45 
4) Catálogo online dinâmico baseado no modelo relacional ........................................................................................ 45 
5) Sublinguagem ampla/compreensiva de dados ........................................................................................................ 46 
6) Atualização de views ............................................................................................................................................... 46 
7) Inserção, atualização e exclusão de alto nível ......................................................................................................... 47 
8) Independência física de dados ................................................................................................................................. 47 
9) Independência lógica de dados ................................................................................................................................ 47 
10) Independência de integridade ............................................................................................................................... 48 
11) Independência de distribuição ............................................................................................................................... 48 
12) Regra da não subversão ou não transposição ........................................................................................................ 48 
ÁLGEBRA RELACIONAL ..................................................................................................................................................... 50 
NORMALIZAÇÃO ............................................................................................................................................................... 55 
Formas normais ........................................................................................................................................................... 55 
QUESTÕES COMENTADAS PELO PROFESSOR ...................................................................................................... 60 
LISTA DE QUESTÕES COMENTADAS ..................................................................................................................... 80 
GABARITO ............................................................................................................................................................ 90 
RESUMO DIRECIONADO ....................................................................................................................................... 91 
BIBLIOGRAFIA ......................................................................................................................................................94 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Teoria da Aula 
O Modelo Relacional 
 
Um banco de dados, como sabemos, é uma coleção de dados relacionados. Quando se trata de bancos de dados, 
algo que devemos ter em mente, é que esses sistemas podem ter diferentes organizações, a depender do modelo 
de SGBD adotado. Esse modelo está bem relacionado ao projeto lógico do banco de dados, já que esse projeto 
deve conter detalhes a respeito de como os dados estarão dispostos no SGBD. 
Há vários modelos de SGBDs existentes, como o hierárquico, o orientado a objetos, o modelo em rede e o 
relacional, que será o objeto da aula de hoje. Em cada um deles, os dados ficam organizados em estruturas com 
características distintas dos demais. 
 
 
Figura: Edgar Frank Codd, o criador do modelo relacional. Fonte: Wikipedia 
 
O modelo relacional foi introduzido por um americano chamado Ted Codd em 1970 e rapidamente ganhou 
popularidade, sendo hoje a opção mais tradicional quando se trata de armazenardados operacionais das 
organizações. 
Esse modelo de dados é relativamente simples tem uma forte fundação matemática, baseiando-se em coisas 
complicadas como teoria dos conjuntos e lógica de predicados para formalizar os seus conceitos básicos. Para fins 
de concurso (e para trabalhar com bancos de dados na prática), você não precisa entender completamente todos 
esses conceitos, então vamos procurar simplificar sempre que possível! 
Podemos dizer que o modelo relacional apresenta três elementos marcantes: 
 
Relações, estruturas similares a tabelas, que são as estruturas que armazenam os dados 
Restrições de integridade, que são o conjunto de regras que ditam o que essas tabelas podem conter e como 
elas se relacionam 
Operadores relacionais, que são operações matemáticas que servem de base para a manipulação e extração 
dos dados 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Nós iremos falar sobre todos esses elementos durante a aula de hoje. Vamos iniciar descrevendo o que é uma 
relação, a estrutura que dá o nome ao modelo relacional, e quais são seus componentes. 
Durante a aula, é importante que você se lembre que o modelo relacional é um modelo teórico que serve de base 
para a criação de bancos de dados relacionais. Assim, alguns aspectos e propriedades que iremos apresentar se 
aplicam ao modelo relacional (o modelo teórico, formal, matemático), mas não necessariamente aos SGBDs que 
se baseiam nesse modelo. Toda vez que ocorrer uma divergência entre teoria e prática, eu vou chamar sua atenção 
e explicar da melhor forma que puder! 
 
Relações 
Os bancos de dados relacionais são exemplos de coleções de dados estruturados. Isso acontece porque os dados 
estão armazenados em estruturas fixas, que seguem um esquema predefinido. No caso dos bancos de dados 
relacionais, essa estrutura é a relação. 
Um relação armazena dados que dizem respeito a um mesmo conceito ou entidade. Por exemplo, em uma relação 
chamada Pessoas, podemos ter vários dados que dizem respeito às pessoas que se quer representar no banco de 
dados. 
Podemos representar informalmente uma relação como uma tabela, ou seja, uma estrutura bidimensional 
composta por linhas e colunas. De fato, muitas provas de concurso não farão muita distinção entre os termos 
“relação” e “tabela”, então, salvo exceções, você poderá considerar ambos os termos como equivalentes. 
Quando colocamos a relação nesse formato de tabela, cada linha é chamada de tupla e cada coluna corresponde 
a um atributo. As tuplas irão caracterizar as ocorrências do que está sendo representado na relação, enquanto os 
atributos irão representar as características relativas a essa “coisa” que está sendo representada. 
Por exemplo, em uma tabela que representa pessoas, cada tupla diz respeito a uma pessoa e cada atribuito é uma 
característica das pessoas. É mais ou menos assim: 
 
Veja que é uma estrutura muito simples, parecida com uma planilha qualquer de dados. Imagino que você já tenha 
tido contato com tabelas em vários momentos da sua vida, não é? Por esse e outros motivos, o modelo relacional 
é tão popular, pois sua estrutura básica de armazenamento é familiar à maioria das pessoas. 
Como já falamos, o modelo relacional é baseado em fundações matemáticas, ou seja, ele pode ser definido em 
torno de conceitos e teorias dessa área. Formalmente falando, uma relação não é exatamente uma tabela, mas 
pode ser definida como um conjunto não ordenado de tuplas. Você deve memorizar essa definição, pois ela é 
cobrada em prova! 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
Atenção! Uma relação é um conjunto não ordenado de tuplas 
 
Vamos pensar só um pouco sobre essa definição, pois isso vai te ajudar a entender algumas propriedades que 
veremos mais para frente. Na matemática, um conjunto é uma coleção de elementos distintos. Esses elementos 
podem ser qualquer coisa, como números, letras, formas ou até mesmo outros conjuntos. 
 
Figura: Representação de um conjunto de formas geométricas. Fonte: Wikipedia 
Em um conjunto, os seus elementos não estão ordenados de nenhuma forma. Dessa maneira, se temos dois 
conjuntos com os mesmos elementos dispostos de forma diferente um do outro, eles podem ser considerados o 
mesmo conjunto. Ou seja, se temos o conjunto de números A = {1, 2, 3} e o conjunto B = {3, 2, 1}, podemos dizer 
que A e B são iguais, já que têm os mesmos elementos (os valores 1, 2 e 3). 
 
Como já dissemos, uma relação é nada mais nada menos que um conjunto em que seus elementos são as tuplas. 
Nesses conjuntos, a ordem dos elementos não é importante. O mesmo acontece nos SGBDs que adotam o modelo 
relacional: a ordem das linhas de uma tabela do banco de dados não é relevante. 
Assim, você pode consultar os dados de uma mesma tabela em vários ordenamentos diferentes, mas a tabela 
continua sendo a mesma. Por exemplo, uma tabela de Pessoas pode ter seus dados ordenados por ordem 
alfabética de nomes, por ordem de idade, por ordem alfabética de sua cidade, dentre outras possibilidades. 
Dessa introdução podemos concluir o seguinte: 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 ➔ As relações são as estruturas que armazenam dados no modelo relacional, geralmente representadas 
como tabelas em provas e nos SGBDs 
➔ Uma relação pode ser definida formalmente como um conjunto não ordenado de tuplas distintas 
entre si 
➔ Como conjuntos não seguem nenhuma ordenação específica, duas relações compostas pelo mesmo 
conjunto de tuplas serão sempre a mesma relação, independentemente da maneira com que suas 
tuplas são ordenadas 
 
Você pode ter percebido que as relações em um modelo lógico relacional costumam ser representações das 
entidades do modelo conceitual. No modelo conceitual que deu origem ao modelo da tabela de exemplo mais 
acima, muito provavelmente havia uma entidade chamada Pessoa, com os atributos CPF, Nome, Data de 
Nascimento e Cidade. 
No entanto, é importante que você saiba que essa correspondência entre entidade do modelo conceitual e 
relação no modelo lógico relacional não é uma correspondência exata. No processo de transformação do 
modelo conceitual em um modelo lógico, pode haver a criação de tabelas que não estavam previstas como 
entidades no modelo conceitual e determinadas entidades que existiam no modelo conceitual podem não ser 
representadas em uma tabela própria no modelo relacional. 
Há uma série de técnicas envolvidas nessa transformação do projeto conceitual em lógico que vão ditar como 
esse processo vai acontecer. Nós veremos algumas delas na aula de hoje! 
 
Tuplas 
Acabamos de definir que uma relação é um conjunto não ordenado de tuplas. Agora nos resta definir formalmente 
o que são essas tuplas. Para continuar as nossas explicações, vamos considerar novamente a relação de exemplo 
que trouxemos anteriormente: 
 
Quando representamos a relação nesse formato de tabela, cada uma das tuplas fica disposta em uma linha da 
tabela. Essas linhas são frequentemente chamadas de “registros” quando estamos falando do contexto mais 
prático do banco de dados, do SGBD mesmo, e não apenas do modelo formal. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Então veja que temos três tuplas nesse nosso exemplo. A primeira traz dados a respeito da pessoa chamada “José 
da Silva”, a segunda a respeito de “Maria do Carmo” e a terceira de “João Cavalcante”. Todos os dados em uma 
mesma linha (o CPF, o Nome, a Data de Nascimento e a Cidade) pertencem a uma mesma pessoa. 
Formalmente, as tuplas podem ser definidas como sendo os conjuntos de valores de atributos que compõem 
uma relação. Se fôssemos organizar essas tuplas da relação acima no formato de conjunto, ficaria da seguinte 
maneira: 
 
Tupla 1 = {CPF: 204.776.124-22, Nome: José da Silva, Dt.Nascimento: 01/05/1990, Cidade: Rio de Janeiro}. 
Tupla 2 = {CPF: 123.980.771-15, Nome: Maria do Carmo, Dt. Nascimento: 20/02/1985, Cidade: São Paulo} 
Tupla 3 = {CPF: 450.689.123-04, Nome: João Cavalcante, Dt. Nascimento: 07/10/1979, Cidade: Recife} 
 
Note que uma tupla, a exemplo de uma relação, também é um conjunto. Isso implica dizer que as propriedades 
dos conjuntos também se aplicam às tuplas. As propriedades das tuplas que costumam ser cobradas em prova são 
aquelas definidas por um autor chamado C.J. Date, que também participou da elaboração e desenvolvimento do 
modelo relacional junto com Codd. Elas são as seguintes: 
Memorize essas propriedades, pois elas costumam ser cobradas em concursos. Vamos ver questões que tratam 
delas, mas antes você vai me permitir fazer alguns comentários sobre cada uma delas, para que você possa 
compreender melhor o espírito de cada uma: 
 
1) Toda tupla tem somente um valor para cada um de seus atributos 
 
Figura: Tupla representada em um SGBD relacional 
A primeira propriedade é a propriedade da atomicidade dos atributos, que diz que cada tupla tem um só valor 
por atributo. Isso quer dizer, por exemplo, que uma pessoa representada em uma só tupla da nossa relação de 
exemplo não poderia ter dois CPFs ou dois nomes, nem ter uma ausência de valor para sua cidade ou data de 
nascimento. Cada tupla tem exatamente um valor para os atributos, nem mais nem menos. Vamos ver algumas 
implicações desta propriedade durante a aula de hoje! 
 
2) Não há ordenação da esquerda pra direita nos componentes de uma tupla. 
Em relação à segunda característica, a que trata da ordenação dos componentes de uma tupla, você já conhece a 
propriedade dos conjuntos matemáticos de não terem ordenação entre seus valores, não é? Assim, no modelo 
relacional formal (teórico), realmente não haverá ordenação dentro dos componentes das tuplas. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
 
* Olha a divergência: na prática, a história é outra. Por razões práticas, a ordem das colunas definidas em um 
SGBD tem uma certa relevância. Por exemplo, determinados comandos da linguagem SQL, a linguagem de 
programação utilizada para interagir com os SGBDs relacionais, vão ter comportamentos diferentes de acordo 
com a ordem em que as colunas da tabela foram definidas. 
Nesse caso, você deve sempre avaliar o contexto da questão. Se está falando de “ordenação de componentes de 
uma tupla”, o examinador está tratando da teoria, do modelo relacional formal, então é seguro marcar que não há 
ordenação. Já se ele vier falar de “colunas de uma tabela” ou de “SGBD”, você vai ver que se trata da prática, então 
há sim uma certa relevância na ordem das colunas. Veja a questão a seguir que expõe essa divergência: 
(CESPE – TCE/PE – 2017) 
Acerca de aspectos diversos referentes a banco de dados relacional, julgue o item a seguir. 
Em uma relação, os nomes das colunas são únicos, as linhas são distintas entre si, e a ordem da disposição das 
linhas e colunas é irrelevante para o banco de dados. 
RESOLUÇÃO: 
Essa foi a prova em que fui aprovado! O gabarito inicial dessa questão dava o item como certo. Devido à parte que 
diz que a ordem das colunas é irrelevante para o BD, discordei, entrei com recurso e o gabarito terminou sendo 
alterado. 
Na prática, quando estamos criando uma tabela, a definimos com uma determinada ordem de colunas. 
Se realizarmos uma consulta nessa tabela sem explicitar que ordem queremos, as linhas ou registros poderão ser 
retornados numa ordem qualquer. Contudo, a ordem das colunas sempre virá na ordem que foi inicialmente 
definida, a não ser que o usuário explicitamente “peça” algo de diferente. 
A ordem das colunas também traz algumas implicações para operações de inserção de dados em tabelas e para 
alguns aspectos técnicos de otimização do SGBD, cujos detalhes estão fora do escopo do nosso curso. De todo 
modo, entenda que a ordem das colunas não é completamente irrelevante. 
C.J. Date aponta que a maioria dos SGBDs utilizam o nome da coluna para acessar diretamente o valor do atributo, 
então a importância da ordem com que esses atributos foram definidos é minimizada. É verdade, mas como o 
examinador disse na questão que tal ordem é irrelevante para o BD, isso é a mesma coisa que dizer que em 
nenhum cenário há influência da ordem das colunas. Como vimos, isso está incorreto. 
Gabarito: E 
 
 
 
Modelo formal
• Sem ordem nos 
componentes da tupla
Prática nos SGBDs
• Ordem das colunas de uma 
tabela tem relevância
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 3) Todo subconjunto de uma tupla é uma tupla 
Em relação à terceira propriedade, não há grandes comentários a se fazer. Ela somente diz que se você extrai 
somente um determinado subconjunto de elementos de uma tupla, esse subconjunto também é considerado uma 
tupla. Só que isso não faz muito sentido na prática, então essa propriedade não tem muito efeito em SGBDs. 
 
4) O grau de uma tupla varia de 0 – n 
Por fim, a quarta propriedade trata da propriedade do grau das tuplas, que é dado pela quantidade de elementos 
que a compõem. Como cada tupla de uma relação tem exatamente um valor para cada atributo da relação, o grau 
da tupla e o grau da relação é o mesmo. Por exemplo, a nossa relação de exemplo chamada “Pessoas” tem quatro 
atributos, então suas tuplas também terão quatro valores. O grau das tuplas e da relação será quatro. 
 
* Olha a divergência: C.J. Date diz que o grau de uma tupla pode variar de 0 a N, ou seja, uma tupla pode não ter 
nenhum valor. Isso vale para o modelo relacional formal, só que isso não faz sentido algum na prática, pois se uma 
tabela de um SGBD não tem nenhuma coluna, ela não pode conter nenhum dado. E de que nos serve uma tabela 
que não contém dados, não é mesmo? 
Por esse motivo, na prática os SGBDs não costumam permitir que se crie uma tabela sem que ela tenha pelo 
menos uma coluna. Essa divergência não costuma muito ser explorada em prova, então só fique ciente que ela 
existe e adote o seguinte entendimento: se a questão perguntar se o “grau de uma tupla pode variar de 0 a N”, 
você pode considerar o item correto. Se perguntar se existem “tabelas sem colunas em um SGBD”, você pode 
considerar incorreto. 
Resumindo as quatro propriedades pra você: 
• Toda tupla contém exatamente um valor para cada um de seus atributos. 
• Não há ordenação da esquerda pra direita nos componentes de uma tupla. * 
• Todo subconjunto de uma tupla é uma tupla. 
• O grau de uma tupla varia de 0 – n. O grau é a quantidade de atributos que compõem a tupla. * 
 
 
 
 
 
Modelo formal
• Grau de uma tupla 
varia de 0 a N
Prática nos SGBDs
• Não faz sentido existir 
tabela sem nenhuma 
coluna
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Atributos 
 
 
Figura: Lista de colunas de uma tabela em um SGBD 
 
Bem, tendo em mente que uma relação é um conjunto não ordenado de tuplas e uma tupla é um conjunto dos 
valores dos atributos, resta falarmos um pouco mais a respeito sobre esse último elemento, os atributos. 
Cada atributo em uma relação tem um nome único. Isso implica dizer que não podemos ter duas colunas em uma 
mesma tabela com o mesmo nome em um SGBD relacional. O motivo é muito tranquilo de se entender, pois em 
um SGBD sempre fazemos referência a um atributo pelo seu nome. 
Por exemplo, quando você vai consultar dados em um SGBD relacional através da linguagem SQL, você precisa 
dizer ao SGBD qual ou quais atributos da tabela em questão você quer ter acessados. Então você constrói um 
comando que diz algo como “me retorne o valor do atributo CPF para a pessoa José da Silva” ou “retorne o valor 
do atributo Data de Nascimento para a pessoa Maria do Carmo”. 
Nesse cenário, se você tivesse dois atributos chamados CPF ou Data de Nascimento dentrode uma mesma 
relação, o SGBD não iria saber qual dos dois retornar. Não há problema, no entanto, em atributos de relações 
diferentes terem o mesmo nome entre si. 
Vamos agora ver quais são alguns tipos de atributos existentes que têm algumas particularidades na hora de 
representar em um SGBD relacional. 
Atributos opcionais 
 
 
Figura: Valores NULL nos resultados de uma consulta em um SGBD 
 
Quando estudamos a modelagem conceitual, observamos que existe um tipo de atributo considerado opcional, 
ou seja, aquele atributo que não precisa ter um valor para todas as ocorrências da entidade. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Em um SGBD relacional, se um determinado atributo como Data de Nascimento da tabela Pessoa é opcional, 
isso significa que nem toda pessoa representada nessa tabela precisa ter um valor para esse atributo. Algumas 
pessoas, portanto, podem simplesmente não informar a data de nascimento no ato do seu cadastro nessa base. 
Só que você viu nas propriedades das tuplas que cada tupla tem exatamente um valor para cada atributo, não é? 
Isso pode ter te causado algumas dúvidas a respeito de como faremos para representar aqueles atributos que são 
opcionais e não tem valores. 
A resposta é a existência de um valor especial, o valor nulo, ou NULL. Um valor nulo é um valor especial, que não 
tem nenhum tipo de dados (ou seja, não podemos dizer que ele é um atributo textual, numérico, de data ou etc.) 
e que representa basicamente uma ausência de valor. 
Toda vez que tivermos o caso em que um atributo é opcional e precisamos representar essa ausência de valor 
para algum registro, não vamos simplesmente deixar esse campo em branco, já que toda tupla deve ter 
exatamente um valor para cada atributo. Devemos utilizar esse valor NULL! 
 
Atributos multivalorados 
 
 
 
No modelo conceitual, atributos multivalorados são aqueles que possuem mais de um valor para uma mesma 
ocorrência da entidade. Para exemplificar esse tipo de cenário, comumente se usa o exemplo do atributo telefone, 
pois é comum que uma mesma pessoa tenha múltiplos números de telefone associados. 
Só que por culpa da propriedade da atomicidade dos atributos, nós não podemos representar em uma mesma 
tupla os vários valores de um atributo multivalorado, já que cada tupla só tem um valor por atributo. Em um SGBD, 
na prática, é a mesma coisa, não tem como você ter mais de um valor para uma mesma coluna em uma mesma 
linha de uma tabela. 
Na prática, a representação de um atributo multivalorado requer que se crie uma tabela auxiliar para guardar os 
múltiplos valores desse atributo, criando-se um relacionamento para ligar essa tabela auxiliar com a tabela 
original. O modelo lógico ficaria mais ou menos assim: 
 
 
Figura: Representação de um modelo lógico com ligação entre a tabela Pessoas e a tabela Telefones 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Nesse relacionamento, uma mesma pessoa pode ter nenhum ou vários telefones associados, enquanto um 
telefone está associado a exclusivamente uma pessoa. Essa ligação que representa os relacionamentos, nos 
SGBDs relacionais, é realizada por algum atributo que tenha valores em comum entre as duas tabelas. 
No caso desse exemplo, o campo CPF Pessoa na tabela Telefones irá conter o valor do CPF da pessoa à qual aquele 
telefone corresponde. Veja um exemplo de dados nessa tabela: 
 
id CPF Pessoa Cod. Área Telefone Tipo do Telefone 
1 123.980.771-15 11 2020-1010 Comercial 
2 123.980.771-15 11 99123-4567 Celular 
3 450.689.123-04 81 3756-4321 Residencial 
 
Observe, então, que um mesmo cliente (identificado pelo seu CPF) pode possuir mais de um telefone, mas sem 
que isso quebre a regra da atomicidade, pois cada número está registrado em uma linha diferente dessa nova 
tabela. 
Quando precisarmos consultar o(s) número(s) de telefone de uma determinada pessoa, é só procurarmos pelo seu 
CPF na tabela de telefones, que serão retornados todos os números correspondentes. 
 
Atributos compostos 
Além dos atributos multivalorados, existem os atributos compostos, que são aqueles que são compostos por várias 
partes distintas. O exemplo mais comum desse tipo de atributo é o endereço, que costuma poder ser dividido em 
partes como logradouro, número, complemento, cidade, etc. 
Nos SGBDs, o que se costuma fazer é armazenar já essas partes individuais em que o atributo composto pode ser 
dividido, cada uma como um atributo separado. Essa característica se deve a um processo que os modelos lógicos 
passam, chamado normalização, mas vamos falar sobre isso depois! 
O atributo endereço, por exemplo, poderia ficar representado da seguinte maneira, separado em quatro partes: 
 
CPF Pessoa Logradouro Número Complemento CEP 
204.776.124-22 Av. Paulista 1578 Bloco B 01311-929 
450.689.123-04 Av. Cais do Apolo 925 NULL 50030-908 
123.980.771-15 Rua Afonso Cavalcanti 455 Sala 10 20211-200 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Uma curiosidade é que um atributo pode ser ao mesmo tempo composto e multivalorado, nada impede que isso 
aconteça. 
 
Domínio 
 
 
Figura: Representação de restrição sobre o tipo de dados de um atributo 
 
Um detalhe em relação aos atributos, é que são definidas regras que ditam os valores que eles podem assumir. 
Uma regra que precisa ser definida para todos os atributos em um SGBD relacional é o tipo de dados. O tipo é 
uma restrição que indica qual é a natureza do dado, por exemplo, se ele é um número inteiro, número decimal, 
cadeia de caracteres, data, dentre outras possibilidades. 
Dica: Atributos textuais geralmente são do tipo cadeia de caracteres, geralmente chamado de VARCHAR ou 
CHAR nos SGBDs. Uma cadeia de caracteres é simplesmente um conjunto de caracteres alfanuméricos, ou seja, 
esse tipo de dados comporta valores como “João da Silva”, “ABC123” ou mesmo valores que utilizam caracteres 
especiais, tipo “123$$45#DEFG”. 
Outras regras que podem ser definidas para os valores dos atributos incluem limitações sobre valores específicos. 
Por exemplo, um campo referente ao sexo biológico de uma pessoa pode ter seus valores restritos somente aos 
caracteres ‘M’ ou ‘F’. 
Para dar outro exemplo, se uma aplicação é destinada a registrar somente pessoas maiores de idade, pode-se 
definir uma regra que só aceite a inserção de datas de nascimento a partir de uma data de 18 anos atrás. 
Considerando essa possibilidade de impor restrições aos valores de um atributo, podemos definir o que é o 
domínio. O domínio de um determinado atributo é simplesmente o conjunto de todos os valores possíveis para 
esse atributo. 
Uma observação importante é que o valor NULL não é parte de nenhum domínio de dados e não tem tipo. 
Devemos notar que colocar um valor NULL em uma célula de uma tabela é algo completamente diferente de 
colocar um valor 0 (zero) para um campo numérico ou uma cadeia de caracteres vazia, para um campo de tipo 
textual. 
O nulo é um valor especial utilizado pelos SGBDs, utilizado para representar a ausência de valor, então não 
podemos também utilizá-lo para comparar com outros valores. Por exemplo, não dá pra dizer coisas como “null 
é igual a zero”, “null é maior que 1”, “em ordem alfabética, null vem depois da letra A”. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 (CESPE – TCM/BA – 2018) Considerando os conceitos de banco de dados relacionais, assinale a opção correta a 
respeito das propriedades de uma tupla. 
a) A tupla tem o mesmo significado e as mesmas propriedades de uma tabela. 
b) Os componentes de uma tupla são ordenados da esquerda para a direita. 
c) Cada tupla contém exatamente um valor para cada um de seus atributos. 
d) Um subconjunto de uma tupla não é considerado uma tupla. 
e) Uma tupla nunca é vazia, seu grau podevariar de 1 até n. 
RESOLUÇÃO: 
Vamos aproveitar para rever as propriedades das tuplas: 
a) Não! Uma tabela é equivalente a uma relação. ERRADA 
b) Veja bem... você viu que ele quase que parafraseou uma das propriedades das Tuplas que o C.J. Date definiu em 
seu livro, não é? 
Quando o examinador falar que os componentes são ordenados da esquerda para direita, você deve pensar na 
propriedade que o Date citou. Ele está fazendo referência de forma literal um livro específico e está tratando das 
propriedades de uma tupla no campo teórico, formal do modelo relacional e, portanto, a afirmativa tem seu valor. 
Contudo, se o examinador afirmar que “a ordem das colunas de uma tabela não tem importância nenhuma para o 
banco de dados (ou para o SGBD)”, como ocorreu na questão do TCE/PE, marque falso, já que é uma afirmativa a 
respeito da prática em um banco de dados que não é aplicável para qualquer situação. 
Pensou que, por ser uma matéria de exatas, você tinha se livrado de divergências doutrinárias e essas confusões 
entre autores e conceitos, não é? Infelizmente não é o caso, mas para memorizar fique com as seguintes 
informações: 
- Os componentes em uma tupla não estão ordenados da esquerda para direita. 
- A ordenação das colunas em uma tabela tem algumas implicações para o banco de dados. 
Viu como uma afirmativa puxa mais pro modelo formal e outra para a aplicação de banco de dados em si? 
Se restou alguma dúvida a respeito, o nosso fórum de dúvidas está aberto! 
ERRADA 
c) Essa é a alternativa correta. Os valores dos atributos em uma tupla são atômicos. Só há exatamente um valor 
por atributo. CERTA 
d) A questão foi quase que inteiramente baseada naquelas propriedades do C.J. Date! Como ele disse, um 
subconjunto de uma tupla é sim considerado outra tupla. ERRADA 
e) Uma tupla pode ser vazia, já que seu grau pode variar de 0 a N. Novamente, é uma afirmativa teórica, já que se 
você tentar criar uma tabela sem colunas em um SGBD relacional provavelmente vai obter um erro. 
Gabarito: C 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
Chaves 
 
Como já mencionamos, os SGBDs não somente gerenciam o armazenamento dos dados, mas também são 
responsáveis por gerenciar e definir uma série de regras para os dados. Por exemplo, através do SGBD nós 
podemos definir como as tabelas ficam estruturadas e o domínio para cada atribito. 
Outro tipo de restrição ou regra que pode ser definido através dos SGBDs são as chaves. As chaves são as 
estruturas que permitem identificar e relacionar as tabelas. Isso é bastante importante, pois ao entendê-las, 
vemos como os atributos chave do modelo conceitual são representados no modelo lógico, e também iremos 
começar a entender como é possível definir os relacionamentos entre as tabelas. 
Para iniciar o nosso estudo das chaves, vamos primeiro definir um diagrama de um modelo lógico que nos 
permitirá ilustrar os conceitos que serão apresentados. 
 
 
Figura: Trecho de um modelo lógico que representa dados de um órgão público 
 
Esse trecho de diagrama traz diversos tipos de relacionamento e de chaves. Vamos falar sobre cada um deles a 
seguir! Antes de prosseguirmos, é importante que você memorize que não existe uma notação muito definida 
para representar modelos lógicos. 
As bancas vão utilizar vários tipos de representação diferente para os modelos lógicos de SGBDs relacionais, mas, 
em geral, não vão se desviar muito dessas estruturas de tabela como estão representadas acima. Em relação aos 
relacionamentos, as bancas também costumam utilizar as mesmas notações do modelo conceitual para 
representar os conceitos de cardinalidade e participação. 
Antes de prosseguirmos, um detalhe: veja que eu coloquei dois relacionamentos entre as tabelas Servidor e 
Setor. Isso é plenamente possível tanto na modelagem conceitual, quanto na modelagem lógica relacional. Para 
que possamos distinguir entre os dois, coloquei os nomes de cada um ao lado da respectiva linha que representa 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 o relacionamento. Em provas de concurso, esse tipo de ocorrência é mais raro, mas é importante que você saiba 
que é possível. 
Chave Primária 
 
Vamos começar com o conceito de chave primária. Nos modelos lógicos, as chaves primárias costumam estar 
marcadas com as iniciais PK (de Primary Key) ou com um pequeno ícone de chave ao lado do nome dos atributos. 
Essas chaves estão bastante relacionadas com o conceito de atributos chave da modelagem conceitual. Uma 
chave primária pode ser definida como uma escolha de um conjunto de atributos que identificam unicamente 
uma tupla dentro de uma relação. 
Esse conjunto de atributos também pode ser unitário, ou seja, somente um atributo faz parte da chave primária. 
Nesse caso, ela será uma chave primária simples. Já quando múltiplos atributos fazem parte da chave primária, 
ela é conhecida como composta. 
 
 
 
Seja chave simples ou composta, o que importa mesmo é que o valor da PK seja único dentro de uma mesma 
tabela, para que possa agir como um identificador de cada linha que faz parte dela. No caso de uma chave primária 
simples, é bem fácil de entender: os valores do atributo que compõe a chave não poderão se repetir na relação. 
Já no caso de uma chave composta, os valores de cada um dos atributos que fazem parte da chave primária, 
individualmente, podem se repetir. No entanto, a composição desses atributos não pode se repetir em momento 
algum. 
Por exemplo, veja uma parte da tabela ParticipaReunião, presente no nosso modelo lógico de exemplo. Por ora, 
esqueça o que essa tabela significa. Veja somente que a chave primária dela é composta pelos dois atributos da 
tabela: idReunião e CPFServidor. 
 
 
idReunião CPFServidor 
120 562.099.970-07 
Chave Primária
Simples
Composta
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
120 245.494.170-80 
398 713.716.000-07 
243 562.099.970-07 
 
Veja que, tomando o atributo idReunião separadamente, os valores se repetem, pois temos o valor 120 duas vezes. 
Em relação ao atributo CPFServidor, é a mesma coisa, pois o valor 562.099.970-07 se repete. O importante, em 
uma chave composta, é somente que todas as combinações entre os valores de idReunião e CPFServidor sejam 
únicas. 
 
Uma observação muito importante é que, apesar da chave primária poder ser composta, só existe uma chave 
primária por tabela. Pode parecer um pouco confuso, mas é assim que funciona. 
Isso acontece porque a chave primária é considerada uma regra, ou restrição de integridade do SGBD, e não um 
atributo ou conjunto de atributos. Tecnicamente, não podemos dizer que os atributos que fazem parte da chave 
primária são a chave. O correto é dizer que esses atributos fazem parte da chave. 
Essa é uma distinção que as bancas não costumam fazer no momento da prova. Você irá ver vários enunciados 
de questões dizendo “o atributo idSetor é a chave primária da tabela Setor” ou “os atributos idReunião e 
CPFServidor são a chave primária da tabela ParticipaReunião”, sem que isso seja considerado incorreto. 
Eu trouxe essa discussão para aula somente porque surgem muitas dúvidas de alunos, que confundem o fato de 
uma chave primária ser composta com haver mais de uma chave primária por tabela, o que não pode acontecer. 
 
Uma outra questão muito importante é que os atributos que compõem uma chave primária não podem assumir 
o valor NULL. Isso acontece porque o nulo representa uma ausência de informação, então tecnicamente não é 
possível realizar várias comparações com ele em um SGBD relacional. Não é possível, por exemplo, dizer que 
NULL é igual a NULL nem que NULL é diferente de NULL. É estranho, eu sei, mas é assim que funciona! 
A moral da história aqui é que, já que não conseguimos comparar NULL com nada, nem com o próprio NULL, não 
dápra usar ele numa chave primária. Isso porque não poderíamos dizer que um valor NULL é igual ou diferente 
dos demais, e, portanto, não conseguiríamos afirmar que a chave é única ou não. 
Outra característica importante é que a chave primária pode ter correspondência com algum elemento do mundo 
real, como o CPF, caso em que é considerada uma chave natural. A chave pode também assumir um valor 
aleatório gerado pelo SGBD, caso em que será chamada de surrogate key, ou chave substituta. 
O único propósito de uma surrogate key ou chave substituta é agir como chave primária. Ela não tem 
correspondência com algum dado do mundo real ou qualquer significado implícito – assim, ela não é considerada 
um atributo descritivo, ou seja, não descreve nenhuma característica do que está sendo representado na tabela. 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
 
 
Para nomear as chaves substitutas, é muito comum que se use o prefixo “id”, de “identificador”, antes do nome da 
tabela. Por exemplo, a nossa tabela Reunião tem um atributo chamado idReunião, que é uma chave primária 
substituta que identifica unicamente cada reunião. 
 
 
 
As chaves substitutas podem ser utilizadas quando não existe algum atributo natural da tabela que seja capaz de 
identificar unicamente cada registro, mas também pode ser utilizada em qualquer outra circunstância, por decisão 
do projetista do banco de dados. 
Muitas vezes os administradores consideram mais fácil gerenciar as chaves substitutas, pois seus valores são fixos, 
imutáveis para cada registro, e não têm associação com nenhum valor ou característica da realidade. 
Essas chaves substitutas muitas vezes são do tipo autoincremento, ou seja, são valores numéricos que vão sendo 
incrementados pelo próprio SGBD à medida que adicionamos registros. Assim, o usuário não precisa se preocupar 
com os valores das chaves. 
Por exemplo, se a chave idReunião for do tipo autoincremento, o SGBD pode atribuir o valor 1 ao id da primeira 
reunião criada. Em seguida, quando a próxima reunião for cadastrada no sistema, o SGBD irá atribuir o valor 
idReunião = 2, já que a anterior tinha sido a reunião 1. A terceira reunião terá idReunião = 3, a quarta 4, a quinta 5 
e assim sucessivamente. 
 
Superchaves e chaves candidatas 
Na maioria dos casos, uma tabela pode ter múltiplos conjuntos de atributos que são capazes de identificar 
unicamente cada registro, incluindo, mas não se limitando à chave primária. Esses conjuntos são conhecidos como 
superchaves. 
Como todos os registros de uma tabela são diferentes entre si (lembra que uma relação é um conjunto de tuplas 
distintas?), então há pelo menos uma superchave em cada tabela de um BD relacional: aquela que é composta por 
todos os atributos da relação. Se todas as tuplas são diferentes, então cada conjunto de todos os atributos 
logicamente será único! 
Chave Primária
Natural
Substituta
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Só que na maioria das vezes, não é necessário usar todos os atributos da relação para identificar unicamente cada 
tupla. Por exemplo, na tabela Pessoas que já vimos, somente a utilização do atributo CPF já era suficiente, como 
nós vimos. Assim, não há nenhuma necessidade de se usar todo o conjunto composto por todos os atributos (CPF, 
Nome, Dt. Nascimento, Cidade) como chave primária, pois só o CPF já basta. 
Assim, podemos considerar que CPF é uma chave mínima, pois é uma chave composta pela quantidade mínima 
de atributos possível para identificar cada atributo da relação. 
Veja que se você pegar os conjuntos {CPF, Nome}, {CPF, Nome, Dt. Nascimento} ou {CPF, Nome, Dt. Nascimento, 
Cidade}, todos eles são capazes de identificar unicamente cada tupla também – os valores desses conjuntos de 
atributos não se repetem na relação. Só que esses conjuntos serão considerados somente superchaves e não 
chaves mínimas, pois são sim capazes de identificar cada tupla, mas tem atributos desnecessários aí no meio, uma 
vez que somente o CPF já seria suficiente. 
Uma tabela pode ter mais de uma chave mínima. Se a tabela também tivesse uma chave substituta como 
“idPessoa”, tanto CPF quanto idPessoa seriam consideradas chaves mínimas, pois têm a quantidade mínima de 
atributos necessários para identificar unicamente cada tupla, não apresentando nenhum atributo supérfluo 
(desnecessário) em sua composição. 
Essas chaves mínimas, durante o projeto do BD, são conhecidas como chaves candidatas, pois são candidatos a 
ser a chave primária. Só que, como sabemos, uma tabela sempre terá somente uma chave primária, então iremos 
escolher somente uma das chaves candidatas para ser chave primária. 
Então o processo de escolha da chave primária fica assim: 
➔ Superchaves são todos os conjuntos de atributos que podem identificar unicamente uma tupla 
➔ Chaves candidatas são as superchaves que são mínimas (sem atributos desnecessários) 
➔ A chave primária é escolhida dentre as chaves candidatas 
 
 
 
 
Agora que aprendemos o conceito de superchaves e chaves candidatas, vemos que nem todos os atributos que 
são capazes de identificar unicamente uma relação são escolhidos como chave primária. 
Nesse sentido, os SGBDs também permitem que se defina uma regra chamada de restrição de unicidade 
(chamada de UNIQUE na linguagem SQL), que diz que um atributo ou conjunto de atributos deve ter valores 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 únicos dentro de uma tabela. Essa regra, quando criada, não permite que se insira valores repetidos para esses 
atributos. 
A única diferença em relação aos critérios da chave primária é que essas restrições de unicidade não se 
preocupam em relação a valores nulos, ou seja, os atributos com restrição UNIQUE podem assumir o valor 
NULL. 
 
Chave Estrangeira 
Em um banco de dados relacional, todos os dados são representados no formato de tabelas. Como já citamos, 
boa parte das entidades presentes no modelo conceitual viram tabelas quando passamos para o modelo lógico. 
Só que fica a dúvida: e os relacionamentos? Como podemos fazer para representá-los? 
Para começarmos a entender como os relacionamentos são representados no modelo relacional, precisamos 
conhecer um novo tipo de chave, chamado de chave estrangeira. O objetivo desse tipo de chave é basicamente 
possibilitar que se crie ligações lógicas entre as tabelas, permitindo a representação dos relacionamentos. 
As chaves estrangeiras geralmente ficam representadas nos modelos lógicos através da sigla FK (de foreign key, 
que é “chave estrangeira” em inglês). Veja o trecho de modelo lógico a seguir e como há alguns atributos marcados 
com esse FK. 
 
 
Figura: Chaves estrangeiras representadas em um modelo lógico. 
 
A marcação “FK” indica que um ou mais atributos da tabela compõem uma chave estrangeira. Uma chave 
estrangeira serve para identificar unicamente um registro em outra tabela. Isso ocorre com base na igualdade 
dos valores dos atributos. 
Por exemplo, a chave estrangeira no atributo idSetor, da tabela Servidor contém valores idênticos ao atributo id 
da tabela Setor, permitindo que se represente o relacionamento Trabalha. Assim, toda vez que um servidor tiver 
um valor X para o atributo idSetor, ele se ligará ao registro da tabela Setor cujo valor de id é também igual a X. Não 
entendeu? Veja o esquema: 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
 
 
O que está acontecendo aí é que existe um relacionamento entre Servidor e Setor, dado pela chave estrangeira 
que liga os campos idSetor e id. Quando esses atributos tiverem o mesmo valor, os seus registros ficarão ligados 
entre si. Assim, podemos afirmar que a funcionária Ester Lopes trabalha no setor Financeiro e o funcionário 
Geraldo Dias no setor de Comunicação. 
Esse atoda chave estrangeira “apontar” para um atributo de outra tabela é geralmente chamado de referenciar 
ou fazer referência. Ou seja, a chave estrangeira presente no atributo idSetor de Servidor referencia o atributo id 
da tabela Setor. Por esse motivo, chamamos a tabela de onde se origina a referência de “referenciadora” e a tabela 
a que se destina a referência de “referenciada”. 
 
Atenção! 
Uma chave estrangeira não necessariamente referencia uma chave 
primária, apesar de ser o caso mais comum. A chave estrangeira pode 
referenciar qualquer conjunto de atributos, desde que esses também possam 
identificar unicamente um registro da tabela de destino. 
 
 
Note que no modelo lógico em questão nós temos algumas chaves com uma numeração ao lado, tipo “FK1” e 
“FK2” na tabela Servidor. Isso ocorre para diferenciar uma chave estrangeira da outra, quando temos mais de 
uma na mesma tabela. Ao contrário das chaves primárias, uma tabela pode ter múltiplas chaves estrangeiras, 
já que uma mesma tabela pode participar de vários relacionamentos diferentes. 
Na minha visão, essa diferenciação é necessária para a clareza do modelo, já que sem ela não poderíamos saber 
se é uma chave estrangeira composta por vários atributos, ou se são várias chaves estrangeiras compostas 
por um atributo cada. Na hora da prova, nem sempre a banca vai fazer essa diferenciação, mas isso não 
costuma ser um problema. 
Nas provas de concurso, as chaves estrangeiras podem ser representadas de diversas maneiras. Às vezes o 
examinador usa o termo “FK”, às vezes coloca um ícone de uma chave um pouco diferente da chave primária e 
às vezes não faz diferenciação alguma dos demais atributos. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
Para fins de prova, o que acontece é que geralmente os nomes dos atributos são bem intuitivos e permitem 
identificar facilmente que são chaves estrangeiras. Por exemplo, o atributo idSetor na tabela Servidor 
obviamente referencia a tabela Setor e o atributo idReunião na tabela ParticipaReunião obviamente referencia 
a tabela Reunião. Os modelos ER e lógicos utilizados em questões tendem a ser relativamente simples e 
intuitivos, então não acho que você terá problemas quanto a isso. 
 
Uma observação final é que, ao contrário da chave primária, a chave estrangeira pode sim assumir o valor nulo, 
desde que o projeto defina que a participação da entidade no relacionamento associado é parcial. Na participação 
parcial, determinadas ocorrências da entidade (ou determinados registros da tabela, no modelo lógico) podem 
simplesmente não participar do relacionamento. 
Por exemplo, veja novamente esse trecho do modelo lógico a seguir, considerando o relacionamento Trabalha. 
Veja que um Servidor pode trabalhar em no mínimo zero e no máximo um Setor. 
 
 
 
Nesse caso, a participação de servidor no relacionamento é opcional, pois um servidor pode não trabalhar em 
nenhum setor específico. Isso pode ocorrer com um servidor que acabou de ser nomeado e ainda está fazendo o 
curso de formação, e por isso ainda não tem uma lotação definida em algum setor. Nesse caso, o valor do atributo 
idSetor, que é chave estrangeira da tabela, pode ficar nulo, uma vez que o servidor não está associado a nenhum 
setor. 
 
 
(FCC – DPE/AM – 2018) 
Considere duas tabelas S (A, B, C) e T (X, Y, Z, A) de um banco de dados relacional, sendo A e X chaves primárias 
das tabelas S e T, respectivamente, e A chave estrangeira na tabela T, com origem em S. Dessa forma, é correto 
afirmar que 
a) T é chamada de tabela referenciadora. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 b) B e C formam uma superchave da tabela S. 
c) T é chamada de tabela indicativa. 
d) S é chamada de tabela prevalente. 
e) Y, Z e A formam uma chave candidata da tabela T. 
RESOLUÇÃO: 
a) Bem, se, em um relacionamento, dizemos que uma chave estrangeira referencia outra tabela, podemos afirmar 
que a tabela de origem é a referenciadora e a de destino é a referenciada. CERTA 
b) Veja que a chave primária da tabela S é o atributo A. B e C poderiam até ser chaves candidatas, mas isso não 
tem nada ver com “superchave” e não há nenhuma indicação nesse sentido na questão. ERRADA 
c) T é a tabela referenciadora, pois é a tabela de origem do relacionamento. ERRADA 
d) S, por sua vez, é a tabela referenciada, pois é o destino do relacionamento. ERRADA 
e) Não há nenhum indicativo nesse sentido no enunciado da questão. Aliás, A é, na verdade, chave estrangeira da 
tabela, como a própria assertiva diz. ERRADA 
Gabarito: A 
 
 
Relacionamentos 
 
A cardinalidade de um relacionamento diz respeito à quantidade máxima de ocorrências de uma entidade que 
pode estar associada a uma ocorrência da outra. Na modelagem conceitual dos bancos de dados, geralmente 
representamos os relacionamentos em função de três tipos de cardinalidades: 1:1, 1:N e M:N. 
A maneira com que esses relacionamentos vão ser implementados em um banco de dados relacional vai variar de 
acordo com essa cardinalidade, mas, de modo geral, iremos utilizar chaves estrangeiras para possibilitar a sua 
representação no modelo lógico. 
 
 
Modelando relacionamentos um para um (1:1) 
 
 
Figura: Trecho de um diagrama ER notação de Elmasri e Navathe indicando um relacionamento (1:1) 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Na cardinalidade 1:1 entre duas tabelas A e B, temos as seguintes regras: 
• Um registro de A referencia no máximo um registro de B 
• Um registro de B referencia no máximo um registro de A 
 
 Como exemplo, temos o relacionamento Gerencia entre Servidor e Setor. Observe no diagrama ER que um 
funcionário só pode gerenciar um setor e um setor só pode ser gerenciado por no máximo um funcionário. O 
mesmo cenário pode ser representado no modelo lógico relacional. Veja o trecho do diagrama a seguir: 
 
 
 
Nesse caso, apesar de estarmos usando a notação pé de galinha e não a notação de Elmasri e Navathe para 
representar a cardinalidade e a participação, dá pra ver que a cardinalidade desse relacionamento é realmente 
1:1, pois os símbolos que ficam mais próximos das entidades são dois traços verticais. Se você não compreende 
essa notação, sugiro verificar a aula que trata de modelagem conceitual novamente! 
 
O que nos interessa agora é ver como isso fica representado nas tabelas do banco de dados. Veja os exemplos de 
dados nessas tabelas a seguir. Note que eu novamente omiti algumas colunas das tabelas, mas isso foi somente 
para não nos atrapalhar na hora da explicação, não se preocupe muito com isso. 
 
 
 
 
Servidor: 
CPF Nome ... 
394.036.580-70 Alexandre Silva ... 
713.716.000-07 Marina Almeida ... 
221.621.540-64 Frederico Souza ... 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
Setor: 
id Nome ... CPFGerente 
1 Financeiro ... 394.036.580-70 
2 Contabilidade ... 713.716.000-07 
 
Assim, vemos que a tabela Setor tem uma chave estrangeira no atributo CPFGerente, que referencia o campo CPF, 
chave primária da tabela Servidor. Para cada registro de setor, irá constar no campo CPFGerente o CPF do servidor 
que é gerente. Nenhuma grande dúvida até aí, não é? 
Um detalhe é que, nesse caso, somente criar a chave estrangeira não seria suficiente para definir esse 
relacionamento como sendo 1:1. Se fizéssemos somente isso, nada no SGBD impediria que dois setores tivessem 
valores repetidos para CPFGerente, tornando o relacionamento 1:N. Por exemplo: 
 
id Nome ... CPFGerente 
1 Financeiro ... 394.036.580-70 
2 Contabilidade ... 713.716.000-07 
3 Controle Interno ... 394.036.580-70 
4 Comunicação ... 394.036.580-70 
 
Por isso, é necessário estabelecer uma outra regra, além da chave estrangeira. Se “dissermos” ao banco de dados 
que os valores de CPFGerente na tabela Setordevem ser únicos, isso bastará para caracterizarmos o 
relacionamento como 1:1. 
Assim, temos que utilizar uma restrição de unicidade. Dizemos ao SGBD algo como: veja bem, esse atributo 
CPFGerente não é uma chave primária, mas também não pode ter seus valores repetidos! Na linguagem SQL, vamos 
criar essa condição ou restrição através de um comando chamado UNIQUE. 
Nesse caso, como os CPFGerente não poderão se repetir, um gerente não poderá estar associado a mais de um 
setor. Pelo outro lado, como um setor só tem um campo que diz qual é o CPF do gerente, um setor também não 
terá como estar associado a mais de um gerente. Está pronto o nosso relacionamento 1:1. 
Quando a participação de ambas as entidades no relacionamento 1:1 é total, acontece uma situação peculiar. 
Nesse caso, tanto a cardinalidade mínima quanto a máxima dos dois lados do relacionamento é 1, o que significa 
dizer que todo registro de A corresponde a exatamente um registro de B e vice-versa. 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
 
Nesse cenário, pode fazer sentido utilizar uma outra abordagem para representar esse relacionamento no 
modelo lógico, sem a necessidade de se utilizar chaves estrangeiras. Essa abordagem envolve mesclar as 
entidades A e B em uma relação única que combine todos os atributos das duas relações envolvidas. Essa 
abordagem aparece pouco em provas de concurso, então só memorize que essa possibilidade existe e siga em 
frente, sem maiores detalhes por aqui! 
 
Modelando relacionamentos um para muitos (1:N) 
 
 
Figura: Trecho de diagrama Entidade-Relacionamento indicando um relacionamento (1:N) 
 
Na cardinalidade 1:N entre duas tabelas A e B, temos as seguintes regras: 
• Um registro de A pode referenciar vários registros de B 
• Um registro de B referencia no máximo um registro de A 
 
Podemos exemplificar como esse tipo de atributo é representado no modelo relacional com o relacionamento 
Trabalha entre as tabelas Servidor e Setor. Seguindo a lógica, sabemos que um servidor pode trabalhar em um 
setor, mas em um setor podem trabalhar diversos funcionários. 
 
 
 
Para representar esse tipo de relacionamento, nós iremos utilizar novamente uma chave estrangeira em uma das 
tabelas. No nosso exemplo, o relacionamento é possibilitado através da chave estrangeira FK1, criada no atributo 
idSetor da tabela Servidor. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 No caso dos relacionamentos 1:N, a chave estrangeira deve ser posicionada na tabela do lado “N” do 
relacionamento. Aqui não faz sentido utilizar uma restrição de unicidade (como fizemos no relacionamento 1:1), 
pois a ideia é realmente permitir que os valores da chave estrangeira possam se repetir, já que é um 
relacionamento um para muitos. 
Veja um exemplo de dados nessas tabelas. Observe que os valores de idSetor, a chave estrangeira, se repetem: 
Servidor 
CPF Nome ... idSetor 
155.282.898-07 Ester Lopes ... 1 
553.809.010-85 Geraldo Dias ... 4 
727.774.068-80 Lara Araujo ... 2 
383.073.866-83 Vitor Assis ... 1 
 
Setor 
id Nome Sala ... 
1 Financeiro 201 ... 
2 Contabilidade 205 ... 
3 Controle Interno 108 ... 
4 Comunicação 510 ... 
Modelando relacionamentos muitos para muitos (M:N) 
 
 
Figura: Trecho de diagrama Entidade-Relacionamento indicando um relacionamento (M:N) 
 
Na cardinalidade M:N entre duas tabelas A e B, temos as seguintes regras: 
• Um registro de A pode referenciar vários registros de B 
• Um registro de B pode referenciar vários registros de A 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Esse tipo de relacionamento é só um pouco mais complexo de se implementar no modelo lógico. Vamos adotar o 
exemplo do relacionamento entre Servidor e Reunião, em que um servidor pode participar de várias reuniões, e 
uma reunião conta com a participação de vários servidores. 
No modelo lógico, o que geralmente se faz é criar uma tabela de ligação entre as duas tabelas envolvidas no 
relacionamento, criando-se dois relacionamentos um para muitos (1:N) entre essa tabela de ligação e as duas 
tabelas envolvidas. Fica assim: 
 
 
Figura: Trecho de modelo lógico representando relacionamento M:N entre Servidor e Reunião, implementado através de tabela de 
ligação ParticipaReunião 
 
Note que o relacionamento entre Servidor e ParticipaReunião é 1:N, e o relacionamento entre ParticipaReunião e 
Reunião é N:1. Veja que os dois relacionamentos um para muitos acabam permitindo a concretização do 
relacionamento muitos para muitos entre as duas tabelas das pontas (Servidor e Reunião). 
Nesse caso, note que ParticipaReunião tem duas chaves estrangeiras. Uma apontando para Reunião e outra para 
Servidor. A composição dessas duas chaves estrangeiras irá ser também a chave primária de ParticipaReunião. 
Agora veja como os dados poderiam ficar nas três tabelas envolvidas: 
 
Servidor 
CPF Nome ... 
155.282.898-07 Ester Lopes ... 
553.809.010-85 Geraldo Dias ... 
727.774.068-80 Lara Araujo ... 
394.036.580-70 Alexandre Silva ... 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
713.716.000-07 Marina Almeida ... 
 
 
Reunião: 
idReunião Data/Hora Sala 
120 11/10/2021 – 10:00 204 
398 21/05/2021 – 09:30 801 
243 09/07/2020 – 13:00 1102 
 
 
 
 
 
 
 
ParticipaReunião: 
idReunião CPFFuncionário Situação 
120 562.099.970-07 Presente 
120 245.494.170-80 Presente 
120 394.036.580-70 Presente 
398 713.716.000-07 Faltou 
398 245.494.170-80 Presente 
243 394.036.580-70 Presente 
243 562.099.970-07 Faltou 
243 713.716.000-07 Presente 
 
Veja, então, que destaquei uma reunião (de id 120) e um funcionário (de CPF 562.099.970-07), pois cada um deles 
está associado a múltiplas ocorrências da outra tabela. A reunião está associada a vários servidores, e o servidor 
está associado a várias reuniões. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Um detalhe que você deve ter percebido é que, como sabemos, um relacionamento também pode ter seus 
próprios atributos. Dessa maneira, podemos colocar aqueles atributos que dizem respeito ao relacionamento 
nessa tabela de ligação. 
No nosso exemplo, observe que o atributo “situação” ficou na tabela intermediária ParticipaReunião. Isso ocorre 
porque esse atributo diz respeito ao relacionamento, ou seja, à participação de um servidor em uma reunião, e 
não somente à reunião ou somente ao servidor. 
Essa abordagem de se utilizar uma tabela intermediária pode ser utilizada para implementar relacionamentos 
de qualquer cardinalidade, mas é algo considerado desnecessário na maioria das vezes para os 
relacionamentos 1:1 e 1:N. Isso ocorre porque seria necessário realizar várias operações de junção entre as 
tabelas para consultar os dados relacionados, além de trazer o trabalho de se manter mais uma estrutura no 
modelo de dados. 
 
 
 
 
 
Modelando autorrelacionamentos 
 
Figura: Trecho do diagrama lógico retratando um autorrelacionamento na tabela Servidor 
 
Você sabe que existem os relacionamentos recursivos, aqueles de grau 1, ou seja, que envolvem apenas um 
conjunto de entidades. Esses relacionamentos, também conhecidos como autorrelacionamentos, são 
representados na mesma maneira que os demais. 
A única diferença aqui é que a tabela referenciadora e a referenciada são a mesma. Para relacionamentos 1:1 e 1:N, 
a ideia é criar uma chave estrangeira que referencie a chave primária da própria tabela. Já no caso de um 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 relacionamento M:N, cria-se uma tabela auxiliar que tem duas chaves estrangeiras apontando para a chave 
primária da tabela original. 
Veja o exemplo da tabela Servidor, que tem um autorrelacionamento utilizado pararepresentar a relação de 
chefia entre dois servidores. Nesse caso, um servidor pode ser chefe de vários outros, enquanto pode ser chefiado 
por apenas um outro servidor. 
Servidor 
CPF Nome CPFChefe 
155.282.898-07 Ester Lopes 713.716.000-07 
553.809.010-85 Geraldo Dias 394.036.580-70 
727.774.068-80 Lara Araujo 155.282.898-07 
394.036.580-70 Alexandre Silva 713.716.000-07 
713.716.000-07 Marina Almeida NULL 
 
Veja que a chave estrangeira (CPFChefe) referencia a chave primária da própria tabela. Assim, um servidor pode 
referenciar um outro servidor. 
Modelagem de relacionamentos (Resumo) 
Para você não se confundir, vamos resumir as possibilidades das técnicas de modelagem lógica dos 
relacionamentos: 
Relacionamentos 1:1: 
• Chave estrangeira em uma das duas relações (melhor ser naquela 
que tiver participação total), com restrição de unicidade 
• Quando a participação for total em ambos os lados, pode-se mesclar 
as relações em uma só 
• Usar tabela de ligação 
Relacionamento 1:N: 
• Chave estrangeira no lado N do relacionamento 
• Usar tabela de ligação 
Relacionamento M:N: • Usar tabela de ligação 
 
 Para fins de prova, na grande maioria das vezes entender e memorizar somente a primeira opção (em 
destaque no quadro) para cada um dos relacionamentos será suficiente. 
 
(CESPE – SEFAZ/RS – 2019) 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 No modelo relacional, a afirmação “Duas tuplas distintas, em qualquer estado da relação, não podem ter valores 
idênticos para os atributos na chave” é 
a) falsa 
b) uma restrição de domínio do modelo. 
c) uma propriedade exclusiva do modelo objeto-relacional. 
d) uma condição que deverá estar explícita na representação dos atributos de uma tupla. 
e) uma propriedade de chave do modelo. 
RESOLUÇÃO: 
No modelo relacional, as chaves primárias devem ser únicas . Essa é a principal propriedade das chaves. Uma outra 
propriedade diz que as chaves primárias são irredutíveis, ou seja, não dá pra tirar nenhum atributo mantendo a sua 
característica de chave (não há atributos supérfluos), já que são chaves mínimas. A única resposta correta é a letra 
E. 
Gabarito: E 
 
(CESPE – SEFAZ/RS – 2018) 
No mapeamento de um modelo entidade-relacionamento para um modelo relacional de banco de dados, o tipo 
de relacionamento que implica a criação de uma terceira tabela para onde serão transpostos as chaves primárias 
e os eventuais atributos das duas tabelas originais é denominado 
a) relacionamento N:N. 
b) relacionamento 1:1. 
c) relacionamento 1:N. 
d) autorrelacionamento 1:N. 
e) relacionamento ternário. 
RESOLUÇÃO: 
Todas as cardinalidades de relacionamentos podem ser implementadas através da utilização de uma tabela 
intermediária de ligação. Só que a questão pede o tipo de relacionamento que implica a criação dessa tabela, ou 
seja, o caso em que isso é obrigatório, e esse é o caso dos relacionamentos muitos para muitos (M:N ou N:N). 
Gabarito: A 
 
(CESPE – MPE/PI – 2018) Tendo em vista que, ao se desenvolver um sistema de vendas e compras para um cliente, 
devem-se descrever os produtos, as entradas, as saídas, o controle de estoque e o lucro das vendas, julgue o item 
subsequente, relativo à modelagem de dados para a aplicação descrita. 
Situação hipotética: O responsável pela modelagem de dados para a aplicação em apreço propôs o seguinte 
modelo lógico de banco de dados relacional: 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 TipoDeProduto (CodigoTipoProduto, DescriçãoTipoProduto) 
Produto (CodigoProduto, DescriçãoProduto, PreçoProduto, CodigoTipoProduto) 
CodigoTipoProduto referencia TipoDeProduto 
 
Assertiva: Nesse modelo lógico, um TipoDeProduto se relaciona com várias entidades do tipo Produto. Com essa 
notação, a visão do cliente se torna clara e direta sobre como serão implementados e armazenados os dados. 
RESOLUÇÃO: 
Você deve estar estranhando esse tipo de modelo lógico numa representação textual, sem diagramas. Trouxe essa 
questão justamente pra introduzir esse tipo de esquema: 
 
1. O nome antes dos parênteses é o nome da tupla; 
2. Os itens dentro dos parênteses são os atributos da tupla; 
3. Nessa questão não apareceu, mas um atributo sublinhado indica que ele compõe a chave primária da tupla; 
4. Finalmente, quando dizemos X referencia Y, queremos dizer que a chave estrangeira no atributo X está 
referenciando a tabela Y. 
 
Avaliando a assertiva, temos que um TipoDeProduto realmente se relaciona com vários itens do tipo Produto. 
Perceba que a chave estrangeira foi definida em “CodigoTipoProduto referencia TipoDeProduto”, ou seja, temos 
um atributo de Produto que referencia a tabela TipoDeProduto. 
Como nada foi dito a respeito de restrições de unicidade desse campo CodigoTipoProduto na tabela Produto, não 
há nenhuma informação na questão que indique que um código de tipo de produto não possa se repetir várias 
vezes na tabela de produto. Assim, podemos ter diversos produtos com o mesmo TipoDeProduto. A primeira parte 
da assertiva é verdadeira. 
A segunda parte da assertiva diz que nesse tipo de esquema (modelo lógico), há uma visão clara e direta sobre 
como será a implementação futura dos dados. Considero a afirmativa verdadeira, já que já é possível enxergar as 
tabelas, chaves e relacionamentos nessa etapa da modelagem. 
Gabarito: C 
 
Integridade 
 
A integridade de um sistema pode dizer respeito ao aspecto físico, do mundo real, que diz respeito ao 
armazenamento dos dados em um meio físico, como em um HD ou fitas de backup. A integridade física pode ser 
comprometida por danos como aqueles causados por corrosão, falhas elétricas, catástrofe natural no local onde 
os servidores ficam, dentre outras inúmeras possibilidades. 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Só que esse não é o tipo de integridade que estamos buscando. A integridade que será objeto do nosso estudo 
será uma integridade lógica, ou seja, aquela que tem a ver com os aspectos do software do banco de dados, como 
as regras que foram definidas ao se projetar o BD. 
Como já mencionamos em várias partes da nossa aula, um banco de dados relacional possui um conjunto de regras 
como os dados devem estar organizados e relacionados. Essas regras que governam o armazenamento e 
processamento dos dados são as restrições de integridade de que iremos tratar nesta seção. 
Categorias 
Elmasri e Navathe dividem as restrições de integridade em três categorias: 
 
As restrições inerentes ao modelo de dados (implícitas) nós já vimos quando estudamos os fundamentos do 
modelo relacional. Todas aquelas regras relacionadas às relações, tuplas e atributos que estudamos no começo da 
aula são restrições implícitas. Por exemplo, ao dizermos que, no modelo relacional, duas tuplas não podem ser 
iguais, estamos expressando uma restrição inerente ao modelo relacional. 
O último tipo, o das restrições semânticas, também não será alvo do nosso estudo aprofundado. Essas restrições 
dizem respeito às regras de negócio que não são fáceis de se implementar num banco de dados. Por exemplo, 
numa aplicação bancária não cabe ao banco de dados dizer se podemos associar um cliente a um empréstimo. 
Quem irá calcular se o cliente pode ou não pegar um empréstimo será o sistema de aplicação do banco operado 
pelo atendente. 
Em vários desses casos até existem funcionalidades na linguagem SQL que permitem definir essas regras, como 
através da utilização de estruturas chamadas gatilhos. Só que essa parte da linguagem é muito complexa, o que 
na maioria das vezes faz com que os desenvolvedores apliquem essas regras de negócio nos próprios programas 
de aplicação, e não no SBGD. 
As restrições que vão ser do nosso maior interesse são as restrições explícitas, pois elas vão variar de acordo com 
o projeto do banco de dados e podem serespecificadas de diferentes maneiras pelos usuários do SGBD. 
Vamos lá? 
 
Restrições baseadas em esquema (explícitas) 
As restrições baseadas em esquema (ou explícitas) em um SGBD relacional são aquelas que podem ser definidas 
via linguagem SQL (mais especificamente em uma sublinguagem chamada DDL – Linguagem de Definição de 
Restrições inerentes ao modelo 
(ou implícitas)
•Restrições decorrentes do 
modelo de dados adotado. 
Restrições baseadas em esquema 
(ou explícitas)
•Essas restrições podem ser 
expressas diretamente nos 
esquemas do modelo de dados.
Restrições semânticas (também 
chamadas baseadas em aplicação, 
regras de negócio ou integridade 
definida por usuário)
•Essas não podem ser 
expressadas no esquema do 
banco de dados, então cabe aos 
programas de aplicação aplicá-
las.
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Dados). Segundo Elmasri e Navathe, essas restrições se dividem em restrições de domínio, de chaves, de valores 
nulos, de entidade e de integridade referencial. 
Para fins de prova, penso que memorizar as restrições de integridade que vou listar a seguir é o suficiente. Note, 
inclusive, que todas elas tratam de conceitos já abordados durante a sua aula, o que vai facilitar o entendimento! 
 
1. Integridade de entidade 
 
 
 
Esse tipo de restrição está relacionado às regras impostas pelas chaves primárias. A integridade de entidade 
define somente que cada chave primária deve ser única e não nula. Também é conhecida como integridade 
primária ou de chave primária. 
 
 
2. Integridade referencial 
A integridade referencial está relacionada ao conceito de chave estrangeira. A regra simplesmente determina que 
uma chave estrangeira só pode estar em dois estados: 
a) Fazendo referência a um registro válido da tabela referenciada; 
b) Assumindo o valor NULL, caso em que o registro em questão não participa do relacionamento. 
Lembrando que esse último caso só é possível no caso de participação parcial da entidade no relacionamento. A 
ideia aqui é basicamente que uma chave estrangeira deve estar referenciando corretamente um registro da tabela 
referenciada ou não referenciando ninguém. 
Por exemplo, considere que temos a chave estrangeira idSetor na tabela Servidor, que referencia o campo id da 
tabela Setor. Nesse caso, se existe algum valor de idSetor que não existe no campo referenciado (id), essa é uma 
violação à integridade referencial. 
 
 
Figura: Representação de violação à integridade referencial – não existe setor com id = 25 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 
3. Integridade de domínio 
O domínio é o conjunto dos valores possíveis para um determinado atributo. Dessa forma, a integridade de 
domínio determina que os valores de todas as colunas, em todos os registros de um banco de dados fazem parte 
de seus respectivos domínios. 
Por exemplo, se dizemos que um atributo é de um tipo numérico, um registro não poderá nunca ter um valor 
textual para esse atributo. 
Dentro da integridade de domínio temos uma subcategoria chamada integridade de vazio. Essa restrição 
determina se o atributo pode ou não assumir valores nulos. 
 
Views (visões) 
 
Uma das vantagens da abordagem de bancos de dados é o suporte a múltiplas visões sobre os dados. Essa 
característica permite que diferentes usuários tenham diferentes perspectivas sobre o mesmo conjunto de dados. 
Assim, determinados usuários podem ver somente parte de uma tabela, enquanto outros enxergam a tabela 
inteira. Um terceiro grupo, ainda, poderia consultar os dados somente de forma agregada (agrupada), sem 
visualizar todos os registros detalhados... enfim, são inúmeras as possibilidades! 
Como você já viu, a estrutura básica dos BDs relacionais é a tabela (relação). Essas tabelas ficam persistidas no 
banco de dados de uma forma fixa, seguindo uma estrutura predefinida. 
Para podermos concretizar essa característica do suporte a múltiplas visões, ou seja, permitir que usuários do BD 
visualizem os dados de uma ou mais tabelas de uma maneira diferente com que elas estão armazenadas, nós 
precisamos executar consultas SQL que extraiam os dados nessas diferentes formas. 
Para exemplificar como isso ocorre, vamos considerar um trecho de uma tabela que contém dados sobre os 
servidores de um órgão. Ela tem a seguinte estrutura: 
 
CPF Nome Salário Endereço Setor 
155.282.898-07 Ester Lopes R$ 13.192,08 Rua X, nº 250 Financeiro 
553.809.010-85 Geraldo Dias R$ 7.555,43 Rua Y, nº 75 Comunicação 
727.774.068-80 Lara Araujo R$ 14.309,46 Rua Z, nº 150 Contabilidade 
383.073.866-83 Vitor Assis R$ 12.137,74 Rua V, nº 10 Financeiro 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Agora considere que essa tabela é usada para vários propósitos. Um dos pontos centrais de se ter um banco de 
dados é esse mesmo: permitir que vários usuários distintos com propósitos distintos possam acessar os dados. 
 
Um desses propósitos consiste em disponibilizar os dados no portal da transparência. Só que para esse fim, é 
necessário omitir o endereço dos servidores, já que essa não é uma informação pública, e sim pessoal de cada 
servidor. 
Nesse caso, não podemos disponibilizar a tabela inteira no portal, então devemos fazer uma consulta SQL que 
retorne somente um subconjunto dos atributos da tabela, sem que o endereço seja retornado. A consulta seria 
como a que está a seguir (não precisa decorar!): 
 
SELECT CPF, Nome, Salario, Setor 
FROM Servidores 
Ao executar essa consulta, o resultado seria retornado na tela da seguinte maneira: 
 
CPF Nome Salário Setor 
155.282.898-07 Ester Lopes R$ 13.192,08 Financeiro 
553.809.010-85 Geraldo Dias R$ 7.555,43 Comunicação 
727.774.068-80 Lara Araujo R$ 14.309,46 Contabilidade 
383.073.866-83 Vitor Assis R$ 12.137,74 Financeiro 
 
Nessa consulta, nós não alteramos a estrutura ou o conteúdo da tabela servidores, nem armazenamos seus 
resultados em local algum. A única coisa que fizemos foi extrair os dados da tabela de uma forma diferente da que 
estão gravadas, omitindo a informação do endereço. 
Para disponibilizar esses resultados no portal da transparência, então, poderíamos executar a consulta SQL que 
mostramos, copiar os resultados exibidos no SGBD e só então disponibilizá-los no portal. No entanto, toda vez 
que houvesse uma mudança nos valores dos dados da tabela, teríamos que fazer todo esse procedimento 
novamente, o que tornaria atualizar este portal algo bastante trabalhoso! 
Como solução, podemos definir uma visão no SGBD. Uma visão (do inglês view) é definida como uma tabela 
derivada de outras tabelas. Ou seja, a view é uma visão diferente sobre os dados que estão armazenados em 
tabelas do banco de dados. 
Nós sempre definimos uma view a partir de uma consulta SQL. No caso do exemplo, poderíamos criar uma view 
chamada ServidoresSemEndereco, por exemplo, que armazena a consulta que executamos mais acima. Assim, 
toda vez que o portal da transparência consultar os dados da view, ela irá retornar os dados dos servidores, 
omitindo a informação do salário, da maneira que definimos acima. 
 
 
 Prof. Arthur Mendonça 
Aula 01 
 
 
Análise de Dados e Informações para o TCE RJ 
 
 Armazenamento de dados 
Uma view é considerada uma tabela virtual, pois ela pode ser acessada em consultas como se fosse uma tabela, 
só que ela geralmente não armazena dado nenhum. Na verdade, a view só guarda a consulta SQL que serviu de 
base para sua criação. 
Assim, na hora que um usuário ou programa de aplicação consultar os dados da view, o SGBD irá executar a 
consulta que foi armazenada e buscar os dados diretamente nas tabelas originais, conforme definido pela 
consulta. Isso garante que os dados estarão sempre atualizados de acordo com as tabelas de origem! 
Resumindo, as views são consideradas tabelas virtuais ou consultas