Banco de Dados I

PROF. CLAUDINETE VICENTE BORGES FERREIRA

BANCO DE DADOS

VITÓRIA 2013

IFes – Instituto Federal do Espírito Santo

1

Banco de Dados I
Governo Federal Ministro de Educação Fernando Haddad Ifes – Instituto Federal do Espírito Santo Reitor Dênio Rebello Arantes Pró-Reitora de Ensino Cristiane Tenan Schlittler dos Santos

IFes – Instituto Federal do Espírito Santo

2

Banco de Dados I

ICONOGRAFIA
Veja, abaixo, alguns símbolos utilizados neste material para guiá-lo em seus estudos.

Fala do professor.

Conceitos importantes. Fique atento!

Atividades que devem ser elaboradas por você, após a leitura dos textos.

Indicação de leituras complementares, referentes ao conteúdo estudado.

Destaque de algo importante, referente ao conteúdo apresentado. Atenção!

Reflexão/questionamento sobre algo importante, referente ao conteúdo apresentado.

Espaço reservado para as anotações que você julgar necessárias.

IFes – Instituto Federal do Espírito Santo

3

Banco de Dados I

Sumário
1. CONCEITOS DE BANCOS DE DADOS ................................................................................................................... 8 1.1. DEFINIÇÃO ........................................................................................................................................................... 8 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 ............................................................................... 13 1.7.1. Sistemas Centralizados ................................................................................................................................. 13 1.7.2. Sistemas Cliente-Servidor ............................................................................................................................. 13 1.7.3. Sistemas Paralelos ........................................................................................................................................ 14 1.7.4. Sistemas Distribuídos .................................................................................................................................... 14 1.8. MODELOS DE BANCOS DE DADOS ................................................................................................................ 14 1.8.1. Modelo em Rede ............................................................................................................................................ 15 1.8.2. Modelo Hierárquico ...................................................................................................................................... 16 1.8.3. Modelo Relacional ........................................................................................................................................ 16 1.8.4. Modelo Objeto-Relacional ........................................................................................................................... 17 1.8.5. Modelo Orientado a Objeto .......................................................................................................................... 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. INTRODUÇÃO .................................................................................................................................................... 24 2.2. MODELOS ........................................................................................................................................................... 24 2.3. MOTIVOS PARA CONSTRUÇÃO DE MODELOS ........................................................................................... 25 2.4. MODELO DE ENTIDADES E RELACIONAMENTOS – E/R ........................................................................... 25 2.4.1. Entidades ....................................................................................................................................................... 25 2.4.2. Atributos ........................................................................................................................................................ 26 2.4.3. Relacionamentos ........................................................................................................................................... 30 2.5. DICIONÁRIO DE DADOS .................................................................................................................................. 37 2.6. EXEMPLO DE UM MODELO DE DADOS ........................................................................................................ 38 2.7. FERRAMENTAS CASE ...................................................................................................................................... 40 2.8. MODELO ER ESTENDIDO - EER ...................................................................................................................... 40 3. PROJETO LÓGICO DE BANCO DE DADOS ....................................................................................................... 42 3.1. DEFINIÇÃO ......................................................................................................................................................... 42 3.2. ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS .............................................................................. 42 3.3. CHAVES ............................................................................................................................................................... 43 3.4. PROPRIEDADES DO MODELO RELACIONAL............................................................................................... 45 3.5. TRADUÇÃO DO MODELO ER PARA O RELACIONAL ................................................................................. 46 3.5.1. Relacionamento 1:1....................................................................................................................................... 48 3.5.2. Relacionamento 1:N ...................................................................................................................................... 48 3.5.3. Relacionamento 1:N - identificado................................................................................................................ 49 3.5.4. Relacionamento N:N ..................................................................................................................................... 49 3.5.5. Generalização e Especialização ................................................................................................................... 50 3.5.6. Autorrelacionamento 1:N .............................................................................................................................. 51 3.5.7. Autorrelacionamento N:N ............................................................................................................................. 52 3.5.8. Atributos Multivalorados .............................................................................................................................. 52 3.6. EXEMPLO DE PROJETO LÓGICO .................................................................................................................... 54

IFes – Instituto Federal do Espírito Santo

4

........ 56 4......7.........2........................................................................2...................................................................................................................................3.. 59 4........2.................................... SQL ..........................3... Linguagem de Manipulação de Dados – SQL DML .................. 58 4............................................................................ Linguagem de Definição de dados – SQL DDL ...................................................................................................................................................................................................................1.......................... LINGUAGENS DE CONSULTA ...................................................................... 58 4......1..............7..... 75 REFERÊNCIAS ....................................2....7.................. 55 3........................................7........................................................................................... 55 3.............. NORMALIZAÇÃO ........... Segunda Forma Normal (2FN) .................................................................1............................................................................................................. 55 3.................................. Primeira Forma Normal (1FN) .................................. DEFINIÇÃO .... Terceira Forma Normal (3FN) ................................................................................. 82 ......... 58 4..........2..........

e para sua vida profissional. caso você faça a opção por trabalhar na área de Análise de Sistemas. por meio de dicas e sugestões. como Ufes. Carlos Alberto Heuser. Nesta disciplina você conhecerá conceitos de modelagem e de bancos de dados. este material impresso não dispensa a utilização dos livros referenciados na bibliografia. com destaque aos pontos mais importantes. Os Bancos de Dados são responsáveis por manter a persistência dos sistemas de informações existentes no mercado. Peter Chen. UVV e Unilinhares. Além destes autores. a ser ofertada no próximo semestre. Aqui você encontrará conceitos com os quais trabalharemos ao longo do Curso. que trazem diversos exemplos adicionais e aprofundamento maior em vários aspectos. o que nos mostra a importância da disciplina em um curso de Análise de Sistemas. tendo sido elaborado tomando como referência livros clássicos das áreas correlatas. responsável pela disciplina Banco de Dados. Foi preparado para você com muito carinho! Sucesso!!! Profa. Apesar disso.Olá! Meu nome é Claudinete Borges. Os conceitos aqui apresentados devem ser bem assimilados. Claudinete Vicente Borges Ferreira . Este material tem como objetivo o de orientá-lo no estudo da disciplina Banco de Dados I. Sou graduada em Ciência da Computação (1995) e mestre em Informática (2001). ambos pela UFES. teve a contribuição valiosa da professora e amiga Eliana Caus que muito enriqueceu com suas notas de aula e sugestões. Atuo como professora do Ifes há cinco anos e já lecionei em outras instituições de ensino superior. Minhas áreas de interesse são Banco de Dados e Engenharia de Software. tais como Abraham Silberschatz. Elmasri Navathe e outros. pois servirão de base para a disciplina Banco de Dados II.

.

1. CONCEITOS DE BANCOS DE DADOS

Olá, Neste capítulo você terá um primeiro contato com a disciplina Banco de Dados. A proposta é de apresentar conceitos importantes que servirão de base para o restante do curso. Bom estudo! Profa. Claudinete Vicente Borges

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, tais como: 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 gerenciá-los, 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 estes dados [SILBERSCHATZ, 2006]. A figura 1 abaixo representa este conceito de forma gráfica.

Figura 1: Ilustração do conceito de um SGBD.

Um banco de dados é um conjunto de dados integrados, cujo objetivo é atender uma comunidade de usuários [ HEUSER, 2004]. Um SGBD é um software de caráter geral, usado para manipulação eficiente de grandes coleções de informações estruturadas e armazenadas de uma forma consistente e integrada [SILBERSCHATZ, 2006]. SGBD = Conjunto de programas + Conjunto de dados.

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. 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 existentes 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 este valor 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 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 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. Considerando que as características descritas não são incluídas nos arquivos convencionais, elas devem ser incluídas nas aplicações. Imagine a complexidade das aplicações escritas para implementá-las! Os Sistemas de Bancos de Dados de médio e grande porte existentes no mercado implementam esses conceitos com muita robustez.

Você deve estar pensando: será que existem vantagens em usar os sistemas de arquivos? O custo mais baixo pode ser considerado uma vantagem.

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 as 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. O DBA pode ser comparado com um profissional da área médica. Se for responsável por sistemas que requerem alta disponibilidade, deve ficar de plantão 24 h por dia.

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 lógico 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.

O objetivo é alcançar o máximo de independência possível. Normalmente. A figura 2 representa graficamente os níveis listados acima. 2006.6. Independência Lógica de dados: habilidade de modificar o esquema conceitual. sem a necessidade de reescrever os programas aplicativos. INDEPENDÊNCIA DE DADOS A independência de dados pode ser definida como a imunidade das aplicações às alterações feitas. sem a necessidade de reescrever os programas aplicativos. Pode ser classificada em: Independência Física de dados: habilidade de modificar o esquema físico. 1.. ou seja. modificações no nível físico visam à melhoria de desempenho. como a criação de índices! . As modificações no nível conceitual são necessárias quando a estrutura lógica do banco de dados é alterada.Os SGBD’s possibilitam aos usuários uma visão abstrata dos dados. Visão n Nível Lógico Nível Físico Figura 2: Níveis de abstração de dados Fonte: Silberschatz. seja no nível físico ou no nível lógico de um banco de dados. Korth e Sudarshan.. Visão 1 Visão 2 . As modificações no nível físico são ocasionalmente necessárias para melhorar o desempenho. Adaptação. os usuários não precisam saber como os dados são armazenados e mantidos para usá-los.

