Curso de
Desenvolvimento de
Servidores - CDS
Disciplina
Introdução a Banco de Dados
Antônio Luiz Santana
Material Produzido por
Realização:
PROFa Claudinete Vicente Borges
Acesse: http://pse.ifes.edu.br/cds/site
Sumário
1. CONCEITOS DE BANCOS DE DADOS................................................................................................................... 9
1.1. DEFINIÇÃO ........................................................................................................................................................... 9
1.2. OBJETIVOS ........................................................................................................................................................... 9
1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS................................................................................................. 9
1.4. USUÁRIOS DE BANCO DE DADOS ................................................................................................................. 11
1.5. ABSTRAÇÃO DE DADOS.................................................................................................................................. 11
1.6. INDEPENDÊNCIA DE DADOS .......................................................................................................................... 12
1.7. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS [SILBERSCHATZ, 2006]..................................... 12
1.7.1. Sistemas Centralizados ................................................................................................................................. 12
1.7.2. Sistemas Cliente-Servidor ............................................................................................................................. 13
1.7.3. Sistemas Paralelos ........................................................................................................................................ 13
1.7.4. Sistemas distribuídos..................................................................................................................................... 14
1.8. MODELOS DE BANCOS DE DADOS................................................................................................................ 14
1.8.1. Modelo em Rede............................................................................................................................................ 14
1.8.2. Modelo Hierárquico...................................................................................................................................... 15
1.8.3. Modelo Relacional ........................................................................................................................................ 16
1.8.4. Modelo Objeto-Relacional ........................................................................................................................... 17
1.8.5. Modelo Orientados a Objetos ....................................................................................................................... 17
1.9. ESTRUTURA GERAL DO SISTEMA................................................................................................................. 18
1.9.1. Componentes de processamentos de consultas ............................................................................................. 18
1.9.2. Componentes para administração do armazenamento de dados .................................................................. 18
1.9.3. Outras estruturas de dados ........................................................................................................................... 18
1.10. LINGUAGEM DE DEFINIÇÃO DE DADOS (DDL) ........................................................................................ 19
1.11. LINGUAGEM DE MANIPULAÇÃO DE DADOS (DML)................................................................................ 20
1.12. PROJETANDO BANCOS DE DADOS............................................................................................................. 20
2. MODELAGEM DE DADOS ..................................................................................................................................... 24
2.1. DEFINIÇÃO ......................................................................................................................................................... 24
2.2. ENTIDADES ........................................................................................................................................................ 24
2.4. RELACIONAMENTO ......................................................................................................................................... 25
2.4.1. Cardinalidade de relacionamento................................................................................................................. 27
2.4.2. Tipos de Relacionamentos............................................................................................................................. 29
2.4.3. Atributos de Relacionamentos [FALBO, 2009] ............................................................................................ 30
2.4.4. Generalização / Especialização de conjuntos de entidades .......................................................................... 31
2.5. DICIONÁRIO DE DADOS .................................................................................................................................. 32
2.6. FERRAMENTAS CASE ...................................................................................................................................... 33
2.7. MODELO ER ESTENDIDO - EER ...................................................................................................................... 33
3. PROJETO LÓGICO DE BANCO DE DADOS....................................................................................................... 34
3.1. DEFINIÇÃO ......................................................................................................................................................... 34
3.2. ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS.............................................................................. 34
3.3. CHAVES............................................................................................................................................................... 35
3.4. PROPRIEDADES DO MODELO RELACIONAL [FALBO,2009] ..................................................................... 36
3.5.1. Relacionamento 1:1....................................................................................................................................... 38
3.5.2. Relacionamento 1:N...................................................................................................................................... 39
3.5.3. Relacionamento 1:N - identificado................................................................................................................ 39
3.5.4. Relacionamento N:N ..................................................................................................................................... 40
3.5.5. Generalização e Especialização ................................................................................................................... 40
3.5.6. Auto Relacionamento 1:N ............................................................................................................................. 41
3.5.7. Auto Relacionamento N:N............................................................................................................................. 42
3.5.8. Atributos Multivalorados .............................................................................................................................. 43
3.6. NORMALIZAÇÃO .............................................................................................................................................. 43
3.6.1. Primeira Forma Normal (1FN)..................................................................................................................... 43
3.6.2. Segunda Forma Normal (2FN) ..................................................................................................................... 44
3.6.3. Terceira Forma Normal (3FN) ..................................................................................................................... 45
4. LINGUAGENS DE CONSULTA.............................................................................................................................. 48
4.1. DEFINIÇÃO ......................................................................................................................................................... 48
4.2. ÁLGEBRA RELACIONAL.................................................................................................................................. 48
4.2.1 Operações Fundamentais............................................................................................................................... 49
4.2.2. Operações Não-Fundamentais...................................................................................................................... 54
4.3. SQL ....................................................................................................................................................................... 58
4.3.1. Estrutura Básica............................................................................................................................................ 59
4.3.2. Linhas (tuplas) duplicadas ............................................................................................................................ 60
4.3.3. Predicados e ligações.................................................................................................................................... 60
4.3.4. Operações de conjunto.................................................................................................................................. 62
4.3.5 Ordenando a exibição de tuplas..................................................................................................................... 62
4.3.6. Membros de conjuntos .................................................................................................................................. 63
4.3.7. Variáveis tuplas (renomeação) ..................................................................................................................... 63
4.3.8. Comparação de conjuntos............................................................................................................................. 64
4.3.9. Testando relações vazias............................................................................................................................... 64
4.3.10. Funções agregadas ..................................................................................................................................... 66
4.3.11. Removendo linhas de uma tabela................................................................................................................ 68
4.3.12. Inserindo linhas em uma tabela .................................................................................................................. 68
4.3.13. Atualizando valores..................................................................................................................................... 69
4.3.14. Valores Nulos .............................................................................................................................................. 70
4.3.15. Definição de dados...................................................................................................................................... 71
4.3.16. Tipos de Domínios da Linguagem SQL....................................................................................................... 72
4.3.17. Integridade .................................................................................................................................................. 73
4.3.18. Implementando Integridade Referencial em SQL ....................................................................................... 74
REFERÊNCIAS.............................................................................................................................................................. 77
1. CONCEITOS DE BANCOS DE DADOS
1.1. DEFINIÇÃO
Um banco de dados, também conhecido como base de dados, é um conjunto
de arquivos estruturados de forma a facilitar o acesso a conjuntos de dados.
Esses arquivos encontram-se, de alguma forma, relacionados. Por exemplo,
em um banco de dados de funcionários de uma empresa podemos encontrar
alguns arquivos: dados pessoais (nome, endereço, dados de documentos,
lotação), dados funcionais (cargo, data de admissão, etc.) e dados para
pagamento (salário base, faixas, etc.). Para obter informações sobre um dado
funcionário, como nome, cargo e salário, será necessário consultar os três
arquivos, que devem estar relacionados. Segundo Heuser, um banco de
dados é um conjunto de dados integrados, cujo objetivo é atender uma
comunidade de usuários [HEUSER, 2004].
Com o crescimento do volume e dos tipos de dados nas organizações, é
preciso utilizar softwares especiais para gerenciar os dados, os chamados
SGBDs (Sistemas Gerenciadores de Banco de Dados). Um SGBD é um
software de caráter geral para a manipulação eficiente de grandes coleções
de informações estruturadas e armazenadas de uma forma consistente e
integrada. Tais sistemas incluem módulos para consulta, atualização e as
interfaces entre o sistema e o usuário. Podemos afirmar, então, que um
SGBD é constituído por um conjunto de dados associados a um conjunto de
programas para acesso a eles [SILBERSCHATZ, 2006].
1.2. OBJETIVOS
Dentre os principais objetivos do uso de Sistemas Gerenciadores de Bancos
de Dados, destacam-se:

Disponibilizar dados integrados para uma grande variedade de
usuários e aplicações por meio de interfaces amigáveis;

Garantir a privacidade dos dados por meio de medidas de segurança
dentro do sistema (como visões, permissões, senhas de acesso);

Permitir compartilhamento dos dados de forma organizada,
mediando a comunicação entre aplicações e banco de dados e
administrando acessos concorrentes;

Possibilitar independência dos dados, poupando ao usuário a
necessidade de conhecer detalhes de implementação interna,
organização de arquivos e estruturas de armazenamento.
1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS
Os sistemas de processamento de arquivos caracterizam-se por uma série de
registros guardados em diversos arquivos e uma série de programas
aplicativos para extrair e adicionar registros nos arquivos apropriados.
9
Podemos citar como desvantagens desse sistema (arquivos), em relação aos
SGBD’s [SILBERSCHATZ,2006]:
Redundância e inconsistência de dados. Considerando que diferentes
programadores têm a possibilidade de criar arquivos com estruturas
diferentes e aplicações para acessá-los, a possibilidade de se redundar dados
por esses arquivos é muito grande. Além disso, em função dessa
redundância, poderão ocorrer as inconsistências, considerando que os dados
poderão ser atualizados em alguns arquivos e em outros não;
Dificuldade no acesso aos dados. Diferentemente dos SGBDs, os sistemas
de arquivos não possuem um ambiente para recuperação dos dados
armazenados. Com isso, para cada informação a ser gerada, é necessário
construir uma aplicação;
Isolamento de dados. Considerando a diversidade de formatos existen tes
dos arquivos e, consequentemente, dos dados armazenados neles, torna-se
uma tarefa difícil a construção de aplicações para a recuperação desses
dados;
Problemas de atomicidade. O conceito de atomicidade está altamente
relacionado ao de “átomo”, que se caracteriza como algo indivisível. Quando
se fala em atomicidade em banco de dados, fala-se de uma unidade de
trabalho que se deve executar totalmente ou que não se deve executar. Um
exemplo clássico de atomicidade seria uma transferência de dinheiro entre
duas contas, A e B. Se desejarmos transferir, por exemplo, R$ 100,00 da
conta A para a Conta B, ou o será transferido integralmente ou não ocorrerá
a transferência. Não é cabível que o dinheiro saia da conta A e não entre na
conta B, por exemplo!
Anomalias de acesso concorrente. Considerando o acesso simultâneo aos
arquivos, por diferentes aplicações ou por diferentes usuários de uma mesma
aplicação, pode-se gerar inconsistências nesses arquivos, devido a esses
acessos. Tomemos como exemplo que uma conta conjunta A - com saldo
igual a R$ 1000,00 - foi acessada de forma simultânea pelos correntistas
Gabriel e Luiza. Gabriel sacou R$100,00 e Luiza, R$200,00. Pergunta-se:
qual o saldo da conta após os saques? Se ambos leram o valor do saldo igual
a R$1000,00, podemos ter como possíveis valores : R$900,00, R$800,00,
levando-se em conta qual valor foi escrito por último. Nesse caso, nenhum
dos dois valores são os corretos. O correto seria ter um saldo igual a
R$700,00.
Problemas de segurança. Nem todos os usuários possuem perfil para
acessar a todos os dados disponíveis em um arquivo. Tomemos como
exemplo um arquivo de funcionários, que possui, entre outros dados, o valor
do salário do funcionário. Embora tenhamos a curiosidade de saber o salário
dos nossos colegas, principalmente do nosso chefe, não é politicamente
correto que desrespeitemos seu direito à privacidade. No entanto, não é
possivel definir, para um arquivo, que alguns campos poderão ser visíveis
por um usuário e por outros não, o que gera vulnerabilidade nesses sistemas;
Problemas de integridade. Para explicar melhor esse item, tomemos como
exemplo dois arquivos, um de sócios e outro de dependentes, de uma
locadora de vídeo. Um dependente está relacionado a um sócio e, por
consequência, a existência daquele depende da existência deste, ao qual
10
estará subordinado. Desse modo, a exclusão de um sócio acarreta a exclusão
de seus dependentes. Esse tipo de integridade, denomina-se de “integridade
referencial”, porém, existem outras mais simples que os arquivos não
comportam.
1.4. USUÁRIOS DE BANCO DE DADOS
Basicamente são quatro os tipos de usuários de sistemas de bancos de dados:
Usuários leigos: interagem com o banco de dados por meio das interfaces de
aplicações escritas por programadores de aplicações;
Usuários avançados: interagem com os bancos de dados por meio de
interfaces disponíveis nesse ambiente. Escrevem consultas SQL e submetem
à execução sem a necessidade de escrever uma aplicação para esse fim;
Programadores aplicações: usuários com formação em computação e que
se propõem a construir aplicações, por meio de ferramentas (compiladores)
destinadas para esse fim. Utilizando essas ferramentas, constroem interfaces
para as aplicações, incluindo formulários e relatórios, acessando bancos de
dados;
Administrador de Banco de Dados (DBA): usuários mais especializados
para um banco de dados. Cabe a eles a administração dessas bases, definição
da melhor estrutura de armazenamento desses dados, definição de aspectos
de segurança, programação de cópias de segurança (backup’s), dentre outros.
1.5. ABSTRAÇÃO DE DADOS
Considerando que o nível de conhecimento dos usuários de bancos de dados
é muito variável, oscilando entre aqueles que conhecem muito e outros que
são leigos, os Sistemas de Bancos de Dados devem prover de mecanismos
que administrem essa complexidade, simplificando as interações dos
usuários com o sistema. Para isso, três níveis de abstração são considerados:
Nível de Visão. Diz respeito à forma como os dados são vistos pelos
usuários (individualmente). Diferentes usuários poderão ter diferentes visões
de um mesmo banco de dados. Um determinado usuário, tanto pode ser um
programador de aplicações, quanto um usuário final. O DBA é um caso
especialmente importante. Ao contrário dos usuários comuns, o DBA terá
de se interessar pelos níveis conceitual e físico.
Lógico. O nível lógico descreve quais dados estão armazenados no banco de
dados e qual a relação existente entre eles. Podemos dizer que a visão lógica
é a visão dos dados “como realmente são” e não como os usuários são
forçados a vê-los devido às restrições de linguagem ou hardware.
Físico. Diz respeito à forma como os dados estão armazenados fisicamente.
Preocupa-se em descrever as estruturas de dados complexas de baixo nível.
11
A figura 1 representa graficamente os níveis listados acima.
Visão 1
Visão 2
...
Visão n
Nível Lógico
Nível Físico
Figura 1: Níveis de abstração de dados
Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptação.
1.6. INDEPENDÊNCIA DE DADOS
A independência de dados pode ser definida como a imunidade das
aplicações às alterações feitas, seja no nível físico seja no nível lógico de um
banco de dados. O objetivo é alcançar o máximo de independência possível.
Pode ser classificada em:
Independência Física de dados: habilidade de modificar o esquema físico,
sem a necessidade de reescrever os programas aplicativos. As modificações
no nível físico são ocasionalmente necessárias para melhorar o desempenho.
Independência Lógica de dados: habilidade de modificar o esquema
conceitual, sem a necessidade de reescrever os programas aplicativos. As
modificações no nível conceitual são necessárias quando a estrutura lógica
do banco de dados é alterada.
1.7. ARQUITETURA DE SISTEMAS DE BANCO DE
DADOS [SILBERSCHATZ, 2006]
A arquitetura de um sistema de banco de dados está altamente relacionada
às características do sistema operacional sobre o qual o SGBD será
executado.
1.7.1. Sistemas Centralizados
Os sistemas centralizados são os executados sobre um único sistema
operacional, não interagindo com outros sistemas. Eles podem ter a
envergadura de um sistema de banco de dados de um só usuário, executado
12
em um computador pessoal ou em sistemas de alto desempenho,
denominados de grande porte.
1.7.2. Sistemas Cliente-Servidor
Como os computadores pessoais têm se tornado mais rápidos, mais potentes
e baratos, há uma tendência de seu uso nos sistemas centralizados. Terminais
conectados a sistemas centralizados estão sendo substituídos por
computadores pessoais. Como resultado, os sistemas centralizados
atualmente agem como sistemas servidores que atendem a solicitações de
sistemas clientes.
A computação cliente-servidor é um processamento cooperativo de
informações de negócio por um conjunto de processadores, no qual
múltiplos clientes iniciam requisições que são realizadas por um ou mais
servidores centrais.
O termo cliente-servidor é usado para descrever software que executa em
mais de um hardware de modo a realizar uma tarefa do negócio. A separação
de hardware é a norma em aplicações cliente-servidor, embora algumas
pessoas utilizem o termo para descrever diferentes componentes de software
se comunicando uns com os outros, ainda que rodando em uma mesma
máquina. A distância entre processadores remotos varia desde computadores
localizados na mesma sala ou prédio, até aqueles localizados em diferentes
prédios, cidades ou mesmo espalhados pelo planeta.
Nessa arquitetura, as funcionalidades de um banco de dados podem ser
superficialmente divididas em duas categorias: front-end e back-end. O
back-end gerencia as estruturas de acesso, o desenvolvimento e a otimização
de consultas, o controle de concorrência e a recuperação. O front-end
consiste em ferramentas como formulários, gerador de relatórios e recursos
de interface gráfica. A interface entre o front-end e o back-end é feita por
meio de SQL ou de um programa de aplicação.
1.7.3. Sistemas Paralelos
Sistemas paralelos imprimem velocidade ao processamento e à CPU, por
meio do uso em paralelo de CPU’s e discos.
No processamento paralelo muitas operações são realizadas ao mesmo
tempo, ao contrário do processamento serial, no qual os passos do
processamento são sucessivos. Um equipamento paralelo de granulaçãogrossa consiste em poucos e poderosos processadores (a maioria dos
servidores atuais), enquanto um paralelismo intensivo ou de granulação fina
usa milhares de pequenos processadores, com capacidade menor de
processamento. Computadores paralelos com centenas de processadores já
estão disponíveis comercialmente.
As duas principais formas de avaliar o desempenho de um sistema de banco
de dados são pelo throughput e pelo tempo de resposta. O primeiro diz
respeito ao número de tarefas que podem ser executadas em um dado
13
intervalo de tempo. Um sistema que processa um grande número de
pequenas transações pode aumentar o throughput por meio do
processamento de diversas transações em paralelo. Já o tempo de resposta
diz respeito ao tempo total que o sistema pode levar para executar uma única
tarefa. Um sistema que processa um grande volume de transações pode
reduzir o tempo de resposta por meio de processamento em paralelo.
1.7.4. Sistemas distribuídos
Em um sistema distribuído, o banco de dados é armazenado,
geograficamente, em diversos computadores, denominados sites. Os
computadores de um sistema de banco de dados distribuídos comunicam-se
com outros, por intermédio de vários meios de comunicação, como redes de
alta velocidade ou linhas telefônicas.
As principais diferenças entre os bancos de dados paralelos e os bancos de
dados distribuídos são que, nos bancos de dados distribuídos, há a
distribuição física geográfica, a administração ocorre de forma separada e há
uma intercomunicação menor. Outra grande diferença é que nos sistemas
distribuídos distinguimos transações locais (acessa um único computador,
em que a transação foi iniciada) e globais (envolve mais de um computador,
sendo necessária a participação de um coordenador).
Há diversas razões para a utilização de sistemas de bancos de dados
distribuídos, dentre as quais: compartilhamento dos dados (usuários de um
local podem ter acesso a dados residentes em outros – por exemplo: bancos),
autonomia (cada local administra seus próprios dados) e disponibilidade (se
porventura uma SGBD sai do ar, os demais podem continuar em operação).
Há, no entanto, algumas desvantagens relacionadas ao seu uso, dentre as
quais: custo de desenvolvimento de software, maior possibilidade de bugs e
aumento do processamento e sobrecarga.
1.8. MODELOS DE BANCOS DE DADOS
Os modelos de bancos de dados definem a forma como os dados encontramse organizados internamente. Em ordem cronológica, os modelos de banco
de dados classificam-se em redes, hierárquicos, relacionais, objetorelacionais e orientados a objetos. A seguir, há uma breve descrição sobre
cada um desses modelos.
1.8.1. Modelo em Rede
Um banco de dados em rede consiste em uma coleção de registros que são
concatenados uns aos outros por meio de ligações. Um registro é, em muitos
aspectos, similar a uma entidade no modelo entidade-relacionamento. Uma
ligação é uma associação entre dois registros. Assim, uma ligação pode ser
vista como um relacionamento binário no modelo ER [SILBERSCHATZ,
2006].
14
Tanto o Modelo Rede como o Modelo Hierárquico podem ser considerados
como estruturas de dados em nível lógico mais próximo do nível físico.
Devido a essa proximidade ao nível físico, as estruturas de dados rede e
hierárquica exibem as rotas lógicas de acesso de dados de forma acentuada,
possibilitando a localização lógica de um determinado registro no banco de
dados.
O Modelo Relacional, quando comparado à Estrutura Rede e Hierárquica, é
mais orientado para modelagem do que como modelo com rotas de acesso,
embora possamos considerar as diversas redundâncias existentes em diversas
tabelas como sendo uma forma de rota de acesso.
O Modelo Rede utiliza como elemento básico de dados a ocorrência de
registro. Um conjunto de ocorrência de registro de um mesmo tipo determina
um tipo de registro.
Um conjunto de tipos de registros relacionados entre si, por meio de
referências especiais, forma uma estrutura de dados em rede. As referências
especiais são conhecidas como ligações, que, por sua vez, podem ser
implementadas sob a forma de ponteiros.
As referências estão normalmente inseridas junto com as ocorrências de
registro; assim, todo o acesso a um próximo registro utiliza o ponteiro
inserido no registro corrente disponível.
Considere um banco de dados com registros de departamento e
empregado, em que empregado possui as seguintes características:
matrícula, nome e cidade; e departamento: código e nome. A figura 2
mostra um exemplo do banco de dados, considerando os dois tipos de
registros informados.
Figura 2: Exemplo de Banco de Dados – Modelo Redes.
O modelo de banco de dados da Figura 2 mostra as ligações entre os
registros de departamento e empregado. Luiza, por exemplo, está lotada no
departamento de informática, enquanto o departamento de Geografia, por
exemplo, possui dois funcionários lotados, Matheus e Gabriel.
1.8.2. Modelo Hierárquico
Um banco de dados hierárquico consiste em uma coleção de registros
relacionados, uns aos outros, por meio de ligações, como no modelo em
redes. A diferença entre eles se dá pelo fato de o banco de dados hierárquico
15
organizar esses registros como coleções de árvores, em vez de gráficos
arbitrários.
Um banco de dados hierárquico compõe-se de um conjunto ordenado de
árvores, mais precisamente, de um conjunto ordenado de ocorrências
múltiplas de um tipo único de árvore.
O tipo árvore compõe-se de um único tipo de registro “raiz”, juntamente
com um conjunto ordenado de zero ou mais (nível inferior) tipos de subárvores dependentes. Um tipo de subárvore, por sua vez, também se compõe
de um único tipo de registro. A associação entre tipos de registros segue uma
hierarquia estabelecida por diversos níveis. No primeiro nível, o superior,
situa-se o tipo de registro “Raiz” . Subordinado a ele, em nível 2, uma série
de outros tipos de registros em nível 2. A cada tipo de registro em nível 2
subordina-se um outro conjunto de tipos de registros. A própria estrutura
hierárquica define as suas rotas de acesso, facilitando, portanto, a
manutenção do banco de dados.
É importante notar que um determinado tipo de registro A, num determinado
nível K, possui ligação com um e somente um tipo de registro B, de nível K1 (superior). Nessas condições, A é denominado registro PAI de B, que, por
sua vez, é registro FILHO de A . No entanto, um tipo de registro A pode
estar ligado a diversos filhos no nível de B. Todas as ocorrências de um dado
tipo de filho que compartilham uma ocorrência de pai comum são chamadas
de gêmeas.
Uma vantagem dos bancos de dados hierárquicos é o tempo de resposta em
consultas. No entanto, a atualização pode ser bastante custosa.
Figura 3: Exemplo de Banco de Dados – Modelo Hierárquico.
1.8.3. Modelo Relacional
O modelo relacional, diferentemente dos modelos redes e hierárquico, usa
um conjunto de tabelas para representar tanto os dados quanto a relação
entre eles. As ligações entre as tabelas é feita por meio dos valores dos
atributos ou colunas, conforme descrito posteriormente. Cada tabela possui
múltiplas colunas, conforme Tabela 1 e Tabela 2.
Matricula
01
02
Nome
Maria
Matheus
Cidade
Vitória
Vila Velha
CodDepto
01
02
16
03
04
Gabriel
Joana
Serra
Aracruz
02
03
Tabela 1: Tabela de Empregados.
CodDepto
01
02
03
NomeDepto
Informática
Geografia
Português
Tabela 2: Tabela de Departamentos.
1.8.4. Modelo Objeto-Relacional
O modelo objeto-relacional, também conhecido como relacional estendido, é
um modelo intermediário entre o relacional e o orientado a objetos. Na
verdade, os bancos de dados que se enquadram nesse modelo caracterizamse por usar a estrutura básica do modelo relacional, incorporando algumas
características dos bancos de dados orientados a objetos. Características
estas que incluem : herança de tipos e tabelas e definição de novos tipos
complexos. A SQL-99 inclui recursos para dar suporte a esse modelo de
banco de dados.
1.8.5. Modelo Orientados a Objetos
O modelo relacional, hierárquico e redes foram muito bem sucedidos no
desenvolvimento da tecnologia de banco de dados necessária para a maioria
das aplicações convencionais de bancos de dados comerciais, possuindo,
entretanto, algumas limitações quando aplicações mais complexas precisam
ser projetadas e implementadas, tais como sistemas de informações
geográficas e multimídias. Essas aplicações têm requisitos e características
que as diferenciam das tradicionais aplicações comerciais, tais como
estruturas complexas para objetos, armazenamento de imagens e textos
longos, dentre outras, além da necessidade de definir operações não
convencionais (NAVATE, 2005).
A abordagem orientada a objetos oferece a flexibilidade para lidar com
alguns desses requisitos, sem estar limitada pelos tipos de dados e
linguagens de consulta disponíveis em sistemas de banco de dados
tradicionais. Nesses bancos, o projetista especifica a estrutura de objetos
complexos bem como as operações que incidem sobre esses objetos.
Outra razão para o uso de banco de dados orientados a objetos é a
predominância das linguagens orientadas a objetos. No caso de uma
aplicação orientada a objetos utilizar um banco de dados relacional para
persistir os dados, é necessário fazer um mapeamento entre esses dois
mundos, o que dá trabalho, considerando as limitações impostas pelo modelo
relacional.
Embora existam muitos benefícios para a adoção do modelo orientado a
objetos, esses bancos de dados não foram muito bem aceitos no mercado, em
função da simplicidade do modelo relacional. Com isso, há uma proposta de
17
um modelo híbrido, denominado objeto-relacional ou relacional estendido,
que se propõe a implementar alguns conceitos de orientação a objetos sobre
a estrutura de um banco de dados relacional. Alguns SGBD´s proprietários e
livres disponíveis no mercado enquadram-se nesse modelo, a exemplo do
Oracle e do PostegreeSQL.
1.9. ESTRUTURA GERAL DO SISTEMA
O sistema de banco de dados é dividido em módulos específicos, de modo a
atender a todas as suas funções, algumas delas fornecidas pelo sistema
operacional. Esses módulos podem ser organizados em dois grandes grupos:
o de processamentos de consultas e o de administração do armazenamento
de dados. A Figura 4 mostra como esses componentes se relacionam.
1.9.1. Componentes de processamentos de consultas
Compilador DML.: traduz comandos DML da linguagem de consulta em
instruções de baixo nível, inteligíveis ao componente de execução de
consultas.
Interpretador DDL: interpreta os comandos DDL e registra-os em um
conjunto de tabelas que contêm metadados, “dados sobre dados”.
Componentes para o tratamento de consultas: executam instruções de
baixo nível geradas pelo compilador DML.
1.9.2.
Componentes
para
armazenamento de dados
administração
do
Gerenciamento de autorizações e integridade: testa o cumprimento das
regras de integridade e a permissão ao usuário no acesso aos dados.
Gerenciamento de transações: garante que o banco de dados permanecerá
em estado consistente, a despeito de falhas no sistema, e que as transações
concorrentes serão executadas sem conflitos em seus procedimentos.
Gerenciador de arquivos: gerencia a alocação de espaço no
armazenamento em disco e as estruturas de dados usadas para representar
essas informações armazenadas em disco.
Gerenciador de buffer: intermedia os dados entre o disco e a memória
principal e decide quais dados colocar em cachê.
1.9.3. Outras estruturas de dados
Diversas outras estruturas de dados são requeridas como parte da
implementação do sistema físico, incluindo:
18
Arquivo de Dados: armazena o banco de dados.
Dicionário de Dados: armazena informações sobre os dados do banco de
dados.
Índices: permite o acesso mais rápido aos dados.
Estatísticas: armazenam informações sobre o banco de dados e são usadas
pelo seletor de estratégias.
Figura 4: Estrutura Geral do Sistema
Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptação.
1.10. LINGUAGEM DE DEFINIÇÃO DE DADOS (DDL)
Contém a especificação dos esquemas dos bancos de dados. O resultado da
compilação de uma consulta de definição de dados (DDL) é armazenado em
um conjunto de tabelas que constituem um arquivo especial chamado
dicionário de dados. Um dicionário de dados é um arquivo de metadados.
19
1.11. LINGUAGEM DE MANIPULAÇÃO DE DADOS
(DML)
A linguagem de manipulação de dados (DML) é a linguagem que viabiliza o
acesso aos dados ou a sua manipulação de forma compatível com o modelo
de dados apropriado.
São responsáveis pela:

Recuperação da informação armazenada no banco de dados
(SELECT);

Inserção de novos dados nos bancos de dados (INSERT);

Eliminação de dados nos bancos de dados (DELETE);