. embora algumas pessoas utilizem o termo para descrever diferentes componentes de software se comunicando uns com os outros. não interagindo com outros sistemas. o controle de concorrência e a recuperação. A separação de hardware é a norma em aplicações cliente-servidor. ainda que rodando em uma mesma máquina. as funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias: front-end e back-end. no qual múltiplos clientes iniciam requisições que são realizadas por um ou mais servidores centrais. Sistemas Centralizados Os sistemas centralizados são os executados sobre um único sistema operacional. até aqueles localizados em diferentes prédios.Qual abordagem é mais fácil de ser alcançada: independência física ou lógica de dados? Normalmente. gerador de relatórios e recursos de interface gráfica.7. 1. O front-end consiste em ferramentas como formulários. Nessa arquitetura. há uma tendência de ampliar o seu uso nos sistemas centralizados. Eles podem ter a envergadura de um sistema de banco de dados de um só usuário. O back-end gerencia as estruturas de acesso. por isso terminais conectados a sistemas centralizados estão sendo substituídos por computadores pessoais. executado em um computador pessoal ou em sistemas de alto desempenho. Como resultado. denominados de “grande porte”.1. como em uma tabela. Sistemas Cliente-Servidor Como os computadores pessoais têm se tornado mais rápidos. 2006]. cidades ou mesmo espalhados pelo planeta. as aplicações que referenciam essa tabela devem continuar funcionando. o desenvolvimento e a otimização de consultas. a despeito da alteração feita! 1.2. O termo cliente-servidor é usado para descrever software que é executado em mais de um hardware de modo a realizar uma tarefa do negócio. 1. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS 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 [SILBERSCHATZ. A distância entre processadores remotos varia desde computadores localizados na mesma sala ou prédio. A interface entre o front-end e o back-end é feita por meio de SQL ou de um programa de aplicação. A computação cliente-servidor é um processamento cooperativo de informações de negócio por um conjunto de processadores.7. os sistemas centralizados atualmente agem como sistemas servidores que atendem a solicitações de sistemas-cliente. Ao criar um índice. mais potentes e baratos.7. a independência física de dados é mais fácil de ser alcançada do que a lógica.

Já o tempo de resposta diz respeito ao tempo total que o sistema pode levar para executar uma única tarefa. Computadores paralelos com centenas de processadores já estão disponíveis comercialmente. Outra grande diferença é que nos sistemas distribuídos distinguimos transações locais (acessa um único computador. ao contrário do processamento serial.4. Sistemas Distribuídos Em um sistema distribuído. há a distribuição física geográfica. relacionais. como redes de alta velocidade ou linhas telefônicas. os demais podem continuar em operação). Um equipamento paralelo de granulaçãogrossa consiste em poucos e poderosos processadores (a maioria dos servidores atuais). As principais diferenças entre os bancos de dados paralelos e os bancos de dados distribuídos são que. Um sistema que processa um grande volume de transações pode reduzir o tempo de resposta por meio de processamento em paralelo. Há. No processamento paralelo muitas operações são realizadas ao mesmo tempo. MODELOS DE BANCOS DE DADOS Os modelos de bancos de dados definem a forma como os dados encontramse organizados internamente. com capacidade menor de processamento. no entanto. Sistemas Paralelos Sistemas paralelos imprimem velocidade ao processamento e à CPU. os modelos de banco de dados classificam-se em redes. algumas desvantagens relacionadas ao seu uso.3. Há diversas razões para a utilização de sistemas de bancos de dados distribuídos. sendo necessária a participação de um coordenador). enquanto um paralelismo intensivo ou de granulação fina usa milhares de pequenos processadores.7. o banco de dados é armazenado. As duas principais formas de avaliar o desempenho de um sistema de banco de dados são pelo throughput e pelo tempo de resposta. autonomia (cada local administra seus próprios dados) e disponibilidade (se porventura um SGBD sair do ar.8. hierárquicos. 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. a administração ocorre de forma separada e há uma intercomunicação menor.7. em diversos computadores denominados sites. dentre as quais: custo de desenvolvimento de software. O primeiro diz respeito ao número de tarefas que podem ser executadas em um dado intervalo de tempo. no qual os passos do processamento são sucessivos. 1. por meio do uso em paralelo de CPU’s e discos. nos bancos de dados distribuídos. 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. Em ordem cronológica. geograficamente. objeto- . maior possibilidade de bugs e aumento do processamento e sobrecarga. em que a transação foi iniciada) e globais (envolve mais de um computador. dentre as quais: compartilhamento dos dados (usuários de um local podem ter acesso a dados residentes em outros – por exemplo: bancos). 1.1.

Devido a essa proximidade ao nível físico.1. podem ser implementadas sob a forma de ponteiros. Um conjunto de ocorrência de registro de um mesmo tipo determina um tipo de registro. O Modelo Relacional. assim. similar a uma entidade no modelo entidade-relacionamento. quando comparado à Estrutura Rede e Hierárquica. 2006]. há uma breve descrição sobre cada um desses modelos. Luiza. que. Uma ligação é uma associação entre dois registros. por sua vez. considerando os dois tipos de registros informados. A seguir. por meio de referências especiais. 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. embora possamos considerar as diversas redundâncias existentes em diversas tabelas como sendo uma forma de rota de acesso. As referências estão normalmente inseridas junto com as ocorrências de registro. Um conjunto de tipos de registros relacionados entre si. em muitos aspectos. Assim.8. por exemplo. 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. forma uma estrutura de dados em rede. uma ligação pode ser vista como um relacionamento binário no modelo ER [SILBERSCHATZ. é mais orientado para modelagem do que como modelo com rotas de acesso. todo o acesso a um próximo registro utiliza o ponteiro inserido no registro corrente disponível. por exemplo. O modelo de banco de dados da Figura 3 mostra as ligações entre os registros de departamento e empregado. em que EMPREGADO possui as seguintes características: matrícula. e DEPARTAMENTO: código e nome. Matheus e Gabriel. 1. possui dois funcionários lotados. possibilitando a localização lógica de um determinado registro no banco de dados. As referências especiais são conhecidas como ligações. está lotada no Departamento de Informática. Figura 3: Exemplo de Banco de Dados – Modelo Redes.relacionais e orientados a objetos. Considere um banco de dados com registros de DEPARTAMENTO e EMPREGADO. enquanto o Departamento de Geografia. Um registro é. nome e cidade. as estruturas de dados rede e hierárquica exibem as rotas lógicas de acesso de dados de forma acentuada. A figura 3 mostra um exemplo do banco de dados. . O Modelo Rede utiliza como elemento básico de dados a ocorrência de registro.

Um banco de dados hierárquico compõe-se de um conjunto ordenado de árvores.2. A própria estrutura hierárquica define as suas rotas de acesso. o superior. usa um conjunto de tabelas para representar tanto os dados quanto a relação entre eles. juntamente com um conjunto ordenado de zero ou mais (nível inferior) tipos de subárvores dependentes. As ligações entre as tabelas é feita por meio dos valores dos atributos ou colunas. facilitando.3. de um conjunto ordenado de ocorrências múltiplas de um tipo único de árvore. por sua vez. Todas as ocorrências de um dado tipo de filho que compartilham uma ocorrência de pai comum são chamadas de gêmeas. Modelo Relacional O modelo relacional. Nessas condições. A é denominado registro PAI de B. No entanto. portanto. A diferença entre eles se dá pelo fato de o banco de dados hierárquico organizar esses registros como coleções de árvores. É importante notar que um determinado tipo de registro B. No primeiro nível. em nível 2. Um tipo de subárvore. O tipo árvore compõe-se de um único tipo de registro “raiz”. No entanto. é registro FILHO de A . Figura 4: Exemplo de Banco de Dados – Modelo Hierárquico. conforme descrito posteriormente. Cada tabela possui múltiplas colunas e pode possuir múltiplas linhas. uma série de outros tipos de registros em nível 2. A associação entre tipos de registros segue uma hierarquia estabelecida por diversos níveis.8. que. A cada tipo de registro em nível 2 subordina-se um outro conjunto de tipos de registros. mais precisamente. por meio de ligações. por sua vez. Modelo Hierárquico Um banco de dados hierárquico consiste em uma coleção de registros relacionados. a atualização pode ser bastante custosa. a manutenção do banco de dados. também se compõe de um único tipo de registro. de nível K1 (superior). como no modelo em redes. situa-se o tipo de registro “Raiz” . As tabelas 1 e 2 abaixo mostram exemplos de Tabelas do modelo relacional. uns aos outros. um tipo de registro A pode estar ligado a diversos filhos no nível de B. Uma vantagem dos bancos de dados hierárquicos é o tempo de resposta em consultas.1. em vez de grafos arbitrários.8. A figura 4 abaixo ilustra um exemplo do modelo Hierárquico. 1. . Subordinado a ele. num determinado nível K. possui ligação com um e somente um tipo de registro A. diferentemente dos modelos redes e hierárquico.

4. armazenamento de imagens e textos longos. A SQL-99 inclui recursos para dar suporte a esse modelo de banco de dados. é um modelo intermediário entre o relacional e o orientado a objetos. sem estar limitada pelos tipos de dados e linguagens de consulta disponíveis em sistemas de banco de dados tradicionais.8.5. entretanto. tais como sistemas de informações geográficas e multimídias. Modelo Orientado a Objeto O modelo relacional. algumas limitações quando aplicações mais complexas precisam ser projetadas e implementadas. 2005]. o projetista especifica a estrutura de objetos complexos bem como as operações que incidem sobre esses objetos. é necessário fazer um mapeamento entre esses dois mundos. Outra razão para o uso de banco de dados orientados a objetos é a predominância das linguagens orientadas a objetos.8. A abordagem orientada a objetos oferece a flexibilidade para lidar com alguns desses requisitos. tais como estruturas complexas para objetos. os bancos de dados que se enquadram nesse modelo caracterizamse por usar a estrutura básica do modelo relacional. também conhecido como relacional estendido. Estas características incluem: herança de tipos e tabelas e definição de novos tipos complexos. Nesses bancos. considerando as limitações impostas pelo modelo relacional. Modelo Objeto-Relacional O modelo objeto-relacional. dentre outras. 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. Na verdade. possuindo. 1.Tabela 1: Tabela EMPREGADOS Matricula 01 02 03 04 CodDepto 01 02 03 Nome Luiza Matheus Gabriel Joana Cidade Vitória Vila Velha Serra Aracruz NomeDepto Informática Geografia Português CodDepto 01 02 02 03 Tabela 2: Tabela DEPARTAMENTOS 1. incorporando algumas características dos bancos de dados orientados a objetos. No caso de uma aplicação orientada a objetos utilizar um banco de dados relacional para persistir os dados. o que dá trabalho. . Essas aplicações têm requisitos e características que as diferenciam das tradicionais aplicações comerciais. além da necessidade de definir operações não convencionais [NAVATHE.

esses bancos de dados não foram muito bem aceitos no mercado em função da simplicidade do modelo relacional. a exemplo do Oracle e do PostgreSQL. denominado objeto-relacional ou relacional estendido.3. 1. a despeito de falhas no sistema. Alguns SGBD´s proprietários e livres disponíveis no mercado enquadram-se nesse modelo. de modo a atender a todas as suas funções. ou seja. há uma proposta de um modelo híbrido. Com isso.Embora existam muitos benefícios para a adoção do modelo orientado a objetos. 1. Componentes para o tratamento de consultas: executam instruções de baixo nível geradas pelo compilador DML. incluindo: Arquivo de Dados: armazena o banco de dados. algumas delas fornecidas pelo sistema operacional. que se propõe a implementar alguns conceitos de orientação a objetos sobre a estrutura de um banco de dados relacional.1. Interpretador DDL: interpreta os comandos DDL e registra-os em um conjunto de tabelas que contêm metadados. 1. Outras estruturas de dados Diversas outras estruturas de dados são requeridas como parte da implementação do sistema físico.2. 1. . Esses módulos podem ser organizados em dois grandes grupos: o de processamentos de consultas e o de administração do armazenamento de dados. “dados sobre dados”. inteligíveis ao componente de execução de consultas. Componentes de processamentos de consultas Compilador DML: traduz comandos DML da linguagem de consulta em instruções de baixo nível.9. A Figura 5 mostra como esses componentes se relacionam. 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.9.9. e que as transações concorrentes serão executadas sem conflitos em seus procedimentos. Gerenciador de buffer: intermedia os dados entre o disco e a memória principal e decide quais dados colocar em cachê.9. 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. ESTRUTURA GERAL DO SISTEMA O sistema de banco de dados é dividido em módulos específicos. Gerenciamento de transações: garante que o banco de dados permanecerá em estado consistente.

ALTER INDEX. DROP TABLE. Estatísticas: armazenam informações sobre o banco de dados e são usadas pelo seletor de estratégias.10. ALTER TABLE. Korth e Sudarshan. 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. Figura 5: Estrutura Geral do Sistema Fonte: Silberschatz. CREATE INDEX. 1. Um dicionário de dados é um arquivo de metadados. LINGUAGEM DE DEFINIÇÃO DE DADOS (DDL) Contém a especificação dos esquemas dos bancos de dados. Principais comandos SQL-DDL: CREATE TABLE. Índices: permite o acesso mais rápido aos dados. .Dicionário de Dados: armazena informações sobre os dados do banco de dados. 2006. DROP INDEX. Adaptação.

Nos capítulos que se seguem serão explorados a modelagem conceitual e o projeto lógico de banco de dados. Estudos indicam que quanto maior o tempo gasto no projeto do banco de dados. Esse planejamento é extremamente importante para a estabilidade de todo o sistema. considera-se a tecnologia do banco de dados a ser usado. inserção de novos dados nos bancos de dados (INSERT). Imagine que seja construída uma casa sem que antes tenha sido feito um projeto de arquitetura.11. O mesmo acontece com sistemas mal-projetados ou nãoprojetados. 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. consiste na criação física do banco de dados. eliminação de dados nos bancos de dados (DELETE). etc. Provavelmente. ao submeter essa casa à manutenção. São responsáveis pela: • • • • recuperação da informação armazenada no banco de dados (SELECT). . como: relacional. restrições de integridade. Podemos comparar a criação de um sistema de banco de dados com a construção de uma casa. A terceira fase. ou mesmo quando submetidos a correções. Eles tornam-se pouco flexíveis a manutenções futuras. menor será o tempo despendido na manutenção do modelo. enquanto os comandos DML são responsáveis por manipular os dados armazenados nessas estruturas! 1. tanto de banco de dados quanto de linguagem de programação. incluindo plantas baixas. PROJETANDO BANCOS DE DADOS Antes de criarmos o banco de dados propriamente dito. tendo a preocupação com estruturas de armazenamento e recuperação dos dados a serem armazenados. considerando o modelo relacional. etc.12. que extrapola a fase de projeto. modificação de dados armazenados no banco de dados (UPDATE). devemos identificar uma forma de planejá-lo. no futuro. mas que independem da tecnologia a ser utilizada. 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. Os comandos DDL são responsáveis por definir as estruturas dos dados. cortes e fachadas. O Modelo Conceitual inclui características a serem incluídas no sistema.1. campos. orientado a objetos. A segunda fase pressupõe a construção de um modelo lógico. A primeira delas consiste na construção de um modelo conceitual. O processo de projetar um banco de dados inclui três fases distintas e integradas. tendo como base o Modelo Conceitual criado e inclui a definição de tabelas. quando for necessário agregar novas informações. Neste modelo.

para cada grupo de usuário abaixo listados. Programador e Analista de Aplicações 6) Liste. 1) Defina SGBD´s. Usuário de aplicações c. Qual modelo de banco de dados será utilizado em nossa disciplina? . 2) Cite duas desvantagens do uso de sistemas de arquivos em relação a SGBD´s. a. Descreva. em poucas linhas. Administrador de Banco de Dados b. 4) Cite as quatro arquiteturas de banco de dados existentes no mercado. referentes ao capitulo 1. 3) Defina uma vantagem de se usar sistemas de arquivos em relação a SGBD. em ordem cronológica. as características de cada uma delas. o nível em que o mesmo se encontra. os modelos de bancos de dados existentes no mercado. 5) Quais são os níveis de abstração proporcionados por um SGBD? Enquadre.Atividade 01 Faça os exercícios de fixação abaixo.

. e) delete from tabela. f) update tabela set campo 1 = valor 1.. d) alter table. Funcionários matricula 01 02 03 04 05 06 Cargos codigo 01 02 03 04 05 nome Ana Maria José Pedro Joana João CPF 123 234 245 125 435 467 cargo 2 1 3 1 2 1 nomeCargo Programador Topógrafo Engenheiro Pedreiro Motorista Liste os nomes dos funcionários para os seguintes cargos: Topógrafo... responda ao que se pede. 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.. Engenheiro.. Programador.. c) insert into tabela...Atividade 02 1) Dadas as relações abaixo. campo2 = valor2. b) create view.. .. a) create table..

4. ( ) Se alterar o esquema conceitual. Controle concorrência de 8. ( ) Desvantagem de sistemas de arquivos. . Possibilidade de erros de acesso concorrente 2. Linguagem de Definição de Dados (DDL) 9. ( ) Contém a especificação dos esquemas de banco. São conceitos importantes que servirão de base para entendimento dos conceitos explorados nos capítulos subseqüentes. Independência física de dados 7. em um determinado momento. ObjetoRelacional O objetivo deste capítulo foi de introduzir conceitos de bancos de dados. 1. Linguagem de Manipulação de Dados (DML) 10. Instância 5. não é necessário reescrever aplicações. Integridade de ( ) Refere-se à precisão ou validade dos dados. ( ) Se alterar o esquema físico.Atividade 03 1) Numere a segunda coluna de acordo com a primeira. ( ) Responsável pela modificação de dados armazenados no banco de dados. Abstração dados 3. não é necessário reescrever aplicações. ( ) Tarefa de um SGBD. ( ) Conjunto de informações contidas em determinado banco de dados. ( ) Os usuários não precisam saber como os dados são armazenados e mantidos. ( ) Trata-se de um modelo de banco de dados. Independência lógica de dados 6.