Modificação de dados armazenados no banco de dados (UPDATE);
1.12. PROJETANDO BANCOS DE DADOS
Antes de criarmos o banco de dados propriamente dito devemos identificar
uma forma de planejá-la. Esse planejamento é extremamente importante para
a estabilidade de todo o sistema. Estudos indicam que quanto maior o tempo
gasto no projeto do banco de dados, menor será o tempo despendido na
manutenção do modelo.
Podemos comparar a criação de um sistema de banco de dados com a
construção de uma casa. Imagine que seja construída uma casa sem que
antes tenha sido feito um projeto de arquitetura, incluindo plantas baixas,
cortes e fachadas. Provavelmente, no futuro, ao submeter essa casa à
manutenção, o proprietário teria o inconveniente de construir quartos do lado
da cozinha ou mesmo ter que fazer “puxadinhas” para realizar a ampliação
da mesma. O mesmo acontece com sistemas mal-projetados ou nãoprojetados. Eles tornam-se pouco flexíveis a manutenções futuras, quando
for necessário agregar novas informações ou mesmo, quando submetidos a
correções.
O processo de projetar um banco de dados inclui três fases distintas e
integradas. A primeira delas consiste na construção de um modelo
conceitual. O Modelo Conceitual inclui características a serem incluídas no
sistema, mas que independem da tecnologia a ser utilizada, tanto de banco de
dados quanto de linguagem de programação. A segunda fase pressupõe a
construção de um modelo lógico, tendo como base o Modelo Conceitual
criado e inclui a definição de tabelas, campos, restrições de integridade, etc.
Nesse modelo, considera-se a tecnologia do banco de dados a ser usado,
como: relacional, orientado a objetos, etc. A terceira fase, que extrapola a
fase de projeto, consiste na criação física do banco de dados, tendo a
preocupação com estruturas de armazenamento e recuperação dos dados a
serem armazenados. Nos capítulos que se seguem serão explorados a
modelagem conceitual e o projeto lógico de banco de dados, considerando o
modelo relacional.
20
Atividade 01
Faça os exercícios de fixação abaixo, referente ao capitulo 1.
1) Defina SGBD´s.
2) Cite duas desvantagens do uso de sistemas de arquivos em
relação a SGBD´s.
3) Defina uma vantagem de se usar sistemas de arquivos em
relação a SGBD.
4) Cite as quatro arquiteturas de banco de dados existentes no
mercado. Descreva, em poucas linhas, as características de
cada uma delas.
5) Quais são os níveis de abstração proporcionados por um
SGBD? Enquadre, para cada grupo de usuário, abaixo
listados, o nível em que o mesmo se encontra.
a. Administrador de Banco de Dados
b. Usuário de aplicações
c. Programador e Analista de Aplicações
6) Liste, em ordem cronológica, os modelos de bancos de
dados existentes no mercado. Qual modelo de banco de dados
será utilizado em nossa disciplina?
21
Atividade 02
1) Dadas as relações abaixo, responda ao que se pede.
Funcionário
Matricula
01
02
03
04
05
06
Cargos
Código
01
02
03
04
05
Nom
e
Ana
Maria
José
Pedro
Joana
João
CPF
Cargo
123
234
245
125
435
467
2
1
3
1
2
1
Nome Cargo
Programador
Topógrafo
Engenheiro
Pedreiro
Motorista
Liste os nomes dos funcionários para os seguintes cargos:
Topógrafo; Engenheiro; Programador:
Para quais cargos não há funcionários lotados?
2) Informe se cada uma das consultas abaixo será executada
pelo Compilador DML ou pelo Interpretador DDL.
a) create table...
b) create view...
c) insert into tabela...
d) alter table...
e) delete from tabela...
f) update tabela set campo 1 = valor 1, campo2 = valor2...
22
Atividade 03
1) Numere a segunda coluna de acordo com a primeira.
1. Possibilidade de
erros de acesso
concorrente
( ) Refere-se à precisão ou
validade dos dados.
2. Abstração
dados
( ) Tarefa de um SGBD.
de
3. Integridade
( ) Se alterar o esquema
conceitual, não é necessário
reescrever aplicações.
4. Instância
(
)
Responsável
pela
modificação
de
dados
armazenados no banco de
dados.
5. Independência
lógica de dados
( ) Se alterar o esquema físico,
não é necessário reescrever
aplicações.
6. Independência
física de dados
( ) Contém a especificação dos
esquemas de banco.
7. Controle
concorrência
de
( ) Conjunto de informações
contidas em determinado banco
de dados, em um determinado
momento.
8. Linguagem de
Definição de Dados
(DDL)
( ) Trata-se de um modelo de
banco de dados.
9. Linguagem de
Manipulação
de
Dados (DML)
( ) Os usuários não precisam
saber como os dados são
armazenados e mantidos.
10.
ObjetoRelacional
( ) Desvantagem de sistemas de
arquivos.
23
2. MODELAGEM DE DADOS
2.1. DEFINIÇÃO
O principal objetivo da modelagem conceitual de dados é construir modelos
que representem os requerimentos das informações do negócio, segundo a
perspectiva do usuário. Partindo desse princípio, ao construir modelos
conceituais não há uma preocupação com a tecnologia a ser adotada para a
sua implementação. Um modelo de dados consiste em uma coleção de
ferramentas conceituais para descrição de dados, relacionamento entre os
dados, semântica e restrições [SILBERSCHATZ,2006]. Neste capítulo
exploraremos o modelo de entidades e relacionamentos (ER) para construção
de modelos de dados, considerando que se trata da técnica de modelagem
mais difundida para representação de modelos conceituais.
O modelo ER é uma técnica de modelagem conceitual utilizada para
representar os dados a serem armazenados em um sistema de informação,
tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos
de dados [CHEN,1990]. Esse modelo foi criado em 1976 por Peter Chen e
pode ser considerado como padrão para a modelagem conceitual.
Basicamente, o modelo ER representa as entidades (coisas) e os
relacionamentos (fatos) do mundo real, em que há o interesse de monitorar o
comportamento no sistema de informação em tese.
2.2. ENTIDADES
Entidades são representações abstratas de “coisas”, “objetos” do mundo real
modelado, para os quais temos interesse em manter informações no banco de
dados. Podem representar tanto objetos concretos quanto abstratos. Quando
se trata de conjuntos de objetos com características semelhantes, usualmente
se denomina conjunto de entidades. Por exemplo, quando nos referimos ao
conjunto de entidade “Departamentos” estamos falando de um conjunto de
departamentos. Quando nos referimos ao departamento de informática,
estamos falando da entidade, de uma instância do conjunto.
Um conjunto de entidades será representado por meio de um retângulo
contendo o nome do conjunto de entidades, em letra maiúscula e no plural,
conforme mostra exemplo da Figura 5.
Ex: FUNCIONÁRIOS, CARGOS, PESSOAS ...
Figura 5: Exemplo de representação de conjunto de entidades
Características dos conjuntos de entidades [FALBO, 2009]:

São substantivos e perduram no tempo.

Cada elemento de um conjunto de entidades só ocorre uma única vez
e a ordenação do conjunto é irrelevante.
24

A princípio são representados em um conjunto de entidades todos os
elementos do mundo real referidos pelo conjunto. Ex:
FUNCIONÁRIOS = todos os funcionários de uma empresa.

Para estabelecermos uma padronização, usaremos nomes de
conjuntos de entidades sempre no plural e escritos em letras
maiúsculas. No entanto, isso não representa uma regra.
2.3. ATRIBUTOS
Descrevem propriedades relevantes de um conjunto de entidades. Podem ser
representados no diagrama ou em um dicionário de dados. Adotaremos esta
última abordagem com o intuito de mantermos um modelo mais legível.
Seguem algumas características de atributos, segundo Falbo (2009):

Um atributo deve ser Completo e Fatorado, ou seja, deve abranger
todas as informações pertinentes e cada atributo deve capturar um
aspecto em separado.

Existem atributos que podem assumir um único valor ou múltiplos
valores,
sendo
classificados
como
monovalorados
ou
multivalorados, respectivamente. Como exemplo de atributos
monovalorados, podemos citar o nome de um funcionário. O
telefone de um funcionário é um atributo multivalorado, pois pode
assumir múltiplos valores ao mesmo tempo ou até mesmo nenhum
valor.
Ao definir um atributo de um conjunto de entidades, é importante também
definir a obrigatoriedade de preenchimento do mesmo. Um atributo para o
qual não haja um valor associado ou este valor não seja conhecido no
momento da criação da entidade, então este atributo deve ser modelado para
aceitar valores vazios – ou nulos.
Na criação de um conjunto de entidade deve-se definir um identificador. Um
identificador é um conjunto de um ou mais atributos que podem ser
utilizados para identificar uma entidade dentro do conjunto. Por exemplo, a
matrícula de um funcionário pode ser um atributo identificador,
considerando que cada funcionário terá uma matrícula única. O atributo
nome, no entanto, não pode ser usado para identificar um funcionário,
considerando que existem homônimos.
2.4. RELACIONAMENTO
Na seção anterior descrevemos atributos de conjuntos de entidades, que são
propriedades dos objetos a serem armazenados em um banco de dados. Além
dos atributos, os conjuntos de entidades caracterizam-se por relacionar-se
com outros conjuntos de entidades, inclusive com ela mesma. A essas
associações denominamos relacionamentos, conjunto de associações entre
entidades (HEUSER, 2004).
Neste texto adotaremos a seguinte notação: um relacionamento será
representado por um losango com um verbo para indicar a ação e uma seta
para informar o sentido de leitura, conforme mostra a Figura 6 abaixo.
25
Figura 6: Exemplo de representação de relacionamento
A leitura feita para o relacionamento da Figura 6 é “funcionários são
enquadrados em cargos”. Todo relacionamento possui uma leitura inversa;
assim, uma outra leitura do relacionamento seria “cargos enquadram
funcionários”.
O relacionamento existente entre os conjuntos de entidades funcionários e
cargos é um relacionamento binário, pois se trata de uma associação entre
dois conjuntos de entidades. Quando o relacionamento envolve três
conjuntos de entidades é conhecido como ternário.
Outros exemplos de relacionamentos:

Alunos cursam disciplinas / Disciplinas são cursadas por alunos;

Editoras publicam livros / Livros são publicados por editoras;

Autores escrevem livros / Livros são escritos por autores;
Para facilitar a visualização foi construído um diagrama de ocorrência,
referente ao modelo ER da Figura 6. Esse diagrama se propõe a mostrar as
ocorrências de entidades do conjunto funcionários, representadas por : f1, f2,
..., fn; as ocorrências do conjunto cargos, representadas por : c1, c2, .., cn e
dos relacionamentos existentes entre as entidades do conjunto de
funcionários e de cargos. O funcionário f1 está enquadrado no cargo c1
através do relacionamento r1. O cargo c1, por outro lado, possui os
funcionários f1 e f3, nele enquadrados, através dos relacionamentos r1 e r3.
FUNCIONÁRIOS
ENQUADRAMENTOS
r
CARGOS
1
f
f1
f
2
f3
f4
f5
f6 .
7
.
.
r
2
c
3
1c
r
r
4
r
5
r
2
c
.
.
.
3
6
r
7
Figura 7: Diagrama de ocorrências
Fonte: Heuser, 2004. Adaptação.
Entre duas entidades, podem existir vários tipos de relacionamentos. A
Figura 8 mostra os relacionamentos de alocação e de gerência entre os
mesmos conjuntos de entidades : FUNCIONÁRIOS e PROJETOS.
26
Figura 8: Entidades com dois tipos de relacionamento
Além disso, uma entidade pode participar de relacionamentos com quaisquer
outras entidades do modelo, inclusive com ela mesma, como mostra o
relacionamento “chefiam” na Figura 9. Nesse caso, denomina-se que há um
auto-relacionamento do conjunto de entidades FUNCIONÁRIOS.
Figura 9: Exemplo de auto-relacionamento
2.4.1. Cardinalidade de relacionamento
Indica os números mínimo (cardinalidade mínima) e máximo (cardinalidade
máxima) de ocorrências possíveis, entre dois conjuntos de entidades, em um
relacionamento. No diagrama de ocorrência da Figura 7, observamos que :
um cargo pode enquadrar vários funcionários, enquanto que um funcionário
deve ser enquadrado em apenas um cargo.
A Figura 10 mostra a representação de cardinalidade no modelo ER. A
leitura é feita da seguinte forma: um funcionário é enquadrado em, no
mínimo 1 e no máximo 1 cargo, enquanto um cargo pode enquadrarno
mínimo zero e no máximo n funcionários. N é um número arbitrário.
Quando conhecemos esse número podemos representá-lo, em vez de o
determinarmos pela letra N. Para efeito de projeto de banco de dados, o
tratamento dado para esse número arbitrário é o mesmo, para qualquer valor
maior que 1.
27
Figura 10: Entidades com dois tipos de relacionamento
28
2.4.2. Tipos de Relacionamentos
O tipo de relacionamento é uma classificação baseada na cardinalidade
máxima, podendo ser : 1:1, 1:N, N:1 e N:N. A seguir, serão explorados
todos os tipos de relacionamentos sobre um relacionamento existente entre
os conjuntos de entidades : FUNCIONÁRIOS E PROJETOS.
Relacionamento 1:1
A Figura 11 mostra um exemplo de relacionamento do tipo 1:1. Cada
Funcionário ou Projeto podem aparecer no máximo em um único par do
relacionamento Gerenciam (Funcionário, Departamento). Nesse caso,
podemos dizer que um funcionário pode gerenciar no máximo um projeto,
ou mesmo nenhum, enquanto um projeto só deve ter um gerente.
Figura 11: Exemplo de relacionamento 1:1
Relacionamento 1:N
A Figura 12 mostra um exemplo de relacionamento do tipo 1:N. Cada
Projeto pode aparecer no máximo em um único par do relacionamento
Gerenciam, enquanto um Funcionário pode aparecer em um número
arbitrário de vezes. Nesse caso, podemos dizer que um funcionário pode
gerenciar vários projetos, enquanto um projeto só pode ter um gerente (tem
que haver pelo menos 1!).
Figura 12: Exemplo de relacionamento 1:N
29
Relacionamento N:N
A Figura 13 mostra um exemplo de relacionamento do tipo N:N. Cada
Funcionário ou Projeto podem aparecer em um número arbitrário de vezes
do relacionamento Gerenciam. Nesse caso, podemos dizer que um
funcionário pode gerenciar vários projetos, enquanto um projeto pode ter
vários gerentes.
Figura 13: Exemplo de relacionamento N:N
Um outro conceito relacionado aos relacionamentos N:N é o de “Entidade
Associativa”, também referenciada por alguns autores, como “Agregação”.
Uma Entidade Associativa é uma abstração por meio da qual
relacionamentos entre duas entidades são tratados como entidades em um
nível mais alto de abstração. Essa “nova entidade”, a associativa, pode,
então, relacionar-se com outras entidades do modelo, como mostra a Figura
14. Um correntista é uma agregação envolvendo os conjuntos de entidades
Clientes e Contas Correntes.
Figura 14: Exemplo de agregação N:N [Falbo, 2009]
2.4.3. Atributos de Relacionamentos [FALBO, 2009]
Assim como as entidades, os relacionamentos também podem ter atributos,
porém apenas os atributos de relacionamentos N:N são caracterizados como
atributos de relacionamentos, os demais podem ser enquadrados em um dos
conjuntos de entidades envolvidos no relacionamento.
30
Para os relacionamentos N:N há um teste que pode ser aplicado para se
deduzir se um atributo é de um dos dois conjuntos de entidades ou se é do
relacionamento.
Figura 15: Exemplo de relacionamento N:N [Falbo, 2009]
Fixa-se um material, como uma impressora, e variam-se os fornecedores
desse material. Se o valor do atributo mudar ao variarmos o elemento do
outro conjunto de entidades, é porque este não é atributo do primeiro
conjunto de entidades, no caso MATERIAIS.
O Procedimento análogo deve ser feito, agora, para a outra entidade.
Fixando-se um fornecedor e variando-se os materiais temos: A Eletrocity
vende uma impressora por R$ 350,00 e um microcomputador por R$
2.000,00. O fato de o valor do atributo ter variado para a mesma entidade
indica que ele não é atributo de FORNECEDORES.
Se não é atributo nem de MATERIAIS, nem de FORNECEDORES, então é
um atributo do relacionamento entre os dois conjuntos de entidades.
2.4.4. Generalização / Especialização de conjuntos de
entidades
Por muitas vezes, incluímos nos modelos ER’s conjuntos de entidades com
diversas características em comum, diferenciando apenas em algumas delas.
Nesse caso, usando o conceito de generalização, pode-se criar um conjunto
de entidades genérico, contendo as características em comum, e
especializam-se as demais com características parcialmente distintas. Um
exemplo clássico é o de pessoa física em jurídica. Observe que existem
várias características em comum entre ambas as pessoas, a exemplo de :
nome, endereço e telefone. Uma pessoa física, no entanto, além dessas
características comuns, possui : sexo e CPF. Uma pessoa jurídica, além
dessas características comuns, possui CNPJ e atividade principal. A Figura
16 mostra a representação desse conceito no modelo ER.
31
Figura 16: Exemplo de generalização / especialização
As entidades: PESSOAS FÍSICAS e JURÍDICAS herdam as características
de clientes e incorporam outras adicionais, que são peculiares de cada um.
Um cliente pode ser pessoa física, jurídica ou nenhum dos dois, mas toda
pessoa física ou jurídica é cliente.
Entidade Fraca
Um outro conceito referenciado nos modelos ER’s é o de Entidade Fraca.
Uma entidade fraca é uma entidade que não tem existência própria. Ela só
aparece no modelo quando relacionada a outra entidade – intitulada como
forte, sendo seus atributos identificadores compostos por pelo menos dois
campos, sendo um deles um atributo da entidade forte. A Figura 17 mostra
um exemplo em que o conjunto de entidades DEPENDENTES é
denominada “entidade fraca”. Para a identificação de um dependente é
necessário que se tenha informação do sócio. Os relacionamentos com essa
característica são denominados identificados.
Figura 17: Exemplo de entidade fraca
2.5. DICIONÁRIO DE DADOS
O Dicionário de Dados é uma listagem organizada de todos os elementos de
dados pertinentes ao sistema, com definições precisas para que os usuários e
desenvolvedores possam conhecer o significado de todos os itens de dados
manipulados pelo sistema.
Em se tratando de Modelos de Dados, essa listagem contém, em ordem
alfabética, as entidades e os relacionamentos com atributos de um DER.
32
Considerando que não há uma padronização sobre a definição de dicionário
de dados, não será rotulado neste material, uma notação para estes, mesmo
por que, as ferramentas CASE normalmente incluem relatórios para geração
desses dicionários.
2.6. FERRAMENTAS CASE
Você deve estar se perguntando como desenhar um diagrama ER. Será no
Paint ou à mão? A resposta é simples. Existem várias ferramentas
computadorizadas destinadas a auxiliar na construção de modelos e projetos
de bancos de dados. São denominadas ferramentas CASE. Dentre outras,
podemos citar Doctor CASE, ERWin e brModelo. Esta última é uma
ferramenta desenvolvida sob a orientação do professor Carlos Heuser,
professor de Banco de Dados da UFRGS, e encontra-se disponível para
download na Internet. Embora seja uma ferramenta simples, permite
trabalharmos com a construção de modelos conceituais e lógicos (tratados no
próximo capítulo).
2.7. MODELO ER ESTENDIDO - EER
O modelo ER possui um poder de expressão muito grande, principalmente
quando se trata de modelagem de aplicações convencionais, porém alguns
recursos são melhores representados por extensões feitas ao modelo básico.
Recursos estes necessários para modelagem de aplicações mais complexas,
como Sistemas de Informações Geográficas e CAD.
Vários modelos semânticos de dados têm sido propostos na literatura, sendo
denominados de modelo ER estendidos ou EER. Não há uma notação padrão
para representação desses modelos, como ocorre com a UML.
Segundo Navathe (2005), o modelo EER engloba todos os conceitos do
modelo ER básico, acrescidos dos conceitos de subclasse e superclasse,
especialização
e
generalização,
tipo
união
e
herança
de
atributo/relacionamento.
33
3. PROJETO LÓGICO DE BANCO DE DADOS
3.1. DEFINIÇÃO
Quando construímos um modelo conceitual, focamos apenas no que o
usuário deseja, abstraindo da plataforma em que este será implementado. No
que se refere aos projetos de Banco de Dados, a preocupação é centrada em
estabelecer de que forma os dados serão armazenados no sistema. Em função
do modelo de banco de dados a ser usado, diferentes soluções de projeto
devem ser adotadas, ou seja, se o software tiver de ser implementado em um
banco de dados hierárquico, por exemplo, um modelo hierárquico deve ser
produzido, adequando-se a modelagem conceitual de dados (ER ou diagrama
de classes) a essa plataforma de implementação.
Considerando que o modelo de banco de dados que predomina no mercado,
atualmente, é o relacional, este capítulo se propõe a discutir conceitos de
projetos relacionados a esse modelo de bancos de dados.
3.2. ESTRUTURA
RELACIONAIS
DOS
BANCOS
DE
DADOS
O modelo relacional consolidou-se no mercado por ser flexível, de simples
compreensão. Está fortemente baseado na teoria matemática sobre relações,
daí o nome relacional.
Um banco de dados relacional consiste em uma coleção de tabelas, cada uma
das quais com um nome único. Uma linha em uma tabela representa um
relacionamento entre um conjunto de valores. Uma vez que essa tabela é
uma coleção de tais relacionamentos, há uma estreita correspondência entre
o conceito de tabela e o conceito matemático de relação, daí a origem do
nome desse modelo de dados.
Considere a tabela EMPREGADOS – Tabela 3. Ela possui três colunas:
Matricula, Nome e Cidade. Seguindo a terminologia do modelo relacional,
tratamos os nomes dessas colunas como atributos. Para cada atributo há um
conjunto de valores permitidos, chamado domínio da coluna em questão.
Para o atributo Matricula, por exemplo, o domínio é o conjunto de todas as
matrículas de funcionários. Suponha que D1 denote esse conjunto, D2 o
conjunto de todos os nomes de pessoas e D3 o conjunto de todas as cidades.
Qualquer linha da tabela EMPREGADOS consiste necessariamente de uma
tupla (v1, v2, v3), em que v1 é a matricula, (isto é, v1 está no domínio D1),
v2 é um nome do funcionário e assim por diante. Em geral, um empregado é
um conjunto de D1 x D2 x D3.
Matricula
01
02
03
04
Nome
Maria
Matheus
Gabriel
Joana
Cidade
Vitória
Vila Velha
Serra
Aracruz
34
Tabela 3: Tabela EMPREGADOS.
Matematicamente, define-se uma relação como um subconjunto de um
produto cartesiano de uma lista de domínios. Essa definição corresponde
quase exatamente à definição de uma tabela. A única diferença é que
designamos nomes aos atributos, ao passo que matematicamente se usam
apenas "nomes" numéricos. Como as tabelas em essência são relações,
podemos usar os termos matemáticos relação e tupla no lugar de tabela e
linhas, respectivamente.
Um valor de domínio que pertence a qualquer domínio possível é o valor
nulo, que indica que um valor é desconhecido ou não existe. Por exemplo,
suponhamos que incluamos o atributo numero_telefone na tabela
Empregado, pode ser que um Empregado não possua telefone ou que o seu
número seja desconhecido.
3.3. CHAVES
É importante especificar como as entidades dentro de um dado conjunto de
entidades podem ser identificadas. Conceitualmente, entidades e
relacionamentos individuais são distintos, entretanto, na perspectiva do
banco de dados, a diferença entre ambos deve ser estabelecida em termos de
seus atributos. O conceito de chaves nos permite fazer tais distinções.
Uma superchave é um conjunto de um ou mais atributos que, tomados
coletivamente, permitem identificar de maneira unívoca uma entidade em
um conjunto de entidades. Considere a inclusão de uma nova coluna na
tabela EMPREGADO, o CPF do empregado. Os atributos (matricula,nome)
e (nome,CPF) são suficientes para distinguir cada elemento do conjunto,
podendo ser considerados como superchaves. Da mesma forma, podemos
considerar o atributo CPF como superchave de empregado. O atributo nome
não pode ser considerado como superchave, porque algumas pessoas podem
ter o mesmo nome. Nosso interesse maior é por superchaves para as quais
nenhum subconjunto possa ser uma superchave. Essas chaves são chamadas
de chaves candidatas. Das superchaves mencionadas anteriormente somente
(nome,CPF) não poderia ser considerada uma chave candidata, visto que o
CPF, sozinho, já o é.
Podemos usar o termo chave primária para caracterizar a chave candidata,
que é escolhida pelo projetista do banco de dados como de significado
principal para a identificação de entidades dentro de um conjunto de
entidades. Quaisquer duas entidades individuais em um conjunto de
entidades não podem ter, simultaneamente, os mesmos valores em seus
atributos-chave.
Em SGBD’s, apenas os conceitos de chaves primárias e chaves candidatas
são de fato implementados!
Um outro conceito de chave, que muito será explorado neste material, é o
conceito de chave estrangeira. Uma chave estrangeira é um atributo ( ou
combinação de atributos) de uma tabela que constitui a chave primária de
uma tabela, daí o nome de estrangeira. É a estratégia usada para implementar
35
os relacionamentos dos modelos conceituais. Essa tabela referenciada pode
ser a própria tabela, para os casos de auto-relacionamento, ou outras
quaisquer do modelo. Outras denominações também são usadas para essas
chaves, a exemplo de chaves externas e chaves transpostas. A Tabela 4
mostra um exemplo de chave estrangeira, o CodDepto. Os valores possíveis
para essa coluna devem constar na Tabela referenciada por esse atributo, no
caso, a de Departamentos. Além desses valores, dependendo do modelo de
dados, nulo pode ser um valor possível.
Matricula
01
02
03
04
Nome
Maria
Matheus
Gabriel
Joana
Cidade
Vitória
Vila Velha
Serra
Aracruz
CodDepto
01
02
02
03
Tabela 4: Tabela de Empregados, destacando a chave estrangeira (CodDepto).
CodDepto
01
02
03
NomeDepto
Informática
Geografia
Português
Tabela 5: Tabela de Departamentos.
3.4. PROPRIEDADES DO MODELO RELACIONAL
[FALBO,2009]

Nenhum campo componente de uma chave primária pode ser nulo.

Cada célula de uma relação pode ser vazia (exceto de uma chave
primária), ou ao contrário, conter no máximo um único valor.

A ordem das linhas é irrelevante.

Não há duas linhas iguais.

Cada coluna tem um nome e colunas distintas devem ter nomes
distintos.

Usando-se os nomes para se fazer referência às colunas, a ordem
delas torna-se irrelevante.

Cada relação recebe um nome próprio distinto do nome de qualquer
outra relação da base de dados.

Os valores de uma coluna são retirados todos de um mesmo
conjunto, denominado domínio da coluna.

Duas ou mais colunas distintas podem ser definidas sobre um
mesmo domínio.

Um campo que seja uma chave estrangeira ou um item transposto só
pode assumir valor nulo ou um valor para o qual exista um registro
na tabela em que ela é chave primária.
36
3.5. TRADUÇÃO
RELACIONAL
DO
MODELO
ER
PARA
O
O objetivo desta seção é apresentar como se procede na elaboração do
projeto lógico de bancos de dados relacionais a partir de modelos conceituais
– no caso o ER. O modelo lógico é um modelo menos abstrato que o
conceitual e provê um nível maior de detalhes. Para os diferentes modelos de
bancos de dados (redes, hierárquicos, relacionais...) diferentes soluções de
projeto devem ser adotadas. Assim, este material terá como foco apenas o
projeto de banco de dados relacional.
A tradução do modelo ER para o relacional seguirá os seguintes passos:

Mapeamento das entidades e atributos;

Mapeamento dos relacionamentos, considerando cada tipo {1:1, 1:N,
N:N};

Mapeamento de generalizações e especializações;

Mapeamento de atributos multivalorados.
Diferentes autores usam diferentes representações para a especificação dos
modelos lógicos de bancos de dados relacionais, sendo alguns representados
de forma gráfica e outros textuais. A abordagem usada neste material será a
de Carlos Heuser (HEUSER,2004), que usa uma notação resumida para
definição do esquema, denominado Esquema Relacional, contendo as
seguintes informações :

Tabelas que formam o banco de dados;

Colunas que compõem cada tabela;

Restrições de integridade (no caso, apenas as restrições referentes às
chaves primárias e estrangeiras são representadas).
Para o exemplo das Tabelas 4 e 5 (Empregados e Departamentos), teremos a
seguinte representação:
Empregados (Matricula, Nome, Cidade, CodDepto)
CodDepto referencia Departamentos
Departamentos (CodDepto , NomeDepto)
Os atributos sublinhados representam as chaves primárias das tabelas
Empregados e Departamentos, respectivamente. CodDepto é uma chave
estrangeira e que referencia a chave primária da tabela Departamentos. Para
os casos das chaves estrangeiras compostas, a representação fica da seguinte
forma: (coluna1, coluna2, ... colunaN) referencia <NomeTabela>.
A fim de facilitar o entendimento, serão usados os mesmos exemplos de
modelos descritos no capítulo 2 para exemplificar os diferentes tipos de
relacionamentos. Consideremos também os atributos abaixo listados para os
conjuntos de entidades Funcionários e Projetos, pois a opção foi de não
representá-los no modelo ER.
Funcionários = Matricula, Nome, Cidade e Data de Admissão
Projetos = Código, Nome e Data de Inicio
Seguindo os passos para elaboração do modelo conceitual temos, como
passo 1, a definição das Tabelas que formam o banco de dados. Via de regra,
37
todo conjunto de entidades gerará uma tabela no banco de dados relacional.
As exceções serão tratadas, quando ocorrerem. Com relação à nomenclatura
usada na tabela, ela não deve, necessariamente, ser a mesma do conjunto de
entidades, considerando que não pode haver espaços em branco e que
devemos evitar nomes extensos para facilitar o trabalho dos programadores.
No que se refere aos atributos dos conjuntos de entidades, eles devem ser
mapeados em colunas das respectivas tabelas, porém, há algumas diretrizes
para definição dessas colunas, conforme especificações a seguir:

Evite usar nomes extensos. Ao fazer referência ao nome de uma
coluna, normalmente escreve-se NomedaTabela.NomedaColuna o
que estende ainda mais o nome do atributo.

Considerando que a referência às colunas ocorre do modo acima
descrito, evite incluir o nome da tabela nos nomes das colunas
dessas tabelas. A exemplo da coluna Nome, da tabela Projetos.
Algumas pessoas escrevem Nome_Projeto.

Crie padrões de projeto para dar nomes às colunas, a exemplo de
Data_Admissão e Data_Inicio. Evite usar prefixos diferentes para
colunas com mesmo tipo de informação, como: Data_Admissão e
Dt_Inicio.

Ao definir a chave primária, escolha a coluna ou combinação destas
colunas com o menor tipo de dados possível. Sobre os campos
chaves, seja chave primária, candidata, seja estrangeira, são criados
índices, e esses índices ocupam muito espaço em disco.