um aeromodelo sendo usado para testes de aerodinâmica. Um modelo de dados consiste em uma coleção de ferramentas conceituais para descrição de dados. ou seja. exploraremos o modelo de entidades e relacionamentos (ER) para construção de modelos de dados. mesmo antes da existência física. com o Modelo de Entidade e Relacionamentos (ER). não estamos condicionando que o modelo seja computadorizado. considerando que se trata da técnica de modelagem mais difundida para representação de modelos conceituais.1. Qualquer ambiente do mundo real é passível de ser modelado. MODELOS Um modelo é a representação abstrata e simplificada de um sistema real. contudo. é perceber que através de algum meio. independentemente de tecnologia. O importante. . com a qual se pode explicar ou testar o seu comportamento. já que o mesmo busca expressar o objeto observado algumas vezes. Partindo desse princípio. Trabalharemos. o manequim da vitrine.2. o desenho em perspectiva de uma nova cozinha.2006]. relacionamento entre os dados. segundo a perspectiva do usuário.2. ao construir modelos conceituais não há uma preocupação com a tecnologia a ser adotada para a sua implementação. Observe que. pode-se antecipar ou substituir a existência de uma realidade qualquer. tangível de tal objeto. Bom estudo! Profª Claudinete Vicente Borges 2. semântica e restrições [SILBERSCHATZ. Neste capítulo. seja uma maquete. MODELAGEM DE DADOS Olá! Neste capítulo você estudará conceitos de modelagem conceitual de dados. com especial destaque. Seguem alguns exemplos de modelos: • • • • • as plantas de apartamentos dos jornais. 2. Um modelo conceitual objetiva modelar os requisitos de negócio segundo a visão do usuário. em seu todo ou em parte. nessa definição. INTRODUÇÃO O principal objetivo da modelagem conceitual de dados é construir modelos que representem os requerimentos das informações do negócio. desenho ou descrição. o molde de uma roupa obtido em uma revista.

Entidades Entidades são representações abstratas de “coisas”.4. Basicamente. representar o ambiente observado. usualmente se denomina conjunto de entidades. 2. o modelo ER representa as entidades (coisas) e os relacionamentos (fatos) do mundo real. 2. estamos falando da entidade. servir de referencial para a geração de estruturas de dados.4. “objetos” do mundo real modelado. Esse modelo foi criado em 1976 por Peter Chen e pode ser considerado como padrão para a modelagem conceitual. estamos falando de um conjunto de departamentos.2.3. tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos de dados [CHEN. Podem representar tanto objetos concretos quanto abstratos. quando nos referimos ao departamento de informática. para os quais temos interesse em manter informações no banco de dados. em letra maiúscula e no plural. MOTIVOS PARA CONSTRUÇÃO DE MODELOS Segundo Cougo [COUGO. de uma instância do conjunto. em que há o interesse de monitorar o comportamento no sistema de informação em tese. favorecer o processo de verificação e validação. . os principais motivos para elaborarmos modelos são: • • • • • • • • focalizar características importantes de sistemas. Quando se trata de conjuntos de objetos com características semelhantes. discutir alterações e correções nos requisitos do usuário a baixo custo e com mínimo risco. Um conjunto de entidades será representado por meio de um retângulo contendo o nome do conjunto de entidades. deixando de lado as menos importantes. Por exemplo: quando nos referimos ao conjunto de entidade “Departamentos”.1997]. servir de instrumento de comunicação.1. conforme mostra exemplo da Figura 6. capturar aspectos de relacionamento entre os objetos observados. confirmar que o ambiente do usuário foi entendido. MODELO DE RELACIONAMENTOS – E/R ENTIDADES E O modelo ER é uma técnica de modelagem conceitual utilizada para representar os dados a serem armazenados em um sistema de informação.1990].

4.. Por exemplo: considerando um sistema para uma biblioteca. a princípio são representados em um conjunto de entidades todos os elementos do mundo real referidos pelo conjunto.. fatorados e independentes [SHLAER. significa dizer que um conjunto de entidades que é relevante para um determinado contexto pode não ser para outro. Os atributos devem contemplar todas as características que proporcionem uma perfeita identificação das entidades às quais esteja associado. Figura 6: Exemplo de representação de conjunto de entidades Características dos conjuntos de entidades [FALBO.A frase “. modeladas como Conjunto de entidades.. para estabelecermos uma padronização.2. as cadeiras são alvo de controle.1990]. Assim. 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.. Deseja-se que o processo de identificação de atributos alcance um elenco de atributos que sejam completos. então. PESSOAS . • 2. Atributos A identificação de entidades está diretamente relacionada à necessidade de se armazenar dados (características ou propriedades) a seu respeito. CARGOS. Tais características ou propriedades são denominadas atributos. Adotaremos esta última abordagem com o intuito de mantermos um modelo mais legível. isso não representa uma regra. sendo.” do parágrafo acima.. O foco é incluir no modelo apenas aqueles conjuntos de entidades que são de interesse para o contexto em questão.. • Completo: “Deve abranger todas as informações pertinentes ao objeto que está sendo definido”. Agora. ao se definir a . Os atributos podem ser representados no diagrama ou em um dicionário de dados.para os quais temos interesse em manter informações no banco de dados. Ex: FUNCIONÁRIOS. O papel do atributo é o de descrever características ou propriedades relevantes de um conjunto de Entidades. não há porque modelar as cadeiras como um conjunto de entidades. No entanto. se tratarmos de um sistema para controle de patrimônios. Ex: FUNCIONÁRIOS = todos os funcionários de uma empresa. usaremos nomes de conjuntos de entidades sempre no plural e escritos em letras maiúsculas.

Não se deve agrupar responsabilidades acessórias aos atributos. Ex. Cada parte. conforme descritos abaixo. cidade. cep • Atributos Multivalorados: é um atributo que pode assumir vários valores para cada entidade. cidade. data de nascimento. data de nascimento.: Entidade: FORNECEDORES Atributos: código. estado. é interessante que se distinga alguns elementos adicionais.entidade PESSOAS. estado civil. Ex. rua.n) . razão social. ao mesmo tempo. número. CNPJ. uf. estado civil.: Entidade: PESSOAS Atributos: data de nascimento Domínio: deve ter as características de data e ser menor que a data corrente Considerações adicionais sobre os atributos: Ainda sobre a identificação dos atributos. número. logradouro. • Independente: os valores que um atributo pode receber (domínio) devem ser independentes uns dos outros. número. bairro. estado. estado. 2002]: • Atributos Monovalorados ou Univalorado: é um atributo que recebe um único valor para cada entidade. uf. Isso não significa que não possamos ter atributos distintos com o mesmo domínio. deve significar um traço. complemento. [POMPILHO. Ex. cada característica. • Fatorado: cada atributo deve ser responsável por um aspecto. uma particularidade da entidade e não estar agregando um conjunto de informações em um único elemento. sexo. Note que o endereço está fracionado nas suas partes constituintes e não agrupado num único elemento denominado endereço.: Entidade: PESSOAS Atributos: nome.: Entidade: FORNECEDORES Atributos: telefone(0. sexo. São atributos que possuem cardinalidade máxima 1. Ex. bairro. cidade.: Entidade: PESSOAS Atributos: nome. rua. deve-se prever todos os atributos que permitam caracterizar completamente os elementos (pessoas) que comporão esta entidade. Cada atributo possui um conjunto dos possíveis valores que pode assumir e isso independe dos demais atributos da entidade. Ex. em um único atributo.

nome-intermediário. O atributo nome em uma entidade pessoa também poderá ser visto como composto se for possível e necessário separá-los nas suas várias partes (primeiro-nome. Ex. Há quem já chame o atributo identificador de Chave Candidata. No domínio de um atributo.: Entidade: FORNECEDORES Atributos: código. seu tamanho. cnpj. são atributos que abrigam uma estrutura de dado. cidade.: Entidade: FORNECEDORES Atributos: (complemento) • Atributo Composto: são atributos formados por um ou mais atributos. cep • Atributos Opcionais: é um atributo que NÃO obriga a existência de valor para cada entidade. de modo único. estado. como mostra o exemplo abaixo no qual o ENDERECO é um atributo composto: FORNECEDORES = codigo + cnpj + razão social + ENDERECO + telefone(0. considerando que existem homônimos. Por exemplo: a matrícula de um funcionário pode ser um atributo identificador.Neste caso. não pode ser usado para identificar um funcionário. os valores especificamente. • Atributos Obrigatórios: é um atributo que obriga a existência de valor para cada entidade. razão social. um fornecedor pode ter nenhum ou vários telefones. Quando não são compostos. Ex. número.n) ENDERECO = logradouro + número + (complemento) + cidade + estado + CEP • Atributo Determinante ou Identificador: atributo que identifica. último-nome). especificamos o Formato desse atributo. Por exemplo: um atributo nome para uma classe de . logradouro. Ex. os atributos são denominados simples. O atributo nome. no entanto. ou seja.: Entidade: FORNECEDORES Atributos: endereço Os atributos compostos serão representados no dicionário de dados em maiúsculo e deverão ser fatorados.: Entidade: FORNECEDORES Atributo: código • Domínio de um atributo: é o conjunto dos possíveis valores que um atributo pode assumir. Serão sublinhados no diagrama como forma de distingui-lo dos demais. uma Entidade. considerando que cada funcionário terá uma matrícula única. Ex. Normalmente são representados no dicionário de dados entre parênteses.

: Entidade: PESSOAS Atributo: Sexo do Empregado Domínio: Campo Alfanumérico. já o atributo sexo poderá ter como domínio as opções “Masculino” ou “Feminino”. .entidades PESSOAS poderá ter como domínio uma “cadeia de caracteres”. 1 caracter. 8 e 9 abaixo mostram exemplos de diferentes formas de representação de Diagramas de Entidades e Relacionamentos. Atributos também descrevem características de relacionamentos. Ex. Figura 7: Notação para Diagrama Entidade-Relacionamento proposto originalmente por Chen Figura 8: Notação alternativa para Diagrama Entidade-Relacionamento . que veremos na próxima seção. só pode assumir os valores “F” e “M” As figuras 7.

Além dos atributos.logradouro Complemento (0. Figura 10: Exemplo de representação de relacionamento A leitura feita para o relacionamento da Figura 10 é “funcionários são enquadrados em cargos”. Todo relacionamento possui uma leitura inversa. conforme mostra a Figura 10 abaixo. A essas associações denominamos relacionamentos. pois se trata de uma associação entre dois conjuntos de entidades.4. assim.3. com um verbo para indicar a ação e uma seta para informar o sentido de leitura. ou seja. conjunto de associações entre entidades [HEUSER. Editoras publicam livros / Livros são publicados por editoras. Neste texto adotaremos a seguinte notação: um relacionamento será representado por um losango.1) numero cidade estado rua Razao social endereco codigo cep codigo CNPJ nome Preco unit Telefone (0. Autores escrevem livros / Livros são escritos por autores. uma outra leitura do relacionamento seria “cargos enquadram funcionários”. inclusive com elas mesmas. O relacionamento existente entre os conjuntos de entidades funcionários e cargos é um relacionamento binário. Relacionamentos Na seção anterior descrevemos atributos de 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. 2004]. . que são propriedades dos objetos a serem armazenados em um banco de dados. os conjuntos de entidades caracterizam-se por relacionar-se com outros conjuntos de entidades.n) FORNECEDORES FORNECIMENTO PRODUTOS Figura 9: Outra notação para Diagrama Entidade-Relacionamento 2.

cn e os relacionamentos existentes entre as entidades do conjunto de funcionários e de cargos. como mostra o relacionamento “chefiam”. possui os funcionários f1 e f3.. na Figura13. A figura 11 representa o diagrama de ocorrência supra citado.. representadas por : f1. fn. denomina-se que há um autorrelacionamento do conjunto de entidades FUNCIONÁRIOS. podem existir vários tipos de relacionamentos. nele enquadrados através dos relacionamentos r1 e r3. A Figura 12 mostra os relacionamentos de alocação e de gerência entre os mesmos conjuntos de entidades: FUNCIONÁRIOS e PROJETOS. Adaptação. . Nesse caso. . c2. as ocorrências do conjunto cargos.Para facilitar a visualização foi construído um diagrama de ocorrência referente ao modelo ER da Figura 10. O cargo c1... Figura 12: Entidades com dois tipos de relacionamento Além disso. representadas por : c1. Entre duas entidades. 2004. Esse diagrama se propõe a mostrar as ocorrências de entidades do conjunto funcionários. f2. inclusive com ela mesma.. Figura 11: Diagrama de ocorrências Fonte: Heuser. O funcionário f1 está enquadrado no cargo c1 através do relacionamento r1. por outro lado. uma entidade pode participar de relacionamentos com quaisquer outras entidades do modelo. .

N é um número arbitrário. pode enquadrar até n funcionários. Esse conceito é baseado na cardinalidade mínima do relacionamento. para qualquer valor maior que 1. Para efeito de projeto de banco de dados. Ele é total em relação a FUNCIONÁRIOS. o tratamento dado para esse número arbitrário é o mesmo. pois todo funcionário participa do relacionamento pelo menos uma vez. e parcial em relação a CARGOS. um funcionário é enquadrado. cargo enquanto um cargo pode enquadrar no mínimo zero e no máximo n funcionários. . por sua vez. no máximo. pois pode existir um cargo que não participe do relacionamento nenhuma vez. a cardinalidade vai anotada do outro lado do relacionamento a que se refere. A Figura 14 mostra a representação de cardinalidade no modelo ER. em um cargo e um cargo. embora pareça pouco natural. observa-se que um cargo pode enquadrar vários funcionários. A leitura é feita da seguinte forma: um funcionário é enquadrado em. enquanto que um funcionário deve ser enquadrado em apenas um cargo. O relacionamento “enquadram” é total em relação a FUNCIONÁRIOS e parcial em relação a CARGOS. No diagrama de ocorrência da Figura 11. no mínimo 1 e no máximo 1. Quando conhecemos esse número podemos representá-lo. em vez de o determinarmos pela letra N.Figura 13: Exemplo de autorrelacionamento Cardinalidade de relacionamento A cardinalidade indica o número 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 exemplo acima. Figura 14: Ilustração do uso de cardinalidade Observe que.

nem todo funcionário gerencia projetos.Tipos de Relacionamentos O tipo de relacionamento é uma classificação baseada na cardinalidade máxima do relacionamento. . N:1 e N:N. e lê-se conforme descrição feita entre parênteses: 1:1 (Um-para-um). enquanto um projeto só deve ter um gerente. ou mesmo nenhum. podendo ser : 1:1. podemos dizer que um funcionário pode gerenciar no máximo um projeto. Nesse caso. N:N (Muitos-para-Muitos). 1:N (Um-para-Muitos) e. 1:N. Departamento). Esta informação é dada pela cardinalidade mínima do relacionamento. serão explorados todos os tipos de relacionamentos sobre um relacionamento existente entre os conjuntos de entidades : FUNCIONÁRIOS E PROJETOS. A seguir. Os tipos de relacionamentos podem ser enquadrados em 3 grandes grupos. • Relacionamento 1:1 A Figura 15 mostra um exemplo de relacionamento do tipo 1:1 no qual cada Funcionário ou Projeto podem aparecer no máximo em um único par do relacionamento Gerenciam (Funcionário. A figura 16 tem uma representação simbólica deste tipo de relacionamento. Figura 15: Exemplo de relacionamento 1:1 Conjunto simbólico da entidade FUNCIONÁRIOS Conjunto simbólico da entidade PROJETOS Figura 16: Representação simbólica do relacionamento 1:1 (um-para-um) Observe que todo projeto é gerenciado por algum funcionário porém.

A figura 18 tem uma representação simbólica deste tipo de relacionamento. enquanto um projeto pode ter vários gerentes.• Relacionamento 1:N A Figura 17 mostra um exemplo de relacionamento do tipo 1:N no qual cada Projeto pode aparecer no máximo em um único par do relacionamento Gerenciam. podemos dizer que um funcionário pode gerenciar vários projetos. enquanto um Funcionário pode aparecer em um número arbitrário de vezes. A figura 20 tem uma representação simbólica deste tipo de relacionamento. 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!). Nesse caso. Figura 19: Exemplo de relacionamento N:N . Figura 17: Exemplo de relacionamento 1:N Conjunto simbólico da entidade FUNCIONÁRIOS Conjunto simbólico da entidade PROJETOS Figura 18: Representação simbólica do relacionamento 1:N (um-para-muitos) • Relacionamento N:N A Figura 19 mostra um exemplo de relacionamento do tipo N:N no qual cada Funcionário ou Projeto podem aparecer em um número arbitrário de vezes do relacionamento Gerenciam. Nesse caso.

2009] Os exemplos acima mostram os diferentes tipos de relacionamentos aplicados a conjuntos de entidades diferentes. então. como mostra a Figura 21. também referenciada por alguns autores. como “Agregação”. relacionar-se com outras entidades do modelo. Essa “nova entidade”.Conjunto simbólico da entidade FUNCIONÁRIOS Conjunto simbólico da entidade PROJETOS Figura 20: Representação simbólica do relacionamento N:N (muitos-paramuitos) Um outro conceito relacionado aos relacionamentos N:N é o de “Entidade Associativa”. Um correntista é uma agregação envolvendo os conjuntos de entidades Clientes e Contas Correntes. . pode. a associativa. 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. Figura 21: Exemplo de agregação N:N [Falbo. porém também se aplicam a autorrelacionamentos.

incluímos nos modelos ER’s conjuntos de entidades com diversas características em comum. no entanto. possui CNPJ e atividade principal. 2009] • Generalização / Especialização de conjuntos de entidades Por muitas vezes.000. Fixando-se um fornecedor e variando-se os materiais temos: A Eletrocity vende uma impressora por R$ 350. é porque este não é atributo do primeiro conjunto de entidades. por sua vez. Uma pessoa jurídica. Este teste consiste no seguinte: fixa-se um material.00 e um microcomputador por R$ 2. enquanto os demais podem ser enquadrados em um dos conjuntos de entidades envolvidos no relacionamento [FALBO. estas. Podem ter atributos e relacionar-se com outras entidades do modelo! • Atributos de Relacionamentos Assim como as entidades. para a outra entidade. A Figura 23 mostra a representação desse conceito no modelo ER. Nesse caso. Figura 22: Exemplo de relacionamento N:N [Falbo. pode-se criar um conjunto de entidades genérico. agora. porém apenas os atributos de relacionamentos N:N são caracterizados como atributos de relacionamentos. além dessas características comuns. e especializam-se as demais com características parcialmente distintas. possuem os mesmos privilégios de um conjunto de entidades do modelo. há um teste que pode ser aplicado para se deduzir se um atributo é de um dos dois conjuntos de entidades ou se é do relacionamento. como uma impressora. Observe que existem várias características em comum entre ambas as pessoas. Se o valor do atributo mudar ao variarmos o elemento do outro conjunto de entidades.00. O fato de o valor do atributo ter variado para a mesma entidade indica que ele não é atributo de FORNECEDORES. possui: sexo e CPF.Relacionamentos N:N geram Entidades Associativas e. O Procedimento análogo deve ser feito. então é um atributo do relacionamento entre os dois conjuntos de entidades. usando o conceito de generalização. Para os relacionamentos N:N. contendo as características em comum. 2009]. Se não é atributo nem de MATERIAIS. e variam-se os fornecedores desse material. Uma pessoa física. diferenciando apenas em algumas delas. a exemplo de: nome. endereço e telefone. . Tomemos como exemplo o modelo constante na figura 22. nem de FORNECEDORES. no caso MATERIAIS. além dessas características comuns. os relacionamentos também podem ter atributos. Um exemplo clássico é o de pessoa física em jurídica.

A Figura 24 mostra um exemplo em que o conjunto de entidades DEPENDENTES é denominada “entidade fraca”. Ela só aparece no modelo quando relacionada a outra entidade – intitulada como forte –. dois campos. Figura 24: Exemplo de entidade fraca 2.Figura 23: Exemplo de generalização / especialização As entidades PESSOAS FÍSICAS e PESSOAS JURÍDICAS herdam as características de clientes e incorporam outras adicionais. sendo um deles um atributo da entidade forte. Especialização: uma entidade de nível mais alto de abstração é desmembrada em várias entidades de nível mais baixo. com características parcialmente distintas. pelo menos. DICIONÁRIO DE DADOS O Dicionário de Dados é uma listagem organizada de todos os elementos de dados pertinentes ao sistema. Um cliente pode ser pessoa física. Uma entidade fraca é uma entidade que não tem existência própria. Os relacionamentos com essa característica são denominados identificados. jurídica ou nenhum dos dois. Entidade Fraca Um outro conceito referenciado nos modelos ER’s é o de Entidade Fraca. com características comuns. Para a identificação de um dependente é necessário que se tenha informação do sócio. com definições precisas para que os usuários e . que são peculiares de cada um. Generalização: entidades de um nível mais baixo de abstração. sendo seus atributos identificadores compostos por.5. mas toda pessoa física ou jurídica é cliente. são agrupadas dando origem a uma entidade de nível mais alto.

poderá ter vários pilotos (sendo este número máximo normalmente igual a 02 pilotos). o nome do circuito. Um piloto sempre representa um país. a duração em minutos. altura e peso. a relação de pilotos que participaram da prova e a posição que cada um obteve na corrida. cabem algumas observações importantes. em um dado momento. de Carlos Alberto Heuser. EXEMPLO DE UM MODELO DE DADOS A seguir eis um estudo de caso referente a um campeonato de fórmula 1 e o modelo ER construído para representar o cenário supracitado. 2. é necessário saber a data em que ocorreu. Além disso. dos quais deseja-se armazenar as seguintes informações: uma sigla. De cada piloto deseja-se saber: código. por outro lado. É necessário ter um controle dos países dos atletas (pilotos). nome. Considerando que não há uma padronização sobre a definição de dicionário de dados. o nome e o Hino Nacional. não será explorado neste material uma formulação na representação destes. enquanto que um país pode ter várias equipes participando do campeonato ou mesmo nenhuma. a qual.” O primeiro passo para construção de um modelo é identificar os elementos do contexto para os quais temos o interesse de manter informações a respeito. Uma equipe também representa um país. embora esteja no texto referenciado quando . identificar os possíveis conjuntos de entidades. Para cada corrida realizada. considerando que o modelo contempla um conjunto de entidades denominado “Pilotos”. Observe que esta relação de pilotos não foi incluída como um atributo de corrida (verifique no dicionário de dados) e sim como um relacionamento entre corridas. iremos destacar os seguintes conjuntos de entidades: equipes. um piloto pode pertencer a apenas uma equipe. mesmo por que as ferramentas CASE normalmente incluem relatórios para geração desses dicionários. A segunda observação refere-se a “posição que cada um obteve na corrida”. De cada equipe deseja-se saber: código e nome. Se incluísse como atributo estaria sendo redundante. Lembre-se de que só faz sentido caracterizar um elemento como um conjunto de entidades se ele possuir atributos próprios! Com relação ao conjunto de entidades “Corridas”. A primeira diz respeito à “relação de pilotos que participaram da prova”.6.desenvolvedores possam conhecer o significado de todos os itens de dados manipulados pelo sistema. enquanto que um país pode ter vários pilotos participando do campeonato ou até mesmo nenhum. as entidades e os relacionamentos com atributos de um DER. Ao longo do campeonato. Se fizermos uma leitura novamente do texto. Para caracterizar uma corrida é necessário que haja pelo menos 01 piloto habilitado a participar. podendo não ter nenhum. Em se tratando de Modelos de Dados. é necessário controlar os pilotos que pertencem a cada equipe. indicamos o livro Projeto de Banco de Dados. Uma equipe. capítulos 02 e 03. “Deseja-se desenvolver um sistema para controlar os resultados de um campeonato de corridas de Fórmula 1. data de nascimento. essa listagem contém. ou seja. Para complementar os conceitos discutidos até esta seção. O sistema deverá manter informações sobre as equipes que participam do campeonato. em ordem alfabética. pilotos. países e corridas.

mas esta informação está relacionada ao piloto e a corrida. Seria construir um conjunto de entidades para representar uma entidade apenas! O mesmo raciocínio vale para o segundo caso. mas se for apenas uma. a Locadora deverá ser modelada como sendo um conjunto de entidades? Se estamos construindo um modelo para uma Escola. aí sim devemos modelar a locadora como um conjunto de entidades. Figura 25: Modelo ER referente ao estudo de caso – Campeonato de Fórmula 1 Dicionário de Dados: EQUIPES = codEquipe + nomeEquipe PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso PAISES = codPais + sigla + nome CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito PARTICIPACOES = posicaoPilotoProva O dicionário de dados acima representa em estilo sublinhado os atributos determinantes para cada conjunto de entidades. ao relacionamento entre estes dois conjuntos de entidades.trata-se da corrida em si. A figura 25 mostra o modelo ER correspondente ao contexto descrito anteriormente. o da Escola. Ao construirmos modelos de dados é comum termos dúvida sobre a representação de conjuntos de entidades. como no exemplo a seguir: se estamos construindo um modelo para uma locadora de vídeo. ou seja. . não faz sentido. a Escola deverá ser modelada como sendo um conjunto de entidades? Em ambos os casos a resposta é Não! Se no primeiro caso tratar de uma rede de locadoras.

acrescidos dos conceitos de subclasse e superclasse. Embora seja uma ferramenta simples.7. tipo união e herança de atributo/relacionamento. Para estes. porém alguns recursos são mais bem representados por extensões feitas ao modelo básico.EER O modelo ER possui um poder de expressão muito grande. 2005]. . trabalharemos com projeto lógico de banco de dados. 2. 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. permite trabalharmos com a construção de modelos conceituais e lógicos (tratados no próximo capítulo). ERWin e brModelo.2. Não há uma notação padrão para representação desses modelos. Esta última é uma ferramenta desenvolvida sob a orientação do professor Carlos Heuser. Segundo Navathe Navathe [NAVATHE. Vários modelos semânticos de dados têm sido propostos na literatura. Ressalto que os modelos conceituais representam os requisitos de negócio independente de tecnologia. Dentre outras. professor de Banco de Dados da UFRGS. FERRAMENTAS CASE Você deve estar se perguntando como desenhar um diagrama ER. como ocorre com a UML. especialização e generalização. principalmente quando se trata de modelagem de aplicações convencionais. capítulo 4. sendo denominados de modelo ER estendidos ou EER. de Esmasri e Navathe. algumas características tecnológicas serão consideradas. como Sistemas de Informações Geográficas e CAD. as quais são denominadas ferramentas CASE. MODELO ER ESTENDIDO . o modelo EER engloba todos os conceitos do modelo ER básico. e encontra-se disponível para download na Internet. Recursos estes necessários para modelagem de aplicações mais complexas. No capítulo seguinte. Uma boa leitura para complementar os conceitos tratados nesta seção é o livro Sistemas de Banco de Dados. Este capítulo teve como objetivo o de apresentar conceitos relacionados com modelagem conceitual de dados.8. que descreve uma forma de representação do modelo EER. podemos citar Doctor CASE.

.

de simples compreensão. focamos apenas no que o usuário deseja. Suponha que D1 denote esse conjunto. chamado domínio da coluna em questão.1. DEFINIÇÃO Quando construímos um modelo conceitual. ou seja. a preocupação é centrada em estabelecer de que forma os dados serão armazenados no sistema. PROJETO LÓGICO DE BANCO DE DADOS Olá! Neste capítulo você estudará conceitos de projeto lógico de banco de dados. daí o nome relacional. Um banco de dados relacional consiste em uma coleção de tabelas. um modelo hierárquico deve ser produzido. Um modelo lógico faz uma adequação do modelo conceitual. D2 o . adequando-se a modelagem conceitual de dados (ER ou diagrama de classes) a essa plataforma de implementação. Bom estudo! Profª Claudinete Vicente Borges 3. incluindo restrições tecnológicas.2. atualmente. é o relacional. este capítulo se propõe a discutir conceitos de projetos relacionados a esse modelo de bancos de dados. por exemplo. tratamos os nomes dessas colunas como atributos. Considerando que o modelo de banco de dados que predomina no mercado. Uma vez que essa tabela é uma coleção de tais relacionamentos. Para o atributo Matricula. diferentes soluções de projeto devem ser adotadas. Está fortemente baseado na teoria matemática sobre relações. Em função do modelo de banco de dados a ser usado. Uma linha em uma tabela representa um relacionamento entre um conjunto de valores. Seguindo a terminologia do modelo relacional. Ela possui três colunas: matrícula. o domínio é o conjunto de todas as matrículas de funcionários. Para cada atributo há um conjunto de valores permitidos. Tratase de um modelo com maior nível de detalhe do que o conceitual. 3. nome e cidade. se o software for implementado em um banco de dados hierárquico. No que se refere aos projetos de Banco de Dados. ESTRUTURA RELACIONAIS DOS BANCOS DE DADOS O modelo relacional consolidou-se no mercado por ser flexível.3. cada uma das quais com um nome único. Considere a tabela EMPREGADOS – Tabela 3. impostas pelo modelo de banco de dados a ser usado. daí a origem do nome desse modelo de dados. abstraindo da plataforma em que este será implementado. por exemplo. há uma estreita correspondência entre o conceito de tabela e o conceito matemático de relação.

Das superchaves mencionadas . 3. Da mesma forma. tomados coletivamente. nome) e (nome. define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios. a exemplo de Endereço de correspondência e Endereço comercial (se existissem nessa tabela EMPREGADOS). A única diferença é que designamos nomes aos atributos. atributos diferentes criados sob o mesmo domínio. (isto é. de maneira unívoca. entidades e relacionamentos individuais são distintos. podemos usar os termos matemáticos relação e tupla no lugar de tabela e linhas. ao passo que matematicamente se usam apenas "nomes" numéricos. v2.conjunto de todos os nomes de pessoas e D3 o conjunto de todas as cidades. Considere a inclusão de uma nova coluna na tabela EMPREGADOS. Um valor de domínio que pertence a qualquer domínio possível é o valor nulo. Como as tabelas em essência são relações. É possível que tenhamos. porque algumas pessoas podem ter o mesmo nome. Conceitualmente. O conceito de chaves nos permite fazer tais distinções. suponhamos que incluamos o atributo numeroTelefone na tabela Empregado. entretanto. um empregado é um conjunto de D1 x D2 x D3.3. CPF) são suficientes para distinguir cada elemento do conjunto. Por exemplo. Uma superchave é um conjunto de um ou mais atributos que. Essas chaves são chamadas de chaves candidatas. Tabela 3: Tabela EMPREGADOS matricula 01 02 03 04 nome Maria Matheus Gabriel Joana cidade Vitória Vila Velha Serra Aracruz Matematicamente. permitem identificar. v3). na perspectiva do banco de dados. Em geral. pode ser que um Empregado não possua telefone ou que o seu número seja desconhecido. o (CPF) do empregado. podendo ser considerados como superchaves. em uma mesma tabela. Nosso interesse maior é por superchaves para as quais nenhum subconjunto possa ser uma superchave. O atributo (nome) não pode ser considerado como superchave. Qualquer linha da tabela EMPREGADOS consiste necessariamente de uma tupla (v1. a diferença entre ambos deve ser estabelecida em termos de seus atributos. respectivamente. CHAVES É importante especificar como as entidades dentro de um dado conjunto de entidades podem ser identificadas. v2 é um nome do funcionário e assim por diante. v1 está no domínio D1). Os atributos (matricula. em que v1 é a matricula. uma entidade em um conjunto de entidades. que indica que um valor é desconhecido ou não existe. Essa definição corresponde quase exatamente à definição de uma tabela. podemos considerar o atributo (CPF) como superchave de empregado.

Uma chave candidata pode assumir um valor nulo (apenas um. como por exemplo um número seqüencial para ser a chave primária da tabela. CPF) não poderia ser considerada uma chave candidata. Em SGBD’s. Um outro conceito de chave. Particularmente. os mesmos valores em seus atributos-chave. é o conceito de chave estrangeira. porém. já o é. prefiro adotar essa solução. Eventualmente. Tabela 4: Exemplo de atributos chave Atributos matricula CPF (CI. Alguns autores defendem que uma chave primária seja escolhida entre as chaves candidatas de uma tabela. que muito será explorado neste material. sozinho. somente (nome. É importante lembrar a todos que o negócio muda e com isso os valores dos atributos também. Cabe ressaltar que os atributos implementados como “Chave Candidata” são atributos possíveis de serem implementados como “Chave Primária”. apenas uma é possível. Uma chave estrangeira é um atributo (ou . o que pode ser muito custoso. pode-se criar um atributo extra. Uma alteração feita em valores de chaves primárias implica propagação para inúmeras tabelas relacionadas.anteriormente. pois do contrário haveria repetição de valores). visto que o CPF. Podemos usar o termo chave primária para caracterizar a chave candidata. No que se refere à chave primária.Nome) Superchave √ √ √ √ Chave Candidata √ √ √ X Chave Primária √ √ √ X Em uma mesma tabela pode haver múltiplas chaves candidatas. simultaneamente. UF) (CPF. apenas os conceitos de chaves primárias e chaves candidatas são de fato implementados! A tabela 4 mostra uma listra de atributos de uma relação Alunos e um indicativo da possibilidade destes serem considerados atributos-chaves. pode-se adotar uma solução de projeto em que a chave primária não seja escolhida entre as chaves candidatas e sim um atributo que não diz respeito ao negócio em si. que é escolhida pelo projetista do banco de dados como de significado principal para a identificação de entidades dentro de um conjunto de entidades. Uma chave primária não pode assumir valor nulo. Quaisquer duas entidades individuais em um conjunto de entidades não podem ter. a exemplo de (matrícula) e (CPF) de EMPREGADOS.

a ordem delas torna-se irrelevante. dependendo do modelo de dados. cada relação recebe um nome próprio distinto do nome de qualquer outra relação da base de dados. Além desses valores.2009] relaciona as seguintes propriedades do modelo relacional: • • • • • • • • • • nenhum campo componente de uma chave primária pode ser nulo. a exemplo de chaves externas e chaves transpostas. os valores de uma coluna são retirados todos de um mesmo conjunto. destacando a chave estrangeira (codDepto) matricula 01 02 03 04 codDepto 01 02 03 nome Maria Matheus Gabriel Joana cidade Vitória Vila Velha Serra Aracruz nomeDepto Informática Geografia Português codDepto 01 02 02 03 Tabela 6: Tabela DEPARTAMENTOS 3. Essa tabela referenciada pode ser a própria tabela. ao contrário. 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. . Tabela 5: Tabela EMPREGADOS. PROPRIEDADES DO MODELO RELACIONAL Falbo [FALBO. Os valores possíveis para essa coluna devem constar na Tabela referenciada por esse atributo.combinação de atributos) de uma tabela que constitui a chave primária de uma tabela. no caso. É a estratégia usada para implementar os relacionamentos dos modelos conceituais. a de DEPARTAMENTOS. cada coluna tem um nome e colunas distintas devem ter nomes distintos. nulo pode ser um valor possível. usando-se os nomes para se fazer referência às colunas. daí o nome de estrangeira. ou outras quaisquer do modelo.4. conter no máximo um único valor. Outras denominações também são usadas para essas chaves. para os casos de autorrelacionamento. o codDepto. cada célula de uma relação pode ser vazia (exceto de uma chave primária) ou. não há duas linhas iguais. denominado domínio da coluna. duas ou mais colunas distintas podem ser definidas sobre um mesmo domínio. A Tabela 5 mostra um exemplo de chave estrangeira. a ordem das linhas é irrelevante.

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. colunas que compõem cada tabela. Para os diferentes modelos de bancos de dados (redes. restrições de integridade (no caso. denominado Esquema Relacional. colunaN) referencia <NomeTabela>. contendo as seguintes informações : • • • tabelas que formam o banco de dados. respectivamente. A abordagem usada neste material será a de Carlos Heuser [HEUSER. apenas as restrições referentes às chaves primárias e estrangeiras são representadas).. mapeamento de atributos multivalorados. pois a opção foi de não representá-los no modelo ER. e Para o exemplo das Tabelas 5 e 6 (EMPREGADOS DEPARTAMENTOS). sendo alguns representados de forma gráfica e outros textuais.2004].. codDepto) codDepto referencia Departamentos Departamentos (codDepto . CodDepto é uma chave estrangeira e que referencia a chave primária da tabela Departamentos. Para os casos das chaves estrangeiras compostas. Diferentes autores usam diferentes representações para a especificação dos modelos lógicos de bancos de dados relacionais. teremos a seguinte representação: Empregados (matricula. relacionais. 1:N. Assim. A fim de facilitar o entendimento. .5. hierárquicos. N:N}. coluna2. mapeamento dos relacionamentos. que usa uma notação resumida para definição do esquema.) diferentes soluções de projetos devem ser adotadas. este material terá como foco apenas o projeto de banco de dados relacional. nomeDepto) Os atributos sublinhados representam as chaves primárias das tabelas Empregados e Departamentos. a representação fica da seguinte forma: (coluna1. nome. considerando cada tipo {1:1. O modelo lógico é um modelo menos abstrato que o conceitual e provê um nível maior de detalhes. serão usados os mesmos exemplos de modelos descritos no capítulo 2 para exemplificar os diferentes tipos de relacionamentos.3. A tradução do modelo ER para o relacional seguirá os seguintes passos: • • • • mapeamento das entidades e atributos. cidade.. Consideremos também os atributos abaixo listados para os conjuntos de entidades Funcionários e Projetos. mapeamento de generalizações e especializações. Funcionarios = matrícula + nome + cidade + data de admissão Projetos = código + nome + data de início ..

todo conjunto de entidades gerará uma tabela no banco de dados relacional. ao definir a chave primária. candidata. conforme especificações a seguir: • evite usar nomes extensos. como: Data_Admissão e dtInicio. ela não deve. • colunas que compõem cada tabela. seja chave primária. apenas as restrições referentes às chaves primárias e estrangeiras são representadas). considerando que a referência às colunas ocorre do modo acima descrito. da tabela PROJETOS. porém. assim. Via de regra. considerando que não pode haver espaços em branco e que devemos evitar nomes extensos para facilitar o trabalho dos programadores. escolha a coluna ou combinação destas colunas com o menor tipo de dados possível. crie padrões de projeto para dar nomes às colunas.nomedaColuna o que estende ainda mais o nome do atributo. Ao fazer referência ao nome de uma coluna. As exceções serão tratadas. não se faz necessário incluir o nome da tabela nos nomes das colunas dessas tabelas. Por exemplo: o valor de um pedido pode ser obtido por meio dos valores dos seus itens. a exemplo de dtAdmissao e dtInicio. evitamos alguns acessos a disco. é útil em um banco de dados por questões de performance. algumas pessoas escrevem Nome_Projeto. eles devem ser mapeados em colunas das respectivas tabelas. • restrições de integridade (no caso. muitas vezes.Seguindo os passos para elaboração do modelo conceitual temos. ser a mesma do conjunto de entidades. Via de regra. e esses índices ocupam muito espaço em disco. seja estrangeira. embora devamos evitar redundâncias nos modelos conceituais. quando ocorrerem. • • • • Notação resumida para especificação de banco de dados relacional: • tabelas que formam o banco de dados. a definição das Tabelas que formam o banco de dados. a redundância. A exemplo da coluna (nome). são criados índices. Os relacionamentos do modelo conceitual ER são mapeados em chaves estrangeiras em um banco de dados relacional. . normalmente escreve-se nomedaTabela. para cada relacionamento uma chave estrangeira deve ser criada. se guardarmos o valor total do pedido como uma coluna na tabela de pedidos. Com relação à nomenclatura usada na tabela. No que se refere aos atributos dos conjuntos de entidades. há algumas diretrizes para definição dessas colunas. Evite usar prefixos diferentes para colunas com mesmo tipo de informação. porém. Sobre os campos chaves. a performance das aplicações. melhorando. como passo 1. necessariamente.

pois cada projeto participa do relacionamento Gerenciam no máximo 1 (uma) vez. dtAdmissao) Projetos (codigo. 3. 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. 3. colunas ou quaisquer outros objetos de um banco de dados. a melhor solução de projeto a se considerar é: incluir a chave estrangeira na relação PROJETOS. nome. dtAdmissao) Projetos (codigo. nome. não uso acentuações e cedilhas em nomes de tabelas. particularmente. O esquema gerado ficaria da seguinte forma: Funcionarios (matricula. se a cardinalidade mínima fosse 1 (um) para ambos.1. evito transtornos com teclados desconfigurados. derivando o seguinte esquema : Funcionarios (matricula. matriculaGerente) matriculaGerente referencia Funcionários Figura 26: Exemplo de relacionamento 1:1 Essa solução foi adotada. nem todo funcionário gerencia um projeto. em vez de colocá-la em empregados.2. da Figura 26. Com isso. nome. cidade. a chave estrangeira deve ser colocada em Projetos. considerando-se que todo projeto tem um gerente. ou seja. Se o relacionamento Gerenciam fosse total em relação a Funcionários e a Projetos. poderíamos optar por criar uma única tabela contendo todos os atributos. embora essa não seja a melhor abordagem.5. dtInicio.Eu. dtInicio. No caso da Figura 27. cidade. nome. porém. não teríamos problemas na implementação dessa solução. Relacionamento 1:1 Considerando o relacionamento Gerenciam.5. se a chave estrangeira fosse criada em Funcionários. Ainda assim. matriculaGerente) matriculaGerente referencia Funcionários .

Nesse caso. e elas fazem parte da chave primária da tabela criada. sexo. requer a identificação da entidade. A chave primária dessa nova tabela deve ser composta. Resumindo. como mostra o exemplo da Figura 28. 03. considerando que diferentes sócios possuem dependentes de número 01. pois apenas as chaves estrangeiras não são suficientes para identificá-los. numDependente.3. dita fraca (DEPENDENTES). etc. apenas o número do dependente não é suficiente para identificálo. temos nesses casos a chave estrangeira fazendo parte da chave primária da tabela mapeada pela entidade fraca. como para os demais tipos de relacionamentos: 1:1 e 1:N. 02.5. Às vezes é necessário incluir mais um atributo para compor a chave primária da tabela. dtCadastro) Dependentes (matricula. considerando que para os funcionários que gerenciam mais de um projeto todas as informações de funcionários apareceriam de forma duplicada. tem-se pelo menos 02 chaves estrangeiras. O esquema gerado ficaria da seguinte forma: Socios (matricula. dtNascimento) Matricula referencia Sócios Figura 28: Exemplo de entidade fraca – relacionamento identificado Nesse caso. nome. ou seja. o relacionamento também deve ser mapeado em uma tabela do banco de dados. denominados identificados.identificado Para os relacionamentos 1:N.5. . a identificação de um elemento da entidade.4. pela chave primária das tabelas relacionadas.Figura 27: Exemplo de relacionamento 1:N A criação da chave estrangeira na tabela Funcionários geraria um erro de projeto. Relacionamento N:N Os bancos de dados relacionais não implementam ligações diretas para os relacionamentos N:N. sexo. Relacionamento 1:N . dita forte (SOCIOS). 3. 3. no mínimo.

nome. Figura 30: Exemplo de generalização / especialização Para os casos em que há generalização / especialização. dtInicio) Gerenciam (matricula. adicionalmente. assim sendo. Um cliente pessoa física possui. fundindo os três conjuntos de entidades. percDedicacao) matricula referencia Funcionários codigo referencia Projetos Os relacionamentos N:N normalmente visam a geração de histórico.5. codigo. Figura 29: Exemplo de relacionamento N:N O esquema gerado ficaria da seguinte forma: Funcionarios (matricula. e um cliente pessoa jurídica possui. adicionalmente. nome.Considere o exemplo da Figura 29. cidade.5. 3. os campos oriundos das tabelas especializadas devem ter a . dtAdmissao) Projetos (codigo. há três opções de projeto que podem ser adotadas: Opção 1: criar uma tabela única. agora com relacionamento N:N. Considere também que um cliente possui as seguintes características (atributos ): Código e Nome. Nesse caso. um CPF e Carteira de Identidade. Generalização e Especialização Considere a Figura 30 para as discussões que se seguem. um CNPJ e uma atividade principal. é comum encontrarmos um campo “data” como parte da chave primária da tabela derivada da entidade associativa. dtInicioAtividade. Considere também que o relacionamento Gerenciam possui os seguintes atributos : Data de Início de Atividade e Percentual de dedicação.

Nesse caso. atividadePrincipal) Opção 3: criar uma tabela para cada conjunto de entidade da hierarquia. Ou seja. carteiraIdentidade) Clientes_PJuridica (codigo. nome. O esquema gerado ficaria da seguinte forma: Clientes (codigo. deve-se ficar atento em alterar o nome do campo – chave estrangeira –. CNPJ. A Figura 31 . O esquema gerado ficaria da seguinte forma: Clientes_PFisica (codigo. CNPJ. embora possamos ter uma menor performance. CPF. 3. deve-se criar a chave estrangeira na única tabela que representa o conjunto de entidades. CPF. a primeira opção tem como vantagem a redução do número de junções entre tabelas e como desvantagem possuir colunas que só terão valores associados quando tratarem de elementos correspondentes à especialização. como existe um relacionamento entre o mesmo conjunto de entidades. particularmente costumo adotar a terceira solução: criar uma tabela para cada conjunto de entidade da hierarquia. atividadePrincipal) codigo referencia Clientes Cada uma das abordagens acima tem vantagens e desvantagens.5. Para a opção 02 temos como desvantagem a repetição de atributos comuns aos dois conjuntos de entidades especializados. carteiraIdentidade. de Clientes. nome) Clientes_PFisica (codigo. Autorrelacionamento 1:N Para os autorrelacionamentos 1:N. nome. não dá para se ter tudo! Eu. pois não é possível ter colunas diferentes e com o mesmo nome em uma tabela. se considerarmos as opções anteriores. Por exemplo.possibilidade de assumirem valores nulos.6. no caso. Nesse caso. já para a terceira opção há uma organização maior da estrutura hierárquica. Como costumo dizer. CNPJ. atividadePrincipal) Opção 2: criar uma tabela para cada entidade da especialização. como Pessoas Físicas e Pessoas Jurídicas. O esquema gerado ficaria da seguinte forma: Clientes (codigo. Nesse caso. em se tratando de pessoa física. não haverá preenchimento de CNPJ e Atividade. os atributos do conjunto de entidades genérico – Clientes – devem ser incluídos em cada uma das tabelas criadas. 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. nome. carteiraIdentidade) codigo referencia Clientes Clientes_PJuridica (codigo. CPF.

nome. vindas da mesma tabela. Por isso. considerando-se que o modelo relacional não comporta múltiplos valores em uma célula de uma tabela. porém. dtAdmissao. O esquema gerado ficaria da seguinte forma: Funcionarios (matricula.representa um modelo ER com esse tipo de relacionamento. consideremos que telefone (0.5. Atributos Multivalorados Os atributos multivalorados de conjunto de entidades também devem ser tratados. cidade. ementa) Pre_Requisitos (codigoDisciplinaPos. o nome de pelo menos um campo deve ser alterado para evitar que haja dois atributos com o mesmo nome em uma mesma tabela. Para esses . codigoDisciplinaPre) codigoDisciplinaPre referencia Disciplinas codigoDisciplinaPos referencia Disciplinas Figura 32: Exemplo de Autorrelacionamento N:N 3. nome. Essa tabela terá duas chaves estrangeiras. agora. Essas chaves estrangeiras compõem a chave primária da tabela criada. matriculaChefe) matriculaChefe referencia Funcionários Figura 31: Exemplo de Autorrelacionamento 1:N 3.8. assim como para os relacionamentos N:N tradicionais. O esquema gerado ficaria da seguinte forma: Disciplinas (codigo.7.5. Autorrelacionamento N:N Para os autorrelacionamentos N:N.n) seja um atributo multivalorado de Funcionários. Para ilustrar. A Figura 32 representa um modelo ER com esse tipo de relacionamento. cria-se uma nova tabela para mapear o relacionamento.

não é amplamente aceita por projetistas de banco de dados. não há limites de telefones para um funcionário. embora seja elegante. tanto pode não haver nenhum. Essa solução. visa à melhoria de performance. dtAdmissao) Telefones (matricula. nome. pois evita junções entre tabelas nas consultas que devem retornar os telefones de funcionários. . o esquema gerado ficaria da seguinte forma: Funcionarios (matricula. Considerando que dificilmente se registra um número grande de telefones para cada pessoa.atributos. como um ou vários. uma solução de projeto adotada é a criação de uma tabela para cada um deles. é costume se criar colunas adicionais na tabela de funcionários para representar esses valores (exemplo : telefone01 e telefone02). Para a tabela criada. Para o exemplo em tese. cidade. quando adotada. numeroTelefone) matricula referencia Funcionarios Nesse caso. deve ser aplicada a mesma solução dos relacionamentos 1:N – identificados. A solução acima adotada para representação de atributos multivalorados.

posicaoPilotoProva) codPiloto referencia PILOTOS codCorrida referencia CORRIDAS . nomeEquipe. dtNascimento.3. peso. através da representação de Esquema Relacional. EXEMPLO DE PROJETO LÓGICO Tomando como base o estudo de caso usado no Capítulo 2. sigla. duracaoProva. é necessário avaliar cada tipo de relacionamento para cada conjunto de entidades do modelo. nomePiloto. aproveitamos os atributos determinantes de cada conjunto de entidades. vamos agora gerar o projeto lógico para o mesmo cenário. Observações importantes: Observe que cada conjunto de entidades foi mapeado em uma tabela no Esquema Relacional e que para chaves primárias. Modelo E/R: Dicionário de Dados: EQUIPES = codEquipe + nomeEquipe PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso PAISES = codPais + sigla + nome CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito PARTICIPACOES = posicaoPilotoProva Esquema Relacional equivalente : PAISES (codPais. Para definição das chaves estrangeiras. altura. referente ao campeonato de Fórmula 1. codPais. codCorrida . nomeCircuito) PARTICIPACOES (codPiloto. nome) EQUIPES (codEquipe . codPais) codPais referencia PAISES PILOTOS (codPiloto. codEquipe) codPais referencia PAISES codEquipe referencia EQUIPES CORRIDAS (codCorrida. dtCorrida.6.

3. cidade.2. as duas tabelas geradas encontram-se normalizadas na primeira forma normal. uma relação R existe na primeira forma normal (1FN) se. nomedoAtor) A coluna Título depende somente do código do filme e Nome do Ator. Nesse caso. de um banco de dados de uma locadora de vídeo. com geração do esquema correspondente. depende somente do Número do Ator. Nesse caso. todos os domínios subjacentes contiverem apenas valores atômicos. cidade. nome. titulo. dtAdmissao) Telefones (matricula. com o seguinte esquema: Filmes (codigoFilme. relacionada à original. e somente se. Esse processo de verificação. dtAdmissao.3. Segundo DATE (2004). e somente se. 3. denominadas 1FN. Segunda Forma Normal (2FN) Quando uma tabela possui uma chave composta. Quase sempre a solução é dividir as colunas em duas tabelas e criar uma terceira tabela que correlacione as linhas das duas tabelas.7. Passando pelo processo de normalização (1FN). dizemos que a tabela viola a segunda forma normal. uma relação R existe na segunda forma normal (2FN) se. 2FN e 3FN.1. as formas normais visam a eliminar informações redundantes nas tabelas. nome. deve-se avaliar. Segundo DATE (2004). nem todos os domínios contêm valores atômicos. composto por um conjunto de regras. telefones) No caso dessa relação. Exemplo: considere o esquema de uma relação filmes. como é o caso de telefones. Para ilustrar esse conceito. porém. Caso ocorra essa dependência parcial.7. suas colunas devem ser dependentes de toda a chave e não de apenas uma parte dela. Há diversas formas normais usadas no processo de verificação. 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. cujo processo é denominado normalização. geraríamos os seguintes esquemas: . tomemos como exemplo a relação Funcionários. Normalmente. estiver na (1FN) e todos os atributos não chaves forem dependentes da chave principal. temos o seguinte esquema: Funcionarios (matricula.7. se a projeção foi bem feita. serão exploradas apenas as três primeiras formas normais. os valores não atômicos devem estar contidos em uma outra tabela. denomina-se “forma normal”. NORMALIZAÇÃO Uma vez concluído o projeto lógico de banco de dados relacional. com a seguinte definição de esquema: Funcionarios (matricula. para cada tabela. codigoAtor. na nossa disciplina. numTelefone) matricula referencia Funcionarios Com isso.

titulo. Muitas vezes. e somente se. Preco) Com o passar do tempo.50 e. Segundo DATE (2004). Drama e Comédia custam R$2. então a solução seria criar uma tabela adicional para armazenar os valores por categoria do filme. buscando melhoria de desempenho das aplicações. Nesse caso. Mais uma vez volto a dizer que tudo tem seu preço! Às vezes. titulo. a coluna Preço dependeria não só da coluna Código do filme. categoria. R$2. . Lançamentos. R$3. nomedoAtor) AtoresFilmes (codigoFilme. 3.3. Essa tabela não está na Terceira Forma Normal. por isso acabamos abrindo mão de uma coisa para termos o que é mais importante no cenário exposto.Filmes (codigoFilme.00. 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. os seguintes esquemas são gerados: Filmes (codigoFilme.codigoCategoria) codigoCategoria referencia Categorias Categorias (codigoCategoria. uma relação R existe na terceira forma normal (3FN) se. 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 (codigoFilme. preco) Suponha que a loja determine o preço dos filmes por categoria: filmes de Terror.7. Musicais.00. como também da coluna Categoria. estiver na (2FN) e todos os atributos não chave forem intransitivamente dependentes da chave principal. Após normalização. titulo) Atores (codigoAtor. você vai adquirindo experiência e não necessitará avaliar mais essas regras para as tabelas projetadas. codigoAtor) codigoFilme referencia Filmes codigoAtor referencia Atores A 2FN deve ser verificada sempre que a tabela possuir uma chave primária composta de 2 ou mais campos. usamos essa experiência para construir modelos desnormalizados. não conseguimos ter projeto perfeito e alta performance.

nomeAuto.Atividade 01 Muitas vezes. nomeCliente. codCliente. valorProduto(1.n). codModelo. codModelo. nomeFab) Automoveis (codAuto. Perifericos (codPeriferico. dada a definição do esquema abaixo. Baseado nisso. codProduto(1.n). nomePessoa) Vendas (codPessoa. nomeProduto(1. . o DBA se depara com situações em que possui o esquema do banco de dados. noConfig) Quantidade ♦ codCPU NomeCPU ♦ codModelo NomeModelo ♦ codModelo CodCPU ♦ codModelo NomeCPU X Y. valor. coloquem a mesma na terceira forma normal. nomeModelo. significa dizer que : Y depende de X b) Dada a relação PEDIDOS. preco. quantidadeProduto(1. PEDIDOS (numeroPedido. gere o modelo conceitual equivalente (esse processo denomina-se Engenharia Reversa). enderecoCliente. noConfig. nomeEntregador. Fabricantes (codFab. codFab) codFab referencia Fabricantes Pessoas (codPessoa. dtVenda. coloquem a mesma na terceira forma normal.n). passo a passo. placaVeiculoEntregador) Este capítulo teve como objetivo o de apresentar conceitos relacionados com projeto lógico de bancos de dados. codCPU. dtPedido. No próximo capítulo trabalharemos com linguagens de consultas aplicadas ao este modelo. cor) codPessoa referencia Pessoas codAuto referencia Automoveis Atividade 02 a) Dada a relação Perifericos.n). porém não tem o modelo conceitual equivalente. mais especificamente no que se refere ao modelo relacional. passo a passo. nomeCPU) As dependências funcionais que existem nesta tabela são as seguintes: ♦ (codPeriferico. codAuto. matriculaEntregador. quantidade.

A Álgebra relacional é uma linguagem de consulta procedural. Uma linguagem de consulta é uma linguagem na qual um usuário requisita informações do banco de dados. denominada Sequel. 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.4. foi desenvolvida no . São classificadas como procedurais e não procedurais. SQL A linguagem SQL foi uma das grandes razões para a consolidação dos bancos de dados relacionais no mercado. Navathe [NAVATHE. focaremos apenas na álgebra relacional. 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. A Linguagem SQL é uma linguagem de consulta comercial. dando o mesmo poder de expressão para ambas as linguagens. gerando publicações de novas versões. Numa linguagem procedural. desde 1986. em 1986. embora seja fundamentada nessas linguagens formais (na álgebra e no cálculo). DEFINIÇÃO Uma linguagem de consulta é uma linguagem na qual o usuário requisita informações do banco de dados. enquanto o cálculo relacional é uma linguagem não-procedural. SQL é uma linguagem de consulta comercial e inclui elementos de uma linguagem procedural e não-procedural. Álgebra Relacional é uma linguagem de consulta formal e procedural. com comandos muito mais amigáveis do que as linguagens formais. 4. Numa linguagem não-procedural. Bom estudo! Profª Claudinete Vicente Borges 4. o usuário descreve a informação desejada. Nas seções seguintes exploraremos a linguagem SQL. sem fornecer um procedimento específico para obter tal informação. São classificadas como procedurais e não procedurais.1. LINGUAGENS DE CONSULTA Olá! Neste capítulo você terá conceitos de linguagens de consultas formais e comerciais para bancos de dados relacionais. intitulada padrão pelo comitê ANSI. Desde sua definição como padrão. passou por diversas revisões. 2005] afirma que qualquer expressão escrita em álgebra relacional pode ser representada também no cálculo.2. É uma linguagem declarativa. A versão original.

inserção.Inclui comandos para consulta.Uso de SQL em linguagens de programação de uso geral. É usada para listar os atributos desejados no resultado de uma consulta. A maioria dos sistemas gerenciadores de bancos de dados comerciais implementam suporte ao padrão SQL. exclusão.1. A primeira versão ficou conhecida como SQL-86 ou SQL1. definição de Visões . como Pascal.A SQL DDL inclui comandos para especificação de direitos de acesso a relações e visões... incorporação DML (SQL Embutida) . A linguagem SQL possui diversas partes: • linguagem de Definição de Dados (DDL) . pois.. alteração). integridade . • • • • • • 4. se apenas o padrão for utilizado. que incluiu recursos para dar suporte aos bancos de dados objetos-relacionais e orientados a objetos.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. a segunda versão foi denominada SQL-92 ou SQL2 e a última versão publicada. a cláusula from corresponde à operação produto cartesiano da álgebra relacional. A estrutura básica de uma expressão SQL SELECT consiste em três cláusulas: select. linguagem de manipulação de dados (DML) .A SQL DDL inclui comandos para especificação de iniciação e finalização de transações.Inclui comandos para definição de esquemas de relações (criação. garante-se a portabilidade.2. e seu nome foi alterado para SQL (Structured Query Language). criação de índices dentre outros.. Linguagem de Manipulação de Dados – SQL DML Consultas SELECT O comando SELECT é responsável por consultar dados em um banco de dados que satisfazem aos predicados (critérios) informados. exclusão e modificação de tuplas em uma relação do banco de dados. Estas facilidades precisam ser usadas com cautela. • • Uma típica consulta SQL SELECT tem a seguinte forma: . C. incorporam uma série de funções adicionais visando a facilitar o trabalho dos desenvolvedores.Laboratório de Pesquisa da IBM e implementada como parte do projeto System R no início dos anos 70. a cláusula where corresponde ao predicado de seleção da álgebra relacional. Ela lista as relações a serem examinadas na avaliação da expressão. A linguagem evoluiu desde então. autorização . Além disso.A SQL DDL inclui comandos para definição de visões. caso haja a necessidade de troca de SGBD. ficou conhecida como SQL-99 ou SQL3. controle de Transações . from e where. • a cláusula select corresponde à operação projeção da álgebra relacional. Consiste em um predicado envolvendo atributos de relações que aparecem na cláusula from.

P é um predicado. .. .. An FROM r1. Essa consulta é equivalente à expressão da álgebra relacional: π A1. A2. An] 6 1 2 3 4 5 Cada uma das cláusulas da consulta acima será explorada nas subseções seguintes. Para execução da consulta acima.. forma-se o produto cartesiano das relações referenciadas na cláusula from. Na prática. SELECT A1... An FROM r1. Mesmo que o otimizador altere a ordem de execução.. A2. ... O número que segue cada linha sugere a ordem de execução. rn [WHERE P] [GROUP BY A1. o otimizador de consultas da linguagem SQL pode converter essa expressão em uma forma equivalente que pode ser processada mais eficientemente. rn [WHERE P] 3 1 2 A numeração constante no final de cada linha da consulta representa a ordem de execução desta linha... buscando por melhoria de performance e para facilitar o aprendizado é interessante termos em mente esta ordem.. r2. A2.. r2. rn [WHERE P] 3 1 2 Cada Ai representa um atributo e cada ri é uma relação. dentro da consulta como um todo. . An pode ser substituída por um (*) para selecionar todos os atributos (colunas) presentes nas tabelas da cláusula from. O conhecimento desta ordem é importante para efeito didático pois facilita o entendimento do comando. . .. .... sendo que apenas as cláusulas SELECT e FROM são obrigatórias... . r2. An FROM r1.. A2. A2.. An] [HAVING Condição] [ORDER BY A1.. mas para efeito didático iremos manter esta ordem de execução. então. A2.. Uma consulta completa pode ter as cláusulas abaixo... . . An (σP (r1 x r2 x ... A2.... executa-se uma seleção da álgebra relacional usando o predicado da cláusula where e.SELECT A1.. projeta o resultado para os atributos da cláusula select.x rn)) A lista de atributos A1. ... SELECT A1.

. inserimos a palavrachave distinct depois da cláusula select para eliminá-las. a relação resultante poderá ter clientes que possuam o mesmo nome.Assim como na álgebra relacional. é relativamente simples escrever uma expressão SQL para representar a operação ligação natural. Esta consulta pode ser escrita da seguinte forma: SELECT DISTINCT Clientes.codigoCli Observe que na consulta acima. A consulta SQL pode ser escrita da seguinte forma: SELECT Nome FROM Clientes Linhas (tuplas) duplicadas Em algumas situações. Aproveitando o exemplo anterior.: Encontre os nomes e cidades de clientes que possuam empréstimos em alguma agência. o resultado de uma consulta SQL é uma relação! Vamos considerar uma primeira consulta simples. Se além disso. Predicados e ligações A SQL não tem uma representação da operação ligação natural.cidade FROM Clientes. Emprestimos WHERE Clientes. uma vez que a ligação natural é definida em termos de produto cartesiano. uma consulta SQL pode retornar uma relação que contenha tuplas (linhas) duplicadas. Nessa situação. Ex.codigoCli=Emprestimos.nome. Nesse caso. “Encontre os nomes de todos os clientes na relação clientes”. Clientes. seleção e projeção. No entanto. apenas necessita-se saber se o cliente possui empréstimo. por isto apenas as tabelas Clientes e Empréstimos foram incluídas. podemos eliminar essas duplicações usando a cláusula distinct: SELECT DISTINCT Nome FROM Clientes A cláusula distinct aplica-se à linha a ser retornada. embora seja colocada antes do primeiro atributo. seria necessário a inclusão da relação Agências. tivesse a necessidade de saber qual a agência em que o empréstimo foi feito. usando nosso esquema exemplo.

como mostra o exemplo a seguir. ).. 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. que oferece outras opções de join . de Elmasri Navathe. Sublinhado (_).nome. etc. >. O caractere de escape é precedido do caractere especial para indicar que este último deverá ser tratado como um caractere normal. .codigoCli Uma boa fonte de pesquisa para complementar os estudos sobre os conceitos tratados nesta seção é consultar o livro Sistemas de Banco de Dados. capítulo 8.<. considere os padrões seguintes. Para ilustrar. _ . <>. caracteres especiais: (. usando a palavra-chave escape. a SQL permite a especificação de um caractere de escape. . = . operador para comparação: between.codigoCli=Emprestimos. %.* e /. Clientes . o like. SELECT distinct nome FROM Clientes WHERE rua LIKE “ %na%” Ou também Ex. :. Substitui um caractere qualquer. +. que utilizam uma barra invertida como caractere de escape. A SQL inclui os conectores and.: Encontre os nomes de todos os clientes cujas ruas incluem a subcadeia “na”.. Ex. _...: Selecionar todas as contas que possuam saldo entre 10000 e 20000.cidade FROM Clientes JOIN Emprestimos ON Clientes. Substitui qualquer subcadeia de caracteres. .: Encontre os nomes de todos os clientes cujas ruas onde moram finalizem com a subcadeia “na”. Ele é usado em conjunto com dois caracteres especiais: Por cento (%). % . usando join: SELECT DISTINCT Clientes. <= . SELECT distinct nome FROM Clientes WHERE rua LIKE “ %na” Para que o padrão possa incluir os caracteres especiais ( isto é. Ex. A consulta acima poderia ser escrita da seguinte forma. Definimos o caractere de escape para uma comparação like.Outro recurso disponível na linguagem SQL para estabelecer ligações entre tabelas são as operações de join. >= . or e not .).

codigoAg = 51 AND Da mesma forma. teremos problemas! Nesse caso não usará o índice.nome FROM Clientes. Uma vez que as relações são conjuntos. as linhas duplicadas são eliminadas.codigoCli Emprestimos. duas condições devem ser atendidas: as relações r e s precisam ter a mesma paridade. Para uma operação União (Union) r ∪ s ser válida. Emprestimos WHERE Clientes. na união destas relações. porém. podendo implicar em baixa performance das aplicações.codigoCli=Emprestimos. na agência de código 51. Embora a cláusula Like seja muito útil. Ex. nas quais não se conhece o início. e os domínios do iésimo atributo de r e do i-ésimo atributo de s devem ser os mesmos. Depositos WHERE Clientes. fazemos: SELECT DISTINCT Clientes. não há problemas.codigoAg = 51 Depositos. Depositos . Quando fixar o início da cadeia. Se quisermos saber todos os clientes que possuem empréstimos na agência de código 51. A procura por não-substituições em vez de substituições se dá por meio do operador not like. fazemos: SELECT DISTINCT Clientes. elas precisam ter o mesmo número de atributos.codigoCli AND Para encontrar todos os clientes que possuem depósito. Operações de conjunto A SQL inclui o operador de conjunto union que opera em relações e corresponde à operação ∪ da álgebra relacional. empréstimo ou ambos.codigoCli= Depositos. como iniciar com “Maria”.nome FROM Clientes. deve ser utilizada com cuidado. quando for aplicada em consultas para procurar caracteres no meio ou no final de cadeias. caso haja para a coluna.Like “ ab\%cd%” escape “\” substitui todas as cadeias começando com “ ab%cd”. fazemos: SELECT DISTINCT Clientes.nome FROM Clientes. se quisermos consultar todos os clientes que possuem depósitos na agência de código 51. Like “ ab\_cd%” escape “\” substitui todas as cadeias começando com “ ab_cd”. isto é.

Para listar em ordem alfabética todos os clientes do banco. considere a consulta “Encontre todos os clientes que possuem uma conta (Depósito) e não possuem empréstimo na agência “Princesa Isabel””.nome FROM Clientes. e não nos preocupamos em usar a cláusula Order by.codigoCli IN (SELECT CodigoCli FROM Depositos.codigoAg Agencias. Agencias WHERE Depositos. Para especificar a ordem de classificação.codigoAg AND NomeAg = “Princesa Isabel”) = .codigoCli=Depositos.codigoCli=Emprestimos. Isso acontece provavelmente porque há um índice ordenado criado sobre essa coluna.WHERE Clientes.codigoAg =51 UNION SELECT DISTINCT Clientes. codigoAg ASC Se desejar que o resultado de uma consulta SQL seja exibido em ordem alfabética. podemos especificar asc para ordem ascendente e desc para descendente.codigoCli AND Emprestimos. Para ilustrar. fazemos: SELECT DISTINCT nome FROM Clientes ORDER BY nome Como padrão.codigoCli AND Depositos. Emprestimos WHERE Clientes. construímos consultas e o resultado é apresentado em ordem alfabética. sua ordenação vai se perder! 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. se o DBA resolver criar esse índice sobre outra coluna. A consulta SQL poderá ser escrita da seguinte forma: SELECT DISTINCT Clientes. Às vezes. utilize a cláusula Order By. Como se segue: SELECT * FROM Emprestimos ORDER BY quantia DESC.nome FROM Clientes WHERE Clientes. a cláusula order by lista tuplas na ordem ascendente. Podemos ordenar uma relação por mais de um elemento.codigoAg = 51 Ordenando a exibição de tuplas A cláusula order by organiza o resultado de uma consulta em uma ordem determinada. conforme esperado. porém.

Agencias WHERE emprestimos.nome FROM Clientes.nome. Lembre-se da ordem de execução de uma consulta SELECT! Redefinindo a relação Agências para uso em exemplos posteriores. e não mais aos nomes originais. NomeAg.codigoCli Uma vez que as relações Clientes e Depósitos foram renomeadas para C e D. na consulta. Muitas vezes usamos este recurso com o objetivo de reduzir o tamanho das expressões SQL. Ela foi construída desta forma para exemplificar o uso do operador IN.nomeAg FROM Agencias .cidade = “Vitória” . Agencias AS ag WHERE agencias. Depositos AS D WHERE C.NomeAg = “Princesa Isabel” AND Clientes.codigoAg agencias.codigoAg AND nomeAg = “Princesa Isabel”) = Esta consulta é equivalente à consulta abaixo.codigoCli NOT IN (SELECT codigoCli FROM Emprestimos.cidade FROM Clientes AS C. CidadeAg. Agencias WHERE Clientes.codigoAg = Agencias. Agencias = (CodigoAg. como mostra o exemplo a seguir. A renomeação é feita usando a palavra reservada “AS”.codigoCli NOT IN (SELECT codigoCli FROM Emprestimos.ativos AND ag. ativos) Comparação de conjuntos Considere a consulta “encontre todas as agências que possuem ativos maiores que alguma agência de Vitória”. Agencias WHERE emprestimos.AND Clientes. quaisquer referências a essas tabelas. C.codigoAg = agencias. assim como na operação renomear da álgebra relacional.codigoAg AND Agencias.codigoCli = Depositos. SELECT DISTINCT Clientes.ativos > ag.codigoAg AND nomeAg = “Princesa Isabel”) Renomeação de Tabelas em uma consulta A renomeação sempre será necessária quando precisarmos usar a mesma tabela mais de uma vez na mesma consulta. SELECT DISTINCT C. Ex: “encontre o nome e a cidade de todos os clientes que possuem depósito”. após o nome da tabela na cláusula FROM.codigoCli AND Depositos. Esta consulta poderá ser escrita em SQL da seguinte forma: SELECT DISTINCT Agencias.codigoCli = D. Depositos. devem ser feitas a C e D.

codigoAg AND Agencias. Agencias WHERE Emprestimos.codigoAg = Agencias. como ilustrado no exemplo acima. >=all. Comparações do tipo >any. Para ilustrar.nomeAg = “Princesa Isabel”) WHERE NOT EXISTS (SELECT * FROM Emprestimos.Nome FROM Clientes WHERE EXISTS (SELECT * FROM Depositos. <all. >=any.NomeAg FROM Agencias WHERE ativos > ANY (SELECT ativos FROM Agencias WHERE Agencias. Observe também que.codigoCli AND Depositos. conforme será abordado a seguir. A mesma consulta acima poderia ser escrita usando o operador any (pelo menos um). não podemos escrever a expressão usando a construção in.codigoCli= Clientes. A consulta anterior pode ser escrita da seguinte forma: SELECT Agencias.codigoCli AND .cidade = “Vitória”) Como o operador Any. <=all.Uma vez que a consulta usa uma comparação “maior que”. o operador all pode ser usado como: >all. Sempre que houver necessidade de comparar um atributo com o resultado de uma subconsulta é necessário usar um operador de conjunto. A construção > all corresponde à frase “maior que todos”. Testando relações vazias A SQL possui um recurso para testar se uma subconsulta retorna alguma tupla. =any são aceitas pela linguagem. vamos escrever a consulta “Encontre todos os clientes que possuem depósito e não possuem empréstimo na agência “Princesa Isabel” ”. SELECT Clientes. <any. A consulta fica como se segue: SELECT Agencias.nomeAg FROM Agencias WHERE ativos > ALL (SELECT ativos FROM Agencias WHERE Agencias.cidade = “Vitória”) Vamos modificar a consulta anterior levemente para encontrar todas as agências que possuem ativos maiores do que todas as agências de Vitória. ela teve que ser renomeada.codigoCli= Clientes. A construção exists retorna true se a subconsulta retornar alguma tupla. =all e <> all. <=any. seja o operador ALL seja o ANY. Agencias WHERE Depositos. como houve necessidade de usar a mesma tabela (Agências) duas vezes na consulta.

eles se aplicam ao mesmo tipo de consulta. nomePessoa. Consulte todas as pessoas que não trabalham em Vitória e que ganham acima de R$2000.codigoAg Agencias. eu costumo substituir o * por 1. Assim. não importa o conteúdo retornado. chefe) Chefe referencia PESSOAS EMPRESAS (codigoEmpresa. 5.. usando a linguagem SQL. Considerando que o objetivo do operador EXISTS é verificar a existência de tuplas na consulta seguinte. na consulta acima . 2.. 6. algumas consultas mais complexas são resolvidas com o operador EXISTS/NOT EXISTS. . 3. salario) codigoPessoa referencia PESSOAS codigoEmpresa referencia EMPRESAS 1. cidade. Consulte todas as pessoas que trabalham na mesma cidade onde moram. nomeEmpresa. Atividade 01 Considere o esquema abaixo para construir as expressões seguintes. PESSOAS (codigoPessoa. Consulte todas as pessoas que moram em Vitória. Na verdade.codigoAg = Agencias. codigoEmpresa. sendo esse operador um pouco mais abrangente que os operadores IN / NOT IN. Consulte todas as pessoas que não trabalham na empresa cujos nomes comecem com “inf_”. Consulte todas as empresas que funcionam em cidades em que não moram pessoas cujo primeiro nome seja Maria (usar operações de conjunto). cidade) TRABALHA (codigoPessoa. O resultado deverá ser apresentado em ordem alfabética. 4. WHERE NOT EXISTS (SELECT * FROM emprestimos…). Consulte todas as pessoas que moram na mesma cidade do chefe.00 em ordem decrescente.nomeAg = “Princesa Isabel”) AND Embora a abordagem dos operadores IN/NOT IN e EXIST/NOT EXISTS sejam diferentes.Emprestimos.

FABRICANTES (codFab.codigoAg GROUP BY Agencias. Consultar as pessoas que compraram automóveis do fabricante “Ford”. cor) codPessoa referencia PESSOAS codAuto referencia AUTOMOVEIS 1. . Consultar as pessoas que compraram “Ford” e não compraram “Volks”.codigoAg = Agencias. usando a cláusula group by. considere a consulta: Encontre o saldo médio das contas em cada agência. preco. 5. Agencias WHERE Depositos. 4. codFab) codFab referencia FABRICANTES PESSOAS (codPessoa. O resultado deverá ser apresentado em ordem alfabética. usando a linguagem SQL.Atividade 02 Considere o esquema abaixo para construir as expressões seguintes.nomeAg.nomeAg A tabela 32 abaixo mostra o resultado parcial da execução da consulta (antes do agrupamento). Consultar as pessoas que compraram carro com ágio. nomePessoa) VENDAS (codPessoa. Consultar as pessoas que não compraram “Ford”. tomando como base o conjunto de valores definidos no início deste capítulo para o esquema bancário. dtVenda.saldo) AS saldoMedio FROM Depositos. valor. Tuplas com o mesmo valor em todos os atributos na cláusula group by são colocados em um grupo. codAuto. 2. Funções agregadas: Média: AVG Mínimo: MIN Máximo: MAX Soma: SUM Contar: COUNT Para ilustrar. Consultar as pessoas (nome) que compraram algum carro. Funções agregadas A SQL oferece a habilidade para computar funções em grupos de tuplas. O(s) atributo(s) informado(s) na cláusula group by são usados para formar grupos. SELECT Agencias. AVG(Depositos. 3. nomeFab) AUTOMOVEIS (codAuto. nomeAuto.

cada agência (nomeAg) constituirá um grupo. temos o resultado na consulta exibido na tabela 33. pois um cliente pode ter mais de uma conta em uma agência e deverá ser contado uma única vez. conforme mostra a seguir: SELECT Agencias.cidadeAg Vitória Vitória Vitória Vitória Uma vez que o agrupamento é feito.Tabela 32: Tabela resultante do produto cartesiano e seleção (cláusula FROM e WHERE) codigo Ag 50 51 51 53 numeroCo nt 999 991 992 993 codigoC li 01 02 03 04 saldo 1000 3200 2300 1200 Agencias. a consulta poderia ser levemente modificada.codigoAg GROUP BY Agencias.nomeAg Centro Princesa Isabel Princesa Isabel Avenida Agencias . além do saldo médio por cada agência. Agencias WHERE Depositos. Tabela 34: Tabela resultante da consulta “encontre o saldo médio e quantidade de clientes em cada agência”. quiséssemos retornar a quantidade de clientes que possuem conta.nomeAg saldoMedio. dará erro! Se. nomeAg Centro Princesa Isabel Avenida saldoMedio 1000 2750 1200 qtdClientes 1 2 1 . nomeAg Centro Princesa Isabel Avenida saldoMedio 1000 2750 1200 Quando escrevemos a cláusula GROUP BY em uma expressão SQL. Tabela 33: Tabela resultante da consulta “encontre o saldo médio das contas em cada agência”.nomeAg. Note que para a cláusula COUNT é importante o uso da cláusula distinct . codigoAg 50 51 51 53 Agencias . apenas funções agregadas são permitidas. AVG(Depositos. Além deles. a cláusula SELECT só poderá retornar atributos que constam no grupo. Caso contrário. A tabela 34 abaixo mostra o resultado da consulta.codigoAg = Agencias. sobre o qual incidirá a função agregada (AVG).codigoCli) AS qtdClientes FROM Depositos. Com isto.saldo) AS COUNT(DISTINCT Depositos.

saldo) AS maiorSaldo FROM Depositos.A consulta abaixo mostra o maior saldo para cada agência. No caso. Agencias WHERE Depositos. AVG(Depositos. desejamos tratar a relação inteira como um grupo simples. não usamos a cláusula group by. apenas a agência “Princesa Isabel” será retornada. Agencias WHERE Depositos. Podemos escrever essa expressão SQL assim: SELECT Agencias.nomeAg. Nesses casos.codigoAg GROUP BY Agencias. A cláusula HAVING elimina grupos. nomeAg Princesa Isabel saldoMedio 2750 A cláusula WHERE elimina linhas em uma consulta.saldo) FROM Depositos .nomeAg HAVING AVG(saldo)>1200 A tabela 36 mostra o resultado da execução da consulta. e é definida pela cláusula having. escrevemos: SELECT AVG (Depositos.nomeAg A tabela 35 mostra o resultado da execução da consulta. Por exemplo. SELECT Agencias.codigoAg= Agencias.codigoAg GROUP BY Agencias. Tabela 35: Tabela resultante da consulta “encontre o maior saldo para cada agência”.saldo) AS saldoMedio FROM Depositos. poderíamos estar interessados apenas em agências em que a média dos saldos seja superior a R$1200.00. Tabela 36: Tabela resultante da consulta “encontre as agências onde a média de saldo seja superior a 1200”.codigoAg= Agencias. Essa condição será aplicada a cada grupo e não a tuplas simples. nomeAg Centro Princesa Isabel Avenida maiorSaldo 1000 3200 1200 Muitas vezes é necessário definir uma condição que se aplique a grupos em vez de tuplas. MAX(Depositos. Para encontrar a média de saldos de todas as contas. Às vezes.nomeAg.

não podemos remover valores apenas em atributos particulares. por agências. por agências. caso ele possua mais de uma conta no banco. Para criar este nome. 8) Consultar o saldo de cada cliente. Sintaxe: DELETE FROM r [WHERE P] Onde r representa uma relação e P um predicado. 2) Consultar o total de agências por cidade. É sempre recomendado que se dê um nome para identificá-la. o(s) cliente(s) com o maior saldo. ao executá-la. 3) Consultar. O predicado da cláusula where pode ser tão complexo quanto o predicado where do comando select. classificado por cidade. em ordem crescente das cidades onde essas agências se situam. DELETE FROM Emprestimos .No exemplo anterior. usando a linguagem SQL. 4) Consultar o valor médio de empréstimos efetuados por cada agência. ou seja.: Fazer uma consulta para excluir todas as tuplas de empréstimo. Atividade 03 Considere o esquema bancário para construir as expressões seguintes. 6) Consultar 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. a coluna projetada por meio de uma função agregada. a média de saldos. não possui um nome. a coluna aparecerá com o nome EXPR. Ex1. Caso contrário. 7) Consultar o menor saldo de clientes. Removendo linhas de uma tabela O comando Delete é usado para remover tuplas em uma dada relação. Note que o comando delete opera em apenas uma relação. não foi renomeada como nos exemplos anteriores. assim como para renomeação de tabelas. também chamado de “Alias” usa-se a cláusula “AS”. 5) Consultar a(s) agência(s) que possui(em) a maior média de quantia emprestada. por exemplo. 1) Consultar todos os clientes que possuem contas em agência(s) que possui(em) o maior ativo. Lembre-se de que só podemos remover tuplas inteiras.