Embora devamos evitar redundâncias nos modelos conceituais, a
redundância, muitas vezes, é útil em um banco de dados, por
questões de performance. Por exemplo, o valor de um pedido pode
ser obtido por meio dos valores dos seus itens, porém, se
guardarmos o valor total do pedido como uma coluna na tabela de
pedidos, evitamos alguns acessos a disco, melhorando, assim, a
performance das aplicações.
3.5.1. Relacionamento 1:1
Considerando o relacionamento Gerenciam, da Figura 17, a melhor solução
de projeto a se considerar é: incluir a chave estrangeira na relação
PROJETOS, em vez de colocá-la em empregados, derivando o seguinte
esquema :
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao)
Projetos (Codigo, Nome, Dt_Inicio, Matricula_Gerente)
Matricula_Gerente referencia Funcionarios
38
Figura 17: Exemplo de relacionamento 1:1
Essa solução foi adotada, considerando-se que todo projeto tem um gerente,
porém, nem todo funcionário gerencia um projeto. Ainda assim, se a chave
estrangeira fosse criada em Funcionários, não teríamos problemas na
implementação dessa solução, embora essa não seja a melhor abordagem.
Se o relacionamento Gerenciam fosse total em relação a Funcionários e a
Projetos, ou seja, se a cardinalidade mínima fosse 1 (um) para ambos,
poderíamos optar por criar uma única tabela contendo todos os atributos.
3.5.2. Relacionamento 1:N
Para os relacionamentos 1:N deve-se criar a chave estrangeira na tabela que
representa o conjunto de entidades cuja cardinalidade máxima é 1. No caso
da Figura 18, a chave estrangeira deve ser colocada em Projetos, pois cada
projeto participa do relacionamento Gerenciam no máximo 1 (uma) vez. O
esquema gerado ficaria da seguinte forma:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao)
Projetos (Codigo, Nome, Dt_Inicio, Matricula_Gerente)
Matricula_Gerente referencia Funcionarios
Figura 18: Exemplo de relacionamento 1:N
3.5.3. Relacionamento 1:N - identificado
Para os relacionamentos 1:N, denominados identificados, como mostra o
exemplo da Figura 19, a identificação de um elemento da entidade, dita
fraca, requer a identificação da entidade, dita forte. Resumindo, temos nesses
casos a chave estrangeira fazendo parte da chave primária da tabela mapeada
pela entidade fraca. O esquema gerado ficaria da seguinte forma:
Sócios (Matricula, Nome, Sexo, Dt_Matricula)
Dependentes (Matricula, Num_Dependente, Sexo, Dt_Nascimento)
Matricula referencia Sócios
Figura 19: Exemplo de entidade fraca – relacionamento identificado
Nesse caso, apenas o número do dependente não é suficiente para identificálo, considerando que diferentes sócios possuem dependentes 01, 02, 03,...
39
3.5.4. Relacionamento N:N
Os bancos de dados relacionais não implementam ligações diretas para os
relacionamentos N:N, como para os demais tipos de relacionamentos : 1:1 e
1:N. Nesse caso, o relacionamento também deve ser mapeado em uma
tabela do banco de dados. A chave primária dessa nova tabela deve ser
composta, no mínimo, pela chave primária das tabelas relacionadas, ou seja,
tem-se pelo menos 02 chaves estrangeiras, e elas fazem parte da chave
primária da tabela criada. Às vezes é necessário incluir mais um atributo
para compor a chave primária da tabela, pois apenas as chaves estrangeiras
não são suficientes para identificá-los.
Considere o exemplo da Figura 20, agora com relacionamento N:N.
Considere também que o relacionamento Gerenciam possui os seguintes
atributos : Data de Inicio de Atividade e Percentual de dedicação.
Figura 20: Exemplo de relacionamento N:N
O esquema gerado ficaria da seguinte forma:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao)
Projetos (Codigo, Nome, Dt_Inicio)
Gerenciam (Matricula ,Codigo, Dt_Inic_Atividade, Perc_Dedicacao)
Matricula referencia Funcionarios
Codigo referencia Projetos
3.5.5. Generalização e Especialização
Considere a Figura 21 para as discussões que se seguem. Considere também
que um cliente possui as seguintes características (atributos ) : Código,
Nome e Endereço. Um cliente pessoa física, possui, adicionalmente, um CPF
e Carteira de Identidade e, um cliente pessoa jurídica, possui,
adicionalmente, um CNPJ e uma atividade principal.
40
Figura 21: Exemplo de generalização / especialização
Para os casos em que há generalização / especialização, há três opções de
projeto que podem ser adotadas:
Opção 1: Criar uma tabela única, fundindo os três conjuntos de entidades.
Nesse caso, os campos oriundos das tabelas especializadas devem ter a
possibilidade de assumirem valores nulos. O esquema gerado ficaria da
seguinte forma:
Clientes (Codigo, Nome, Endereco, CPF, Carteira_Identidade, CNPJ,
Ativ_Principal)
Opção 2: Criar uma tabela para cada entidade da especialização, como
Pessoas Físicas e Pessoas Jurídicas. Nesse caso, os atributos do conjunto de
entidades genérico – Clientes – devem ser incluídos em cada uma das tabelas
criadas. O esquema gerado ficaria da seguinte forma:
Clientes_PFisica (Codigo, Nome, Endereco, CPF, Carteira_Identidade)
Clientes_PJuridica (Codigo, Nome, Endereco, CNPJ, Ativ_Principal)
Opção 3: Criar uma tabela para cada conjunto de entidade da hierarquia.
Nesse caso, a chave primária das tabelas filhas (pessoas físicas e jurídicas)
devem ser chaves estrangeiras e as mesmas do conjunto mais genérico, no
caso, de Clientes. O esquema gerado ficaria da seguinte forma:
Clientes (Codigo, Nome, Endereco)
Clientes_PFisica (Codigo, CPF, Carteira_Identidade)
Codigo referencia Clientes
Clientes_PJuridica (Codigo, CNPJ, Ativ_Principal)
Codigo referencia Clientes
3.5.6. Auto Relacionamento 1:N
Para os auto-relacionamentos 1:N, como existe um relacionamento entre o
mesmo conjunto de entidades, deve-se criar a chave estrangeira na única
tabela que representa o conjunto de entidades. Nesse caso, deve-se ficar
atento em alterar o nome do campo – chave estrangeira –, pois não é possível
41
ter colunas diferentes e com o mesmo nome em uma tabela. A Figura 22
representa um modelo ER com esse tipo de relacionamento. O esquema
gerado ficaria da seguinte forma:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao, Matricula_Chefe)
Matricula_Chefe referencia Funcionarios
Figura 22: Exemplo de relacionamento 1:N
3.5.7. Auto Relacionamento N:N
Para os auto-relacionamentos N:N, assim como para os relacionamentos N:N
tradicionais, cria-se uma nova tabela para mapear o relacionamento. Essa
tabela terá duas chaves estrangeiras, agora, porém, vindas da mesma tabela.
Essas chaves estrangeiras compõem a chave primária da tabela criada. O
nome de pelo menos um campo deve ser alterado para evitar que haja dois
atributos com o mesmo nome em uma mesma tabela. A Figura 23 representa
um modelo ER com esse tipo de relacionamento. O esquema gerado ficaria
da seguinte forma:
Disciplinas (Codigo, Nome, Ementa)
Pre_Requisitos (CodigoDisciplinaPos, CodigoDisciplinaPre)
CodigoDisciplinaPre referencia Disciplinas
CódigoDisciplinaPos referencia Disciplinas
42
Figura 23: Exemplo de relacionamento N:N
3.5.8. Atributos Multivalorados
Os atributos multivalorados de conjunto de entidades também devem ser
tratados, considerando-se que o modelo relacional não comporta múltiplos
valores em uma célula de uma tabela. Para ilustrar, consideremos que
telefone (0,n) seja um atributo multivalorado de Funcionários. Para esses
atributos, uma solução de projeto adotada é a criação de uma tabela para
cada um deles. Para a tabela criada, deve ser aplicada a mesma solução dos
relacionamentos 1:N – identificados. Para o exemplo em tese, o esquema
gerado ficaria da seguinte forma:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao)
Telefones (Matricula, Num_Telefone)
Matricula referencia Funcionarios
Nesse caso, não há limites de telefones para um funcionário, tanto pode não
haver nenhum, como um ou vários.
3.6. NORMALIZAÇÃO
Uma vez concluído o projeto lógico de banco de dados relacional, com
geração do esquema correspondente, deve-se avaliar, para cada tabela, se a
projeção foi bem feita. Esse processo de verificação, composto por um
conjunto de regras, denomina-se “forma normal”. Há diversas formas
normais usadas no processo de verificação, porém na nossa disciplina serão
exploradas apenas as três primeiras formas normais, denominadas 1FN, 2FN
e 3FN. Normalmente as formas normais visam eliminar informações
redundantes nas tabelas, cujo processo é denominado normalização.
3.6.1. Primeira Forma Normal (1FN)
Um banco de dados está na Primeira Forma Normal, quando não existem
dados repetidos em nenhuma das linhas da tabela.
43
Segundo DATE (2004), uma relação R existe na primeira forma normal
(1FN) se, e somente se, todos os domínios subjacentes contiverem apenas
valores atômicos.
Para ilustrar esse conceito, tomemos como exemplo a relação Funcionários,
com a seguinte definição de esquema:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao, Telefones)
No caso dessa relação, nem todos os domínios contêm valores atômicos,
como é o caso de telefones. Nesse caso, os valores não atômicos devem estar
contidos em uma outra tabela, relacionada à original. Passando pelo processo
de normalização (1FN), temos o seguinte esquema:
Funcionarios (Matricula, Nome, Cidade, Dt_Admissao)
Telefones (Matricula, Num_Telefone)
Matricula referencia Funcionarios
Com isso, as duas tabelas geradas encontram-se normalizadas na primeira
forma normal.
3.6.2. Segunda Forma Normal (2FN)
Quando uma tabela possui uma chave composta, suas colunas devem ser
dependentes de toda a chave e não de apenas uma parte dela. Caso ocorra
essa dependência parcial, dizemos que a tabela viola a segunda forma
normal.
Segundo DATE (2004), uma relação R existe na segunda forma normal
(2FN) se, e somente se, estiver na (1FN) e todos os atributos não chaves
forem dependentes da chave principal.
Exemplo: Considere o esquema de uma relação filmes, de um banco de
dados de uma locadora de vídeo, com o seguinte esquema:
Filmes (CodigodoFilme, CodigodoAtor, Titulo, NomedoAtor)
A coluna Título depende somente do Número da Fita, e Nome do Ator,
depende somente do Número do Ator. Quase sempre a solução é dividir as
colunas em duas tabelas e criar uma terceira tabela que correlacione as linhas
das duas tabelas. Nesse caso geraríamos os seguintes esquemas:
Filmes (CodigodoFilme, Titulo)
Atores (CodigodoAtor, NomedoAtor)
AtoresFilmes (CodigodoFilme, CodigodoAtor)
CodigodoFilme referencia Filmes
CodigodoAtor referencia Atores
44
3.6.3. Terceira Forma Normal (3FN)
Uma tabela encontra-se na Terceira Forma Normal se todas as suas colunas
dependerem de toda a chave principal e não houver interdependência entre
as colunas que não são chaves da tabela.
Segundo DATE (2004), uma relação R existe na terceira forma normal
(3FN) se, e somente se, estiver na (2FN) e todos os atributos não chave
forem intransitivamente dependentes da chave principal.
Exemplo: Considere o esquema modificado da relação filmes de um banco
de dados de uma locadora de vídeo com o seguinte esquema:
Filmes (CodigodoFilme, Titulo, Categoria, Preco)
Suponha que a loja determine o preço dos filmes por categoria: filmes de
Terror, Drama e Comédia custam R$2,00; Musicais R$2,50 e Lançamentos
R$3,00. Nesse caso, a coluna Preço dependeria não só da coluna Código do
filme, como também da coluna Categoria. Essa tabela não está na Terceira
Forma Normal. A solução seria criar uma tabela adicional para armazenar os
valores por categoria do filme. Após normalização, os seguintes esquemas
são gerados:
Filmes (CodigodoFilme, Titulo,CodigoCategoria)
CodigoCategoria referencia Categorias
Categorias (CodigoCategoria, Preco)
Atividade 01
Muitas vezes, o DBA se depara com situações em que possui o
esquema do banco de dados, porém não tem o modelo conceitual
equivalente. Baseado nisso, dada a definição do esquema abaixo,
gere o modelo conceitual equivalente (esse processo denomina-se
Engenharia Reversa).
Fabricante (codf, nomef)
Automovel (coda, nomea, preço, codf)
Codf referencia Fabricante
Pessoa (codp, nomep)
Venda (codp, coda, data, valor, cor)
Codp referencia Pessoa
Coda referencia Automovel
Atividade 02
Dado o modelo ER e dicionário de dados abaixo, gere o esquema
relacional equivalente:
45
Dicionário de Dados:
EQUIPES = CodEquipe + NomeEquipe
PILOTOS =
Altura +Peso
CodPiloto +NomePiloto + DataNascimento +
PAISES =
CodPais + Sigla + Nome
CORRIDAS = CodCorrida + DataCorrida + DuracaoProva +
NomeCircuito
PARTICIPACOES = PosicaoPilotoProva
46
Atividade 03
a) Dado a relação Perifericos, coloquem a mesma na terceira
forma normal, passo a passo.
Perifericos (Cod_Periferico, CodModelo, NoConfig,
Quantidade, NomeModelo, CodCPU, NomeCPU)
As dependências funcionais que existem nesta tabela são as
seguintes:
 (Cod_Periferico, CodModelo, NoConfig) 
Quantidade
 CodCPU  NomeCPU
 CodModelo  NomeModelo
 CodModelo  CodCPU
 CodModelo  NomeCPU
X  Y, significa dizer que : Y depende de X
b) Dado a relação Pedidos, coloquem a mesma na terceira
forma normal, passo a passo.
Pedidos (Numero_Pedido, Data, CodCliente, NomeCliente,
EnderecoCliente,
CodigoProduto*,
NomeProduto*,
ValorProduto*, QuantidadeProduto*, MatriculaEntregador,
NomeEntregador, PlacaVeiculoEntregador)
47
4. LINGUAGENS DE CONSULTA
4.1. DEFINIÇÃO
Uma linguagem de consulta é uma linguagem na qual um usuário requisita
informações do banco de dados. São classificadas como procedurais e não
procedurais. Numa linguagem procedural um usuário instrui o sistema para
executar uma sequência de operações no banco de dados, a fim de computar
o resultado desejado. Numa linguagem não-procedural o usuário descreve a
informação desejada, sem fornecer um procedimento específico para obter
tal informação.
A Álgebra relacional é uma linguagem procedural, enquanto o cálculo
relacional é uma linguagem não procedural. Navathe (2005) afirma que
qualquer expressão escrita em álgebra relacional pode ser representada
também no cálculo, dando o mesmo poder de expressão para ambas as
linguagens. Como o nosso propósito de usar uma linguagem de consulta
formal é o de entendermos o que ocorre nos “bastidores” da execução de
uma consulta, focaremos apenas na álgebra relacional.
A Linguagem SQL é uma linguagem de consulta comercial, intitulada
padrão pelo comitê ANSI, desde 1986. É uma linguagem declarativa, com
comandos muito mais amigáveis do que as linguagens formais, embora seja
fundamentada nessas linguagens formais (na álgebra e no cálculo).
Nas seções seguintes exploraremos a Álgebra Relacional e a linguagem
SQL.
4.2. ÁLGEBRA RELACIONAL
A álgebra relacional é uma linguagem de consulta procedural. Ela consiste
em um conjunto de operações que tomam uma ou duas relações (tabelas)
como entrada e produzem uma nova relação como resultado. Inclui um
conjunto de operações, classificadas como fundamentais e não fundamentais.
As operações fundamentais da álgebra relacional são: selecionar, projetar,
renomear, (unárias) - produto cartesiano, união e diferença de conjuntos
(binárias). Além das operações fundamentais, existem outras operações, a
saber, interseção de conjuntos, ligação natural, entre outras, que são
definidas em termos das operações fundamentais. As operações não
fundamentais são usadas para simplificar consultas, considerando que uma
operação não fundamental engloba consultas fundamentais. A Figura 23
mostra, de forma gráfica, cada uma das operações da álgebra.
As operações da álgebra relacional atuam sobre uma ou duas relações, sendo
classificadas como unárias ou binárias. As relações unárias trabalham sobre
uma relação e as binárias sobre duas relações. Caso seja necessário usar mais
de duas tabelas em uma consulta, operações podem ser usadas de forma
48
encadeada. Como o resultado de uma consulta da álgebra é uma nova
relação, esta pode ser usada como entrada para a próxima operação.
P roduto
S elecionar
P rojetar
U nião
a
a
b
b
c
c
x
y
a
b
c
x
y
x
y
x
y
Intersecção
D iferença
Ligação (natural)
a1
a2
a3
b1
b1
b2
b1
b2
b3
c1
c2
c3
a1
a2
a3
b1
b1
b2
D ividir
c1
c1
c2
a
a
a
b
c
x
y
z
x
y
x
z
a
Figura 23: Visão geral das operações da Álgebra Relacional
Fonte: Heuser, 2004. Adaptação.
4.2.1 Operações Fundamentais
Considere o seguinte esquema de banco de dados para exemplos posteriores,
ao longo deste capítulo. Trata-se de um esquema bancário, composto de
quatro tabelas: Agencias, Clientes, Depósitos e Empréstimos. Ele foi
adaptado de Silberschatz (2006).
Lembre sempre da definição deste esquema para
quando a ele nos referirmos ao longo deste capítulo.
Agencias (CodigoAg, NomeAg, CidadeAg)
Clientes (CodigoCli, Nome, rua, cidade)
Depositos (CodigoAg, NumeroCont, CodigoCli,
saldo)
CodigoAg referencia Agencias
CodigoCli referencia Clientes
Emprestimos (CodigoAg, CodigoCli, NumeroEmp,
49
quantia)
CodigoAg referencia Agencias
CodigoCli referencia Clientes

Operação selecionar
A operação selecionar seleciona tuplas (linhas) que satisfazem a um dado
predicado. Usamos a letra minúscula grega sigma () para representar a
seleção. O predicado aparece subscrito em . A relação argumento (entrada)
aparece entre parênteses, seguindo o . A Figura 24 representa graficamente
essa operação.
Sintaxe: σ<predicado>(Relação)
Figura 24: Operação seleção
Usando o nosso esquema exemplo para selecionar as tuplas da relação
empréstimo em que o código da agência é 0662, escreve-se:
CodigoAg=0662(Emprestimos)
Podemos encontrar todas as tuplas em que a quantia emprestada seja maior
que 1200.
quantia >1200(Emprestimos)
As comparações são permitidas, usando =, ,, ,  e  e os conectivos e
(^) e ou ().

Operação Projetar
A operação projetar é uma operação unária que retorna sua relação
argumento, com certas colunas deixadas de fora. A projeção é representada
pela letra grega pi (). A Figura 25 representa graficamente essa operação.
Sintaxe: <lista de atributos>(Relação)
50
Figura 25: Operação projeção
Suponha que desejemos uma relação mostrando os clientes e as agências nas
quais eles tomaram empréstimos, mas não nos importamos com a quantia e o
número do empréstimo. Escrevemos:
CodigoAg,CodigoCli(Emprestimos)
Encontre todos os clientes (Nome) que moram em “Aracruz”.
Devemos fazer uma seleção de todos os clientes que moram em Aracruz e,
em seguida, projetar o nome desses clientes.
 Nome(clientes-cidade=”Aracruz” (Clientes))

Operação Produto Cartesiano
A operação produto cartesiano, representada por (X) é capaz de combinar
informações a partir de diversas relações. Trata-se de uma operação binária.
Essa operação nos mostra todos os atributos das relações envolvidas. A
Figura 26 representa graficamente essa operação.
Sintaxe: (Relação1 Χ Relação2)
Figura 26: Operação produto cartesiano
Para selecionarmos todos os nomes dos clientes que possuam empréstimo na
agência cujo código é 0662, escrevemos:
 Nome (CodigoAg=0662
Clientes))