codigoCli.. Inserindo linhas em uma tabela Para inserir um dado em uma relação. omitindo a relação de atributos... a consulta falhará e.00. porém vazia. porém. An) VALUES (V1. Obviamente. . . A2. DELETE FROM Emprestimos WHERE numero between 1300 AND 1500 Ex4.Ex2.1. fazemos o seguinte comando: INSERT INTO depositos (codigoAg.: Remover todos os empréstimos com números entre 1300 e 1500. DELETE FROM Depositos WHERE depositos.9000. Essa abordagem. numeroCont. na conta 9000 da agência de código=2.codigoCli in (SELECT codigoCli FROM Clientes WHERE nome=”joão”) Ex3. todas as linhas serão excluídas. permanecerá criada.: Remover todos os depósitos de “joão” DELETE FROM Depositos.1200) A SQL permite que essa mesma inserção seja escrita da seguinte forma: Insert into depositos Values (2.1200). Vn) Onde r representa uma relação A atributos e V valores a serem inseridos. os valores dos atributos para tuplas inseridas precisam ser membros do mesmo domínio do atributo.1.. V2. Sintaxe: INSERT INTO r (A1.. cujo valor seja R$1200. se usar o comando DELETE FROM Tabela sem predicado na cláusula WHERE. a tabela. consequentemente.. Para isso.Depositos WHERE Depositos. no entanto.9000. ou especificamos uma tupla para ser inserida ou escrevemos uma consulta cujo resultado seja um conjunto de tuplas a serem inseridas. .codigoAg in (SELECT codigoAg FROM Agencias WHERE cidade=’Vitoria’) O comando DELETE é um comando da Linguagem DML. tendo em vista que. saldo) VALUES (2. a exemplo da inclusão de um novo atributo. por isso.: Remover todos os depósitos de agências localizadas em “Vitória”. se houver alteração do esquema da relação. não é recomendada. a aplicação que a utiliza acarretará em erros. Suponha que desejamos inserir um novo depósito de João (código = 1).

UPDATE Depositos SET saldo = saldo * 1. com um saldo de R$200. Agencias WHERE Emprestimos. Empréstimos.00 recebam aumento de 6% e as demais de 5%.05 WHERE saldo<=10000 . codigoCli.05 Suponha que todas as contas com saldo superior a R$10000. O comando UPDATE é um comando da Linguagem DML. Nesse caso.codigoCli.. Por isso.numeroEmp. esteja atento! Suponha que esteja sendo feito o pagamento de juros e que sejam acrescentados 5% em todos os saldos. o comando update deve ser aplicado..Podemos querer também inserir tuplas baseadas no resultado de uma consulta. Altera valores de campos e não a estrutura da tabela. a2 = v2. INSERT INTO Depositos (codigoAg. an = vn [WHERE p] Em que r representa uma relação. Suponha que desejemos inserir todos os clientes que possuam empréstimos na agência “Princesa Isabel” na relação depósitos. 200 FROM Emprestimos. a atributos. Sintaxe: UPDATE r SET a1 = v1..nomeAg=”Princesa Isabel” Essa possibilidade de consultar dados em tabelas e inserir em outra pode ser muito útil para trabalhar com migração de banco de dados. saldo) SELECT Emprestimos. Os alunos costumam confundir isso. podemos desejar mudar valores em tuplas.codigoAg AND Agencias. Atualizando valores Em certas situações.00. . p predicado e v os novos valores para os respectivos atributos. Escrevemos UPDATE Depositos SET saldo = saldo * 1.codigoAg=Agencias.06 WHERE saldo >10000 UPDATE Depositos SET saldo = saldo * 1. Empréstimos. numeroCont.codigoAg.

está sendo atribuído o valor nulo para o atributo “ativos”. Caso contrário. que todas as contas de pessoas que possuem empréstimos no banco terão acréscimo de 1%. automaticamente ele assumiria o valor nulo. nomeAg. ”Vitória”) A consulta acima só será válida se o campo ativos puder assumir valor nulo.codigoCli = Emprestimos. ”Centro”. Não é possível inserir linhas em mais de uma tabela em um comando. Considere a expressão cujo objetivo é o de incluir uma nova agência: INSERT INTO Agencias (codigoAg.01 WHERE codigoCli IN (SELECT codigoCli FROM Emprestimos) Como você deve ter observado. cidadeAg. UPDATE e DELETE – atuam sempre sobre uma única tabela. ocasionará erro. ”Vitória”. Valores Nulos É possível para tuplas inseridas em uma dada relação atribuir valores a apenas alguns atributos do esquema. Considere.A cláusula where pode conter uma série de comandos select aninhados. A mesma consulta poderia ser reescrita omitindo esse atributo. para achar todos os clientes que aparecem na relação empréstimos com valores nulos para quantia. A palavra chave null pode ser usada em um predicado para testar se um valor é nulo. Emprestimos WHERE Clientes. NULL) Nesse caso. UPDATE Depositos SET saldo = saldo * 1. .”Centro”. Assim. nomeAg.codigoCli AND quantia IS NULL O predicado IS NOT NULL testa a ausência de um valor nulo. Os atributos restantes são designados como nulos. ativos) VALUES (2. cidadeAg) VALUES (2. escrevemos: SELECT DISTINCT nome FROM Clientes. INSERT INTO Agencias (codigoAg. Nesse caso. por exemplo. os comandos de atualização – INSERT.

A SQL DDL permite a especificação não apenas de um conjunto de relações. 6.2. Faça comando(s) SQL para efetivar a atualização da cidade. nomePessoa.Atividade 04 Considere o esquema abaixo para construir as expressões seguintes.00.00. Linguagem de Definição de dados – SQL DDL 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). 1. com um salário= R$100. 4. usando a linguagem SQL. PESSOAS (codigoPessoa. todos os moradores de Vitória 4. a estrutura física de armazenamento de cada relação no disco. 5. Todas as pessoas que moram em Colatina e trabalham na empresa “Campana” deverão se mudar para Vitória. o conjunto de índices a ser mantido para cada relação. Obs: As pessoas serão remanejadas. codigoEmpresa. Serão contratados com salário = R$200.2. 2. mas também de informações sobre cada relação. Exclua todas as pessoas que possuem salário = R$1000. 3. nomeEmpresa. Faça comando(s) SQL para efetuar tal transação. salario) codigoPessoa referencia Pessoas codigoEmpresa referencia Empresas Observação: estas atividades foram elaboradas para exercitar os comandos de atualização.00. chefe) Chefe referencia PESSOAS EMPRESAS (codigoEmpresa. Uma determinada empresa de código “xyz” quer contratar todos que moram em Vitória e estão desempregados. cidade. Faça comando(s) SQL para que tal transação seja efetuada. devido aos requisitos do diretor da empresa. Exclua todas as pessoas que trabalham em empresas situadas em Vitória. 7. dando um aumento de salário de 10%. cidade) TRABALHA (codigoPessoa. Inclua na empresa de código “01”. restrições de integridade. Faça um comando SQL para ajustar o salário de todos os funcionários da empresa “Campana” em 5%. o domínio de valores associados a cada atributo.00. incluindo: • • • • • o esquema para cada relação. Desconsidere a integridade referencial dos dados. . 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.

Se o tamanho for variável. conforme veremos adiante. use varchar. 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. esse campo for definido como char(50). usando ou não. em horas. igual a n. . apenas 10 espaços serão alocados. definido pelo usuário. Para remover uma relação de banco de dados SQL. minutos e segundos. An Dn) Em que r é uma relação. O número consiste de p dígitos.. Float(n): número de ponto flutuante com a precisão definida pelo usuário em pelo menos n dígitos. é melhor definir como char... sendo que d dos p dígitos estão à direita do ponto decimal. Varchar(n): cadeia de caracteres de tamanho variável. e se o espaço necessário para alocar um valor para esse campo tiver 10 caracteres. podemos escrever a seguinte expressão SQL. . Time: representa horário. CREATE TABLE r (A1 D1. 2006]: Char(n): cadeia de caracteres de tamanho fixo. A relação criada acima está inicialmente vazia.Tipos de Domínios da Linguagem SQL A linguagem SQL inclui diversos tipos de domínios. Numeric(p. DROP TABLE r Ex. serão alocados os 50 espaços. Ao definir um campo de uma tabela. Int: inteiro (subconjunto finito dos inteiros que depende do equipamento). se ocupar sempre a mesma quantidade de caracteres. Smallint: inteiro pequeno (um subconjunto do domínio dos inteiros que depende do equipamento). Se. O comando insert poderá ser usado para carregar os dados para uma relação. usamos o comando drop table. Se você definir um campo de uma tabela como varchar(50). mês e dia do mês. Uma relação SQL é definida usando a instrução CREATE TABLE. definido pelo usuário. : para excluir a relação Depósitos. no máximo igual a n. por exemplo. que remove todas as informações sobre a relação retirada do banco de dados. Real: números de ponto flutuante cuja precisão depende do equipamento em questão. no entanto.d): número de ponto fixo cuja precisão é definida pelo usuário. conforme lista abaixo [SILBERSCHATZ. Date: calendário contendo um ano (com quatro dígitos). O comando create table inclui opções para especificar certas restrições de integridade.

caso exista outra tabela com chave estrangeira que faça referência à tabela que está sendo excluída. como mostra o exemplo: DROP TABLE Depositos CASCADE Neste caso. recém incluída na relação Clientes: ALTER TABLE Clientes drop column cpf Exemplo de um comando alter table incluindo uma restrição. considera-se não só a Integridade Física dos arquivos portadores do banco de dados. a coluna incluída necessariamente deverá ser NULL. O comando alter table é usado para alterar a estrutura de uma relação existente. Ao alterar a estrutura de uma tabela. a exemplo de chaves primárias e estrangeiras. 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. É facilmente testado pelo .DROP TABLE Depositos Ao excluir uma tabela. Exemplo de um comando alter table excluindo a coluna “cpf”.0) NULL Ao adicionar uma coluna em uma tabela existente. os quais costumam ser classificados da seguinte forma: • Integridade de Domínio. excluir campos existentes ou incluir restrições. É necessário excluir antes a tabela referenciada ou usar exclusão em cascata. se esta tabela possuir registros. Domínio é uma lista de valores que precisa estar associada a todo atributo. caso haja uma tabela que faça referência à tabela Depositos. como também manutenção da qualidade dos dados armazenados em termos de precisão e consistência. esta também será eliminada do banco de dados. Constitui a forma mais elementar de restrição de integridade. São vários os tipos de integridade. é possível incluir novos campos. Exemplo de um comando alter table incluindo uma coluna “cpf” na relação Clientes: ALTER TABLE Clientes ADD cpf NUMERIC(11. ocorrerá erro. a chave primária da relação Clientes: ALTER TABLE Clientes ADD CONSTRAINT PK_Clientes PRIMARY KEY (CodigoCli) Integridade Quando se fala em manter a integridade de dados.

Esse recurso permite a especificação de chaves primárias. 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. A existência de uma chave estrangeira impede que anomalias ocorram em função de alterações executadas no banco de dados. 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. o que se denomina Integridade Referencial. Frequentemente. ao alterar o valor da chave primária referenciada por outras tabelas. Especifica se um campo de uma coluna pode ou não assumir valor nulo. conforme elencadas abaixo: • • • ao incluir uma linha na tabela que contém a chave estrangeira. O único valor diferente desse que é permitido é o valor nulo. Especifica a unicidade dos valores para a chave primária e candidatas. Um subsequente “recurso de aperfeiçoamento de integridade” foi aprovado como uma adição ao padrão. ao excluir uma linha da tabela que contém chave primária referenciada por outras tabelas. candidatas e estrangeiras como parte da instrução create table. 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. o valor inserido tem que fazer parte da tabela em que ela é chave primária. Se não for. • Integridade de Vazio. a cláusula unique da instrução create table inclui uma lista de atributos que compreende a chave candidata. ao se alterar o valor da chave estrangeira. quando for possível. Integridade de Chaves. haverá bloqueio na alteração. • • • a cláusula primary key da instrução create table inclui uma lista de atributos que compreende a chave primária. Não pode permitir que os campos com entrada obrigatória assumam valores nulos. deve-se ter garantia de que o novo valor esteja constante na tabela em que ela é chave primária.sistema cada vez que um novo item de dado é inserido no banco de dados. 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. • • • Implementando Integridade Referencial em SQL A SQL original padrão não incluiu instruções para especificar chaves estrangeiras. . Integridade Referencial.

numeroCont int not null. CHECK (Saldo >=0) ) A cláusula Check garante integridade aos valores dos atributos e pode fazer referência. Existe também a possibilidade de criar as tabelas sem integridade referencial e incluir essa implementação usando a instrução Alter Table. cidadeAg varchar(30) not null. saldo real. . Embora tenhamos incluído a cláusula not null para os campos que compõem a chave primária de cada tabela. PRIMARY KEY (codigoAg. a valores de atributos em outras tabelas. UNIQUE (CPF)) CREATE TABLE Agencias (codigoAg int not null. FOREIGN KEY (codigoAg) REFERENCES Agencias. PRIMARY KEY (CodigoAg)) CREATE TABLE Depositos (codigoAg int not null. não é necessário. cidade varchar(30) not null. codigoCli int not null. nome varchar(30) not null. agências e depósitos para o esquema bancário. PRIMARY KEY (codigoCli). cpf numeric(11. nomeAg varchar(30) not null. A SQL assume que todos os campos chaves (primária) não permitam valores nulos. FOREIGN KEY (codigoCli) REFERENCES Clientes.Criando as relações clientes. inclusive.0) not null.numeroCont). CREATE TABLE Clientes (codigoCli int not null. rua varchar(30) not null.

cidadeAg char(30). que possibilita que um campo tenha seu valor incrementado automaticamente. ‘Vitória’) A primeira agência inserida terá o código igual a um e a seguinte. como mostra o exemplo a seguir: INSERT INTO Agencias (nomeAg. pode ser escrita como se segue: CREATE TABLE Agencias (codigoAg int identity(1. não deve ser passado valor para o código da agência. difere para cada um. implementa a propriedade identity(x. o incremento. implementada pela maioria dos SGBDs disponíveis no mercado.Existe uma propriedade. nomeAg char(30). onde x define o valor inicial e y. porém. O MS SQL Server. No exemplo de criação da tabela Agencias. cidadeAg) VALUES (‘Centro’. As restrições Default e Check serão mais exploradas na disciplina Banco de Dados II. .1) not null. considerando o código da agência como auto incrementável.y). considerando que este valor será gerado pelo sistema. considerando que o valor do incremento foi definido como 1. por exemplo. igual a 2. PRIMARY KEY (codigoAg)) Ao inserir uma agência. A sintaxe.

multa) (codFilme. na tabela “Fitas”. faça comandos SQL DDL padrão para criar as estruturas das tabelas. Não permita valores diferentes de ‘S’ ou ‘N’ nos campos “lancamento”. dtNascimento) Filmes (codFilme. e “dublada”. coeficienteRendimento) codigoCurso referencia Cursos Cursos (codigoC. nomeFilme. codigoCurso. exceto os campos: telefones.: Considere a entrada obrigatória de todos os campos. nomeCliente. vlrLocacao. telefone. Periodo. dtDevolucao. nomeC) Disciplinas (codigoDisc. dtLocacao. lancamento. codigoCurso. numeroFita) referencia Fitas codCliente referencia Clientes Reservas (codfilme. nota) codigoAl referencia Alunos codigoDisc referencia Disciplinas Pre_Requisitos (codigoDiscPos. valor) Obs. situacao) codFilme referencia Filmes codCliente referencia Clientes Classes (codClasse. numeroFita. nomeDisc) codigoCurso referencia Cursos Historico (codigoAl. codClasse) codClasse referencia Classes Fitas (codFilme. dtReserva. codCliente. . dublada) codFilme referencia Filmes Locacoes (codFilme. data de devolução de fitas e valor de multa. nome. numeroFita. nomeAl. dtAquisicao.Atividade 05 Dados os esquemas abaixo. b) Clientes (codCliente. a) Alunos (codigoAl. usando o tipo de dados que melhor se aplique a cada atributo e impondo integridade referencial. codigoDiscPre) codigoDiscPos referencia Disciplinas codigoDiscPre referencia Disciplinas telefone. na tabela “Filmes”. codCliente. codigoDisc.

4. Carlos Alberto.br/%7Efalbo/disciplinas/projeto. 5. Análise de Sistemas Orientada para Objetos. POMPILHO. SILBERSCHATZ. S. Paulo. Acesso em 23 de março de 2009. 2004. 1997. São Paulo: Makron Books. Projeto de Banco de Dados. ed.inf. S.A abordagem EntidadeRelacionamento para Projeto Lógico. Análise Essencial – guia prático de Análise de Sistemas. DATE.REFERÊNCIAS NAVATHE. Bancos de dados: introdução aos sistemas de bancos de dados. 2002. Rio de Janeiro: Campus. Ricardo Almeida. 1990. Christopher. COUGO. J. S. Disponível em http://www. FALBO. 8. . SHLAER.. Porto Alegre: Sagra Luzzato. ed. São Paulo: Campus. Sistema de banco de dados. Rio de Janeiro: Campus. 2005. HEUSER. CHEN. ed.ufes. Rio de Janeiro: Editora Ciência Moderna Ltda. 2006. Elmasri. 1990. Abraham. Projeto de Sistemas – Notas de Aula. Peter. MELLOR. Sistemas de Bancos de dados.html. J. 2004. São Paulo: McGraw-Hill : Newstec. São Paulo: Pearson Addison Wesley. Modelagem Conceitual e Projeto de Banco de Dados. Modelagem de Dados .