^ Emprestimo. CodigoCli = Clientes. CodigoCli
(Emprestimos X
Operação União (binária)
A operação união de conjuntos, representada por (), permite-nos encontrar
tuplas que estão em uma das relações envolvidas. A Figura 27 representa
graficamente essa operação.
51
Sintaxe: (Relação1  Relação2)
Figura 27: Operação união
Vamos supor que quiséssemos conhecer todas as pessoas que possuam
Depósitos, Empréstimos, ou ambos, numa determinada agência. Com os
recursos que temos até agora, não seria possível conseguirmos tal
informação. Nessa situação, deveríamos fazer a união de todos que possuam
depósitos com todos que possuam empréstimos nessa agência. Como
veremos no exemplo a seguir:
Ex. Selecionar todos os clientes que possuam depósitos, empréstimos, ou
ambos, na agência 051.
Nome (CodigoAg=”051” ^depositos. CodigoCli = Clientes. CodigoCli(Depositos X Clientes))

Nome (CodigoAg=”051” ^emprestimos. CodigoCli = Clientes. CodigoCli(Emprestimos X Clientes))
Uma vez que as relações são conjuntos, as linhas duplicadas são eliminadas.

Operação Diferença de conjuntos
A operação diferença de conjuntos, representada por (-), é uma operação
binária e nos permite encontrar tuplas que estão em uma relação e não em
outra. A expressão r - s resulta em uma relação que contém todas as tuplas
que estão em r e não em s. A Figura 28 representa graficamente essa
operação.
Sintaxe: (Relação1 - Relação2)
Figura 28: Operação diferença de conjuntos
52
Ex. Encontrar todos os clientes que possuam um depósito, mas não possuem
um empréstimo na agência 051.
Nome (CodigoAg=”051” ^ depositos.CodigoCli = Clientes.CodigoCli(Depositos X Clientes))
Nome (CodigoAg=”051” ^Emprestimos.CodigoCli = Clientes.CodigoCli(Emprestimos X Clientes))

Operação Renomear
A operação renomear, representada pela letra grega Rô (), é necessária
sempre que uma relação aparece mais de uma vez em uma consulta. Ela faz
uma cópia da relação original.
Sintaxe: ρ NomeNovo (Relação)
Ex. Encontre todos os clientes que moram na mesma rua e cidade que João.
Podemos obter a rua e a cidade de João da seguinte forma:
t  rua, cidade (Nome=”João” (Clientes)) ou t  Nome=”João” (Clientes)
Entretanto, para encontrar outros clientes com essa rua e cidade, devemos
referir-nos à relação Clientes pela segunda vez. Perceba que inserir
novamente uma relação clientes na consulta, gerará ambigüidade. Por isso,
deve-se renomeá-la.
Clientes2 (Clientes)
cliente2.cliente-.nome
(Clientes))
(clientes.cidade = clientes2.cidade ^ clientes.rua = clientes2.rua
(t X Clientes2
53
Atividade 01
Considere o esquema bancário abordado anteriormente e construa
expressões em álgebra relacional para as questões que se seguem.
1. Selecionar todos os clientes (nomes) que possuam depósitos.
2. Selecionar todos os clientes que possuam depósito na mesma
cidade onde moram.
3. Encontrar todas as agências que possuam clientes com nome
“Maria” (depósitos ou empréstimos).
4. Usando as Operações Fundamentais, encontrar a conta com
maior saldo.
Atividade 02
Considere o esquema seguinte para construir expressões, usando
operações fundamentais da álgebra relacional para as questões que
se seguem.
Pessoas (CodPessoa, Nome, Cidade, Chefe)
Empresas (CodEmpresa, Nome, Cidade)
Trabalha (CodPessoa, CodEmpresa, Salario)
CodPessoa referencia Pessoas
CodEmpresa referencia Empresas
5. Consulte todas as pessoas que trabalham. A consulta deverá
retornar o nome das pessoas e a cidade onde moram.
6. Consulte o nome das empresas que possuem funcionários que
ganham menos que um salário mínimo (considere o valor do
salário de R$400,00).
7. Consulte todas as pessoas (nomes) que trabalham em Vitória.
8. Consulte todas as pessoas (nomes) que trabalham na mesma
cidade onde moram.
9. Consulte todas as pessoas (nomes) que moram na mesma
cidade do chefe.
10. Consulte todas as empresas (nomes) que funcionam em
cidades em que não moram Maria.
11. Consulte todas as pessoas (nomes) que não trabalham em
Vitória e que ganham acima de R$ 2000.
12. Selecione o nome do funcionário da empresa de código “01”
que possui o menor salário.
4.2.2. Operações Não-Fundamentais
Utilizando as operações fundamentais da álgebra relacional podemos
expressar qualquer consulta da álgebra relacional. Entretanto, algumas
consultas são longas ou complexas demais para serem expressas. Nesse caso,
o uso das operações não fundamentais pode reduzir o tamanho e a
complexidade dessas consultas.

Operação Intersecção de conjuntos
A operação Intersecção de conjuntos, representada por (), é uma operação
binária e nos permite encontrar tuplas que estão nas duas relações envolvidas
54
na consulta. Pode ser expressa em função das operações fundamentais da
seguinte forma: r  s = r – (r – s). A Figura 29 representa graficamente essa
operação.
Sintaxe: (Relação1 
Relação2)
Figura 29 : Operação Intersecção de conjuntos
Suponha que desejemos encontrar todos os clientes com um empréstimo e
uma conta na agência “051”.
Escrevemos da seguinte forma:
Nome (CodigoAg=”051” ^ Depositos.CodigoCli = Clientes.CodigoCli(Depositos X Clientes))

Nome (CodigoAg=”051”
Clientes))

^
Emprestimos.CodigoCli
=
Clientes.CodigoCli(Emprestimos
X
Operação Ligação natural
A ligação natural, representada pelo símbolo (|X|) é uma operação binária
que permite combinar certas seleções e um produto cartesiano em uma
operação. A operação ligação natural forma um produto cartesiano de seus
dois argumentos e faz uma seleção, forçando uma equidade sobre os
atributos que aparecem em ambos os esquemas relação. A Figura 30
representa graficamente essa operação.
Sintaxe: (Relação1 |X| Relação2)
Figura 30: Operação Ligação Natural
Ex1: “Encontre todos os clientes que têm empréstimos e a cidade em que
vivem”.
Nome, cidade (Emprestimos |X| Clientes)
55
Ex2: “Encontre todos os cliente que têm empréstimos e que moram em
“Vitória””.
Nome, cidade (cidade=”Vitória” (Emprestimos |X| Clientes))

Operação Divisão
A operação divisão, representada por (), é usada em consultas em que os
atributos da relação final são os atributos da relação1 que não existem na
relação2. As linhas da relação final contêm as linhas de R1 que incluem
todos os valores das colunas comuns a R2. Normalmente aplica-se a
consultas que incluem a frase “para todos”. A Figura 31 representa
graficamente essa operação.
Sintaxe: (Relação1 ÷ Relação2)
÷
÷
Figura 31: Operação Divisão
Suponha que desejemos encontrar todos os clientes que têm uma conta em
todas as agências localizadas em “Vitória”. Podemos obter todas as agências
de Vitória por meio da expressão:
r1  CodigoAg (cidade=”Vitória” (Agências))
Podemos encontrar todos os pares Nome, CodigoAg, nos quais um cliente
possui uma conta em uma agência, escrevendo:
r2  Nome, CodigoAg (Depositos |X| Clientes)
Agora precisamos encontrar clientes que apareçam em r2 com cada nome de
agência em r1.
Escrevemos essa consulta da seguinte forma:
Nome, CodigoAg (Depositos |X| Clientes)  CodigoAg (cidade=”Vitória” (Agências))

Operação de Remoção
A operação remoção se faz necessária sempre que houver necessidade de
excluir tuplas de uma relação.
Sintaxe: R = R – E , onde E é uma consulta da álgebra relacional
Exemplo1: Excluir todos os depósitos do cliente de código 01
Depositos = Depositos - (CodigoCli = “01” (Depositos))
Exemplo2: Excluir todas as contas de “joão”
E  CodigoAg, NumeroCont, CodigoCli, saldo (Nome=”joão” (Depositos |X| Clientes))
Depositos = Depositos - E

Operação de Inserção
56
A operação inserção se faz necessária sempre que houver a necessidade de
incluir tuplas em uma relação.
Sintaxe: R = R  E , onde E é uma consulta da álgebra relacional
Exemplo1: Depositos = Depositos  {(51, 980987, 1, 1200)}
Exemplo2: Gerar um depósito para todas as pessoas que possuem
empréstimos. A conta gerada terá o mesmo número do empréstimo e o valor
do depósito será igual ao da quantia emprestada.
Depositos = Depositos  CodigoAg, numeroEmp, CodigoCli, quantia (Emprestimos)

Operação de Atualização
A operação atualização representada pela letra grega delta () se faz
necessária sempre que houver a necessidade de alterar valores de tuplas em
uma relação.
Sintaxe: A  E ( R), em que E é uma consulta da álgebra relacional.
Exemplo1: Acrescer o saldo das contas de todas as pessoas em 5 %.
saldo  saldo * 1.05 ( Depositos )
Exemplo2: Suponhamos que contas com saldos superiores a R$10.000,00
recebam 6% de juros e as demais 5%.
saldo  saldo * 1.06 (saldo > 10000 ( Depositos ))
saldo  saldo * 1.05 (saldo <= 10000 ( Depositos ))
57
Atividade 03
Considere o esquema seguinte para construir expressões,
usando operações da álgebra relacional para as questões que
se seguem.
Fabricante (codf, nomef)
Automovel (coda, nomea, preco, codf)
Codf referencia Fabricante
Pessoa (codp, nomep)
Venda (codp, coda, data, valor, cor)
Codp referencia Pessoa
Coda referencia Automovel
1. Relacione os nomes das pessoas que compraram
algum carro.
2. Relacione os automóveis (nomes) da “Fiat”.
3. Quem comprou “Ford”?
4. Quem comprou carro com ágio (valor da venda
maior que o valor do automóvel)?
5. Quem não comprou “Ford”?
6. Quem comprou “Ford” e não comprou “Volks”?
7. Qual é o carro mais caro (nome)?
8. Atualizar os valores dos automóveis da “GM” em
15%.
9. Exclua todas as vendas anteriores a ‘01/01/1990’.
10. Selecione todas as pessoas que compraram mais de
um carro, de diferentes modelos, do mesmo
fabricante.
4.3. SQL
A linguagem SQL foi uma das grandes razões para a consolidação dos
bancos de dados relacionais no mercado. Desde sua definição como padrão,
em 1986, passou por diversas revisões, gerando publicações de novas
versões. A versão original, denominada Sequel, foi desenvolvida no
Laboratório de Pesquisa da IBM e implementada como parte do projeto
System R no início dos anos 70. A linguagem evoluiu desde então, e nome
foi mudado para SQL (Structured Query Language). A primeira versão ficou
conhecida como SQL-86 ou SQL1, a segunda versão foi denominada SQL92 ou SQL2, e a última versão publicada, que incluiu recursos para dar
suporte aos bancos de dados objetos-relacionais e orientados a objetos, ficou
conhecida como SQL-99 ou SQL3.
A maioria dos sistemas gerenciadores de bancos de dados comerciais
implementa suporte ao padrão SQL. Além disso, incorporam uma série de
funções adicionais, visando facilitar o trabalho dos desenvolvedores. Essas
facilidades precisam ser usadas com cautela, pois, se apenas o padrão for
58
utilizado, garante-se a portabilidade, caso haja a necessidade de troca de
SGBD. A linguagem SQL possui diversas partes:

Linguagem de Definição de Dados (DDL) - Inclui comandos para
definição de esquemas de relações, exclusão de relações, criação de
índices e modificações do esquema de relações;

Linguagem de manipulação de dados (DML) - Inclui comandos para
inserção, exclusão e modificação de tuplas no banco de dados;

Incorporação DML (SQL Embutida) - Uso de SQL em linguagens
de programação de uso geral, como Pascal, C,...;

Definição de Visões - A SQL DDL inclui comandos para definição
de visões;

Autorização - A SQL DDL inclui comandos para especificação de
direitos de acesso a relações e visões;

Integridade - A SQL DDL inclui comandos para especificação de
regras de integridade que os dados que serão armazenados no banco
de dados devem satisfazer;

Controle de Transações - A SQL DDL inclui comandos para
especificação de iniciação e finalização de transações.
4.3.1. Estrutura Básica
A estrutura básica de uma expressão SQL consiste em três cláusulas: select,
from e where.

A cláusula select corresponde à operação projeção da álgebra
relacional. É usada para listar os atributos desejados no resultado de
uma consulta.

A cláusula from corresponde à operação produto cartesiano da
álgebra relacional. Ela lista as relações a serem examinadas na
avaliação da expressão.

A cláusula where corresponde ao predicado de seleção da álgebra
relacional. Consiste em um predicado envolvendo atributos de
relações que aparecem na cláusula from.
Uma típica consulta SQL tem a seguinte forma:
SELECT A1, A2, ..., An
FROM r1, r2, ..., rn
[WHERE P]
3
1
2
Cada Ai representa um atributo e cada ri é uma relação. P é um predicado.
Essa consulta é equivalente à expressão da álgebra relacional:
 A1, A2, ..., An (P (r1 x r2 x ...x rn))
A lista de atributos A1, A2, ..., An pode ser substituída por um (*) para
selecionar todos os atributos (colunas) presentes nas tabelas da cláusula
from.
59
A SQL forma o produto cartesiano das relações chamadas na cláusula from,
executa uma seleção da álgebra relacional usando o predicado da cláusula
where e, então, projeta o resultado para os atributos da cláusula select. Na
prática, a SQL pode converter essa expressão em uma forma equivalente que
pode ser processada mais eficientemente, mas para efeito didático iremos
manter essa ordem de execução.
Uma consulta completa pode ter as cláusulas abaixo, sendo que apenas as
cláusulas SELECT e FROM são obrigatórias. O número que segue cada
linha sugere a ordem de execução.
SELECT A1, A2, ..., An
FROM r1, r2, ..., rn
[WHERE P]
[GROUP BY A1, A2, ..., An]
[HAVING Condição]
[ORDER BY A1, A2, ..., An]
6
1
2
3
4
5
Vamos considerar uma primeira consulta simples, usando nosso esquema de
exemplo. “Encontre os nomes de todos os clientes na relação clientes”. A
consulta SQL pode ser escrita da seguinte forma:
SELECT Nome
FROM Clientes
4.3.2. Linhas (tuplas) duplicadas
Em algumas situações, uma consulta SQL pode retornar uma relação que
contenha tuplas (linhas) duplicadas. Nessa situação, inserimos a palavrachave distinct depois da cláusula select para eliminá-las.
Aproveitando o exemplo anterior, a relação resultante poderá ter clientes que
possuam o mesmo nome. Nesse caso, podemos eliminar essas duplicações,
usando a cláusula distinct:
SELECT DISTINCT Nome
FROM Clientes
4.3.3. Predicados e ligações
A SQL não tem uma representação da operação ligação natural. No entanto,
uma vez que a ligação natural é definida em termos de um produto
cartesiano, uma seleção e uma projeção, é relativamente simples escrever
uma expressão SQL para uma ligação natural.
60
Ex.: “Encontre os nomes e cidades de clientes que possuam empréstimos em
alguma agência”. Na SQL, isso pode ser escrito da seguinte forma:
SELECT distinct Nome, Cidade
FROM Clientes, Emprestimos
WHERE Clientes.CodigoCli=Emprestimos.CodigoCli
A SQL inclui os conectores and, or e not ; caracteres especiais: (, ), ., :, _,
%,<, >, <= , >= , = , <>, +, - ,* e /; operador para comparação: between,
como mostra o exemplo a seguir.
“Selecionar todas as contas que possuam saldo entre 10000 e 20000”.
SELECT NumeroCont
FROM Depositos
WHERE saldo BETWEEN 10000 AND 20000
Que equivale a consulta
SELECT NumeroCont
FROM Depositos
WHERE saldo >= 10000 AND saldo <= 20000
A SQL inclui também um operador para comparações de cadeias de
caracteres, o like. Ele é usado em conjunto com dois caracteres especiais:
Por cento (%). Substitui qualquer subcadeia de caracteres.
Sublinhado (_). Substitui qualquer caractere.
Ex.: “Encontre os nomes de todos os clientes cujas ruas incluem a subcadeia
“na””.
SELECT distinct Nome
FROM Clientes
WHERE rua LIKE “ %na%”
Ou também
Ex.: “Encontre os nomes de todos os clientes cujas ruas finalizem com a
subcadeia “na”, seguido de um caractere”.
SELECT distinct Nome
FROM Clientes
WHERE rua LIKE “ %na”
Para que o padrão possa incluir os caracteres especiais ( isto é, % , _ , etc...),
a SQL permite a especificação de um caractere de escape. O caractere de
escape é usado imediatamente antes de um caractere especial para indicar
que o caractere especial deverá ser tratado como um caractere normal.
Definimos o caractere de escape para uma comparação like, usando a
palavra-chave escape. Para ilustrar, considere os padrões seguintes, que
utilizam uma barra invertida como caractere de escape.
Like “ ab\%cd%” escape “\” substitui todas as cadeias começando
com “ ab%cd”;
61
Like “ ab\_cd%” escape “\” substitui todas as cadeias começando com
“ ab_cd”.
A procura por não-substituições em vez de substituições se dá por
meio do operador not like.
4.3.4. Operações de conjunto
A SQL inclui a operação de conjunto union que opera em relações e
corresponde à operação  da álgebra relacional.
Uma vez que as relações são conjuntos, na união deslas, as linhas duplicadas
são eliminadas.
Ex. “Se quisermos saber todos os clientes que possuem empréstimo na
agência de código “ 051””, fazemos:
SELECT DISTINCT Nome
FROM Clientes, Emprestimos
WHERE Clientes.CodigoCli=Emprestimos.CodigoCli AND CodigoAg =
“051”
Da mesma forma, se quisermos saber “todos os clientes que possuem
depósitos na agência de código “051”, fazemos:
SELECT DISTINCT Nome
FROM Clientes, Depositos
WHERE
Clientes.CodigoCli=
Depositos.CodigoAg = “051”
Depositos.CodigoCli
AND
"Para achar todos os clientes que possuam um depósito, um empréstimo, ou
ambos, na agência de código “051”, fazemos:
SELECT DISTINCT Nome
FROM Clientes, Depositos
WHERE Clientes.CodigoCli=epositos.CodigoCli AND Depositos.CodigoAg
= “051”
UNION
SELECT distinct Nome
FROM Clientes, Emprestimos
WHERE Clientes.CodigoCli=Emprestimos.CodigoCli AND CodigoAg =
“051”
4.3.5 Ordenando a exibição de tuplas
A cláusula order by organiza o resultado de uma consulta em uma ordem
determinada. Para listar em ordem alfabética todos os clientes do banco,
fazemos:
SELECT distinct Nome
FROM Clientes
ORDER BY Nome
62
Como padrão, SQL lista tuplas na ordem ascendente. Para especificar a
ordem de classificação, podemos especificar asc para ordem ascendente e
desc para descendente. Podemos ordenar uma relação por mais de um
elemento. Como se segue:
SELECT *
FROM Emprestimos
ORDER BY quantia DESC, CodigoAg ASC
4.3.6. Membros de conjuntos
O conectivo in/not in testa os membros de conjunto, em que o conjunto é
uma coleção de valores produzidos por uma cláusula select. Para ilustrar,
considere a consulta “Encontre todos os clientes que possuem uma conta e
não possuem empréstimo na agência “Princesa Isabel””. A consulta SQL
pode ser escrita da seguinte forma:
SELECT distinct Nome
FROM Clientes
WHERE Clientes.CodigoCli IN
(SELECT CodigoCli
FROM Depositos, Agencias
WHERE depositos.CodigoAg = agencias.CodigoAg
AND NomeAg = “Princesa Isabel”)
AND Clientes.CodigoCli NOT IN
(SELECT CodigoCli
FROM Emprestimos, Agencias
WHERE emprestimos.CodigoAg = agencias.CodigoAg
AND NomeAg = “Princesa Isabel”)
4.3.7. Variáveis tuplas (renomeação)
A renomeação sempre é necessária quando temos necessidade de usar a
mesma tabela mais de uma vez na mesma consulta, assim como na operação
renomear da álgebra relacional. Muitas vezes usamos este recurso com o
objetivo de reduzir o tamanho das expressões SQL. A renomeação é feita
usando a palavra reservada “AS”, após o nome da tabela na cláusula FROM,
como mostra o exemplo a seguir.
Ex: “encontre o nome e a cidade de todos os clientes que possuem depósito
em qualquer agência”.
SELECT distinct C.Nome, C.cidade
FROM Clientes AS C, Depositos AS D
WHERE C.CodigoCli = D.CodigoCli
Uma vez que as relações Clientes e Depositos foram renomeadas para C e D,
quaisquer referências a essas tabelas, na consulta, devem ser feitas a C e D, e
63
não mais aos nomes originais. Lembre-se da ordem de execução de uma
consulta SELECT!
4.3.8. Comparação de conjuntos
Considere a consulta “encontre todas as agências que possuem ativos
maiores que alguma agência de Vitória”. Podemos escrever a seguinte
expressão SQL:
SELECT distinct Agencias.NomeAg
FROM Agencias , Agencias AS ag
WHERE agencias.ativos > ag.ativos AND ag.cidade = “Vitória”
Uma vez que é uma comparação “maior que”, não podemos escrever a
expressão usando a construção in. Observe também que, como houve
necessidade de usar a mesma tabela (Agências) duas vezes na consulta, ela
teve que ser renomeada.
A mesma consulta acima poderia ser escrita usando o operador any (pelo
menos um).
Comparações do tipo >any, <any, >=any, <=any, =any são aceitos pela
linguagem. A consulta anterior pode ser escrita da seguinte forma:
SELECT NomeAg
FROM Agencias
WHERE ativos > any
(SELECT ativos
FROM agencias
WHERE agencias.cidade = “Vitória”)
Vamos modificando a consulta anterior levemente para encontrar todas as
agências que possuem ativos maiores do que todas as agências de Vitória. A
construção > all corresponde à frase “maior que todos”. A consulta fica
como se segue:
SELECT NomeAg
FROM Agencias
WHERE ativos > all
(SELECT ativos
FROM Agencias
WHERE agencias.cidade = “Vitória”)
Como o operador Any, o operador all pode ser usado como: >all, <all,
>=all, <=all, =all e <> all.
4.3.9. Testando relações vazias
A SQL possui um recurso para testar se uma subconsulta retorna alguma
tupla. A construção exists retorna true se a subconsulta retornar alguma
tupla. Para ilustrar, vamos escrever a consulta “Encontre todos os clientes
64
que possuem depósito e não possuem empréstimo na agência “Princesa
Isabel” ”.
SELECT Nome
FROM Clientes
WHERE EXISTS
(SELECT * FROM Depositos, Agencias
WHERE
depositos.CodigoCli=
clientes.CodigoCli
AND
agencias.CodigoAg = depositos.CodigoAg AND NomeAg =
“Princesa Isabel”)
WHERE NOT EXISTS
(SELECT * FROM emprestimos, agencias
WHERE emprestimos.CodigoCli= clientes.CodigoCli AND
agencias.CodigoAg = emprestimos.CodigoAg AND NomeAg =
“Princesa Isabel”)
Atividade 04
Considere o esquema abaixo para construir as expressões
seguintes, usando a linguagem SQL.
Pessoas (CodPessoa, Nome, Cidade, Chefe)
Chefe referencia Pessoas
Empresas (CodEmpresa, Nome, Cidade)
Trabalha (CodPessoa, CodEmpresa, Salario)
CodPessoa referencia Pessoas
CodEmpresa referencia Empresas
1. Consulte todas as pessoas que moram em Vitória.
2. Consulte todas as pessoas que trabalham na mesma cidade
onde moram.
3. Consulte todas as pessoas que moram na mesma cidade
do chefe.
4. Consulte todas as empresas que funcionam em cidades em
que não moram pessoas cujo primeiro nome seja Maria
(usar operações de conjunto).
5. Consulte todas as pessoas que não trabalham em Vitória e
que ganham acima de R$2000,00 em ordem decrescente.
6. Consulte todas as pessoas que não trabalham na empresa
cujos nomes comecem com “inf_”. O resultado deverá ser
apresentado em ordem alfabética.
65
Atividade 05
Considere o esquema abaixo para construir as expressões
seguintes, usando a linguagem SQL.
Fabricante (codf, nomef)
Automovel (coda, nomea, preço, codf)
Codf referencia Fabricante
Pessoa (codp, nomep)
Venda (codp, coda, data, valor, cor)
Codp referencia Pessoa
Coda referencia Automovel
1. Liste as pessoas que compraram algum carro.
2. Liste as pessoas que compraram automóveis “Ford”
(fabricante).
3. Liste as pessoas que não compraram “Ford”.
4. Liste as pessoas que compraram carro com ágio. O
resultado deverá ser apresentado em ordem alfabética.
5. Liste as pessoas que compraram “Ford” e não compraram
“Volks”.
4.3.10. Funções agregadas
A SQL oferece a habilidade para computar funções em grupos de tuplas,
usando a cláusula group by. O(s) atributo(s) dado(s) na cláusula group by
são usados para formar grupos. Tuplas com o mesmo valor em todos os
atributos na cláusula group by são colocados em um grupo.
Funções agregadas:
Média: AVG
Mínimo: MIN
Máximo: MAX
Soma: SUM
Contar: COUNT
Para ilustrar, considere as consultas “ Encontre o saldo médio das contas em
cada agência”
SELECT NomeAg, AVG(Depósitos.saldo) AS Saldo_Medio
FROM Depositos, Agencias
WHERE Depositos.CodigoAg = Agencias.CodigoAg
GROUP BY NomeAg
“Encontre a quantidade de depositantes de cada agência”
SELECT NomeAg, COUNT(distinct Nome) AS Qtd_Clientes
FROM Depositos, Agencias
WHERE Depositos.CodigoAg = Agencias.CodigoAg
GROUP BY NomeAg
66
Note que nesta última consulta é importante a existência da cláusula
distinct, pois um cliente pode ter mais de uma conta em uma agência e
deverá ser contado uma única vez.
“Encontre o maior saldo de cada agência”
SELECT NomeAg, MAX(Depositos.saldo) AS Maior_Saldo
FROM Depositos, Agencias
WHERE Depositos.CodigoAg= agencias.CodigoAg
GROUP BY NomeAg
Às vezes é útil definir uma condição que se aplique a grupos em vez de
tuplas. Por exemplo, poderíamos estar interessados apenas em agências em
que a média dos saldos seja maior que R$1200,00. Essa condição será
aplicada a cada grupo e não a tuplas simples e é definida pela cláusula
having. Podemos escrever essa expressão SQL assim:
SELECT NomeAg, AVG(Depositos.saldo) AS Saldo_Medio
FROM Depositos
GROUP BY NomeAg
HAVING AVG(saldo)>1200
Às vezes, desejamos tratar a relação inteira como um grupo simples. Nesses
casos, não usamos a cláusula group by. Para encontrar a média de saldos de
todas as contas, escrevemos:
SELECT AVG (Depositos.saldo)
FROM Depósitos
Atividade 06
Considere o esquema bancário para construir as expressões
seguintes, usando a linguagem SQL.
1) Selecione todos os clientes que possuem contas em
agência(s) que possui(em) o maior ativo.
2) Selecione o total de agências por cidade, classificado por
cidade.
3) Selecione, por agências, o(s) cliente(s) com o maior saldo.
4) Selecione o valor médio de empréstimos efetuados por
cada agência, em ordem crescente das cidades onde essas
agências se situam.
5) Selecione a(s) agência(s) que possui(em) a maior média
de quantia emprestada.
6) Selecione todas as agências situadas fora de Vitória que
possuem a média de depósitos maior do que alguma
agência localizada em Vitória.
7) Selecione o menor saldo de clientes, por agências.
8) Selecione o saldo de cada cliente, caso ele possua mais de
uma conta no banco.
67
4.3.11. Removendo linhas de uma tabela
O comando Delete é usado para remover tuplas em uma dada relação.
Lembre-se que só podemos remover tuplas inteiras, não podemos remover
valores apenas em atributos particulares.
Sintaxe:
DELETE
FROM r
[WHERE P]
Onde r representa uma relação e P um predicado.
Note que o comando delete opera em apenas uma relação. O predicado da
cláusula where pode ser tão complexo quanto o predicado where do
comando select.
Ex1.: Removendo todas as tuplas de empréstimo.
DELETE FROM emprestimos
Ex2.: Remover todos os depósitos de “joão”
DELETE FROM Depositos
WHERE depositos.CodigoCli in
(SELECT CodigoCli
FROM Clientes
WHERE Nome=”joão”)
Ex3.: Remover todos os empréstimos com números entre 1300 e 1500.
DELETE FROM Emprestimos
WHERE numero between 1300 AND 1500
Ex4.: Remover todos os depósitos de agências localizadas em “Vitória”.
DELETE FROM Depositos
WHERE depositos.CodigoAg in
(SELECT CodigoAg
FROM Agencias
WHERE cidade=”Vitoria”)
4.3.12. Inserindo linhas em uma tabela
Para inserir um dado em uma relação, ou especificamos uma tupla para ser
inserida ou escrevemos uma consulta cujo resultado seja um conjunto de
tuplas a serem inseridas. Obviamente, os valores dos atributos para tuplas
inseridas precisam ser membros do mesmo domínio do atributo.
Sintaxe:
INSERT INTO r (A1, A2, ..., An)
VALUES (V1, V2, ..., Vn)
Onde r representa uma relação A atributos e V valores a serem inseridos.
68
Suponha que desejamos inserir um novo depósito de João (código = 1), cujo
valor seja R$1200,00, na conta 9000 da agência de código=2. Para isso,
fazemos o seguinte comando:
INSERT INTO depositos (CodigoAg, NumeroCont, CodigoCli, saldo)
VALUES (2,9000,1,1200)
Podemos querer também inserir tuplas baseadas no resultado de uma
consulta. Suponha que desejemos inserir todos os clientes que possuam
empréstimos na agência “Princesa Isabel” na relação depósitos, com um
saldo de R$200,00.
INSERT INTO Depositos (CodigoAg, NumeroCont, CodigoCli, saldo)
SELECT emprestimos.CodigoAg, NumeroEmp, CodigoCli, 200
FROM Emprestimos, Agencias
WHERE emprestimos.CodigoAg=agencias.CodigoAg AND
NomeAg=”Princesa Isabel”
4.3.13. Atualizando valores
Em certas situações, podemos desejar mudar valores em tuplas. Nesse caso,
o comando update deve ser aplicado.
Sintaxe:
UPDATE r SET a1 = v1, a2 = v2, ..., an = vn
[WHERE p]
Em que r representa uma relação, a atributos, p predicado e v os novos
valores para os respectivos atributos.
Suponha que esteja sendo feito o pagamento de juros e que sejam
acrescentados 5% em todos os saldos. Escrevemos
UPDATE Depositos
SET saldo = saldo * 1.05
Suponha que todas as contas com saldo superior a R$10000,00 recebam
aumento de 6% e as demais de 5%.
UPDATE Depositos
SET saldo = saldo * 1.06
WHERE saldo >10000
UPDATE Depositos
SET saldo = saldo * 1.05
WHERE saldo<=10000
A cláusula where pode conter uma série de comandos select aninhados.
Considere, por exemplo, que todas as contas de pessoas que possuem
empréstimos no banco terão acréscimo de 1%.
UPDATE Depositos
SET saldo = saldo * 1.01
WHERE CodigoCli IN (SELECT CodigoCli FROM emprestimos)
69
4.3.14. Valores Nulos
É possível para tuplas inseridas em uma dada relação atribuir valores a
apenas alguns atributos do esquema. Os atributos restantes são designados
como nulos. Considere a expressão cujo objetivo é o de incluir uma nova
agência:
INSERT into Agencias (CodigoAg, NomeAg, CidadeAg, ativos)
VALUES (2,’Centro’,’Vitória’,null)
Nesse caso, está sendo atribuído o valor nulo para o atributo “ativos”. A
mesma consulta poderia ser reescrita omitindo esse atributo. Nesse caso,
automaticamente ele assumiria o valor nulo.
INSERT into Agencias (CodigoAg, NomeAg, CidadeAg)
VALUES (2,’Centro’,’Vitória’)
A palavra chave null pode ser usada em um predicado para testar se um
valor é nulo. Assim, para achar todos os clientes que aparecem na relação
empréstimos com valores nulos para quantia, escrevemos:
SELECT distinct Nome
FROM Clientes, Emprestimos
WHERE Clientes.CodigoCli = Emprestimos.CodigoCli
AND Quantia IS NULL
O predicado is not null testa a ausência de um valor nulo.
70
Atividade 07
Considere o esquema abaixo para construir as expressões
seguintes, usando a linguagem SQL.
Pessoas (CodPessoa, Nome, Cidade, Chefe)
Chefe referencia Pessoas
Empresas (CodEmpresa, Nome, Cidade)
Trabalha (CodPessoa, CodEmpresa, Salario)
CodPessoa referencia Pessoas
CodEmpresa referencia Empresas
Observação: Estas atividades foram elaboradas para exercitar os
comandos de atualização. Desconsidere a integridade referencial
dos dados.
1. Exclua todas as pessoas que possuem salario =
R$1000,00.
2. Exclua todas as pessoas que trabalham em empresas
situadas em Vitória.
3. Inclua na empresa de código “01”, com um salário=
R$100,00, todos os moradores de Vitória
4. Uma determinada empresa de código “x” vai contratar
todos os funcionários da empresa de código “y” que
ganham acima de R$1000,00, dando um aumento de
salário de 10%. Faça comando(s) SQL para que tal
transação seja efetuada. Obs: As pessoas serão
remanejadas.
5. Uma determinada empresa de código “xyz” quer contratar
todos que moram em Vitória e estão desempregados.
Serão contratados com salário = R$200,00. Faça
comando(s) SQL para efetuar tal transação.
6. Faça um comando SQL para ajustar o salário de todos os
funcionários da empresa “Campana” em 5%.
7. Todas as pessoas que moram em Colatina e trabalham na
empresa “Campana” deverão se mudar para Vitória,
devido aos requisitos do diretor da empresa. Faça
comando(s) SQL para efetivar a atualização da cidade.
4.3.15. Definição de dados
O conjunto de relações de um Banco de Dados precisa ser especificado ao
sistema por meio de uma linguagem de definição de dados (DDL).
A SQL DDL permite a especificação não apenas de um conjunto de relações,
mas também de informações sobre cada relação, incluindo:

O esquema para cada relação;

O domínio de valores associados a cada atributo;

O conjunto de índices a ser mantido para cada relação;

Restrições de integridade;

A estrutura física de armazenamento de cada relação no disco.
71
4.3.16. Tipos de Domínios da Linguagem SQL
A linguagem SQL inclui diversos tipos de domínios, conforme lista abaixo
[SILBERSCHATZ, 2006]:
Char(n): cadeia de caracteres de tamanho fixo, igual a n, definido pelo
usuário;
Varchar(n): cadeia de caracteres de tamanho variável, no máximo igual a n,
definido pelo usuário;
Int: inteiro (subconjunto finito dos inteiros que depende do equipamento).
Smallint: inteiro pequeno (um subconjunto do domínio dos inteiros que
depende do equipamento);
Numeric(p,d): número de ponto fixo cuja precisão é definida pelo usuário.
O número consiste de p dígitos , sendo que d dos p dígitos estão à direita do
ponto decimal;
Real: números de ponto flutuante cuja precisão depende do equipamento em
questão;
Float(n): número de ponto flutuante com a precisão definida pelo usuário
em pelo menos n dígitos;
Date: calendário contendo um ano (com quatro dígitos), mês e dia do mês;
Time: representa horário, em horas, minutos e segundos.
Uma relação SQL é definida usando a instrução CREATE TABLE.
CREATE TABLE r (A1 D1, ..., An Dn)
Em que r é uma relação, cada Ai é o nome de um atributo no esquema de
relação r e Di é o tipo de dados de valores no domínio de atributo Ai. O
comando create table inclui opções para especificar certas restrições de
integridade, conforme veremos adiante.
A relação criada acima está inicialmente vazia. O comando insert poderá ser
usado para carregar os dados para uma relação.
Para remover uma relação de banco de dados SQL, usamos o comando drop
table, que remove todas as informações sobre a relação retirada do banco de
dados.
DROP TABLE r
Ex. : para excluir a relação Depósitos, podemos escrever a seguinte
expressão SQL.
DROP TABLE Depositos
72
O comando alter table é usado para alterar a estrutura de uma relação
existente. Ao alterar a estrutura de uma tabela, é possível incluir novos
campos, excluir campos existentes ou incluir restrições, a exemplo de chaves
primárias e estrangeiras.
Sintaxe:
alter table r <add,drop> A [dominio, integridade]
Em que r é a relação a ser alterada; add, adiciona um atributo a r e drop,
remove um atributo de r.
Ex.: Incluindo uma coluna de CPF na tabela clientes. Não será possível
incluir um cliente sem CPF, uma vez que foi definido como NOT NULL.
ALTER TABLE Clientes ADD cpf NUMERIC(11,0) NOT NULL
4.3.17. Integridade
Quando se fala em manter a integridade de dados, considera-se não só a
Integridade Física dos arquivos portadores do banco de dados, como também
manutenção da qualidade dos dados armazenados em termos de precisão e
consistência.
As restrições de integridade fornecem meios para assegurar que mudanças
feitas no banco de dados por usuários autorizados não resultem na perda da
consistência dos dados. São vários os tipos de integridade. Eles costumam
ser classificados da seguinte forma:

Integridade de Domínio
Domínio é uma lista de valores que precisa estar associada a todo atributo.
Constitui a forma mais elementar de restrição de integridade. É facilmente
testado pelo sistema cada vez que um novo item de dado é inserido no banco
de dados.

Integridade de Vazio
Especifica se um campo de uma coluna pode ou não assumir valor nulo. Não
pode permitir que os campos com entrada obrigatória assumam valores
nulos.

Integridade de Chaves
Especifica a unicidade dos valores para a chave primária e candidatas.

Integridade Referencial
Frequentemente desejamos assegurar que um valor que aparece em uma
relação para um dado conjunto de atributos, apareça também para um certo
conjunto de atributos em outra relação, o que se denomina Integridade
Referencial.
A existência de uma chave estrangeira impede que anomalias ocorram em
função de alterações executadas no banco de dados, conforme elencadas
abaixo:
73

Ao incluir uma linha na tabela que contém a chave estrangeira, o
valor inserido tem que fazer parte da tabela em que ela é chave
primária. O único valor diferente desse que é permitido é o valor
nulo, quando for possível;

Ao excluir uma linha da tabela que contém chave primária
referenciada por outras tabelas, pode-se implementar os seguintes
cenários: excluir em cascata as linhas nas tabelas relacionadas em
que se encontram as chaves estrangeiras referentes a essa chave
primária ou impedir que a exclusão seja feita;

Ao alterar o valor da chave primária referenciada por outras tabelas,
pode-se implementar os seguintes cenários: alterar em cascata os
valores das chaves estrangeiras nas tabelas relacionadas ou impedir
que a alteração seja feita;

Ao se alterar o valor da chave estrangeira, deve-se ter garantia de
que o novo valor esteja constante na tabela em que ela é chave
primária. Se não for, haverá bloqueio na alteração.
4.3.18. Implementando Integridade Referencial em SQL
A SQL original padrão não incluiu instruções para especificar chaves
estrangeiras. Um subsequente “recurso de aperfeiçoamento de integridade”
foi aprovado como uma adição ao padrão. Esse recurso permite a
especificação de chaves primárias, candidatas e estrangeiras como parte da
instrução create table.

A cláusula primary key da instrução create table inclui uma lista de
atributos que compreende a chave primária.

A cláusula unique da instrução create table inclui uma lista de
atributos que compreende a chave candidata.

A cláusula foreign key da instrução create table inclui uma lista de
atributos que compreende a chave estrangeira e o nome da relação
referida pela chave estrangeira.
Criando as relações clientes, agências e depósitos para o esquema do banco.
CREATE TABLE Clientes
(CodigoCli int not null,
nome char(30) not null,
rua char(30),
cidade char(30),
cpf numeric(11,0),
PRIMARY KEY (CodigoCli)
UNIQUE (CPF))
CREATE TABLE Agencias
(codigoAg int not null,
NomeAg char(30),
CidadeAg char(30),
PRIMARY KEY (CodigoAg))
CREATE TABLE Depositos
(codigoAg int not null,
74
NumeroCont char(10) not null,
CodigoCli int not null,
saldo real,
PRIMARY KEY (codigoAg,NumeroCont),
FOREIGN KEY (CodigoCli) REFERENCES Clientes,
FOREIGN KEY (codigoAg) REFERENCES Agencias,
CHECK (Saldo >=0) )
A cláusula Check garante integridade aos valores dos atributos e pode fazer
referência, inclusive, a valores de atributos em outras tabelas.
75
Atividade 08
Dados os esquemas abaixo, faça comandos SQL DDL padrão para
criar as estruturas das tabelas, usando o tipo de dados que melhor
se aplique a cada atributo e impondo integridade referencial.
a)
Alunos
(CodigoAl, NomeAl, CodigoCurso, Telefone,
CoeficienteRendimento)
CodigoCurso referencia Cursos
Cursos
(CodigoC, NomeC)
Disciplinas
(CodigoDisc, CodigoCurso, NomeDisc)
CodigoCurso referencia Cursos
Historico
(CodigoAl, CodigoDisc, Periodo, Nota)
CodigoAl referencia Alunos
CodigoDisc referencia Disciplinas
Pre_Requisitos (CodigoDiscPos, CodigoDiscPre)
CodigoDiscPos referencia Disciplinas
CodigoDiscPre referencia Disciplinas
b)
Clientes (CodCliente, NomeCliente, Telefone, DtNascimento)
Filmes
(CodFilme, NomeFilme, Lancamento, DtAquisicao,
CodClasse)
CodClasse referencia Classes
Fitas (CodFilme, NumeroFita, Dublada)
CodFilme referencia Filmes
Locacoes
(CodFilme, NumeroFita, CodCliente, DtLocacao,
DtDevolucao, VlrLocacao, Multa)
(CodFilme, NumeroFita) referencia Fitas
CodCliente referencia Clientes
Reservas (Codfilme, CodCliente, DtReserva, Situacao)
CodFilme referencia Filmes
CodCliente referencia Clientes
Classes (CodClasse, Nome, Valor)
Obs.: Considere a entrada obrigatória de todos os campos, exceto
os campos: telefones, data de devolução de fitas e valor de multa.
Não permita valores diferentes de ‘S’ ou ‘N’ nos campos
“Lançamento”, na tabela “Filmes”, e “Dublada”, na tabela “Fitas”.
76
REFERÊNCIAS
NAVATHE, E. Sistemas de Bancos de dados. 4. ed. São Paulo:
Pearson Addison Wesley, 2005.
DATE, C. J. Bancos de dados: introdução aos sistemas de bancos de
dados. 8. ed. Rio de Janeiro: Campus, 2004.
SILBERSCHATZ, Abraham. Sistema de banco de dados. 5. ed. São
Paulo: Campus, 2006.
CHEN, Peter. Modelagem de Dados - A abordagem EntidadeRelacionamento para Projeto Lógico. São Paulo: Makron Books,
1990.
HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre:
Sagra Luzzato, 2004.
FALBO, R. A. Projeto de Sistemas – Notas de Aula. Disponível em
http://www.inf.ufes.br/%7Efalbo/disciplinas/projeto.html. Acesso em
23 de março de 2009.
77