apostila - banco de dados i 2011-03 (1)

PROF. CLAUDINETE VICENTE BORGES FERREIRA

BANCO DE DADOS I

SERRA2011

Governo FederalMinistro de EducaçãoFernando Haddad

Ifes – Instituto Federal do Espírito Santo Reitor

Denio Rebello Arantes

Pró-Reitora de EnsinoCristiane Tenan Schlittler dos Santos

Coordenadora do CEAD – Centro de Educação a DistânciaYvina Pavan Baldo

Coordenadores da UAB – Universidade Aberta do Brasil Elton Siqueira Moura Danielli Veiga Carneiro Sondermann

Curso de Tecnologia em Análise e Desenvolvimento de SistemasCoordenação de Curso

Andromeda Gorete Correa de Menezes

Designer InstrucionalAline Freitas da Silva

Professor Especialista/AutorClaudinete Vicente Borges Ferreira

Catalogação da fonte: Rogéria Gomes Belchior - CRB 12/417

F383b Ferreira, Claudinete Vicente Borges

Banco de dados I. / Claudinete Vicente Borges Ferreira. – Vitória: Ifes, 2011.

129 p. : il.

1. Banco de dados. I. Instituto Federal do Espírito Santo.

II. Título.

CDD 005.74

DIREITOS RESERVADOSIfes – Instituto Federal do Espírito Santo Avenida Rio Branco, nº 50 Santa Lúcia - CEP. 29056-255 – Vitória – ES - Telefone: 3227-5564

Créditos de autoria da editoraçãoCapa: Juliana Cristina da SilvaProjeto gráfico: Juliana Cristina e Nelson Torres

Iconografia: Nelson TorresEditoração eletrônica: Duo Translations

Revisão de texto: Esther Ortlibe Faria de Almeida

COPYRIGHT – É proibida a reprodução, mesmo que parcial, por qualquer meio, sem autorização escrita dos autores e do detentor dos direitos autorais.

Olá, Aluno(a)!

É um prazer tê-lo(a) conosco.

O Ifes oferece a você, em parceria com as Prefeituras e com o Governo Federal, o Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas, na modalidade a distância. Apesar de este curso ser ofertado a distância, esperamos que haja proximidade entre nós, pois, hoje, graças aos recursos da tecnologia da informação (e-mail, chat, videoconferência, etc.), podemos manter uma comunicação efetiva.

É importante que você conheça toda a equipe envolvida neste curso: co-ordenadores, professores especialistas, tutores a distância e tutores presen-ciais, porque, quando precisar de algum tipo de ajuda, saberá a quem recorrer.

Na EaD - Educação a Distância, você é o grande responsável pelo sucesso a aprendizagem. Por isso, é necessário que você se organize para os estudos e para a realização de todas as atividades, nos prazos estabelecidos, con-forme orientação dos Professores Especialistas e Tutores. Fique atento às orientações de estudo que se encontram no Manual do Aluno.

A EaD, pela sua característica de amplitude e pelo uso de tecnologias mo-dernas, representa uma nova forma de aprender, respeitando, sempre, o seu tempo.

Desejamos-lhe sucesso e dedicação!

Equipe do Ifes

Fala do Professor

Conceitos importantes. Fique atento!

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

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

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

Reflexão/questionamento sobre algo impor-tante referente ao conteúdo apresentado.

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

ICONOGRAFIA

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

Cap. 1 - CONCEITOS DE BANCOS DE DADOS 9

1.1 Definição 91.2 Objetivos 101.3 Sistemas de arquivos convencionais 111.4 Usuários de banco de dados 121.6 Independência de Dados 141.7 Arquitetura de sistemas de banco de dados 15

1.7.1 Sistemas Centralizados 151.7.2 Sistemas cliente-servidor 151.7.3 Sistemas Paralelos 161.7.4 Sistemas Distribuídos 16

1.8 Modelos de bancos de dados 171.8.1 Modelo em rede 171.8.2 Modelo herárquico 181.8.3 Modelo relacional 191.8.4 Modelo objeto-relacional 201.8.5 Modelo orientado a objeto 20

1.9 Estrutura geral do sistema 211.9.1 Componentes de processamentos de consultas 211.9.2 Componentes para administração do armazenamento de

dados 211.9.3 Outras estruturas de dados 22

1.10 Linguagem de definição de dados (DDL) 231.11 Linguagem de manipulação de dados (DML) 241.12 Projetando bancos de dados 24

Cap. 2 - MODELAGEM DE DADOS 29

2.1 Introdução 292.2 Modelos 292.3 Motivos para construção de modelos 302.4 Modelo de entidades e relacionamentos - E/R 30

2.4.1 Entidades 312.4.2 Atributos 322.4.3 Relacionamentos 36

2.5 Dicionário de dados 452.6 Exemplo de um modelo de dados 462.7 Ferramentas case 482.8 Modelo ER estendido - EER 48

BANCO DE DADOS I

Cap. 3 - PROJETO LÓGICO DE BANCO DE DADOS 51

3.1 Definição 513.2 Estrutura dos bancos de dados relacionais 513.3 Chaves 533.4 Propriedades do modelo relacional 553.5 Tradução do modelo ER para o relacional 56

3.5.1 Relacionamento 1:1 583.5.2 Relacionamento 1:N 593.5.3 Relacionamento 1:N - identificado 593.5.4 Relacionamento N:N 603.5.5 Generalização e especialização 613.5.6 Autorrelacionamento 1:N 633.5.7 Autorrelacionamento N:N 633.5.8 Atributos multivalorados 64

3.6 Exemplo de projeto lógico 653.7 Normalização 66

3.7.1 Primeira forma normal (1FN) 673.7.2 Segunda forma normal (2FN) 673.7.3 Terceira forma normal (3FN) 68

Cap. 4 - LINGUAGENS DE CONSULTA 71

4.1 Definição 714.2 Álgebra Relacional 72

4.2.1 Operações fundamentais 734.2.2 Operações não-fundamentais 88

4.3 SQL 954.3.1 Linguagem de manipulação de dados – SQL DML 964.3.2 Linguagem de definição de dados – SQL DDL 120

REFERÊNCIAS 129

APRESENTAÇÃO

Olá!

Meu nome é Claudinete Borges, responsável pela disciplina Banco de Da-dos I. Atuo como professora do Ifes há cinco anos e já lecionei em ou-tras instituições de ensino superior, como Ufes, UVV e Unilinhares. Sou graduada em Ciência da Computação (1995) e mestre em Informática (2001), ambos pela UFES. Minhas áreas de interesse são Banco de Dados e Engenharia de Software.

Nesta disciplina você conhecerá conceitos de modelagem e de bancos de dados. Os Bancos de Dados são responsáveis por manter a persistência dos sistemas de informações existentes no mercado, o que nos mostra a importância da disciplina em um curso de Análise de Sistemas.

Este material tem como objetivo o de orientá-lo no estudo da disciplina Banco de Dados I, por meio de dicas e sugestões, com destaque aos pontos mais importantes. Aqui você encontrará conceitos com os quais trabalha-remos ao longo do Curso, tendo sido elaborado tomando como referência livros clássicos das áreas correlatas, tais como Abraham Silberschatz, Peter Chen, Carlos Alberto Heuser, Elmasri Navathe e outros. Além destes au-tores, teve a contribuição valiosa da professora e amiga Eliana Caus que muito enriqueceu com suas notas de aula e sugestões. Apesar disso, este material impresso não dispensa a utilização dos livros referenciados na bibliografia, que trazem diversos exemplos adicionais e aprofundamento maior em vários aspectos.

Os conceitos aqui apresentados devem ser bem assimilados, pois servirão de base para a disciplina Banco de Dados II, a ser ofertada no próximo se-mestre, e para sua vida profissional, caso você faça a opção por trabalhar na área de Análise de Sistemas. Foi preparado para você com muito carinho!

Sucesso!!!

Profa. Claudinete Vicente Borges Ferreira

8

Tecnologia em Análise e Desenvolvimento de Sistemas

CONCEITOS DE BANCOS DE DADOS

Olá,

Neste capítulo você terá um primeiro contato com a disciplina Ban-co 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 con-junto 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 associa-dos a um conjunto de programas para acesso a estes dados [SILBERS-CHATZ, 2006]. A figura 1 abaixo representa este conceito de forma gráfica.

10


arquivosinter-

relacionados

conjunto deprogramas

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

Um banco de dados é um conjunto de dados integrados, cujo ob-jetivo é atender uma comunidade de usuários [ HEUSER, 2004].

Um SGBD é um software de caráter geral, usado para ma-nipulação eficiente de grandes coleções de informações estru-turadas 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, me-diando a comunicação entre aplicações e banco de dados e adminis-trando acessos concorrentes;

• possibilitar independência dos dados, poupando ao usuário a neces-sidade de conhecer detalhes de implementação interna, organização de arquivos e estruturas de armazenamento.

Capítulo 1

11

Banco de Dados I

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 di-ferentes 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 siste-mas 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, tor-na-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ên-cia 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á trans-ferido 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 devi-do 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 es-

Conceitos de Bancos de Dados

12


crito 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 vulne-rabilidade 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. Ima-gine 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 conside-rado 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 interfa-ces de aplicações escritas por programadores de aplicações;

Capítulo 1

13

Banco de Dados I

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 (com-piladores) destinadas para esse fim. Utilizando essas ferramentas, cons-troem interfaces para as aplicações, incluindo formulários e relatórios, acessando bancos de dados;

Administrador de Banco de Dados (DBA): usuários mais especia-lizados 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.


14


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.

Os SGBD’s possibilitam aos usuários uma visão abstrata dos da-dos, ou seja, os usuários não precisam saber como os dados são armazenados e mantidos para usá-los.

A figura 2 representa graficamente os níveis listados acima.

Visão 1 Visão 2 Visão n- - -

Nível Lógico

Nível Físico

Figura 2 - Níveis de abstração de dadosFonte: Silberschatz, Korth e Sudarshan, 2006. Adaptação.

1.6 Independência de dados

A independência de dados pode ser definida como a imunidade das apli-cações às alterações feitas, seja no nível físico ou no nível lógico de um banco de dados. O objetivo é alcançar o máximo de independência possível. Pode ser classificada em:

Independência Física de dados: habilidade de modificar o esquema físico, sem a necessidade de reescrever os programas aplicativos. As modificações no nível físico são ocasionalmente necessárias para me-lhorar o desempenho.

Independência Lógica de dados: habilidade de modificar o esquema conceitual, sem a necessidade de reescrever os programas aplicativos. As modificações no nível conceitual são necessárias quando a estrutura lógica do banco de dados é alterada.

Capítulo 1

15

Banco de Dados I

Normalmente, modificações no nível físico visam à melhoria de desempenho, como a criação de índices!

Qual abordagem é mais fácil de ser alcançada: independência física ou lógica de dados? Normalmente, a independência física de dados é mais fácil de ser alcançada do que a lógica. Ao criar um índice, como em uma tabela, as aplicações que referenciam essa tabela de-vem continuar funcionando, a despeito da alteração feita!

1.7 Arquitetura de sistemas de banco de dados

A arquitetura de um sistema de banco de dados está altamente relacio-nada às características do sistema operacional sobre o qual o SGBD será executado [SILBERSCHATZ, 2006].

1.7.1 Sistemas centralizados

Os sistemas centralizados são os executados sobre um único sistema operacional, não interagindo com outros sistemas. Eles podem ter a en-vergadura de um sistema de banco de dados de um só usuário, execu-tado em um computador pessoal ou em sistemas de alto desempenho, denominados de “grande porte”.

1.7.2 Sistemas cliente-servidor

Como os computadores pessoais têm se tornado mais rápidos, mais po-tentes e baratos, há uma tendência de ampliar o seu uso nos sistemas centralizados, por isso terminais conectados a sistemas centralizados estão sendo substituídos por computadores pessoais. Como resultado, os sistemas centralizados atualmente agem como sistemas servidores que atendem a solicitações de sistemas-cliente.

A computação cliente-servidor é um processamento cooperativo de informa-ções de negócio por um conjunto de processadores, no qual múltiplos clientes iniciam requisições que são realizadas por um ou mais servidores centrais.

O termo cliente-servidor é usado para descrever software que é execu-tado em mais de um hardware de modo a realizar uma tarefa do negó-cio. A separação de hardware é a norma em aplicações cliente-servidor, embora algumas pessoas utilizem o termo para descrever diferentes


16


componentes de software se comunicando uns com os outros, ainda que rodando em uma mesma máquina. A distância entre processadores remotos varia desde computadores localizados na mesma sala ou pré-dio, até aqueles localizados em diferentes prédios, cidades ou mesmo espalhados pelo planeta.

Nessa arquitetura, as funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias: front-end e back-end. O back-end gerencia as estruturas de acesso, o desenvolvimento e a otimi-zação de consultas, o controle de concorrência e a recuperação. O front-end consiste em ferramentas como formulários, gerador de relatórios e recursos de interface gráfica. A interface entre o front-end e o back-end é feita por meio de SQL ou de um programa de aplicação.

1.7.3 Sistemas paralelos

Sistemas paralelos imprimem velocidade ao processamento e à CPU, por meio do uso em paralelo de CPU’s e discos.

No processamento paralelo muitas operações são realizadas ao mesmo tempo, ao contrário do processamento serial, no qual os passos do pro-cessamento são sucessivos. Um equipamento paralelo de granulação-grossa consiste em poucos e poderosos processadores (a maioria dos servidores atuais), enquanto um paralelismo intensivo ou de granulação fina usa milhares de pequenos processadores, com capacidade menor de processamento. Computadores paralelos com centenas de processado-res já estão disponíveis comercialmente.

As duas principais formas de avaliar o desempenho de um sistema de banco de dados são pelo throughput e pelo tempo de resposta. O primei-ro diz respeito ao número de tarefas que podem ser executadas em um dado intervalo de tempo. Um sistema que processa um grande número de pequenas transações pode aumentar o throughput por meio do proces-samento de diversas transações em paralelo. Já o tempo de resposta diz respeito ao tempo total que o sistema pode levar para executar uma única tarefa. Um sistema que processa um grande volume de transações pode reduzir o tempo de resposta por meio de processamento em paralelo.

1.7.4 Sistemas distribuídos

Em um sistema distribuído, o banco de dados é armazenado, geografi-camente, em diversos computadores denominados sites. Os computa-dores de um sistema de banco de dados distribuídos comunicam-se com outros por intermédio de vários meios de comunicação, como redes de alta velocidade ou linhas telefônicas.

Capítulo 1

17

Banco de Dados I

As principais diferenças entre os bancos de dados paralelos e os bancos de dados distribuídos são que, nos bancos de dados distribuídos, há a distribuição física geográfica, a administração ocorre de forma separada e há uma intercomunicação menor. Outra grande diferença é que nos sistemas distribuídos distinguimos transações locais (acessa um único computador, em que a transação foi iniciada) e globais (envolve mais de um computador, sendo necessária a participação de um coordenador).

Há diversas razões para a utilização de sistemas de bancos de dados dis-tribuídos, dentre as quais: compartilhamento dos dados (usuários de um local podem ter acesso a dados residentes em outros – por exemplo: ban-cos), autonomia (cada local administra seus próprios dados) e disponibi-lidade (se porventura um SGBD sair do ar, os demais podem continuar em operação). Há, no entanto, algumas desvantagens relacionadas ao seu uso, dentre as quais: custo de desenvolvimento de software, maior possi-bilidade de bugs e aumento do processamento e sobrecarga.

1.8 Modelos de bancos de dados

Os modelos de bancos de dados definem a forma como os dados encon-tram-se organizados internamente. Em ordem cronológica, os modelos de banco de dados classificam-se em redes, hierárquicos, relacionais, objeto-relacionais e orientados a objetos. A seguir, há uma breve des-crição sobre cada um desses modelos.

1.8.1 Modelo em rede

Um banco de dados em rede consiste em uma coleção de registros que são concatenados uns aos outros por meio de ligações. Um registro é, em muitos aspectos, similar a uma entidade no modelo entidade-rela-cionamento. Uma ligação é uma associação entre dois registros. Assim, uma ligação pode ser vista como um relacionamento binário no modelo ER [SILBERSCHATZ, 2006].

Tanto o Modelo Rede como o Modelo Hierárquico podem ser consi-derados como estruturas de dados em nível lógico mais próximo do nível físico. Devido a essa proximidade ao nível físico, as estruturas de dados rede e hierárquica exibem as rotas lógicas de acesso de da-dos de forma acentuada, possibilitando a localização lógica de um determinado registro no banco de dados.

O Modelo Relacional, quando comparado à Estrutura Rede e Hierárqui-ca, é mais orientado para modelagem do que como modelo com rotas de


18


acesso, embora possamos considerar as diversas redundâncias existen-tes em diversas tabelas como sendo uma forma de rota de acesso.

O Modelo Rede utiliza como elemento básico de dados a ocorrência de registro. Um conjunto de ocorrência de registro de um mesmo tipo determina um tipo de registro.

Um conjunto de tipos de registros relacionados entre si, por meio de re-ferências especiais, forma uma estrutura de dados em rede. As referên-cias especiais são conhecidas como ligações, que, por sua vez, podem ser implementadas sob a forma de ponteiros.

As referências estão normalmente inseridas junto com as ocorrências de registro; assim, todo o acesso a um próximo registro utiliza o ponteiro inserido no registro corrente disponível.

Considere um banco de dados com registros de DEPARTAMENTO e EMPREGADO, em que EMPREGADO possui as seguintes característi-cas: matrícula, nome e cidade; e DEPARTAMENTO: código e nome. A figura 3 mostra um exemplo do banco de dados, considerando os dois tipos de registros informados.

102 Gabriel Serra

01 Informática

02 Geografia

03 Português

100 Luiza Vitória101 Matheus Vila Velha

103 Joana Aracruz

Figura 3 - Exemplo de Banco de Dados – Modelo Redes.

O modelo de banco de dados da Figura 3 mostra as ligações entre os registros de departamento e empregado. Luiza, por exemplo, está lotada no Departamento de Informática, enquanto o Departamento de Geogra-fia, por exemplo, possui dois funcionários lotados, Matheus e Gabriel.

1.8.2 Modelo hierárquico

Um banco de dados hierárquico consiste em uma coleção de registros relacionados, uns aos outros, por meio de ligações, como no modelo em redes. A diferença entre eles se dá pelo fato de o banco de dados hierárquico organizar esses registros como coleções de árvores, em vez de grafos arbitrários.

Um banco de dados hierárquico compõe-se de um conjunto ordenado

Capítulo 1

19

Banco de Dados I

de árvores, mais precisamente, de um conjunto ordenado de ocorrências múltiplas de um tipo único de árvore.

O tipo árvore compõe-se de um único tipo de registro “raiz”, juntamen-te com um conjunto ordenado de zero ou mais (nível inferior) tipos de sub-árvores dependentes. Um tipo de subárvore, por sua vez, também se compõe de um único tipo de registro. A associação entre tipos de registros segue uma hierarquia estabelecida por diversos níveis. No pri-meiro nível, o superior, situa-se o tipo de registro “Raiz” . Subordinado a ele, em nível 2, uma série de outros tipos de registros em nível 2. A cada tipo de registro em nível 2 subordina-se um outro conjunto de ti-pos de registros. A própria estrutura hierárquica define as suas rotas de acesso, facilitando, portanto, a manutenção do banco de dados.

É importante notar que um determinado tipo de registro B, num deter-minado nível K, possui ligação com um e somente um tipo de registro A, de nível K-1 (superior). Nessas condições, A é denominado registro PAI de B, que, por sua vez, é registro FILHO de A . No entanto, um tipo de registro A pode estar ligado a diversos filhos no nível de B. Todas as ocorrências de um dado tipo de filho que compartilham uma ocorrência de pai comum são chamadas de gêmeas.

Uma vantagem dos bancos de dados hierárquicos é o tempo de resposta em consultas. No entanto, a atualização pode ser bastante custosa. A figura 4 abaixo ilustra um exemplo do modelo Hierárquico.

01 Informática01 Informática

100 Luiza Vitória

01 Informática02 Geografia

03 Português

102 Gabriel Serra

101 Matheus Vila Velha

103 Joana Aracruz

Figura 4 - Exemplo de Banco de Dados – Modelo Hierárquico.

1.8.3 Modelo relacional

O modelo relacional, diferentemente dos modelos redes e hierárquico, usa um conjunto de tabelas para representar tanto os dados quanto a re-lação entre eles. As ligações entre as tabelas é feita por meio dos valores dos atributos ou colunas, conforme descrito posteriormente. Cada tabe-la possui múltiplas colunas e pode possuir múltiplas linhas. As tabelas 1 e 2 abaixo mostram exemplos de Tabelas do modelo relacional.


20


Tabela 1 - Tabela EMPREGADOS

Matricula Nome Cidade CodDepto01 Maria Vitória 0102 Matheus Vila Velha 0203 Gabriel Serra 0204 Joana Aracruz 03

Tabela 2 - Tabela DEPARTAMENTOS

CodDepto NomeDepto01 Informática02 Geografia03 Português

1.8.4 Modelo objeto-relacional

O modelo objeto-relacional, também conhecido como relacional es-tendido, é um modelo intermediário entre o relacional e o orientado a objetos. Na verdade, os bancos de dados que se enquadram nesse mo-delo caracterizam-se por usar a estrutura básica do modelo relacional, incorporando algumas características dos bancos de dados orientados a objetos. Estas características incluem : herança de tipos e tabelas e definição de novos tipos complexos. A SQL-99 inclui recursos para dar suporte a esse modelo de banco de dados.

1.8.5 Modelo Orientado a Objeto

O modelo relacional, hierárquico e redes foram muito bem sucedidos no desenvolvimento da tecnologia de banco de dados necessária para a maioria das aplicações convencionais de bancos de dados comerciais, possuindo, entretanto, algumas limitações quando aplicações mais com-plexas precisam ser projetadas e implementadas, tais como sistemas de informações geográficas e multimídias. Essas aplicações têm requisitos e características que as diferenciam das tradicionais aplicações comer-ciais, tais como estruturas complexas para objetos, armazenamento de imagens e textos longos, dentre outras, além da necessidade de definir operações não convencionais [NAVATHE, 2005].

A abordagem orientada a objetos oferece a flexibilidade para lidar com alguns desses requisitos, sem estar limitada pelos tipos de dados e lin-guagens de consulta disponíveis em sistemas de banco de dados tra-dicionais. Nesses bancos, o projetista especifica a estrutura de objetos complexos bem como as operações que incidem sobre esses objetos.

Capítulo 1

21

Banco de Dados I

Outra razão para o uso de banco de dados orientados a objetos é a predo-minância das linguagens orientadas a objetos. No caso de uma aplicação orientada a objetos utilizar um banco de dados relacional para persistir os dados, é necessário fazer um mapeamento entre esses dois mundos, o que dá trabalho, considerando as limitações impostas pelo modelo relacional.

Embora existam muitos benefícios para a adoção do modelo orientado a objetos, esses bancos de dados não foram muito bem aceitos no mer-cado em função da simplicidade do modelo relacional. Com isso, há uma proposta de um modelo híbrido, denominado objeto-relacional ou relacional estendido, que se propõe a implementar alguns conceitos de orientação a objetos sobre a estrutura de um banco de dados relacional. Alguns SGBD´s proprietários e livres disponíveis no mercado enqua-dram-se nesse modelo, a exemplo do Oracle e do PostgreSQL.

1.9 Estrutura geral do sistema

O sistema de banco de dados é dividido em módulos específicos, de modo a atender a todas as suas funções, algumas delas fornecidas pelo sistema ope-racional. Esses módulos podem ser organizados em dois grandes grupos: o de processamentos de consultas e o de administração do armazenamento de dados. A Figura 5 mostra como esses componentes se relacionam.

1.9.1 Componentes de processamentos de consultas

Compilador DML: traduz comandos DML da linguagem de con-sulta em instruções de baixo nível, inteligíveis ao componente de execução de consultas.

Interpretador DDL: interpreta os comandos DDL e registra-os em um conjunto de tabelas que contêm metadados, ou seja, “dados sobre dados”.

Componentes para o tratamento de consultas: executam instruções de baixo nível geradas pelo compilador DML.

1.9.2 Componentes para administração do armazena-mento de dados

Gerenciamento de autorizações e integridade: testa o cumprimento das regras de integridade e a permissão ao usuário no acesso aos dados.

Gerenciamento de transações: garante que o banco de dados perma-necerá em estado consistente, a despeito de falhas no sistema, e que


22


as transações concorrentes serão executadas sem conflitos em seus procedimentos.

Gerenciador de arquivos: gerencia a alocação de espaço no armazena-mento em disco e as estruturas de dados usadas para representar essas informações armazenadas em disco.

Gerenciador de buffer: intermedia os dados entre o disco e a memória principal e decide quais dados colocar em cachê.

1.9.3 Outras estruturas de dados

Diversas outras estruturas de dados são requeridas como parte da im-plementação do sistema físico, incluindo:

Arquivo de Dados: armazena o banco de dados.

Dicionário de Dados: armazena informações sobre os dados do banco de dados.

Índices: permite o acesso mais rápido aos dados.

Estatísticas: armazenam informações sobre o banco de dados e são usadas pelo seletor de estratégias.

Capítulo 1

23

Banco de Dados I

Usuários Leigos(caixas, agentes,usuários da Web)

Interfaces deaplicação

Compitaldor elinkeditor

Programadoresde aplicação

Usuáriosavançados(analistas)

Administrador debanco de adados

Programas deaplicação

Ferramentade consulta

Ferramentas deAdministração

Consultas deDML

Interpretadorde DDL

Código de objetos doprograma de aplicação

Gerenciador debuffer

Dados

Gerenciador dearquivos

Gerenciador deautorização eintegridade

Gerenciador detransação

Indices Dicionário de dados

Dados estatísitcos

usa escreve

Processador de consulta

Gerenciador de armazenamento

usa usa

Mecanismo de avaliaçãode consulta

Compilador e organizadorde DML

Armazenamento de disco

Figura 5 - Estrutura Geral do SistemaFonte: Silberschatz, Korth e Sudarshan, 2006. Adaptação.

1.10 Linguagem de definição de dados (DDL)

Contém a especificação dos esquemas dos bancos de dados. O resultado da compilação de uma consulta de definição de dados (DDL) é armazenado em um conjunto de tabelas que constituem um arquivo especial chamado dicionário de dados. Um dicionário de dados é um arquivo de metadados.

Principais comandos SQL-DDL: CREATE TABLE; ALTER TABLE; DROP TABLE; CREATE INDEX; ALTER INDEX; DROP INDEX;


24


1.11 Linguagem de manipulação de dados (DML)

A linguagem de manipulação de dados (DML) é a linguagem que viabi-liza o acesso aos dados ou a sua manipulação de forma compatível com o modelo de dados apropriado.

São responsáveis pela:

• recuperação da informação armazenada no banco de dados (SELECT);• inserção de novos dados nos bancos de dados (INSERT);• eliminação de dados nos bancos de dados (DELETE);• modificação de dados armazenados no banco de dados (UPDATE).

Os comandos DDL são responsáveis por definir as estruturas dos dados, enquanto os comandos DML são responsáveis por mani-pular os dados armazenados nessas estruturas!

1.12 Projetando bancos de dados

Antes de criarmos o banco de dados propriamente dito, devemos iden-tificar uma forma de planejá-lo. Esse planejamento é extremamente im-portante para a estabilidade de todo o sistema. Estudos indicam que quanto maior o tempo gasto no projeto do banco de dados, menor será o tempo despendido na manutenção do modelo.

Podemos comparar a criação de um sistema de banco de dados com a cons-trução de uma casa. Imagine que seja construída uma casa sem que antes tenha sido feito um projeto de arquitetura, incluindo plantas baixas, cortes e fachadas. Provavelmente, no futuro, ao submeter essa casa à manutenção, o proprietário teria o inconveniente de construir quartos do lado da cozinha ou mesmo ter que fazer “puxadinhas” para realizar a ampliação da mesma. O mesmo acontece com sistemas mal-projetados ou não-projetados. Eles tornam-se pouco flexíveis a manutenções futuras, quando for necessário agregar novas informações, ou mesmo quando submetidos a correções.

O processo de projetar um banco de dados inclui três fases distintas e integradas. A primeira delas consiste na construção de um modelo con-ceitual. O Modelo Conceitual inclui características a serem incluídas no sistema, mas que independem da tecnologia a ser utilizada, tanto de banco de dados quanto de linguagem de programação. A segunda fase pressupõe a construção de um modelo lógico, tendo como base o Mode-

Capítulo 1

25

Banco de Dados I

lo Conceitual criado e inclui a definição de tabelas, campos, restrições de integridade, etc. Neste modelo, considera-se a tecnologia do banco de dados a ser usado, como: relacional, orientado a objetos, etc. A ter-ceira fase, que extrapola a fase de projeto, consiste na criação física do banco de dados, tendo a preocupação com estruturas de armazenamento e recuperação dos dados a serem armazenados. Nos capítulos que se seguem serão explorados a modelagem conceitual e o projeto lógico de banco de dados, considerando o modelo relacional.

ATIVIDADE 1

Faça os exercícios de fixação abaixo, referentes ao capitulo 1.

1) Defina SGBD´s.

2) Cite duas desvantagens do uso de sistemas de arquivos em relação a SGBD´s.

3) Defina uma vantagem de se usar sistemas de arquivos em relação a SGBD.

4) Cite as quatro arquiteturas de banco de dados existentes no mercado. Descreva, em poucas linhas, as características de cada uma delas.

5) Quais são os níveis de abstração proporcionados por um SGBD? Enquadre, para cada grupo de usuário abaixo listados, o nível em que o mesmo se encontra.

a. Administrador de Banco de Dadosb. Usuário de aplicaçõesc. Programador e Analista de Aplicações

6) Liste, em ordem cronológica, os modelos de bancos de dados existentes no mercado. Qual modelo de banco de dados será utili-zado em nossa disciplina?


26


ATIVIDADE 2

1) Dadas as relações abaixo, responda ao que se pede.

Funcionários

matricula nome CPF cargo01 Ana 123 202 Maria 234 103 José 245 304 Pedro 125 105 Joana 435 206 João 467 1

Cargos

codigo nomeCargo01 Programador02 Topógrafo03 Engenheiro04 Pedreiro05 Motorista

Liste os nomes dos funcionários para os seguintes cargos: Topó-grafo; Engenheiro; Programador.

Para quais cargos não há funcionários lotados?

2) Informe se cada uma das consultas abaixo será executada pelo Compilador DML ou pelo Interpretador DDL.

a) create table...

b) create view...

c) insert into tabela...

d) alter table...

e) delete from tabela...

f) update tabela set campo 1 = valor 1, campo2 = valor2...

Capítulo 1

27

Banco de Dados I

ATIVIDADE 3

1) Numere a segunda coluna de acordo com a primeira.

1. Possibilidade de erros de acesso concorrente

( ) Refere-se à precisão ou validade dos dados.

2. Abstração de dados ( ) Tarefa de um SGBD.

3. Integridade ( ) Se alterar o esquema conceitual, não é necessário reescrever aplicações.

4. Instância( ) Responsável pela modi-ficação de dados armazena-dos no banco de dados.

5. Independência lógica de dados

( ) Se alterar o esquema físi-co, não é necessário reescrever aplicações.

6. Independência física de dados

( ) Contém a especificação dos esquemas de banco.

7. Controle de concorrência

( ) Conjunto de informações contidas em determinado banco de dados, em um deter-minado momento.

8. Linguagem de Definição de Dados (DDL)

( ) Trata-se de um modelo de banco de dados.

9. Linguagem de Manipulação de Dados (DML)

( ) Os usuários não precisam saber como os dados são arma-zenados e mantidos.

10. Objeto-Relacional ( ) Desvantagem de sistemas de arquivos.

O objetivo deste capítulo foi de introduzir conceitos de bancos de dados. São conceitos importantes que servirão de base para enten-dimento dos conceitos explorados nos capítulos subseqüentes.


28


Olá!

Neste capítulo você estudará conceitos de modelagem conceitual de dados. Um modelo conceitual objetiva modelar os requisitos de ne-gócio segundo a visão do usuário, ou seja, independentemente de tecnologia. Trabalharemos, com especial destaque, com o Modelo de Entidade e Relacionamentos (ER).

Bom estudo!

Profª Claudinete Vicente Borges

2.1 Introdução

O principal objetivo da modelagem conceitual de dados é construir mo-delos que representem os requerimentos das informações do negócio, segundo a perspectiva do usuário. Partindo desse princípio, ao cons-truir modelos conceituais não há uma preocupação com a tecnologia a ser adotada para a sua implementação. Um modelo de dados consis-te em uma coleção de ferramentas conceituais para descrição de da-dos, relacionamento entre os dados, semântica e restrições [SILBERS-CHATZ,2006]. Neste capítulo, exploraremos o modelo de entidades e relacionamentos (ER) para construção de modelos de dados, conside-rando que se trata da técnica de modelagem mais difundida para repre-sentação de modelos conceituais.

2.2 Modelos

Um modelo é a representação abstrata e simplificada de um sistema real, com a qual se pode explicar ou testar o seu comportamento, em seu todo ou em parte. Observe que, nessa definição, não estamos condicionando que o modelo seja computadorizado. Qualquer ambiente do mundo real é passível de ser modelado, já que o mesmo busca expressar o objeto observado algumas vezes, mesmo antes da existência física, tangível de tal objeto. Seguem alguns exemplos de modelos:

MODELAGEM DE DADOS

30


• as plantas de apartamentos dos jornais;• o manequim da vitrine;• um aeromodelo sendo usado para testes de aerodinâmica;• o desenho em perspectiva de uma nova cozinha;• o molde de uma roupa obtido em uma revista.

O importante, contudo, é perceber que através de algum meio, seja uma maquete, desenho ou descrição, pode-se antecipar ou substituir a exis-tência de uma realidade qualquer.

2.3 Motivos para construção de modelos

Segundo Cougo [COUGO,1997], os principais motivos para elaborar-mos modelos são:

• focalizar características importantes de sistemas, deixando de lado as menos importantes;

• discutir alterações e correções nos requisitos do usuário a baixo cus-to e com mínimo risco;

• confirmar que o ambiente do usuário foi entendido;• representar o ambiente observado;• servir de instrumento de comunicação;• favorecer o processo de verificação e validação;• capturar aspectos de relacionamento entre os objetos observados;• servir de referencial para a geração de estruturas de dados.

2.4 Modelo de entidades e relacionamentos - E/R

O modelo ER é uma técnica de modelagem conceitual utilizada para re-presentar os dados a serem armazenados em um sistema de informação, tendo sido desenvolvida originalmente para dar suporte ao projeto de ban-cos de dados [CHEN,1990]. Esse modelo foi criado em 1976 por Peter Chen e pode ser considerado como padrão para a modelagem conceitual.

Basicamente, o modelo ER representa as entidades (coisas) e os relacio-namentos (fatos) do mundo real, em que há o interesse de monitorar o comportamento no sistema de informação em tese.

Capítulo 2

31

Banco de Dados I

2.4.1 Entidades

Entidades são representações abstratas de “coisas”, “objetos” do mundo real modelado, para os quais temos interesse em manter informações no banco de dados. Podem representar tanto objetos concretos quanto abstratos. Quando se trata de conjuntos de objetos com características semelhantes, usualmente se denomina conjunto de entidades. Por exem-plo: quando nos referimos ao conjunto de entidade “Departamentos”, estamos falando de um conjunto de departamentos; quando nos referi-mos ao departamento de informática, estamos falando da entidade, de uma instância do conjunto.

Um conjunto de entidades será representado por meio de um retângulo contendo o nome do conjunto de entidades, em letra maiúscula e no plural, conforme mostra exemplo da Figura 6.

A frase “...para os quais temos interesse em manter informações no ban-co de dados...” do parágrafo acima, significa dizer que um conjunto de entidades que é relevante para um determinado contexto pode não ser para outro. O foco é incluir no modelo apenas aqueles conjuntos de en-tidades que são de interesse para o contexto em questão. Por exemplo: considerando um sistema para uma biblioteca, não há porque modelar as cadeiras como um conjunto de entidades. Agora, se tratarmos de um sistema para controle de patrimônios, as cadeiras são alvo de controle, sendo, então, modeladas como Conjunto de entidades.

Ex: FUNCIONÁRIOS, CARGOS, PESSOAS ...

FUNCIONÁRIOS CARGOS

Figura 6 - Exemplo de representação de conjunto de entidades

Características dos conjuntos de entidades [FALBO, 2009]:

• são substantivos e perduram no tempo;• cada elemento de um conjunto de entidades só ocorre uma única

vez e a ordenação do conjunto é irrelevante;• a princípio são representados em um conjunto de entidades todos os

elementos do mundo real referidos pelo conjunto. Ex: FUNCIONÁ-RIOS = todos os funcionários de uma empresa;

Modelagem de Dados

32


• para estabelecermos uma padronização, usaremos nomes de con-juntos de entidades sempre no plural e escritos em letras maiúscu-las. No entanto, isso não representa uma regra.

2.4.2 Atributos

A identificação de entidades está diretamente relacionada à necessidade de se armazenar dados (características ou propriedades) a seu respeito. Tais características ou propriedades são denominadas atributos. O papel do atributo é o de descrever características ou propriedades relevantes de um conjunto de Entidades.

Os atributos podem ser representados no diagrama ou em um dicio-nário de dados. Adotaremos esta última abordagem com o intuito de mantermos um modelo mais legível.

Deseja-se que o processo de identificação de atributos alcance um elenco de atributos que sejam completos, fatorados e independentes [SHLAER,1990].

• Completo: “Deve abranger todas as informações pertinentes ao objeto que está sendo definido”. Os atributos devem contemplar todas as características que proporcionem uma perfeita identifi-cação das entidades às quais esteja associado. Assim, ao se defi-nir a entidade PESSOAS, deve-se prever todos os atributos que me permitam caracterizar completamente os elementos (pesso-as) que comporão esta entidade.

Ex.: Entidade: PESSOAS

Atributos: nome, rua, número, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.

• Fatorado: cada atributo deve ser responsável por um aspecto. Não se deve agrupar responsabilidades acessórias aos atributos. Cada parte, cada característica, deve significar um traço, uma particularidade da entidade e não estar agregando um conjunto de informações em um único elemento, em um único atributo.


Atributos: nome, rua, número, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.

Capítulo 2

33

Banco de Dados I

Note que o endereço está fracionado nas suas partes constituintes e não agrupado num único elemento denominado endereço.

• Independente: os valores que um atributo pode receber (domí-nio) devem ser independentes uns dos outros. Isso não significa que não possamos ter atributos distintos com o mesmo domínio. Cada atributo possui um conjunto dos possíveis valores que pode assumir e isso independe dos demais atributos da entidade.


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, é interessante que se distinga alguns elementos adicionais, conforme descritos abaixo. [POMPILHO, 2002]:

• Atributos Monovalorados ou Univalorado: é um atributo que recebe um único valor para cada entidade. São atributos que possuem cardinalidade máxima 1.

Ex.: Entidade: FORNECEDORES

Atributos: código, CNPJ, razão social, logradouro, nú-mero, complemento, cidade, estado, cep

• Atributos Multivalorados: é um atributo que pode assumir vá-rios valores para cada entidade, ao mesmo tempo.


Atributos: telefone(0,n)

Neste caso, um fornecedor pode ter nenhum ou vários telefones.

• Atributos Obrigatórios: é um atributo que obriga a existência de valor para cada entidade.


Atributos: código, cnpj, razão social, logradouro, núme-ro, cidade, estado, cep

Modelagem de Dados

34


• Atributos Opcionais: é um atributo que NÃO obriga a existên-cia de valor para cada entidade. Normalmente são representados no dicionário de dados entre parênteses.


Atributos: (complemento)

• Atributo Composto: são atributos formados por um ou mais atributos, ou seja, são atributos que abrigam uma estrutura de dado. O atributo nome em uma entidade pessoa também pode-rá ser visto como composto se for possível e necessário separá-los nas suas várias partes (primeiro-nome, nome-intermediário, último-nome). Quando não são compostos, os atributos são de-nominados simples.


Atributos: endereço

Os atributos compostos serão representados no dicionário de da-dos em maiúsculo e deverão ser fatorados, como mostra o exem-plo abaixo no qual o ENDERECO é um atributo composto:

FORNECEDORES = codigo + cnpj + razão social + EN-DERECO + telefone(0,n)

ENDERECO = logradouro + número + (complemento) + cidade + estado + CEP

• Atributo Determinante ou Identificador: atributo que identi-fica, de modo único, uma Entidade. Serão sublinhados no dia-grama como forma de distingui-lo dos demais. Há quem já cha-me o atributo identificador de Chave Candidata. Por exemplo: a matrícula de um funcionário pode ser um atributo identificador, considerando que cada funcionário terá uma matrícula única. O atributo nome, no entanto, não pode ser usado para identificar um funcionário, considerando que existem homônimos.


Atributos código

Capítulo 2

35

Banco de Dados I

• Domínio de um atributo: é o conjunto dos possíveis valores que um atributo pode assumir. No domínio de um atributo, especi-ficamos o Formato desse atributo, seu tamanho, os valores es-pecificamente. Por exemplo: um atributo nome para uma classe de entidades PESSOAS poderá ter como domínio uma “cadeia de caracteres”, já o atributo sexo poderá ter como domínio as opções “Masculino” ou “Feminino”.


Atributo: Sexo do Empregado

Domínio: Campo Alfanumérico, 1 caracter, só pode as-sumir os valores “F” e “M”

As figuras 7, 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, que veremos na próxima seção.

FORNECEDORES FORNECIMENTO PRODUTOStelefone

codigo codigo

cnpj nomepreco unt

razaosocial

endereco

rua

logradouro

numero

cidadeestado

cep

complemento

Figura 7 - Notação para Diagrama Entidade-Relacionamento proposto originalmente por Chen

Modelagem de Dados

36


DICIONÁRIOS DE DADOS

FORNECEDORES = + cnpj + razão social + ENDEREÇO + {telefone}PRODUTOS = + nome + preço unitENDEREÇO = RUA + cidade + estado + cepRUA = logradouro + numero + (complemento)

códigocodigo

FORNECEDORES FORNECIMENTO PRODUTOS

Figura 8 - Notação alternativa para Diagrama Entidade-Relacionamento

FORNECEDORES FORNECIMENTO PRODUTOS

telefone (0,n)

codigocodigo

CNPJ nome

preco unit

razaosocial

endereço

rua

logradouro

número

cidadeestado

cep

complemento (0,1)

Figura 9- Outra notação para Diagrama Entidade-Relacionamento

2.4.3 Relacionamentos

Na seção anterior descrevemos atributos de conjuntos de entidades, que são propriedades dos objetos a serem armazenados em um banco de dados. Além dos atributos, os conjuntos de entidades caracterizam-se por relacionar-se com outros conjuntos de entidades, inclusive com elas mesmas. A essas associações denominamos relacionamentos, ou seja, conjunto de associações entre entidades [HEUSER, 2004].

Neste texto adotaremos a seguinte notação: um relacionamento será re-presentado por um losango, com um verbo para indicar a ação e uma seta para informar o sentido de leitura, conforme mostra a Figura 10 abaixo.

Capítulo 2

37

Banco de Dados I

FUNCIONÁRIOS São enquadrados em CARGOS

Figura 10 - Exemplo de representação de relacionamento

A leitura feita para o relacionamento da Figura 10 é “funcionários são enqua-drados em cargos”. Todo relacionamento possui uma leitura inversa; assim, uma outra leitura do relacionamento seria “cargos enquadram funcionários”.

O relacionamento existente entre os conjuntos de entidades funcioná-rios e cargos é um relacionamento binário, pois se trata de uma associa-ção entre dois conjuntos de entidades. Quando o relacionamento envol-ve três conjuntos de entidades é conhecido como ternário.

Outros exemplos de relacionamentos:

• Alunos cursam disciplinas / Disciplinas são cursadas por alunos;• Editoras publicam livros / Livros são publicados por editoras;• Autores escrevem livros / Livros são escritos por autores.

Para facilitar a visualização foi construído um diagrama de ocorrência referente ao modelo ER da Figura 10. Esse diagrama se propõe a mostrar as ocorrências de entidades do conjunto funcionários, representadas por : f1, f2, ..., fn; as ocorrências do conjunto cargos, representadas por : c1, c2, .., cn e os relacionamentos existentes entre as entidades do conjunto de funcionários e de cargos. O funcionário f1 está enquadrado no cargo c1 através do relacionamento r1. O cargo c1, por outro lado, possui os funcionários f1 e f3, nele enquadrados através dos relacionamentos r1 e r3. A figura 11 representa o diagrama de ocorrência supra citado.

f1

r1

r2

r3

r4

r5

r6

r7

c1

c2

c3

f2

f3

f4

f5

f6

f7

FUNCIONÁRIOS

ENQUADRAMENTOS

CARGOS

Figura 11 - Diagrama de ocorrênciasFonte: Heuser, 2004. Adaptação.

Modelagem de Dados

38


Entre duas entidades, podem existir vários tipos de relacionamentos. A Figura 12 mostra os relacionamentos de alocação e de gerência entre os mesmos conjuntos de entidades: FUNCIONÁRIOS e PROJETOS.

Gerenciam

FUNCIONÁRIOS São alocados em PROJETOS

Figura 12 - Entidades com dois tipos de relacionamento

Além disso, uma entidade pode participar de relacionamentos com quaisquer outras entidades do modelo, inclusive com ela mesma, como mostra o relacionamento “chefiam”, na Figura13. Nesse caso, deno-mina-se que há um autorrelacionamento do conjunto de entidades FUNCIONÁRIOS.

Chefiam

Gerenciam

FUNCIONÁRIOS São alocados em PROJETOS

Figura 13 - Exemplo de autorrelacionamento

Cardinalidade de relacionamento

A cardinalidade indica o número mínimo (cardinalidade mínima) e máxi-mo (cardinalidade máxima) de ocorrências possíveis entre dois conjuntos de entidades em um relacionamento. No diagrama de ocorrência da Figura 11, observa-se que um cargo pode enquadrar vários funcionários, enquanto que um funcionário deve ser enquadrado em apenas um cargo.

A Figura 14 mostra a representação de cardinalidade no modelo ER. A leitu-

Capítulo 2

39

Banco de Dados I

ra é feita da seguinte forma: um funcionário é enquadrado em, no mínimo 1 e no máximo 1, cargo enquanto um cargo pode enquadrar no mínimo zero e no máximo n funcionários. N é um número arbitrário. Quando conhece-mos esse número podemos representá-lo, em vez de o determinarmos pela letra N. Para efeito de projeto de banco de dados, o tratamento dado para esse número arbitrário é o mesmo, para qualquer valor maior que 1.

FUNCIONÁRIOS São enquadrados em CARGOS(0,n) (1,1)

Figura 14 - Ilustração do uso de cardinalidade

Observe que, embora pareça pouco natural, a cardinalidade vai anotada do outro lado do relacionamento a que se refere. No exem-plo acima, um funcionário é enquadrado, no máximo, em um car-go e um cargo, por sua vez, pode enquadrar até n funcionários.

O relacionamento “enquadram” é total em relação a FUNCIONÁ-RIOS e parcial em relação a CARGOS. Esse conceito é baseado na cardinalidade mínima do relacionamento. Ele é total em relação a FUNCIONÁRIOS, pois todo funcionário participa do relacionamen-to pelo menos uma vez; e parcial em relação a CARGOS, pois pode existir um cargo que não participe do relacionamento nenhuma vez.

Tipos de Relacionamentos

O tipo de relacionamento é uma classificação baseada na cardinalidade má-xima do relacionamento, podendo ser : 1:1, 1:N, N:1 e N:N. A seguir, serão explorados todos os tipos de relacionamentos sobre um relacionamento exis-tente entre os conjuntos de entidades : FUNCIONÁRIOS E PROJETOS.

Os tipos de relacionamentos podem ser enquadrados em 3 gran-des grupos, e lê-se conforme descrição feita entre parênteses:

1:1 (Um-para-um),

1:N (Um-para-Muitos) e,

N:N (Muitos-para-Muitos).

Modelagem de Dados

40


• 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, Departamento). Nesse caso, podemos dizer que um funcionário pode gerenciar no máximo um proje-to, ou mesmo nenhum, enquanto um projeto só deve ter um gerente. A fi-gura 16 tem uma representação simbólica deste tipo de relacionamento.

FUNCIONÁRIOS Gerenciam PROJETOS(1,1) (0,1)

Figura 15 - Exemplo de relacionamento 1:1

Figura 16 - Representação simbólica do relacionamento 1:1 (um-para-um)

Observe que todo projeto é gerenciado por algum funcionário po-rém, nem todo funcionário gerencia projetos. Esta informação é dada pela cardinalidade mínima do relacionamento.

• 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 relacio-namento Gerenciam, enquanto um Funcionário pode aparecer em um número arbitrário de vezes. Nesse caso, podemos dizer que um funcio-nário pode gerenciar vários projetos, enquanto um projeto só pode ter um gerente (tem que haver pelo menos 1!). A figura 18 tem uma repre-sentação simbólica deste tipo de relacionamento.

Capítulo 2

41

Banco de Dados I

FUNCIONÁRIOS Gerenciam PROJETOS(1,1) (0,n)

Figura 17: Exemplo de relacionamento 1:N

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, podemos dizer que um funcionário pode gerenciar vários projetos, enquanto um projeto pode ter vários gerentes. A figura 20 tem uma representação simbólica deste tipo de relacionamento.

FUNCIONÁRIOS Gerenciam PROJETOS(1,n) (0,n)

Figura 19 - Exemplo de relacionamento N:N

Modelagem de Dados

42


Conjunto simbólicoda entidade FUNCIONÁRIOS

Conjunto simbólicoda entidade PROJETOS

Figura 20 - Representação simbólica do relacionamento N:N (muitos-para-muitos)

Um outro conceito relacionado aos relacionamentos N:N é o de “En-tidade Associativa”, também referenciada por alguns autores, como “Agregação”. Uma Entidade Associativa é uma abstração por meio da qual relacionamentos entre duas entidades são tratados como entidades em um nível mais alto de abstração. Essa “nova entidade”, a associativa, pode, então, relacionar-se com outras entidades do modelo, como mos-tra a Figura 21. Um correntista é uma agregação envolvendo os conjun-tos de entidades Clientes e Contas Correntes.

CLIENTESCONTAS

CORRENTES

CARTÕESMAGNÉTICOS

CORRENTISTAS

(1,N) (0,N)

(1,1)

(0,1)

são emitidos para

possuem

Figura 21 - Exemplo de agregação N:N [Falbo, 2009]

Os exemplos acima mostram os diferentes tipos de relaciona-mentos aplicados a conjuntos de entidades diferentes, porém também se aplicam a autorrelacionamentos.

Capítulo 2

43

Banco de Dados I

Relacionamentos N:N geram Entidades Associativas e, estas, por sua vez, possuem os mesmos privilégios de um conjunto de enti-dades do modelo. Podem ter atributos e relacionar-se com outras entidades do modelo!

• Atributos de Relacionamentos

Assim como as entidades, os relacionamentos também podem ter atri-butos, porém apenas os atributos de relacionamentos N:N são caracte-rizados como atributos de relacionamentos, enquanto os demais podem ser enquadrados em um dos conjuntos de entidades envolvidos no rela-cionamento [FALBO, 2009].

Para os relacionamentos N:N, há um teste que pode ser aplicado para se deduzir se um atributo é de um dos dois conjuntos de entidades ou se é do relacionamento. Tomemos como exemplo o modelo constante na figura 22. Este teste consiste no seguinte: fixa-se um material, como uma impressora, e variam-se os fornecedores desse material. Se o valor do atributo mudar ao variarmos o elemento do outro conjunto de enti-dades, é porque este não é atributo do primeiro conjunto de entidades, no caso MATERIAIS.

O Procedimento análogo deve ser feito, agora, para a outra entidade. Fixando-se um fornecedor e variando-se os materiais temos: A Eletro-city vende uma impressora por R$ 350,00 e um microcomputador por R$ 2.000,00. O fato de o valor do atributo ter variado para a mesma entidade indica que ele não é atributo de FORNECEDORES.

Se não é atributo nem de MATERIAIS, nem de FORNECEDORES, então é um atributo do relacionamento entre os dois conjuntos de entidades.

fornecem

(0,N)

FORNECEDORES MATERIAIS(1,N)

Figura 22 - Exemplo de relacionamento N:N [Falbo, 2009]

• Generalização / Especialização de conjuntos de entidades

Por muitas vezes, incluímos nos modelos ER’s conjuntos de entidades com diversas características em comum, diferenciando apenas em al-gumas delas. Nesse caso, usando o conceito de generalização, pode-se

Modelagem de Dados

44


criar um conjunto de entidades genérico, contendo as características em comum, e especializam-se as demais com características parcialmente distintas. Um exemplo clássico é o de pessoa física em jurídica. Observe que existem várias características em comum entre ambas as pessoas, a exemplo de: nome, endereço e telefone. Uma pessoa física, no entanto, além dessas características comuns, possui: sexo e CPF. Uma pessoa jurí-dica, além dessas características comuns, possui CNPJ e atividade princi-pal. A Figura 23 mostra a representação desse conceito no modelo ER.

CLIENTES

PESS0AS FÍSICASPESSOAS JURÍDICAS

Figura 23 - Exemplo de generalização / especialização

As entidades PESSOAS FÍSICAS e PESSOAS JURÍDICAS herdam as ca-racterísticas de clientes e incorporam outras adicionais, que são peculia-res de cada um. Um cliente pode ser pessoa física, jurídica ou nenhum dos dois, mas toda pessoa física ou jurídica é cliente.

Generalização: entidades de um nível mais baixo de abstração, com características comuns, são agrupadas dando origem a uma entidade de nível mais alto.

Especialização: uma entidade de nível mais alto de abstração é desmembrada em várias entidades de nível mais baixo, com ca-racterísticas parcialmente distintas.

Capítulo 2

45

Banco de Dados I

Entidade Fraca

Um outro conceito referenciado nos modelos ER’s é o de Entidade Fra-ca. Uma entidade fraca é uma entidade que não tem existência própria. Ela só aparece no modelo quando relacionada a outra entidade – inti-tulada como forte –, sendo seus atributos identificadores compostos por, pelo menos, dois campos, sendo um deles um atributo da entidade forte. A Figura 24 mostra um exemplo em que o conjunto de entidades DEPENDENTES é denominada “entidade fraca”. Para a identificação de um dependente é necessário que se tenha informação do sócio. Os rela-cionamentos com essa característica são denominados identificados.

SÓCIOS(1,1) (0,N)

Possuem DEPENDENTES

Figura 24 - Exemplo de entidade fraca

2.5 Dicionário de dados

O Dicionário de Dados é uma listagem organizada de todos os elemen-tos de dados pertinentes ao sistema, com definições precisas para que os usuários e desenvolvedores possam conhecer o significado de todos os itens de dados manipulados pelo sistema.

Em se tratando de Modelos de Dados, essa listagem contém, em ordem alfabética, as entidades e os relacionamentos com atributos de um DER.

Considerando que não há uma padronização sobre a definição de di-cionário de dados, não será explorado neste material uma formulação na representação destes, mesmo por que as ferramentas CASE normal-mente incluem relatórios para geração desses dicionários.

Para complementar os conceitos discutidos até esta seção, indica-mos o livro Projeto de Banco de Dados, de Carlos Alberto Heuser, capítulos 02 e 03.

Modelagem de Dados

46


2.6 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.

“Deseja-se desenvolver um sistema para controlar os resultados de um campeonato de corridas de Fórmula 1. O sistema deverá manter infor-mações sobre as equipes que participam do campeonato. De cada equi-pe deseja-se saber: código e nome. Além disso, é necessário controlar os pilotos que pertencem a cada equipe. De cada piloto deseja-se saber: código, nome, data de nascimento, altura e peso. Ao longo do campeo-nato, um piloto pode pertencer a apenas uma equipe. Uma equipe, por outro lado, poderá ter vários pilotos (sendo este número máximo nor-malmente igual a 02 pilotos), podendo não ter nenhum, em um dado momento. É necessário ter um controle dos países dos atletas (pilotos), dos quais deseja-se armazenar as seguintes informações: uma sigla, o nome e o Hino Nacional. Um piloto sempre representa um país, en-quanto que um país pode ter vários pilotos participando do campeonato ou até mesmo nenhum. Uma equipe também representa um país, en-quanto que um país pode ter várias equipes participando do campeona-to ou mesmo nenhuma. Para cada corrida realizada, é necessário saber a data em que ocorreu, o nome do circuito, a duração em minutos, a relação de pilotos que participaram da prova e a posição que cada um obteve na corrida. Para caracterizar uma corrida é necessário que haja pelo menos 01 piloto habilitado a participar.”

O primeiro passo para construção de um modelo é identificar os ele-mentos do contexto para os quais temos o interesse de manter informa-ções a respeito, ou seja, identificar os possíveis conjuntos de entidades. Se fizermos uma leitura novamente do texto, iremos destacar os seguin-tes conjuntos de entidades: equipes, pilotos, países e corridas. 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”, cabem algumas ob-servações importantes. A primeira diz respeito à “relação de pilotos que participaram da prova”. Observe que esta relação de pilotos não foi in-cluída como um atributo de corrida (verifique no dicionário de dados) e sim como um relacionamento entre corridas. Se incluísse como atributo estaria sendo redundante, considerando que o modelo contempla um conjunto de entidades denominado “Pilotos”. A segunda observação refere-se a “posição que cada um obteve na corrida”, a qual, embora es-teja no texto referenciado quando trata-se da corrida em si, mas esta informação está relacionada ao piloto e a corrida, ou seja, ao relaciona-mento entre estes dois conjuntos de entidades.

Capítulo 2

47

Banco de Dados I

A figura 25 mostra o modelo ER correspondente ao contexto descrito anteriormente.

PILOTOS(0,n) (1,1)

(0,n)

(1,1)(1,1)(0,n)

(0,n)

EQUIPES

PAISESCORRIDAS

participam de

participações

são de

Possuem

São de

(1,n)

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.

Modelagem de Dados

48


Ao construirmos modelos de dados é comum termos dúvida sobre a representação de conjuntos de entidades, como no exemplo a se-guir: se estamos construindo um modelo para uma locadora de ví-deo, a Locadora deverá ser modelada como sendo um conjunto de entidades? Se estamos construindo um modelo para uma Escola, 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, aí sim devemos modelar a locadora como um conjunto de entidades, mas se for apenas uma, não faz sentido. Seria construir um conjunto de entidades para representar uma entidade apenas! O mesmo raciocínio vale para o segundo caso, o da Escola.

2.7 Ferramentas case

Você deve estar se perguntando como desenhar um diagrama ER. Será no Paint ou à mão? A resposta é simples: existem várias ferramentas computadorizadas destinadas a auxiliar na construção de modelos e projetos de bancos de dados, as quais são denominadas ferramentas CASE. Dentre outras, podemos citar Doctor CASE, ERWin e brModelo. Esta última é uma ferramenta desenvolvida sob a orientação do profes-sor Carlos Heuser, professor de Banco de Dados da UFRGS, e encontra-se disponível para download na Internet. Embora seja uma ferramenta simples, permite trabalharmos com a construção de modelos conceitu-ais e lógicos (tratados no próximo capítulo).

2.8 Modelo ER estendido - EER

O modelo ER possui um poder de expressão muito grande, principal-mente quando se trata de modelagem de aplicações convencionais, po-rém alguns recursos são mais bem representados por extensões feitas ao modelo básico. Recursos estes necessários para modelagem de aplicações mais complexas, como Sistemas de Informações Geográficas e CAD.

Vários modelos semânticos de dados têm sido propostos na literatura, sen-do denominados de modelo ER estendidos ou EER. Não há uma notação padrão para representação desses modelos, como ocorre com a UML.

Segundo Navathe Navathe [NAVATHE, 2005], o modelo EER engloba todos os conceitos do modelo ER básico, acrescidos dos conceitos de subclasse e superclasse, especialização e generalização, tipo união e herança de atributo/relacionamento.

Capítulo 2

49

Banco de Dados I

Uma boa leitura para complementar os conceitos tratados nesta se-ção é o livro Sistemas de Banco de Dados, de Esmasri e Navathe, ca-pítulo 4, que descreve uma forma de representação do modelo EER.

Este capítulo teve como objetivo o de apresentar conceitos relaciona-dos com modelagem conceitual de dados. Ressalto que os modelos conceituais representam os requisitos de negócio independente de tecnologia. No capítulo seguinte, trabalharemos com projeto lógico de banco de dados. Para estes, algumas características tecnológicas serão consideradas.

Modelagem de Dados

50


Olá!

Neste capítulo você estudará conceitos de projeto lógico de banco de dados. Um modelo lógico faz uma adequação do modelo conceitual, incluindo restrições tecnológicas, impostas pelo modelo de banco de dados a ser usado. Trata-se de um modelo com maior nível de deta-lhe do que o conceitual.

Bom estudo!


3.1 Definição

Quando construímos um modelo conceitual, focamos apenas no que o usuário deseja, abstraindo da plataforma em que este será implementado. No que se refere aos projetos de Banco de Dados, a preocupação é centra-da em estabelecer de que forma os dados serão armazenados no sistema. Em função do modelo de banco de dados a ser usado, diferentes soluções de projeto devem ser adotadas, ou seja, se o software for implementado em um banco de dados hierárquico, por exemplo, um modelo hierárquico deve ser produzido, adequando-se a modelagem conceitual de dados (ER ou diagrama de classes) a essa plataforma de implementação.

Considerando que o modelo de banco de dados que predomina no mer-cado, atualmente, é o relacional, este capítulo se propõe a discutir con-ceitos de projetos relacionados a esse modelo de bancos de dados.

3.2 Estrutura dos bancos de dados relacionais

O modelo relacional consolidou-se no mercado por ser flexível, de sim-ples compreensão. Está fortemente baseado na teoria matemática sobre relações, daí o nome relacional.

Um banco de dados relacional consiste em uma coleção de tabelas, cada uma das quais com um nome único. Uma linha em uma tabela repre-senta um relacionamento entre um conjunto de valores. Uma vez que

PROJETO LÓGICO DE BANCO DE DADOS

52


essa tabela é uma coleção de tais relacionamentos, há uma estreita cor-respondência entre o conceito de tabela e o conceito matemático de re-lação, daí a origem do nome desse modelo de dados.

Considere a tabela EMPREGADOS – Tabela 3. Ela possui três colu-nas: matrícula, nome e cidade. Seguindo a terminologia do modelo re-lacional, tratamos os nomes dessas colunas como atributos. Para cada atributo há um conjunto de valores permitidos, chamado domínio da coluna em questão. Para o atributo Matricula, por exemplo, o domínio é o conjunto de todas as matrículas de funcionários. Suponha que D1 denote esse conjunto, D2 o conjunto de todos os nomes de pessoas e D3 o conjunto de todas as cidades. Qualquer linha da tabela EMPREGA-DOS consiste necessariamente de uma tupla (v1, v2, v3), em que v1 é a matricula, (isto é, v1 está no domínio D1), v2 é um nome do funcioná-rio e assim por diante. Em geral, um empregado é um conjunto de D1 x D2 x D3.

Tabela 3 - Tabela EMPREGADOS

matricula nome cidade01 Maria Vitória02 Matheus Vila Velha03 Gabriel Serra04 Joana Aracruz

Matematicamente, define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios. Essa definição corres-ponde quase exatamente à definição de uma tabela. A única diferença é que designamos nomes aos atributos, ao passo que matematicamente se usam apenas “nomes” numéricos. Como as tabelas em essência são relações, podemos usar os termos matemáticos relação e tupla no lugar de tabela e linhas, respectivamente.

É possível que tenhamos, em uma mesma tabela, atributos dife-rentes criados sob o mesmo domínio, a exemplo de Endereço de correspondência e Endereço comercial (se existissem nessa tabela EMPREGADOS).

Um valor de domínio que pertence a qualquer domínio possível é o valor nulo, que indica que um valor é desconhecido ou não existe. Por

Capítulo 3

53

Banco de Dados I

exemplo, suponhamos que incluamos o atributo numeroTelefone na ta-bela Empregado, pode ser que um Empregado não possua telefone ou que o seu número seja desconhecido.

3.3 Chaves

É importante especificar como as entidades dentro de um dado conjun-to de entidades podem ser identificadas. Conceitualmente, entidades e relacionamentos individuais são distintos, entretanto, na perspectiva do banco de dados, a diferença entre ambos deve ser estabelecida em termos de seus atributos. O conceito de chaves nos permite fazer tais distinções.

Uma superchave é um conjunto de um ou mais atributos que, tomados coletivamente, permitem identificar, de maneira unívoca, uma entidade em um conjunto de entidades. Considere a inclusão de uma nova coluna na tabela EMPREGADOS, o (CPF) do empregado. Os atributos (matricu-la, nome) e (nome, CPF) são suficientes para distinguir cada elemento do conjunto, podendo ser considerados como superchaves. Da mesma forma, podemos considerar o atributo (CPF) como superchave de empregado. O atributo (nome) não pode ser considerado como superchave, porque algumas pessoas podem ter o mesmo nome. Nosso interesse maior é por superchaves para as quais nenhum subconjunto possa ser uma supercha-ve. Essas chaves são chamadas de chaves candidatas. Das superchaves mencionadas anteriormente, somente (nome, CPF) não poderia ser con-siderada uma chave candidata, visto que o CPF, sozinho, já o é.

Podemos usar o termo chave primária para caracterizar a chave candidata, que é escolhida pelo projetista do banco de dados como de significado prin-cipal para a identificação de entidades dentro de um conjunto de entidades. Quaisquer duas entidades individuais em um conjunto de entidades não podem ter, simultaneamente, os mesmos valores em seus atributos-chave.

Em SGBD’s, apenas os conceitos de chaves primárias e chaves candida-tas 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. Cabe ressaltar que os atributos implementados como “Chave Candida-ta” são atributos possíveis de serem implementados como “Chave Pri-mária”, porém, pode-se criar um atributo extra, como por exemplo um número seqüencial para ser a chave primária da tabela.

Projeto Lógico de Banco de Dados

54


Tabela 4 - Exemplo de atributos chave

Atributos Superchave Chave Candidata Chave Primáriamatricula √ √ √

CPF √ √ √

(CI, UF) √ √ √

(CPF,Nome) √ X X

Em uma mesma tabela pode haver múltiplas chaves candidatas, a exemplo de (matrícula) e (CPF) de EMPREGADOS. No que se refere à chave primária, apenas uma é possível.

Uma chave candidata pode assumir um valor nulo (apenas um, pois do contrário haveria repetição de valores). Uma chave primá-ria não pode assumir valor nulo.

Alguns autores defendem que uma chave primária seja escolhida entre as chaves candidatas de uma tabela. Eventualmente, 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. Particularmente, prefiro adotar essa so-lução. É importante lembrar a todos que o negócio muda e com isso os valores dos atributos também. Uma alteração feita em valores de chaves primárias implica propagação para inúmeras tabelas rela-cionadas, o que pode ser muito custoso.

Um outro conceito de chave, que muito será explorado neste material, é o conceito de chave estrangeira. Uma chave estrangeira é um atributo (ou combinação de atributos) de uma tabela que constitui a chave primária de uma tabela, daí o nome de estrangeira. É a estratégia usada para imple-mentar os relacionamentos dos modelos conceituais. Essa tabela referen-ciada pode ser a própria tabela, para os casos de autorrelacionamento, ou outras quaisquer do modelo. Outras denominações também são usadas para essas chaves, a exemplo de chaves externas e chaves transpostas. A Ta-bela 5 mostra um exemplo de chave estrangeira, o codDepto. Os valores possíveis para essa coluna devem constar na Tabela referenciada por esse atributo, no caso, a de DEPARTAMENTOS. Além desses valores, depen-dendo do modelo de dados, nulo pode ser um valor possível.

Capítulo 3

55

Banco de Dados I

Tabela 5 - Tabela EMPREGADOS, destacando a chave estrangeira (codDepto)

matricula nome cidade codDepto01 Maria Vitória 0102 Matheus Vila Velha 0203 Gabriel Serra 0204 Joana Aracruz 03

Tabela 6 - Tabela DEPARTAMENTOS

codDepto nomeDepto01 Informática02 Geografia03 Português

3.4 Propriedades do modelo relacional

Falbo [FALBO,2009] relaciona as seguintes propriedades do modelo relacional:

• nenhum campo componente de uma chave primária pode ser nulo;• cada célula de uma relação pode ser vazia (exceto de uma chave pri-

mária) ou, ao contrário, conter no máximo um único valor;• a ordem das linhas é irrelevante;• não há duas linhas iguais;• cada coluna tem um nome e colunas distintas devem ter nomes

distintos;• usando-se os nomes para se fazer referência às colunas, a ordem de-

las torna-se irrelevante;• cada relação recebe um nome próprio distinto do nome de qualquer

outra relação da base de dados;• os valores de uma coluna são retirados todos de um mesmo conjun-

to, denominado domínio da coluna;• duas ou mais colunas distintas podem ser definidas sobre um

mesmo domínio;• um campo que seja uma chave estrangeira ou um item transposto só

pode assumir valor nulo ou um valor para o qual exista um registro na tabela em que ela é chave primária.


56


3.5 Tradução do modelo ER para o relacional

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 con-ceituais – no caso o ER. O modelo lógico é um modelo menos abstrato que o conceitual e provê um nível maior de detalhes. Para os diferentes modelos de bancos de dados (redes, hierárquicos, relacionais...) diferen-tes soluções de projetos devem ser adotadas. Assim, este material terá como foco apenas o projeto de banco de dados relacional.

A tradução do modelo ER para o relacional seguirá os seguintes passos:

• mapeamento das entidades e atributos;• mapeamento dos relacionamentos, considerando cada tipo {1:1,

1:N, N:N};• mapeamento de generalizações e especializações;• mapeamento de atributos multivalorados.

Diferentes autores usam diferentes representações para a especifica-ção dos modelos lógicos de bancos de dados relacionais, sendo alguns representados de forma gráfica e outros textuais. A abordagem usada neste material será a de Carlos Heuser [HEUSER,2004], que usa uma notação resumida para definição do esquema, denominado Esquema Relacional, contendo as seguintes informações :

• tabelas que formam o banco de dados;• colunas que compõem cada tabela;• restrições de integridade (no caso, apenas as restrições referentes às

chaves primárias e estrangeiras são representadas).

Para o exemplo das Tabelas 5 e 6 (EMPREGADOS e DEPARTAMEN-TOS), teremos a seguinte representação:

Empregados (matricula, nome, cidade, codDepto)

codDepto referencia Departamentos

Departamentos (codDepto , nomeDepto)

Os atributos sublinhados representam as chaves primárias das tabe-las Empregados e Departamentos, respectivamente. CodDepto é uma chave estrangeira e que referencia a chave primária da tabela Departa-mentos. Para os casos das chaves estrangeiras compostas, a representa-

Capítulo 3

57

Banco de Dados I

ção fica da seguinte forma: (coluna1, coluna2, ... colunaN) referencia <NomeTabela>.

A fim de facilitar o entendimento, serão usados os mesmos exemplos de modelos descritos no capítulo 2 para exemplificar os diferentes tipos de relacionamentos. Consideremos também os atributos abaixo listados para os conjuntos de entidades Funcionários e Projetos, pois a opção foi de não representá-los no modelo ER.

Funcionarios = matrícula + nome + cidade + data de admissão

Projetos = código + nome + data de início

Seguindo os passos para elaboração do modelo conceitual temos, como passo 1, a definição das Tabelas que formam o banco de dados. Via de regra, todo conjunto de entidades gerará uma tabela no banco de dados relacional. As exceções serão tratadas, quando ocorrerem. Com relação à nomenclatura usada na tabela, ela não deve, necessariamente, ser a mesma do conjunto de entidades, considerando que não pode haver espaços em branco e que deve-mos evitar nomes extensos para facilitar o trabalho dos programadores.

No que se refere aos atributos dos conjuntos de entidades, eles devem ser mapeados em colunas das respectivas tabelas, porém, há algumas dire-trizes para definição dessas colunas, conforme especificações a seguir:

• evite usar nomes extensos. Ao fazer referência ao nome de uma co-luna, normalmente escreve-se nomedaTabela.nomedaColuna o que estende ainda mais o nome do atributo;

• considerando que a referência às colunas ocorre do modo acima descrito, não se faz necessário incluir o nome da tabela nos nomes das colunas dessas tabelas. A exemplo da coluna (nome), da tabela PROJETOS, algumas pessoas escrevem Nome_Projeto;

• crie padrões de projeto para dar nomes às colunas, a exemplo de dtAdmissao e dtInicio. Evite usar prefixos diferentes para colunas com mesmo tipo de informação, como: Data_Admissão e dtInicio;

• ao definir a chave primária, escolha a coluna ou combinação des-tas colunas com o menor tipo de dados possível. Sobre os campos chaves, seja chave primária, candidata, seja estrangeira, são criados índices, e esses índices ocupam muito espaço em disco;

• embora devamos evitar redundâncias nos modelos conceituais, a re-dundância, muitas vezes, é útil em um banco de dados por questões de performance. Por exemplo: o valor de um pedido pode ser obtido por meio dos valores dos seus itens, porém, se guardarmos o valor to-tal do pedido como uma coluna na tabela de pedidos, evitamos alguns acessos a disco, melhorando, assim, a performance das aplicações.


58


Notação resumida para especificação de banco de dados relacional:

• tabelas que formam o banco de dados;

• colunas que compõem cada tabela;

• restrições de integridade (no caso, apenas as restrições refe-rentes às chaves primárias e estrangeiras são representadas).

Os relacionamentos do modelo conceitual ER são mapeados em chaves estrangeiras em um banco de dados relacional. Via de regra, para cada relacionamento uma chave estrangeira deve ser criada.

Eu, particularmente, não uso acentuações e cedilhas em nomes de tabelas, colunas ou quaisquer outros objetos de um banco de dados. Com isso, evito transtornos com teclados desconfigurados.

3.5.1 Relacionamento 1:1

Considerando o relacionamento Gerenciam, da Figura 26, a melhor solução de projeto a se considerar é: incluir a chave estrangeira na relação PROJE-TOS, em vez de colocá-la em empregados, derivando o seguinte esquema :

Funcionarios (matricula, nome, cidade, dtAdmissao)

Projetos (codigo, nome, dtInicio, matriculaGerente)

matriculaGerente referencia Funcionários

FUNCIONÁRIOS(1,1) (0,1)

Gerenciam PROJETOS

Figura 26 - Exemplo de relacionamento 1:1

Essa solução foi adotada, considerando-se que todo projeto tem um gerente; porém, nem todo funcionário gerencia um projeto. Ainda assim, se a chave estrangeira fosse criada em Funcionários, não teríamos pro-

Capítulo 3

59

Banco de Dados I

blemas na implementação dessa solução, embora essa não seja a melhor abordagem.Se o relacionamento Gerenciam fosse total em relação a Funcionários e a Projetos, ou seja, se a cardinalidade mínima fosse 1 (um) para ambos, po-deríamos optar por criar uma única tabela contendo todos os atributos.

3.5.2 Relacionamento 1:N

Para os relacionamentos 1:N deve-se criar a chave estrangeira na tabela que representa o conjunto de entidades cuja cardinalidade máxima é 1. No caso da Figura 27, a chave estrangeira deve ser colocada em Projetos, pois cada projeto participa do relacionamento Gerenciam no máximo 1 (uma) vez. O esquema gerado ficaria da seguinte forma:


Projetos (codigo, nome, dtInicio, matriculaGerente)

matriculaGerente referencia Funcionários

FUNCIONÁRIOS(1,1) (0,n)

Gerenciam PROJETOS

Figura 27 - Exemplo de relacionamento 1:N

A criação da chave estrangeira na tabela Funcionários geraria um erro de projeto, considerando que para os funcionários que ge-renciam mais de um projeto todas as informações de funcionários apareceriam de forma duplicada.

3.5.3 Relacionamento 1:N - identificado

Para os relacionamentos 1:N, denominados identificados, como mostra o exemplo da Figura 28, a identificação de um elemento da entidade, dita fraca (DEPENDENTES), requer a identificação da entidade, dita forte (SOCIOS). Resumindo, temos nesses casos a chave estrangeira fa-zendo parte da chave primária da tabela mapeada pela entidade fraca. O esquema gerado ficaria da seguinte forma:


60


Socios (matricula, nome, sexo, dtCadastro)

Dependentes (matricula, numDependente, sexo, dtNascimento)

Matricula referencia Sócios

SÓCIOS(1,1) (0,N)

Possuem DEPENDENTES

Figura 28 - Exemplo de entidade fraca – relacionamento identificado

Nesse caso, apenas o número do dependente não é suficiente para iden-tificá-lo, considerando que diferentes sócios possuem dependentes de número 01, 02, 03, etc.

3.5.4 Relacionamento N:N

Os bancos de dados relacionais não implementam ligações diretas para os relacionamentos N:N, como para os demais tipos de relacionamen-tos: 1:1 e 1:N. Nesse caso, o relacionamento também deve ser mapeado em uma tabela do banco de dados. A chave primária dessa nova tabela deve ser composta, no mínimo, pela chave primária das tabelas relacio-nadas, ou seja, tem-se pelo menos 02 chaves estrangeiras, e elas fazem parte da chave primária da tabela criada. Às vezes é necessário incluir mais um atributo para compor a chave primária da tabela, pois apenas as chaves estrangeiras não são suficientes para identificá-los.

Considere o exemplo da Figura 29, agora com relacionamento N:N. Considere também que o relacionamento Gerenciam possui os seguin-tes atributos : Data de Início de Atividade e Percentual de dedicação.

FUNCIONÁRIOS(1,n) (0,n)

Gerenciam PROJETOS

Figura 29 - Exemplo de relacionamento N:N

O esquema gerado ficaria da seguinte forma:

Capítulo 3

61

Banco de Dados I


Projetos (codigo, nome, dtInicio)

Gerenciam (matricula, codigo, dtInicioAtividade, percDedicacao)

matricula referencia Funcionários

codigo referencia Projetos

Os relacionamentos N:N normalmente visam a geração de histó-rico, assim sendo, é comum encontrarmos um campo “data” como parte da chave primária da tabela derivada da entidade associativa.

3.5.5 Generalização e especialização

Considere a Figura 30 para as discussões que se seguem. Considere também que um cliente possui as seguintes características (atributos ): Código e Nome. Um cliente pessoa física possui, adicionalmente, um CPF e Carteira de Identidade; e um cliente pessoa jurídica possui, adi-cionalmente, um CNPJ e uma atividade principal.

CLIENTES

PESS0AS FÍSICASPESSOAS JURÍDICAS

Figura 30 - Exemplo de generalização / especialização

Para os casos em que há generalização / especialização, há três opções de projeto que podem ser adotadas:


62


Opção 1: criar uma tabela única, fundindo os três conjuntos de entida-des. Nesse caso, os campos oriundos das tabelas especializadas devem ter a possibilidade de assumirem valores nulos. O esquema gerado fica-ria da seguinte forma:

Clientes (codigo, nome, CPF, carteiraIdentidade, CNPJ, atividadePrincipal)

Opção 2: criar uma tabela para cada entidade da especialização, como Pessoas Físicas e Pessoas Jurídicas. Nesse caso, os atributos do conjunto de entidades genérico – Clientes – devem ser incluídos em cada uma das tabelas criadas. O esquema gerado ficaria da seguinte forma:

Clientes_PFisica (codigo, nome, CPF, carteiraIdentidade)

Clientes_PJuridica (codigo, nome, CNPJ, atividadePrincipal)

Opção 3: criar uma tabela para cada conjunto de entidade da hierarquia. Nesse caso, a chave primária das tabelas filhas (pessoas físicas e jurídicas) devem ser chaves estrangeiras e as mesmas do conjunto mais genérico, no caso, de Clientes. O esquema gerado ficaria da seguinte forma:

Clientes (codigo, nome)

Clientes_PFisica (codigo, CPF, carteiraIdentidade)

codigo referencia Clientes

Clientes_PJuridica (codigo, CNPJ, atividadePrincipal)

codigo referencia Clientes

Cada uma das abordagens acima tem vantagens e desvantagens. Ou seja, 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 correspon-dentes à especialização. Por exemplo, em se tratando de pessoa física, não haverá preenchimento de CNPJ e Atividade. Para a opção 02 temos como desvantagem a repetição de atributos comuns aos dois conjuntos de entidades especializados; já para a terceira opção há uma organização maior da estrutura hierárquica, embora possamos ter uma menor performance, se considerarmos as opções anteriores.

Como costumo dizer, não dá para se ter tudo! Eu, particularmente costumo adotar a terceira solução: criar uma tabela para cada con-junto de entidade da hierarquia.

Capítulo 3

63

Banco de Dados I

3.5.6 Autorrelacionamento 1:N

Para os autorrelacionamentos 1:N, como existe um relacionamento en-tre o mesmo conjunto de entidades, deve-se criar a chave estrangeira na única tabela que representa o conjunto de entidades. Nesse caso, deve-se ficar atento em alterar o nome do campo – chave estrangeira –, pois não é possível ter colunas diferentes e com o mesmo nome em uma tabela. A Figura 31 representa um modelo ER com esse tipo de relacionamento. O esquema gerado ficaria da seguinte forma:

Funcionarios (matricula, nome, cidade, dtAdmissao, matriculaChefe)

matriculaChefe referencia Funcionários

Chefiam

FUNCIONÁRIOS

(1,1) (0,n)

Figura 31 - Exemplo de Autorrelacionamento 1:N

3.5.7 Autorrelacionamento N:N

Para os autorrelacionamentos N:N, assim como para os relacionamen-tos N:N tradicionais, cria-se uma nova tabela para mapear o relaciona-mento. Essa tabela terá duas chaves estrangeiras, agora, porém, vindas da mesma tabela. Essas chaves estrangeiras compõem a chave primária da tabela criada. Por isso, o nome de pelo menos um campo deve ser alterado para evitar que haja dois atributos com o mesmo nome em uma mesma tabela. A Figura 32 representa um modelo ER com esse tipo de relacionamento. O esquema gerado ficaria da seguinte forma:

Disciplinas (codigo, nome, ementa)

Pre_Requisitos (codigoDisciplinaPos, codigoDisciplinaPre)

codigoDisciplinaPre referencia Disciplinas


64


codigoDisciplinaPos referencia Disciplinas

DISCIPLINAS

(0,n) (0,n)

São pré-requisitos para

Figura 32 - Exemplo de Autorrelacionamento N:N

3.5.8 Atributos multivalorados

Os atributos multivalorados de conjunto de entidades também devem ser tratados, considerando-se que o modelo relacional não comporta múltiplos valores em uma célula de uma tabela. Para ilustrar, considere-mos que telefone (0,n) seja um atributo multivalorado de Funcionários. Para esses atributos, uma solução de projeto adotada é a criação de uma tabela para cada um deles. Para a tabela criada, deve ser aplicada a mes-ma solução dos relacionamentos 1:N – identificados. Para o exemplo em tese, o esquema gerado ficaria da seguinte forma:


Telefones (matricula, numeroTelefone)

matricula referencia Funcionarios

Nesse caso, não há limites de telefones para um funcionário, tanto pode não haver nenhum, como um ou vários.

Capítulo 3

65

Banco de Dados I

A solução acima adotada para representação de atributos multivalo-rados, embora seja elegante, não é amplamente aceita por projetistas de banco de dados. Considerando que dificilmente se registra um nú-mero grande de telefones para cada pessoa, é costume se criar colunas adicionais na tabela de funcionários para representar esses valores (exemplo : telefone01 e telefone02). Essa solução, quando adotada, visa à melhoria de performance, pois evita junções entre tabelas nas consultas que devem retornar os telefones de funcionários.

3.6 Exemplo de projeto lógico

Tomando como base o estudo de caso usado no Capítulo 2, referente ao campeonato de Fórmula 1, vamos agora gerar o projeto lógico para o mesmo cenário, através da representação de Esquema Relacional.

Observações importantes: Observe que cada conjunto de entidades foi mapeado em uma tabela no Esquema Relacional e que para chaves primárias, aproveitamos os atributos determinantes de cada conjunto de entidades. Para definição das chaves estrangeiras, é necessário ava-liar cada tipo de relacionamento para cada conjunto de entidades do modelo.

Modelo E/R:

PILOTOS(0,n) (1,1)

(0,n)

(1,1)(1,1)(0,n)

(0,n)

EQUIPES

PAISESCORRIDAS

participam de

participações

são de

Possuem

São de

(1,n)

Dicionário de Dados:

EQUIPES = codEquipe + nomeEquipe

PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso


66


PAISES = codPais + sigla + nome

CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito

PARTICIPACOES = posicaoPilotoProva

Esquema Relacional equivalente :

PAISES (codPais, sigla, nome)

EQUIPES (codEquipe , nomeEquipe, codPais)

codPais referencia PAISES

PILOTOS (codPiloto, nomePiloto, dtNascimento, altura, peso, codPais, codEquipe)

codPais referencia PAISES

codEquipe referencia EQUIPES

CORRIDAS (codCorrida, dtCorrida, duracaoProva, nomeCircuito)

PARTICIPACOES (codPiloto, codCorrida , posicaoPilotoProva)

codPiloto referencia PILOTOS

codCorrida referencia CORRIDAS

3.7 Normalização

Uma vez concluído o projeto lógico de banco de dados relacional, com ge-ração do esquema correspondente, deve-se avaliar, para cada tabela, se a projeção foi bem feita. Esse processo de verificação, composto por um con-junto de regras, denomina-se “forma normal”. Há diversas formas normais usadas no processo de verificação; porém, na nossa disciplina, serão explo-radas apenas as três primeiras formas normais, denominadas 1FN, 2FN e 3FN. Normalmente, as formas normais visam a eliminar informações re-dundantes nas tabelas, cujo processo é denominado normalização.

Capítulo 3

67

Banco de Dados I

3.7.1 Primeira forma normal (1FN)

Um banco de dados está na Primeira Forma Normal quando não exis-tem dados repetidos em nenhuma das linhas da tabela.

Segundo DATE (2004), uma relação R existe na primeira forma normal (1FN) se, e somente se, todos os domínios subjacentes contiverem ape-nas valores atômicos.

Para ilustrar esse conceito, tomemos como exemplo a relação Funcioná-rios, com a seguinte definição de esquema:

Funcionarios (matricula, nome, cidade, dtAdmissao, telefones)

No caso dessa relação, nem todos os domínios contêm valores atômicos, como é o caso de telefones. Nesse caso, os valores não atômicos devem estar contidos em uma outra tabela, relacionada à original. Passando pelo processo de normalização (1FN), temos o seguinte esquema:


Telefones (matricula, numTelefone)

matricula referencia Funcionarios

Com isso, as duas tabelas geradas encontram-se normalizadas na pri-meira forma normal.

3.7.2 Segunda forma normal (2FN)

Quando uma tabela possui uma chave composta, suas colunas devem ser dependentes de toda a chave e não de apenas uma parte dela. Caso ocorra essa dependência parcial, dizemos que a tabela viola a segunda forma normal.

Segundo DATE (2004), uma relação R existe na segunda forma normal (2FN) se, e somente se, estiver na (1FN) e todos os atributos não chaves forem dependentes da chave principal.

Exemplo: considere o esquema de uma relação filmes, de um banco de dados de uma locadora de vídeo, com o seguinte esquema:

Filmes (codigoFilme, codigoAtor, titulo, nomedoAtor)

A coluna Título depende somente do código do filme e Nome do Ator, depende somente do Número do Ator. Quase sempre a solução é dividir


68


as colunas em duas tabelas e criar uma terceira tabela que correlacione as linhas das duas tabelas. Nesse caso, geraríamos os seguintes esquemas:

Filmes (codigoFilme, titulo)

Atores (codigoAtor, nomedoAtor)

AtoresFilmes (codigoFilme, 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.

3.7.3 Terceira forma normal (3FN)

Uma tabela encontra-se na Terceira Forma Normal se todas as suas co-lunas dependerem de toda a chave principal e não houver interdepen-dência entre as colunas que não são chaves da tabela.

Segundo DATE (2004), uma relação R existe na terceira forma normal (3FN) se, e somente se, estiver na (2FN) e todos os atributos não chave forem intransitivamente dependentes da chave principal.

Exemplo: considere o esquema modificado da relação filmes de um banco de dados de uma locadora de vídeo com o seguinte esquema:

Filmes (codigoFilme, titulo, categoria, preco)

Suponha que a loja determine o preço dos filmes por categoria: filmes de Terror, Drama e Comédia custam R$2,00; Musicais, R$2,50 e; Lança-mentos, R$3,00. Nesse caso, a coluna Preço dependeria não só da coluna Código do filme, como também da coluna Categoria. Essa tabela não está na Terceira Forma Normal, então a solução seria criar uma tabela adicional para armazenar os valores por categoria do filme. Após nor-malização, os seguintes esquemas são gerados:

Filmes (codigoFilme, titulo,codigoCategoria)

codigoCategoria referencia Categorias

Categorias (codigoCategoria, Preco)

Capítulo 3

69

Banco de Dados I

Com o passar do tempo, você vai adquirindo experiência e não ne-cessitará avaliar mais essas regras para as tabelas projetadas. Mui-tas vezes, usamos essa experiência para construir modelos desnor-malizados, buscando melhoria de desempenho das aplicações. Mais uma vez volto a dizer que tudo tem seu preço! Às vezes, não con-seguimos ter projeto perfeito e alta performance, por isso acabamos abrindo mão de uma coisa para termos o que é mais importante no cenário exposto.

ATIVIDADE 1

Muitas vezes, o DBA se depara com situações em que possui o esquema do banco de dados, porém não tem o modelo conceitual equivalente. Baseado nisso, dada a definição do esquema abaixo, gere o modelo conceitual equivalente (esse processo denomina-se Engenharia Reversa).

Fabricantes (codFab, nomeFab)

Automoveis (codAuto, nomeAuto, preco, codFab)

codFab referencia Fabricantes

Pessoas (codPessoa, nomePessoa)

Vendas (codPessoa, codAuto, dtVenda, valor, cor)

codPessoa referencia Pessoas

codAuto referencia Automoveis


70


ATIVIDADE 2

a) Dada a relação Perifericos, coloquem a mesma na terceira for-ma normal, passo a passo.

Perifericos (codPeriferico, codModelo, noConfig, quantidade, no-meModelo, codCPU, nomeCPU)

As dependências funcionais que existem nesta tabela são as seguintes:

• (codPeriferico, codModelo, noConfig) Quantidade

• codCPU NomeCPU

• codModelo NomeModelo

• codModelo CodCPU

• codModelo NomeCPU

X Y, significa dizer que : Y depende de X

b) Dada a relação PEDIDOS, coloquem a mesma na terceira for-ma normal, passo a passo.

PEDIDOS (numeroPedido, dtPedido, codCliente, nomeClien-te, enderecoCliente, codProduto(1,n), nomeProduto(1,n), valorProduto(1,n), quantidadeProduto(1,n), matriculaEntrega-dor, nomeEntregador, placaVeiculoEntregador)

Este capítulo teve como objetivo o de apresentar conceitos relaciona-dos com projeto lógico de bancos de dados, mais especificamente no que se refere ao modelo relacional. No próximo capítulo trabalhare-mos com linguagens de consultas aplicadas ao este modelo.

Capítulo 3

Olá!

Neste capítulo você terá conceitos de linguagens de consultas for-mais e comerciais para bancos de dados relacionais.

Bom estudo!


4.1 Definição

Uma linguagem de consulta é uma linguagem na qual o usuário re-quisita informações do banco de dados. São classificadas como pro-cedurais e não procedurais. Numa linguagem procedural, um usuário instrui o sistema para executar uma sequência de operações no ban-co de dados a fim de computar o resultado desejado. Numa lingua-gem não-procedural, o usuário descreve a informação desejada, sem fornecer um procedimento específico para obter tal informação.

A Álgebra relacional é uma linguagem de consulta procedural, en-quanto o cálculo relacional é uma linguagem não-procedural. Na-vathe [NAVATHE, 2005] afirma que qualquer expressão escrita em álgebra relacional pode ser representada também no cálculo, dan-do o mesmo poder de expressão para ambas as linguagens. Como o nosso propósito de usar uma linguagem de consulta formal é o de entendermos o que ocorre nos “bastidores” da execução de uma consulta, focaremos apenas na álgebra relacional.

A Linguagem SQL é uma linguagem de consulta comercial, intitula-da padrão pelo comitê ANSI, desde 1986. É uma linguagem decla-rativa, com comandos muito mais amigáveis do que as linguagens formais, embora seja fundamentada nessas linguagens formais (na álgebra e no cálculo).

Nas seções seguintes exploraremos a Álgebra Relacional e a linguagem SQL.

LINGUAGENS DE CONSULTA

72


Uma linguagem de consulta é uma linguagem na qual um usuário requisita informações do banco de dados. São classificadas como procedurais e não procedurais. Álgebra Relacional é uma lingua-gem de consulta formal e procedural. SQL é uma linguagem de consulta comercial e inclui elementos de uma linguagem proce-dural e não-procedural.

4.2 Álgebra relacional

A álgebra relacional é uma linguagem de consulta procedural. Ela con-siste em um conjunto de operações que tomam uma ou duas relações (tabelas) como entrada e produz uma nova relação como saída. Inclui um conjunto de operações, classificadas como fundamentais e não fundamentais.

As operações fundamentais da álgebra relacional são: selecionar, pro-jetar, renomear, (unárias) - produto cartesiano, união e diferença de conjuntos (binárias). Além das operações fundamentais, existem outras operações, a saber: interseção de conjuntos, ligação natural e divisão que são definidas em termos das operações fundamentais. As operações não fundamentais são usadas para simplificar consultas, considerando que uma operação não fundamental engloba operações fundamentais. A Figura 33 mostra uma representação gráfica para cada uma das ope-rações da álgebra.

As operações da álgebra relacional atuam sobre uma ou duas relações, sendo classificadas como unárias ou binárias. As relações unárias rece-bem como argumento apenas uma relação e as binárias recebem duas relações. Caso seja necessário usar mais de duas relações em uma con-sulta, as operações devem ser usadas de forma encadeada. Como o re-sultado de uma consulta da álgebra é uma nova relação, esta pode ser usada como argumento para a próxima operação.

Capítulo 4

73

Banco de Dados I

Figura 33 - Visão geral das operações da Álgebra RelacionalFonte: Heuser, 2004. Adaptação.

4.2.1 Operações fundamentais

Considere o seguinte esquema de banco de dados para exemplos pos-teriores, ao longo deste capítulo. Trata-se de um esquema bancário, composto de quatro tabelas: AGÊNCIAS, CLIENTES, DEPÓSITOS e EMPRÉSTIMOS. Este esquema foi adaptado de Silberschatz [SILBERS-CHATZ, 2006].

Linguagens de Consulta

Ligação (natural)Dividir

Diferença

IntersecçãoUnião

Selecionar Projetar

Produto

a

b

c

a

a

b

b

c

c

x

y

x

y

x

y

x

y

a

a

a

b

c

x

y

z

x

y

x

y

aa1

a2

a3

b1

b2

b3

b1

b2

b3

c1

c2

c3

a1

a2

a3

b1

b1

b3

c1

c1

c3

74


Lembre-se sempre da definição deste esquema “Bancário” para quando a ele nos referirmos ao longo deste capítulo.

AGENCIAS (codigoAg, nomeAg, cidadeAg)

CLIENTES (codigoCli, nome, rua, cidade)

DEPOSITOS (codigoAg,numeroCont, codigoCli, saldo)

codigoAg referencia AGENCIAS

codigoCli referencia CLIENTES

EMPRESTIMOS (codigoAg,numeroEmp, codigoCli, quantia)

codigoAg referencia AGENCIAS

codigoCli referencia CLIENTES

Para facilitar o entendimento das operações da Álgebra Relacional, os esquemas darão lugar à representação em tabelas de valores, con-forme mostra abaixo :

AGENCIAS

codigoAg nomeAg cidadeAg50 Centro Vitória51 Princesa Isabel Vitória52 Praia Vila Velha53 Avenida Viana

CLIENTES

codigoCli nome rua cidade01 Ana Amélia Nasser Vitória02 Lara Das Flores Vitória03 João Champagnart Vila Velha04 José Maira Santos Viana05 Luisa Champagnart Vila Velha06 Lucas Santa Rita Vitória

Capítulo 4

75

Banco de Dados I

DEPOSITOS

codigoAg numeroCont codigoCli saldo50 999 01 100051 991 02 320051 992 03 230053 993 04 1200

EMPRESTIMOS

codigoAg codigoCli numeroEmp quantia51 02 888 200052 03 881 4000

• Operação selecionar

A operação selecionar seleciona tuplas (linhas) em uma relação, que satis-fazem a um dado predicado. É uma operação unária. Usamos a letra mi-núscula grega sigma (σ) para representar a seleção. O predicado aparece subscrito a (σ). A relação argumento (entrada) aparece entre parênteses, seguindo o (σ). A Figura 34 representa graficamente essa operação.

Sintaxe: σ<predicado>(Relação)

A1 B1

A2

A3

A4

B2

B3

B4

R=A=A1 =

A B

A1 B1

A Bσ (R)

Figura 34 - Operação seleção

Usando o esquema exemplo, vamos construir uma consulta para sele-cionar os Clientes que moram em Vitória. Para tanto, escreve-se:

σcidade=”Vitória”(CLIENTES)

A relação resultante da consulta é exibida na tabela 7 abaixo:

Tabela 7 - Relação resultante da seleção sobre CLIENTES.

codigoCli nome Rua cidade01 Ana Amélia Nasser Vitória02 Lara Das Flores Vitória06 Lucas Santa Rita Vitória


76


Observe que a seleção elimina linhas, assim sendo, todas as colu-nas da tabela CLIENTES foram projetadas.

As comparações são permitidas, usando os operadores:

• igual (=);

• diferente (≠);

• menor (<);

• menor ou igual (≤);

• maior ou igual (≥);

e os conectivos:

• e (∧);

• ou (∨).

• Operação Projetar

A operação projetar é uma operação unária que retorna sua relação argu-mento, com certas colunas deixadas de fora. A projeção é representada pela letra grega pi (π). A Figura 35 representa graficamente essa operação.

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

A1 C1

A2

A3

A4

C2

C3

C4

A C

A1 B1

A2

A3

A4

B2

B3

B4

R=A B

A,C =(R)

C1

C2

C3

C4

C

π

Figura 35 - Operação projeção

Usando o esquema exemplo, vamos construir uma consulta para proje-tar os Clientes e as cidades onde moram. Para tanto, escreve-se:

Capítulo 4

77

Banco de Dados I

πnome,cidade(Clientes)

A relação resultante da consulta é exibida na tabela 8 abaixo:

Tabela 8 - Relação resultante da projeção sobre CLIENTES.

nome cidadeAna VitóriaLara VitóriaJoão Vila VelhaJosé VianaLuisa Vila VelhaLucas Vitória

Alterando levemente a consulta acima, agora desejamos encontrar to-dos os nomes de clientes que moram em “Vitória”.

Para realizar esta consulta, devemos fazer uma seleção de todos os clien-tes que moram em Vitória e, em seguida, projetar os seus nomes.

π nome(σclientes.cidade=”Vitória” (CLIENTES))

A relação resultante da consulta é exibida na tabela 9 indicada abaixo:

Tabela 9 - Relação resultante da seleção seguida de projeção sobre CLIENTES.

NomeAnaLaraLucas

Quando houver encadeamento de operações em uma consulta, a ordem de execução destas é da direita para a esquerda. No exem-plo acima, primeiro executa-se a operação de seleção e, depois, sobre o resultado da seleção, aplica-se a projeção.

• Operação Produto Cartesiano

A operação produto cartesiano, representada por (X), é capaz de combi-nar informações a partir de diversas relações. Trata-se de uma operação binária. Essa operação nos mostra todos os atributos das relações envol-vidas no produto. A Figura 36 representa graficamente esta operação.


78


Sintaxe: (Relação1 Χ Relação2)

Figura 36 - Operação produto cartesiano

Cuidado com ambiguidade de nomes de atributos. Quando houver atributos com mesmo nome nas relações usadas em uma consulta é necessário referenciá-los usando o nome da relação antes do nome do atributo a fim de diferenciá-los. Exemplo : Quando se escreve Clien-tes.codigoCli referencia-se à coluna codigoCli da tabela Clientes

Usando o esquema exemplo, vamos construir uma consulta para sele-cionar os nomes de Clientes que possuam empréstimo na agência cujo código é 51. Para tanto, escreve-se:

π Clientes.nome (σEmprestimos.codigoAg=51 ^ Clientes.codigoCli =Emprestimos.codigoCli (CLIENTES X EMPRESTIMOS))

As tabelas 10, 11 e 12 abaixo mostram as relações intermediárias gera-das durante a execução da consulta em ordem cronológica. Cabe ressal-tar que, a ordem de execução da consulta é:

1- Produto cartesiano;

2- Seleção e;

3- Projeção.

Capítulo 4

79

Banco de Dados I

Tabela 10 - Tabela resultante da operação produto cartesiano (CLIENTES X EMPRÉSTIMOS).

Clientes. codigoCli

Clientes.nome

Clientes.rua

Clientes.cidade

Emprés-timos.codigoAg

Emprés-timos.codigoCli

Emprés-timos.numero-Emp

Emprés-timos.quantia

01 AnaAmélia Nasser

Vitória 51 02 888 2000

02 LaraDas Flores

Vitória 51 02 888 2000

03 JoãoCham-pagnart

Vila Velha

51 02 888 2000

04 JoséMaira Santos

Viana 51 02 888 2000

05 LuisaCham-pagnart

Vila Velha

51 02 888 2000

06 LucasSanta Rita

Vitória 51 02 888 2000


Vitória 52 03 881 4000

02 LaraDas Flores

Vitória 52 03 881 4000


Vila Velha

52 03 881 4000


Viana 52 03 881 4000


Vila Velha

52 03 881 4000

06 LucasSanta Rita

Vitória 52 03 881 4000


80


Tabela 11 - Tabela resultante da operação seleção sobre produto cartesiano

σ Emprestimos.codigoAg=51 ^ Clientes.codigoCli =Emprestimos.codigoCli (CLIENTES X EMPRÉSTIMOS).

Tabela 12: Tabela resultante da operação projeção sobre seleção. πClientes.nome (σEmprestimos.codigoAg=51 ^ Clientes.codigoCli =Emprestimos.codigoCli (CLIENTES X EMPRESTIMOS))

Clientes.nomeLara

Após a execução da consulta, a relação resultante é a da tabela 12, ou seja, apenas Lara possui empréstimo na agência 51.

• Operação União (binária)

A operação união de conjuntos, representada por (∪), é uma operação binária que nos permite encontrar tuplas que estão em uma das relações envolvidas. A Figura 37 representa graficamente a operação.

Sintaxe: (Relação1 ∪ Relação2)

A1A1

B1B1

A2A5

A3

A4

B2B5

B3

B4

A AB B

R1 R2

=

R1 R2

A1 B1

A2

A3

A4

B2

B3

B4

A B

A5 B5

Figura 37 - Operação união

Clientes.codigoCli

Clientes.nome

Clientes.rua

Clientes.cidade



Emprés-timos.nu-meroEmp


02 LaraDas Flores

Vitória 51 02 888 2000

Capítulo 4

81

Banco de Dados I

Usando o esquema exemplo, vamos supor que quiséssemos conhecer todas as pessoas que possuam Depósitos ou Empréstimos, ou ambos, numa determinada agência. Nesta situação, devemos fazer a união de todos os clientes que possuam depósitos com todos os que possuam empréstimos nessa agência, como veremos no exemplo a seguir:

Ex. Selecionar todos os clientes que possuam depósitos, empréstimos ou ambos, na agência 51.

πClientes.nome (σDepositos.codigoAg=51 ^ Clientes.codigoCli=Depositos.CodigoCli (CLIENTES X DEPOSITOS))

∪

πClientes.nome (σEmprestimos.codigoAg=51 ^ Clientes.codigoCli =Emprestimos.codigoCli (CLIENTES X EMPRESTIMOS))

Observe que a primeira parte da consulta refere-se às pessoas que pos-suem depósitos na agência 51. A segunda parte refere-se às pessoas que possuem empréstimos na agência 51. O resultado é a união de ambas.

Usando o raciocínio análogo ao exemplo utilizado para a operação pro-duto cartesiano, vamos fazer a primeira parte da consulta. A tabela 13 mostra a relação resultado da consulta.

Tabela 13 - Clientes que possuem depósitos na agência 51

Clientes.nomeLaraJoão

A tabela 14 mostra os clientes que possuem empréstimos na agência 51, que constitui a segunda parte da consulta.

Tabela 14 - Clientes que possuem empréstimos na agência 51

Clientes.nomeLara

Fazendo a união destas duas relações temos como resultado a tabela 15

Tabela 15 - Clientes que possuem depósitos e/ou empréstimos na agência 51



82


Para uma operação União r ∪ s ser válida, é necessário que duas condições sejam satisfeitas:

1. as relações r e s precisam ter a mesma paridade. Isto é, elas pre-cisam ter o mesmo número de atributos e;

2. os domínios do i-ésimo atributo de r e do i-ésimo atributo de s devem ser os mesmos.

Observe que a operação União da Álgebra relacional segue exata-mente os mesmos princípios da união de conjuntos, assim sendo, não há duplicidade de linhas iguais na relação resultante.

• Operação Diferença de conjuntos

A operação diferença de conjuntos, representada por (-), é uma opera-ção binária e nos permite encontrar tuplas que estão em uma relação e não estão em outra. A expressão r - s resulta em uma relação que contém todas as tuplas que estão em r e não em s. A Figura 38 representa grafi-camente esta operação.

Sintaxe: (Relação1 - Relação2)

A1 B1

A2

A3

A4

B2

B3

B4

A B

R1

A1 B1

A3

A5

B3

B5

A B

R2

- =A2 B2

A4 B4

A B

R1 - R2

Figura 38 - Operação diferença de conjuntos

Usando o esquema exemplo, vamos consultar todos os clientes que pos-suam um depósito, mas não possuem um empréstimo na agência 51. Para isto, faremos uma consulta que resulte todos os clientes que pos-suem depósitos na agência 51, e uma segunda consulta resultando todos os clientes que possuam empréstimos na agência 51. O resultado deseja-do é a diferença da primeira menos a segunda relação.

Capítulo 4

83

Banco de Dados I

πClientes.nome(σDepositos.codigoAg=51 ^ Clientes.codigoCli = Depositos.codigoCli (CLIENTES X DEPOSITOS))

-

π Clientes.nome (σEmprestimos.codigoAg=51 ^ Clientes.codigoCli = Emprestimos.codigoCli (CLIENTES X EMPRESTIMOS))

É importante observar que, ao contrário das operações união e intersecção de conjuntos, na operação diferença a ordem das rela-ções é importante, ou seja, r – s é diferente de s – r.

Relembremos que a tabela 16 abaixo (equivalente a tabela 13) contém todos os clientes que possuem depósitos na agência 51, conforme mos-tra abaixo, e a tabela 17 (equivalente a tabela 14) contém todos os clien-tes que possuem empréstimos na mesma agência.




Clientes.nomeLara

Fazendo a diferença destas duas relações, temos como relação resultante a tabela 18, que contém todos os clientes que possuem depósitos mas não possuem empréstimos na agência 51.

Tabela 18 - Clientes que possuem depósitos e não possuem emprésti-mos na agência 51

Clientes.nomeJoão


84


• Operação Renomear

A operação renomear, representada pela letra grega Rô (ρ), é necessária sempre que uma relação aparece mais de uma vez em uma consulta. Ela faz uma cópia da relação original.

Sintaxe: ρ NomeNovo (Relação)

Ex. Encontre todos os clientes que moram na mesma rua e cidade que João.

Para obter a rua e a cidade de João, faça da seguinte forma:

t πrua, cidade (σnome=”João” (Clientes))

A tabela 19 mostra a relação resultante da consulta acima.

Tabela 19 - Relação t contendo rua e cidade onde João mora

Rua CidadeChampagnart Vila Velha

Entretanto, para encontrar outros clientes com essa rua e cidade, deve-mos referir-nos à relação Clientes pela segunda vez. Perceba que inserir novamente uma relação clientes na consulta gerará ambiguidade. Por isso será necessário renomeá-la. A consulta abaixo, além de renomear a relação Clientes para Clientes2, faz em seguida um produto cartesiano com t, que contém a rua e cidade em que João mora.

πcliente2..nome (σClientes.cidade = Clientes2.cidade ^ Clientes.rua = Clientes2.rua ^ Clientes2.nome <> “João” (t X ρClientes2 (Clientes))

Observe que, embora o produto cartesiano na consulta acima te-nha sido feito com t, a seleção referencia clientes e não t.

As tabelas 20, 21, 22, 23 e 24 abaixo mostram, em ordem cronológica, as relações intermediárias geradas no processamento da consulta

Capítulo 4

85

Banco de Dados I

Tabela 20 - Relação CLIENTES

codigoCli nome Rua cidade01 Ana Amélia Nasser Vitória02 Lara Das Flores Vitória03 João Champagnart Vila Velha04 José Maira Santos Viana05 Luisa Champagnart Vila Velha06 Lucas Santa Rita Vitória

Tabela 21: Relação CLIENTES2 resultante da operação ρClientes2 (CLIENTES)

Clientes2.codigoCli

Clientes2. nome

Clientes2.ruaClientes2.cidade

01 Ana Amélia Nasser Vitória02 Lara Das Flores Vitória03 João Champagnart Vila Velha04 José Maira Santos Viana05 Luisa Champagnart Vila Velha06 Lucas Santa Rita Vitória

Tabela 22: Relação resultante da operação produto cartesiano (t X ρCLIENTES2 (CLIENTES))

Clien-tes2.codigoCli

Clien-tes2. nome

Clien-tes2.rua

Clien-tes2.cidade

Clientes. rua

Clientes.cidade


VitóriaCham-pagnart

Vila Velha

02 LaraDas Flores


Vila Velha


Vila Velha

Cham-pagnart

Vila Velha


VianaCham-pagnart

Vila Velha


Vila Velha

Cham-pagnart

Vila Velha

06 LucasSanta Rita


Vila Velha


86


Tabela 23 - Relação resultante da operação seleção

(σclientes.cidade = clientes2.cidade ^ clientes.rua = clientes2.rua ^ clientes2.nome <> “João” (t X ρClientes2 (CLIENTES))

Clien-tes2.codigoCli

Clien-tes2. nome

Clien-tes2.rua

Clien-tes2.cidade

Clientes. rua

Clientes.cidade


Vila Velha

Cham-pagnart

Vila Velha

Tabela 24 - Relação resultante da operação projeção πcliente2..nome ((σclientes.

cidade = clientes2.cidade ^ clientes.rua = clientes2.rua ^ clientes2.nome <> “João” (t X ρCLIENTES2 (CLIENTES))

Clientes2. nomeLuisa

Concluindo, somente Luisa mora na mesma rua e cidade que João.

ATIVIDADE 1

Considere o esquema bancário abordado anteriormente e cons-trua expressões em álgebra relacional para as questões que se seguem.

1. Consultar todos os clientes (nomes) que possuam depósitos.

2. Consultar todos os clientes que possuam depósito na mesma cidade onde moram.

3. Consultar todas as agências que possuam clientes com nome “Maria” (depósitos ou empréstimos).

4. Consultar a conta com maior saldo.

Capítulo 4

87

Banco de Dados I

ATIVIDADE 2

Considere o esquema seguinte para construir expressões, usan-do operações fundamentais da álgebra relacional para as questões que se seguem.

PESSOAS (codigoPessoa, nomePessoa, cidade, chefe)

EMPRESAS (codigoEmpresa, nomeEmpresa, cidade)

TRABALHA (codigoPessoa, codigoEmpresa, salario)

codigoPessoa referencia Pessoas

codigoEmpresa referencia Empresas

5. Consultar todas as pessoas que trabalham. A consulta deverá retornar o nome das pessoas e a cidade onde moram.

6. Consultar o nome das empresas que possuem funcionários que ganham menos que um salário mínimo (considere o valor do sa-lário de R$400,00).

7. Consultar todas as pessoas (nomes) que trabalham em Vitória.

8. Consultar todas as pessoas (nomes) que trabalham na mesma cidade onde moram.

9. Consultar todas as pessoas (nomes) que moram na mesma ci-dade do chefe.

10. Consultar todas as empresas (nomes) que funcionam em cida-des em que não moram Maria.

11. Consultar todas as pessoas (nomes) que não trabalham em Vitória e que ganham acima de R$ 2.000,00.

12. Consultar o nome do funcionário da empresa de código “01” que possui o menor salário.


88


4.2.2 Operações não-fundamentais

Utilizando as operações fundamentais da álgebra relacional pode-mos expressar qualquer consulta. Entretanto, algumas consultas são longas ou complexas demais para serem expressas. Neste caso, o uso das operações não-fundamentais pode reduzir o tamanho e a com-plexidade dessas consultas.

• Operação Intersecção de conjuntos

A operação Intersecção de conjuntos, representada por (∩), é uma operação binária e nos permite encontrar tuplas que estão nas duas relações envolvidas na consulta. Pode ser expressa em função das ope-rações fundamentais da seguinte forma: r ∩ s = r – (r – s). A Figura 39 representa graficamente essa operação.

Sintaxe: (Relação1 ∩ Relação2)

A1 B1

A2

A3

A4

B2

B3

B4

A B

R1

A1 B1

A4 B4

A B

R2

= A1 B1

A4 B4

A B

R1 R2

Figura 39 - Operação Intersecção de conjuntos

Usando o esquema exemplo, vamos consultar todos os clientes que pos-suam depósito e empréstimo na agência 51. Para tanto, escreve-se:

π Clientes.nome (σDepositos.codigoAg=51 ^ Clientes.codigoCli =Depositos.codigoCli (CLIENTES X DEPOSITOS))

∩

π clientes.nome (σEmprestimos.codigoAg=51 ^ Clientes.codigoCli =Emprestimos.codigoCli (CLIENTES X EMPRESTIMOS))

As tabelas 25 e 26 abaixo relacionam respectivamente os clientes que possuem depósitos e os que possuem empréstimos na agência 51.

Capítulo 4

89

Banco de Dados I




Clientes.nomeLara

Se fizermos a intersecção destes dois conjuntos, teremos todos os clien-tes que se encontram nos dois conjuntos, ou seja, apenas Lara possui depósito e empréstimo na agência 51, conforme mostra a tabela 27.

Tabela 27 - Clientes que possuem depósito e empréstimos na agência 51

Clientes.nomeLara

• Operação Ligação natural

A operação ligação natural, representada pelo símbolo (|X|), é uma operação binária que permite combinar certas seleções e um produto cartesiano em uma operação. A operação ligação natural forma um pro-duto cartesiano de seus dois argumentos e faz uma seleção, forçando uma equidade sobre os atributos que aparecem em ambos os esquemas relação. A Figura 40 representa graficamente a operação.

Sintaxe: (Relação1 |X| Relação2)

Figura 40 - Operação Ligação Natural

Usando o esquema exemplo, encontre todos os clientes que têm em-préstimos. Retorne os nomes dos clientes e a cidade em que vivem. Para tanto, escreve-se:


90


π Clientes.nome, Clientes.cidade (EMPRESTIMOS |X| CLIENTES)

As tabelas 28 e 29 mostram, em ordem cronológica, as relações interme-diárias geradas durante o processamento da consulta.

Cabe ressaltar que a relação resultante da ligação natural é baseada no produto cartesiano entre Clientes e Empréstimos, seguida de uma seleção, ligando a chave primária de Clientes com a Chave estrangeira de Em-préstimos. Na tabela 28 destaca-se em vermelho todas as linhas que serão excluídas, restando apenas 2 linhas, referentes aos clientes Lara e João.

Tabela 28 - Tabela resultante da operação Ligação Natural (CLIENTES |X| EMPRESTIMOS).

Clientes.codigoCli

Clientes.nome

Clientes.rua

Clientes.cidade



Emprés-timos.numero-Emp



Vitória 51 02 888 2000

02 LaraDas Flores

Vitória 51 02 888 2000


Vila Velha

51 02 888 2000


Viana 51 02 888 2000


Vila Velha

51 02 888 2000

06 LucasSanta Rita

Vitória 51 02 888 2000

Capítulo 4

91

Banco de Dados I

Tabela 29 - Tabela resultante da operação projeção π Clientes.nome, Clientes.cidade (CLIENTES |X| EMPRESTIMOS).

Clientes.nome Clientes.cidadeLara VitóriaJoão Vila Velha

Resumindo, a tabela 29 mostra o nome e cidade de todos os clientes que possuem empréstimos.

Se desejássemos encontrar todos os clientes que têm empréstimos e que moram em “Vitória”, teríamos que executar uma operação de seleção sobre a relação resultante da ligação natural – tabela 28. Neste caso, re-tornaria apenas Lara, considerando que, das pessoas que possuem em-préstimos, apenas ela mora em Vitória.

πClientes.nome (σClientes,cidade=”Vitória” (EMPRESTIMOS |X| CLIENTES))


Vitória 52 03 881 4000

02 LaraDas Flores

Vitória 52 03 881 4000


Vila Velha

52 03 881 4000


Viana 52 03 881 4000


Vila Velha

52 03 881 4000

06 LucasSanta Rita

Vitória 52 03 881 4000


92


• Operação Divisão

A operação divisão, representada por (÷), é uma operação binária e é usada em consultas em que os atributos da relação final são os atributos da relação1 que não existem na relação2. As linhas da relação final con-têm as linhas de R1 que incluem todos os valores das colunas comuns a R2. Normalmente aplica-se a consultas que incluem a frase “para todos”. A Figura 41 representa graficamente essa operação.

Sintaxe: (Relação1 ÷ Relação2)

Figura 41 - Operação Divisão

Usando o esquema exemplo, suponha que desejemos encontrar todos os clientes que têm uma conta em todas as agências localizadas em “Vitó-ria”. Podemos obter todas as agências de Vitória por meio da expressão:

r1 πcodigoAg (σcidade=”Vitória” (AGÊNCIAS))

A tabela 30 mostra a relação resultante da consulta acima.

Tabela 30 - Tabela resultante da consulta πcodigoAg (σcidade=”Vitória” (AGÊNCIAS))

codigoAg5051

Podemos encontrar todos os pares Nome, CodigoAg, nos quais um cliente possui uma conta em uma agência, escrevendo:

r2 πClientes.nome, Depositos.codigoAg (CLIENTES |X| DEPOSITOS)

A tabela 31 mostra a relação resultante da consulta.

Capítulo 4

93

Banco de Dados I

Tabela 31 - Tabela resultante da consulta πcodigoAg (σcidade=”Vitória” (AGÊNCIAS))

nome codigoAgAna 50Lara 51João 51José 53

Agora precisamos encontrar clientes que apareçam em r2 com cada có-digo de agência em r1.

Escrevemos essa consulta da seguinte forma:

π Clientes.Nome, Depositos.codigoAg (DEPOSITOS |X| CLIENTES) ÷ πcodigoAg (σcidade=”Vitória” (AGÊNCIAS))

Neste caso, nenhum cliente será retornado, pois ninguém possui conta em todas as agências de Vitória.

• Operação de Remoção

A operação remoção se faz necessária sempre que houver necessidade de excluir tuplas de uma relação.

Sintaxe: R = R – E , onde E é uma consulta da álgebra relacional

Exemplo1: Excluir todos os depósitos do cliente de código 01

Depositos = Depositos - (σcodigoCli = “01” (DEPOSITOS))

Exemplo2: Excluir todas as contas de “joão”

E πcodigoAg, numeroCont, codigoCli, saldo (σnome=”joão” (DEPOSITOS |X| CLIENTES))

DEPOSITOS = DEPOSITOS - E

• Operação de Inserção

A operação inserção se faz necessária sempre que houver a necessidade de incluir tuplas em uma relação.

Sintaxe: R = R ∪ E , onde E é uma consulta da álgebra relacional

Exemplo1: DEPOSITOS = DEPOSITOS ∪ {(51, 980987, 1, 1200)}


94


Exemplo2: Gerar um depósito para todas as pessoas que possuem em-préstimos. A conta gerada terá o mesmo número do empréstimo e o valor do depósito será igual ao da quantia emprestada.

DEPOSITOS = DEPOSITOS ∪ πcodigoAg, numeroEmp, codigoCli, quantia (EMPRES-TIMOS |X| CLIENTES)

Observe que as operações de inserção e remoção utilizam-se como base as operações diferença e união de conjuntos, assim sendo, as condições necessárias para estas operações serem válidas também se aplicam às operações de inserção e remoção. Digo: para uma operação união e diferença de conjunto ser válida, é necessário que duas condições sejam satisfeitas:

1. as relações r e s precisam ter a mesma paridade. Isto é, elas pre-cisam ter o mesmo número de atributos e;

2. os domínios do i-ésimo atributo de r e do i-ésimo atributo de s devem ser os mesmos.

• Operação de Atualização

A operação atualização, representada pela letra grega delta (δ), faz-se necessária sempre que houver a necessidade de alterar valores de tuplas em uma relação.

Sintaxe: δA E ( R), em que E é uma consulta da álgebra relacional.

Exemplo1: acrescer o saldo das contas de todas as pessoas em 5 %.

δsaldo saldo * 1.05 ( DEPOSITOS )

Exemplo2: suponhamos que contas com saldos superiores a R$10.000,00 recebam 6% de juros e as demais 5%.

δsaldo saldo * 1.06 (σsaldo > 10000 ( DEPOSITOS ))

δsaldo saldo * 1.05 (σsaldo <= 10000 ( DEPOSITOS ))

Capítulo 4

95

Banco de Dados I

Neste capítulo tratamos apenas da Álgebra Relacional, não tendo sido abordado o Cálculo relacional de Tupla. Uma boa fonte de pes-quisa para os estudos sobre cálculo relacional de tupla é o livro Sistemas de Banco de Dados, de Abraham Silberchatz, capítulo 5.

ATIVIDADE 3

Considere o esquema seguinte para construir expressões, usando operações da álgebra relacional para as questões que se seguem.

FABRICANTES (codFab, nomeFab)

AUTOMOVEIS (codAuto, nomeAuto, preco, codFab)

codFab referencia FABRICANTES

PESSOAS (codPessoa, nomePessoa)

VENDAS (codPessoa, codAuto, dtVenda, valor, cor)

codPessoa referencia PESSOAS

codAuto referencia AUTOMOVEIS

1. Consultar os nomes das pessoas que compraram algum carro.

2. Consultar os automóveis (nomes) da “Fiat”.

3. Consultar as pessoas (nomes) que compraram “Ford”.

4. Consultar as pessoas (nomes) que compraram carro com ágio (valor da venda maior que o valor do automóvel).

5. Consultar as pessoas (nomes) que não compraram “Ford”.

6. Consultar as pessoas (nomes) que compraram “Ford” e não compraram “Volks”.

7. Consultar o nome do carro mais caro.

8. Atualizar os valores dos automóveis da “GM” em 15%.

9. Excluir todas as vendas anteriores a ‘01/01/1990’.

10. Consultar todas as pessoas que compraram mais de um carro, de diferentes modelos, do mesmo fabricante.

4.3 SQL

A linguagem SQL foi uma das grandes razões para a consolidação dos bancos de dados relacionais no mercado. Desde sua definição como pa-


96


drão, em 1986, passou por diversas revisões, gerando publicações de novas versões. A versão original, denominada Sequel, foi desenvolvida no Laboratório de Pesquisa da IBM e implementada como parte do pro-jeto System R no início dos anos 70. A linguagem evoluiu desde então, e seu nome foi alterado para SQL (Structured Query Language). A pri-meira versão ficou conhecida como SQL-86 ou SQL1, a segunda versão foi denominada SQL-92 ou SQL2 e a última versão publicada, que in-cluiu recursos para dar suporte aos bancos de dados objetos-relacionais e orientados a objetos, ficou conhecida como SQL-99 ou SQL3.

A maioria dos sistemas gerenciadores de bancos de dados comerciais implementam suporte ao padrão SQL. Além disso, incorporam uma sé-rie de funções adicionais visando a facilitar o trabalho dos desenvolve-dores. Estas facilidades precisam ser usadas com cautela, pois, se apenas o padrão for utilizado, garante-se a portabilidade, caso haja a necessida-de de troca de SGBD. A linguagem SQL possui diversas partes:

• linguagem de Definição de Dados (DDL) - Inclui comandos para definição de esquemas de relações (criação, exclusão, alteração), criação de índices dentre outros;

• linguagem de manipulação de dados (DML) - Inclui comandos para consulta, inserção, exclusão e modificação de tuplas em uma relação do banco de dados;

• incorporação DML (SQL Embutida) - Uso de SQL em linguagens de programação de uso geral, como Pascal, C,...;

• definição de Visões - A SQL DDL inclui comandos para defini-ção de visões;

• autorização - A SQL DDL inclui comandos para especificação de direitos de acesso a relações e visões;

• integridade - A SQL DDL inclui comandos para especificação de regras de integridade que os dados que serão armazenados no banco de dados devem satisfazer;

• controle de Transações - A SQL DDL inclui comandos para especi-ficação de iniciação e finalização de transações.

4.3.1 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. A estru-tura básica de uma expressão SQL SELECT consiste em três cláusulas: select, from e where.

Capítulo 4

97

Banco de Dados I

• a cláusula select corresponde à operação projeção da álgebra re-lacional. É usada para listar os atributos desejados no resultado de uma consulta;

• a cláusula from corresponde à operação produto cartesiano da álgebra relacional. Ela lista as relações a serem examinadas na avaliação da expressão;

• a cláusula where corresponde ao predicado de seleção da álgebra relacional. Consiste em um predicado envolvendo atributos de relações que aparecem na cláusula from.

Uma típica consulta SQL SELECT tem a seguinte forma:

SELECT A1, A2, ..., An 3

FROM r1, r2, ..., rn 1

[WHERE P] 2

Cada Ai representa um atributo e cada ri é uma relação. P é um predica-do. Essa consulta é equivalente à expressão da álgebra relacional:

π A1, A2, ..., An (σP (r1 x r2 x ...x rn))

A lista de atributos A1, A2, ..., An pode ser substituída por um (*) para sele-cionar todos os atributos (colunas) presentes nas tabelas da cláusula from.


FROM r1, r2, ..., rn 1

[WHERE P] 2

A numeração constante no final de cada linha da consulta repre-senta a ordem de execução desta linha, dentro da consulta como um todo. Mesmo que o otimizador altere a ordem de execução, bus-cando por melhoria de performance e para facilitar o aprendizado é interessante termos em mente esta ordem.

Para execução da consulta acima, forma-se o produto cartesiano das re-lações referenciadas na cláusula from, executa-se uma seleção da álgebra relacional usando o predicado da cláusula where e, então, projeta o resul-tado para os atributos da cláusula select. Na prática, o otimizador de con-sultas da linguagem SQL pode converter essa expressão em uma forma


98


equivalente que pode ser processada mais eficientemente, mas para efeito didático iremos manter esta ordem de execução.

Uma consulta completa pode ter as cláusulas abaixo, sendo que apenas as cláusulas SELECT e FROM são obrigatórias. O número que segue cada linha sugere a ordem de execução. O conhecimento desta ordem é im-portante para efeito didático pois facilita o entendimento do comando.


FROM r1, r2, ..., rn 1

[WHERE P] 2

[GROUP BY A1, A2, ..., An] 3

[HAVING Condição] 4

[ORDER BY A1, A2, ..., An] 5

Cada uma das cláusulas da consulta acima será explorada nas sub-seções seguintes.

Assim como na álgebra relacional, o resultado de uma consulta SQL é uma relação!

Vamos considerar uma primeira consulta simples, usando nosso esque-ma exemplo. “Encontre os nomes de todos os clientes na relação clien-tes”. A consulta SQL pode ser escrita da seguinte forma:

SELECT NomeFROM Clientes

Linhas (tuplas) duplicadas

Em algumas situações, uma consulta SQL pode retornar uma relação que contenha tuplas (linhas) duplicadas. Nessa situação, inserimos a palavra-chave distinct depois da cláusula select para eliminá-las.

Capítulo 4

99

Banco de Dados I

Aproveitando o exemplo anterior, a relação resultante poderá ter clien-tes que possuam o mesmo nome. Nesse caso, 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.

Predicados e ligações

A SQL não tem uma representação da operação ligação natural. No en-tanto, uma vez que a ligação natural é definida em termos de produto cartesiano, seleção e projeção, é relativamente simples escrever uma ex-pressão SQL para representar a operação ligação natural.

Ex.: Encontre os nomes e cidades de clientes que possuam empréstimos em alguma agência. Esta consulta pode ser escrita da seguinte forma:

SELECT DISTINCT Clientes.nome, Clientes.cidade FROM Clientes, EmprestimosWHERE Clientes.codigoCli=Emprestimos.codigoCli

Observe que na consulta acima, apenas necessita-se saber se o clien-te possui empréstimo, por isto apenas as tabelas Clientes e Emprés-timos foram incluídas. Se além disso, tivesse a necessidade de saber qual a agência em que o empréstimo foi feito, seria necessário a in-clusão da relação Agências.


100


Outro recurso disponível na linguagem SQL para estabelecer li-gações entre tabelas são as operações de join. A consulta acima poderia ser escrita da seguinte forma, usando join:

SELECT DISTINCT Clientes.nome, Clientes .cidade FROM Clientes JOIN Emprestimos ON Clientes.codigoCli=Emprestimos.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, de Elmasri Navathe, capítulo 8, que oferece ou-tras opções de join .

A SQL inclui os conectores and, or e not ; caracteres especiais: (, ), ., :, _, %,<, >, <= , >= , = , <>, +, - ,* e /; operador para comparação: between, como mostra o exemplo a seguir.

Ex.: Selecionar todas as contas que possuam saldo entre 10000 e 20000.

SELECT numeroCont FROM DepositosWHERE saldo BETWEEN 10000 AND 20000

Que equivale a consulta

SELECT numeroCont FROM DepositosWHERE saldo >= 10000 AND saldo <= 20000

A SQL inclui também um operador para comparações de cadeias de caracteres, o like. Ele é usado em conjunto com dois caracteres especiais:

Por cento (%). Substitui qualquer subcadeia de caracteres.

Sublinhado (_). Substitui um caractere qualquer.

Ex.: Encontre os nomes de todos os clientes cujas ruas incluem a sub-cadeia “na”.

Capítulo 4

101

Banco de Dados I

SELECT distinct nome FROM ClientesWHERE rua LIKE “ %na%”

Ou também

Ex.: Encontre os nomes de todos os clientes cujas ruas onde moram finalizem com a subcadeia “na”.

SELECT distinct nome FROM ClientesWHERE rua LIKE “ %na”

Para que o padrão possa incluir os caracteres especiais ( isto é, % , _ , etc...), a SQL permite a especificação de um caractere de escape. O caractere de escape é precedido do caractere especial para indicar que este último deverá ser tratado como um caractere normal. Definimos o caractere de escape para uma comparação like, usando a palavra-chave escape. Para ilustrar, considere os padrões seguintes, que utilizam uma barra invertida como caractere de escape.

Like “ ab\%cd%” escape “\” substitui todas as cadeias começando com “ ab%cd”;

Like “ ab\_cd%” escape “\” substitui todas as cadeias começando com “ ab_cd”.

A procura por não-substituições em vez de substituições se dá por meio do operador not like.

Embora a cláusula Like seja muito útil, deve ser utilizada com cui-dado. Quando fixar o início da cadeia, como iniciar com “Maria”, não há problemas, porém, quando for aplicada em consultas para procurar caracteres no meio ou no final de cadeias, nas quais não se conhece o início, teremos problemas! Nesse caso não usará o índice, caso haja para a coluna, podendo implicar em baixa performance das aplicações.


102


Operações de conjunto

A SQL inclui o operador de conjunto union que opera em relações e corresponde à operação ∪ da álgebra relacional.

Uma vez que as relações são conjuntos, na união destas relações, as li-nhas duplicadas são eliminadas.

Para uma operação União (Union) r ∪ s ser válida, duas condi-ções devem ser atendidas: as relações r e s precisam ter a mesma paridade, isto é, elas precisam ter o mesmo número de atributos; e os domínios do i-ésimo atributo de r e do i-ésimo atributo de s devem ser os mesmos.

Ex. Se quisermos saber todos os clientes que possuem empréstimos na agência de código 51, fazemos:

SELECT DISTINCT Clientes.nomeFROM Clientes, EmprestimosWHERE Clientes.codigoCli=Emprestimos.codigoCli AND Empresti-mos.codigoAg = 51

Da mesma forma, se quisermos consultar todos os clientes que possuem depósitos na agência de código 51, fazemos:

SELECT DISTINCT Clientes.nomeFROM Clientes, DepositosWHERE Clientes.codigoCli= Depositos.codigoCli AND Depositos.co-digoAg = 51

Para encontrar todos os clientes que possuem depósito, empréstimo ou ambos, na agência de código 51, fazemos:

SELECT DISTINCT Clientes.nomeFROM Clientes, DepositosWHERE Clientes.codigoCli=Depositos.codigoCli AND Depositos.co-digoAg =51

Capítulo 4

103

Banco de Dados I

UNION

SELECT DISTINCT Clientes.nomeFROM Clientes, EmprestimosWHERE Clientes.codigoCli=Emprestimos.codigoCli AND Empresti-mos.codigoAg = 51

Ordenando a exibição de tuplas

A cláusula order by organiza o resultado de uma consulta em uma or-dem determinada. Para listar em ordem alfabética todos os clientes do banco, fazemos:

SELECT DISTINCT nome FROM ClientesORDER BY nome

Como padrão, a cláusula order by lista tuplas na ordem ascendente. Para especificar a ordem de classificação, podemos especificar asc para ordem ascendente e desc para descendente. Podemos ordenar uma re-lação por mais de um elemento. Como se segue:

SELECT *FROM Emprestimos ORDER BY quantia DESC, codigoAg ASC

Se desejar que o resultado de uma consulta SQL seja exibido em ordem alfabética, utilize a cláusula Order By. Às vezes, construímos consultas e o resultado é apresentado em ordem alfabética, confor-me esperado, e não nos preocupamos em usar a cláusula Order by. Isso acontece provavelmente porque há um índice ordenado criado sobre essa coluna; porém, se o DBA resolver criar esse índice sobre outra coluna, sua ordenação vai se perder!


104


Membros de conjuntos

O conectivo in/not in testa os membros de conjunto em que o conjun-to é uma coleção de valores produzidos por uma cláusula select. Para ilustrar, considere a consulta “Encontre todos os clientes que possuem uma conta (Depósito) e não possuem empréstimo na agência “Princesa Isabel””. A consulta SQL poderá ser escrita da seguinte forma:

SELECT DISTINCT Clientes.nomeFROM ClientesWHERE Clientes.codigoCli IN

(SELECT CodigoCli FROM Depositos, AgenciasWHERE Depositos.codigoAg = Agencias.codigoAgAND NomeAg = “Princesa Isabel”)

AND Clientes.codigoCli NOT IN(SELECT codigoCli FROM Emprestimos, AgenciasWHERE emprestimos.codigoAg = agen-cias.codigoAgAND nomeAg = “Princesa Isabel”)

Esta consulta é equivalente à consulta abaixo. Ela foi construída desta forma para exemplificar o uso do operador IN.

SELECT DISTINCT Clientes.nomeFROM Clientes, Depositos, AgenciasWHERE Clientes.codigoCli = Depositos.codigoCli AND Depositos.co-digoAg = Agencias.codigoAgAND Agencias.NomeAg = “Princesa Isabel”AND Clientes.codigoCli NOT IN

(SELECT codigoCli FROM Emprestimos, AgenciasWHERE emprestimos.codigoAg = agen-cias.codigoAg

AND nomeAg = “Princesa Isabel”)

Capítulo 4

105

Banco de Dados I

Renomeação de Tabelas em uma consulta

A renomeação sempre será necessária quando precisarmos usar a mes-ma tabela mais de uma vez na mesma consulta, assim como na operação renomear da álgebra relacional. Muitas vezes usamos este recurso com o objetivo de reduzir o tamanho das expressões SQL. A renomeação é feita usando a palavra reservada “AS”, após o nome da tabela na cláusula FROM, como mostra o exemplo a seguir.

Ex: “encontre o nome e a cidade de todos os clientes que possuem depósito”.

SELECT DISTINCT C.nome, C.cidadeFROM Clientes AS C, Depositos AS DWHERE C.codigoCli = D.codigoCli

Uma vez que as relações Clientes e Depósitos foram renomeadas para C e D, quaisquer referências a essas tabelas, na consulta, devem ser feitas a C e D, e não mais aos nomes originais. Lembre-se da ordem de execução de uma consulta SELECT!

Redefinindo a relação Agências para uso em exemplos posteriores.

Agencias = (CodigoAg, NomeAg, CidadeAg, ativos)

Comparação de conjuntos

Considere a consulta “encontre todas as agências que possuem ativos maiores que alguma agência de Vitória”. Esta consulta poderá ser escrita em SQL da seguinte forma:

SELECT DISTINCT Agencias.nomeAgFROM Agencias , Agencias AS agWHERE agencias.ativos > ag.ativos AND ag.cidade = “Vitória”Uma vez que a consulta usa uma comparação “maior que”, não pode-mos escrever a expressão usando a construção in. Observe também que, como houve necessidade de usar a mesma tabela (Agências) duas vezes na consulta, ela teve que ser renomeada.


106


A mesma consulta acima poderia ser escrita usando o operador any (pelo menos um), conforme será abordado a seguir.

Comparações do tipo >any, <any, >=any, <=any, =any são aceitas pela linguagem. A consulta anterior pode ser escrita da seguinte forma:

SELECT Agencias.NomeAgFROM Agencias WHERE ativos > ANY

(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. A construção > all corresponde à frase “maior que todos”. A consulta fica como se segue:

SELECT Agencias.nomeAgFROM Agencias WHERE ativos > ALL

(SELECT ativos FROM Agencias WHERE Agencias.cidade = “Vitória”)

Como o operador Any, o operador all pode ser usado como: >all, <all, >=all, <=all, =all e <> all.

Capítulo 4

107

Banco de Dados I

Sempre que houver necessidade de comparar um atributo com o resultado de uma subconsulta é necessário usar um operador de conjunto, seja o operador ALL seja o ANY, como ilustrado no exemplo acima.

Testando relações vazias

A SQL possui um recurso para testar se uma subconsulta retorna algu-ma tupla. A construção exists retorna true se a subconsulta retornar alguma tupla. Para ilustrar, 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.NomeFROM ClientesWHERE EXISTS

(SELECT * FROM Depositos, AgenciasWHERE Depositos.codigoCli= Clientes.codigoCli AND De-positos.codigoAg = Agencias.codigoAg AND Agencias.nomeAg = “Princesa Isabel”)

WHERE NOT EXISTS(SELECT * FROM Emprestimos, AgenciasWHERE Emprestimos.codigoCli= Clientes.codigoCli ANDEmprestimos.codigoAg = Agencias.codigoAg AND Agencias.nomeAg = “Princesa Isabel”)

Embora a abordagem dos operadores IN/NOT IN e EXIST/NOT EXISTS sejam diferentes, eles se aplicam ao mesmo tipo de con-sulta. Na verdade, algumas consultas mais complexas são resolvi-das com o operador EXISTS/NOT EXISTS, sendo esse operador um pouco mais abrangente que os operadores IN / NOT IN.


108


Considerando que o objetivo do operador EXISTS é verificar a exis-tência de tuplas na consulta seguinte, não importa o conteúdo retor-nado. Assim, na consulta acima ... WHERE NOT EXISTS(SELECT * FROM emprestimos…), eu costumo substituir o * por 1.

ATIVIDADE 4

Considere o esquema abaixo para construir as expressões seguin-tes, usando a linguagem SQL.


Chefe referencia PESSOAS





1. Consulte todas as pessoas que moram em Vitória.

2. Consulte todas as pessoas que trabalham na mesma cidade onde moram.

3. Consulte todas as pessoas que moram na mesma cidade do chefe.

4. Consulte todas as empresas que funcionam em cidades em que não moram pessoas cujo primeiro nome seja Maria (usar operações de conjunto).

5. Consulte todas as pessoas que não trabalham em Vitória e que ganham acima de R$2000,00 em ordem decrescente.

6. Consulte todas as pessoas que não trabalham na empresa cujos nomes comecem com “inf_”. O resultado deverá ser apresen-tado em ordem alfabética.

Capítulo 4

109

Banco de Dados I

ATIVIDADE 5


FABRICANTES (codFab, nomeFab)

AUTOMOVEIS (codAuto, nomeAuto, preco, codFab)

codFab referencia FABRICANTES

PESSOAS (codPessoa, nomePessoa)

VENDAS (codPessoa, codAuto, dtVenda, valor, cor)

codPessoa referencia PESSOAS

codAuto referencia AUTOMOVEIS

1. Consultar as pessoas (nome) que compraram algum carro.

2. Consultar as pessoas que compraram automóveis do fabrican-te “Ford”.

3. Consultar as pessoas que não compraram “Ford”.

4. Consultar as pessoas que compraram carro com ágio. O resul-tado deverá ser apresentado em ordem alfabética.

5. Consultar as pessoas que compraram “Ford” e não compra-ram “Volks”.

Funções agregadas

A SQL oferece a habilidade para computar funções em grupos de tuplas, usando a cláusula group by. O(s) atributo(s) informado(s) na cláusula group by são usados para formar grupos. Tuplas com o mesmo valor em todos os atributos na cláusula group by são colocados em um grupo.

Funções agregadas:

Média: AVG

Mínimo: MIN

Máximo: MAX

Soma: SUM

Contar: COUNT


110


Para ilustrar, considere a consulta: Encontre o saldo médio das contas em cada agência.

SELECT Agencias.nomeAg, AVG(Depositos.saldo) AS saldoMedioFROM Depositos, AgenciasWHERE Depositos.codigoAg = Agencias.codigoAg GROUP BY Agencias.nomeAg

A tabela 32 abaixo mostra o resultado parcial da execução da consulta (antes do agrupamento), tomando como base o conjunto de valores de-finidos no início deste capítulo para o esquema bancário.

Tabela 32 - Tabela resultante do produto cartesiano e seleção (cláusula FROM e WHERE)

codigo-Ag

nume-roCont

codigo-Cli

saldo

Agen-cias.codigo-Ag

Agen-cias .nome-Ag

Agen-cias .cida-deAg

50 999 01 1000 50 Centro Vitória

51 991 02 3200 51Prin-cesa Isabel

Vitória

51 992 03 2300 51Prin-cesa Isabel

Vitória

53 993 04 1200 53 Avenida Vitória

Uma vez que o agrupamento é feito, cada agência (nomeAg) constituirá um grupo, sobre o qual incidirá a função agregada (AVG). Com isto, temos o resultado na consulta exibido na tabela 33.

Tabela 33 - Tabela resultante da consulta “encontre o saldo médio das contas em cada agência”.

Capítulo 4

111

Banco de Dados I

nomeAg saldoMedioCentro 1000Princesa Isabel 2750Avenida 1200

Quando escrevemos a cláusula GROUP BY em uma expressão SQL, a cláusula SELECT só poderá retornar atributos que cons-tam no grupo. Além deles, apenas funções agregadas são permiti-das. Caso contrário, dará erro!

Se, além do saldo médio por cada agência, quiséssemos retornar a quan-tidade de clientes que possuem conta, a consulta poderia ser levemente modificada, conforme mostra a seguir:

SELECT Agencias.nomeAg, AVG(Depositos.saldo) AS saldoMedio, COUNT(DISTINCT Depositos.codigoCli) AS qtdClientes

FROM Depositos, Agencias

WHERE Depositos.codigoAg = Agencias.codigoAg

GROUP BY Agencias.nomeAg

Note que para a cláusula COUNT é importante o uso da cláusula dis-tinct , pois um cliente pode ter mais de uma conta em uma agência e deverá ser contado uma única vez. A tabela 34 abaixo mostra o resulta-do da consulta.

Tabela 34 - Tabela resultante da consulta “encontre o saldo médio e quantidade de clientes em cada agência”.

nomeAg saldoMedio qtdClientesCentro 1000 1Princesa Isabel 2750 2Avenida 1200 1


112


A consulta abaixo mostra o maior saldo para cada agência.

SELECT Agencias.nomeAg, MAX(Depositos.saldo) AS maiorSaldoFROM Depositos, AgenciasWHERE Depositos.codigoAg= Agencias.codigoAgGROUP BY Agencias.nomeAgA tabela 35 mostra o resultado da execução da consulta.

Tabela 35 - Tabela resultante da consulta “encontre o maior saldo para cada agência”.

nomeAg maiorSaldoCentro 1000Princesa Isabel 3200Avenida 1200

Muitas vezes é necessário definir uma condição que se aplique a grupos em vez de tuplas. Por exemplo, poderíamos estar interessados apenas em agências em que a média dos saldos seja superior a R$1200,00. Essa condição será aplicada a cada grupo e não a tuplas simples, e é definida pela cláusula having. Podemos escrever essa expressão SQL assim:

SELECT Agencias.nomeAg, AVG(Depositos.saldo) AS saldoMedioFROM Depositos, AgenciasWHERE Depositos.codigoAg= Agencias.codigoAgGROUP BY Agencias.nomeAgHAVING AVG(saldo)>1200A tabela 36 mostra o resultado da execução da consulta. No caso, apenas a agência “Princesa Isabel” será retornada.

Tabela 36 - Tabela resultante da consulta “encontre as agências onde a média de saldo seja superior a 1200”.

nomeAg saldoMedioPrincesa Isabel 2750

A cláusula WHERE elimina linhas em uma consulta.

A cláusula HAVING elimina grupos.

Às vezes, desejamos tratar a relação inteira como um grupo sim-ples. Nesses casos, não usamos a cláusula group by. Para encontrar a média de saldos de todas as contas, escrevemos:

Capítulo 4

113

Banco de Dados I

SELECT AVG (Depositos.saldo)FROM Depositos

No exemplo anterior, a coluna projetada por meio de uma função agregada, a média de saldos, não possui um nome, ou seja, não foi renomeada como nos exemplos anteriores. É sempre recomendado que se dê um nome para identificá-la. Para criar este nome, tam-bém chamado de “Alias” usa-se a cláusula “AS”, assim como para renomeação de tabelas. Caso contrário, ao executá-la, a coluna aparecerá com o nome EXPR, por exemplo.

ATIVIDADE 6

Considere o esquema bancário para construir as expressões se-guintes, usando a linguagem SQL.

1. Consultar todos os clientes que possuem contas em agência(s) que possui(em) o maior ativo.

2. Consultar o total de agências por cidade, classificado por cidade.

3. Consultar, por agências, o(s) cliente(s) com o maior saldo.

4. Consultar o valor médio de empréstimos efetuados por cada agência, em ordem crescente das cidades onde essas agências se situam.

5. Consultar a(s) agência(s) que possui(em) a maior média de quantia emprestada.

6. Consultar todas as agências situadas fora de Vitória que pos-suem a média de depósitos maior do que alguma agência lo-calizada em Vitória.

7. Consultar o menor saldo de clientes, por agências.

8. Consultar o saldo de cada cliente, caso ele possua mais de uma conta no banco.


114


Removendo linhas de uma tabela

O comando Delete é usado para remover tuplas em uma dada relação. Lembre-se de que só podemos remover tuplas inteiras, não podemos remover valores apenas em atributos particulares.

Sintaxe:

DELETEFROM r[WHERE P]

Onde r representa uma relação e P um predicado.

Note que o comando delete opera em apenas uma relação. O predicado da cláusula where pode ser tão complexo quanto o predicado where do comando select.

Ex1.: Fazer uma consulta para excluir todas as tuplas de empréstimo.

DELETE FROM EmprestimosEx2.: Remover todos os depósitos de “joão”DELETE FROM Depositos.DepositosWHERE Depositos.codigoCli in

(SELECT codigoCli FROM ClientesWHERE nome=”joão”)

Ex3.: Remover todos os empréstimos com números entre 1300 e 1500.

DELETE FROM EmprestimosWHERE numero between 1300 AND 1500

Ex4.: Remover todos os depósitos de agências localizadas em “Vitória”.

DELETE FROM DepositosWHERE depositos.codigoAg in

(SELECT codigoAg FROM Agencias WHERE cidade=’Vitoria’)

Capítulo 4

115

Banco de Dados I

O comando DELETE é um comando da Linguagem DML; por isso, se usar o comando DELETE FROM Tabela sem predicado na cláu-sula WHERE, todas as linhas serão excluídas; a tabela, no entanto, permanecerá criada, porém vazia.

Inserindo linhas em uma tabela

Para inserir um dado em uma relação, ou especificamos uma tupla para ser inserida ou escrevemos uma consulta cujo resultado seja um conjunto de tuplas a serem inseridas. Obviamente, os valores dos atributos para tuplas inseridas precisam ser membros do mesmo domínio do atributo.

Sintaxe:

INSERT INTO r (A1, A2, ..., An)VALUES (V1, V2, ..., Vn)

Onde r representa uma relação A atributos e V valores a serem inseridos.

Suponha que desejamos inserir um novo depósito de João (código = 1), cujo valor seja R$1200,00, na conta 9000 da agência de código=2. Para isso, fazemos o seguinte comando:

INSERT INTO depositos (codigoAg, numeroCont, codigoCli, saldo)VALUES (2,9000,1,1200)

A SQL permite que essa mesma inserção seja escrita da seguinte forma: Insert into depositos Values (2,9000,1,1200), omitindo a relação de atributos. Essa abordagem, porém, não é recomendada, tendo em vista que, se houver alteração do esquema da relação, a exemplo da inclusão de um novo atributo, a consulta falhará e, consequentemente, a aplicação que a utiliza acarretará em erros.


116


Podemos querer também inserir tuplas baseadas no resultado de uma consulta. Suponha que desejemos inserir todos os clientes que possuam empréstimos na agência “Princesa Isabel” na relação depósitos, com um saldo de R$200,00.

INSERT INTO Depositos (codigoAg, numeroCont, codigoCli, saldo)SELECT Emprestimos.codigoAg, Empréstimos.numeroEmp, Emprésti-mos.codigoCli, 200 FROM Emprestimos, Agencias WHERE Emprestimos.codigoAg=Agencias.codigoAg AND Agencias.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.

Atualizando valores

Em certas situações, podemos desejar mudar valores em tuplas. Nesse caso, o comando update deve ser aplicado.

Sintaxe:

UPDATE r SET a1 = v1, a2 = v2, ..., an = vn[WHERE p]

Em que r representa uma relação, a atributos, p predicado e v os novos valores para os respectivos atributos.

O comando UPDATE é um comando da Linguagem DML. Altera valores de campos e não a estrutura da tabela. Os alunos costumam confundir isso. Por isso, esteja atento!

Suponha que esteja sendo feito o pagamento de juros e que sejam acres-centados 5% em todos os saldos. Escrevemos

UPDATE DepositosSET saldo = saldo * 1.05

Capítulo 4

117

Banco de Dados I

Suponha que todas as contas com saldo superior a R$10000,00 recebam aumento de 6% e as demais de 5%.

UPDATE Depositos SET saldo = saldo * 1.06WHERE saldo >10000

UPDATE Depositos SET saldo = saldo * 1.05WHERE saldo<=10000

A cláusula where pode conter uma série de comandos select aninhados. Considere, por exemplo, que todas as contas de pessoas que possuem empréstimos no banco terão acréscimo de 1%.

UPDATE Depositos SET saldo = saldo * 1.01WHERE codigoCli IN (SELECT codigoCli FROM Emprestimos)

Como você deve ter observado, os comandos de atualização – INSERT, UPDATE e DELETE – atuam sempre sobre uma única tabela. Não é possível inserir linhas em mais de uma tabela em um comando.

Valores Nulos

É possível para tuplas inseridas em uma dada relação atribuir valores a apenas alguns atributos do esquema. Os atributos restantes são designa-dos como nulos. Considere a expressão cujo objetivo é o de incluir uma nova agência:

INSERT INTO Agencias (codigoAg, nomeAg, cidadeAg, ativos)VALUES (2,”Centro”, ”Vitória”, NULL)Nesse caso, está sendo atribuído o valor nulo para o atributo “ativos”. A mesma consulta poderia ser reescrita omitindo esse atributo. Nesse caso, automaticamente ele assumiria o valor nulo.

INSERT INTO Agencias (codigoAg, nomeAg, cidadeAg)VALUES (2, ”Centro”, ”Vitória”)


118


A consulta acima só será válida se o campo ativos puder assumir valor nulo. Caso contrário, ocasionará erro.

A palavra chave null pode ser usada em um predicado para testar se um valor é nulo. Assim, para achar todos os clientes que aparecem na rela-ção empréstimos com valores nulos para quantia, escrevemos:

SELECT DISTINCT nomeFROM Clientes, EmprestimosWHERE Clientes.codigoCli = Emprestimos.codigoCliAND quantia IS NULLO predicado IS NOT NULL testa a ausência de um valor nulo.

Capítulo 4

119

Banco de Dados I

ATIVIDADE 7



Chefe referencia PESSOAS





Observação: estas atividades foram elaboradas para exercitar os comandos de atualização. Desconsidere a integridade referencial dos dados.

1. Exclua todas as pessoas que possuem salário = R$1000,00.

2. Exclua todas as pessoas que trabalham em empresas situadas em Vitória.

3. Inclua na empresa de código “01”, com um salário= R$100,00, todos os moradores de Vitória

4. Uma determinada empresa de código “x” vai contratar todos os funcionários da empresa de código “y” que ganham acima de R$1000,00, dando um aumento de salário de 10%. Faça comando(s) SQL para que tal transação seja efetuada. Obs: As pessoas serão remanejadas.

5. Uma determinada empresa de código “xyz” quer contratar todos que moram em Vitória e estão desempregados. Serão contratados com salário = R$200,00. Faça comando(s) SQL para efetuar tal transação.

6. Faça um comando SQL para ajustar o salário de todos os fun-cionários da empresa “Campana” em 5%.

7. Todas as pessoas que moram em Colatina e trabalham na em-presa “Campana” deverão se mudar para Vitória, devido aos requisitos do diretor da empresa. Faça comando(s) SQL para efetivar a atualização da cidade.


120


4.3.2 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).

A SQL DDL permite a especificação não apenas de um conjunto de rela-ções, mas também de informações sobre cada relação, incluindo:

• o esquema para cada relação;• o domínio de valores associados a cada atributo;• o conjunto de índices a ser mantido para cada relação;• restrições de integridade;• a estrutura física de armazenamento de cada relação no disco.

Tipos de Domínios da Linguagem SQL

A linguagem SQL inclui diversos tipos de domínios, conforme lista abaixo [SILBERSCHATZ, 2006]:

Char(n): cadeia de caracteres de tamanho fixo, igual a n, definido pelo usuário;

Varchar(n): cadeia de caracteres de tamanho variável, no máximo igual a n, definido pelo usuário;

Int: inteiro (subconjunto finito dos inteiros que depende do equipamento).

Smallint: inteiro pequeno (um subconjunto do domínio dos inteiros que depende do equipamento);

Numeric(p,d): número de ponto fixo cuja precisão é definida pelo usu-ário. O número consiste de p dígitos, sendo que d dos p dígitos estão à direita do ponto decimal;

Real: números de ponto flutuante cuja precisão depende do equipa-mento em questão;

Float(n): número de ponto flutuante com a precisão definida pelo usu-ário em pelo menos n dígitos;

Date: calendário contendo um ano (com quatro dígitos), mês e dia do mês;

Time: representa horário, em horas, minutos e segundos.

Capítulo 4

121

Banco de Dados I

Se você definir um campo de uma tabela como varchar(50), por exemplo, e se o espaço necessário para alocar um valor para esse campo tiver 10 caracteres, apenas 10 espaços serão alocados. Se, no entanto, esse campo for definido como char(50), usando ou não, serão alocados os 50 espaços.

Ao definir um campo de uma tabela, se ocupar sempre a mesma quantidade de caracteres, é melhor definir como char. Se o tamanho for variável, use varchar.

Uma relação SQL é definida usando a instrução CREATE TABLE.

CREATE TABLE r (A1 D1, ..., An Dn)

Em que r é uma relação, cada Ai é o nome de um atributo no esquema de relação r e Di é o tipo de dados de valores no domínio de atributo Ai. O comando create table inclui opções para especificar certas restrições de integridade, conforme veremos adiante.

A relação criada acima está inicialmente vazia. O comando insert pode-rá ser usado para carregar os dados para uma relação.

Para remover uma relação de banco de dados SQL, usamos o comando drop table, que remove todas as informações sobre a relação retirada do banco de dados.

DROP TABLE r

Ex. : para excluir a relação Depósitos, podemos escrever a seguinte ex-pressão SQL.

DROP TABLE Depositos

Ao excluir uma tabela, caso exista outra tabela com chave estran-geira que faça referência à tabela que está sendo excluída, ocorrerá erro. É necessário excluir antes a tabela referenciada ou usar exclu-são em cascata, como mostra o exemplo:

DROP TABLE Depositos CASCADE

Neste caso, caso haja uma tabela que faça referência à tabela Depo-sitos, esta também será eliminada do banco de dados.


122


O comando alter table é usado para alterar a estrutura de uma relação existente. Ao alterar a estrutura de uma tabela, é possível incluir novos campos, excluir campos existentes ou incluir restrições, a exemplo de chaves primárias e estrangeiras.

Exemplo de um comando alter table incluindo uma coluna “cpf ” na relação Clientes:

ALTER TABLE Clientes ADD cpf NUMERIC(11,0) NULL

Ao adicionar uma coluna em uma tabela existente, se esta tabela pos-suir registros, a coluna incluída necessariamente deverá ser NULL.

Exemplo de um comando alter table excluindo a coluna “cpf ”, recém incluída na relação Clientes:

ALTER TABLE Clientes drop column cpf

Exemplo de um comando alter table incluindo uma restrição, 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, considera-se não só a Integridade Física dos arquivos portadores do banco de dados, como também manutenção da qualidade dos dados armazenados em termos de precisão e consistência.

As restrições de integridade fornecem meios para assegurar que mu-danças feitas no banco de dados por usuários autorizados não resultem na perda da consistência dos dados. São vários os tipos de integridade, os quais costumam ser classificados da seguinte forma:

• Integridade de Domínio. Domínio é uma lista de valores que preci-sa estar associada a todo atributo. Constitui a forma mais elementar de restrição de integridade. É facilmente testado pelo sistema cada vez que um novo item de dado é inserido no banco de dados.

• Integridade de Vazio. Especifica se um campo de uma coluna pode ou não assumir valor nulo. Não pode permitir que os campos com entrada obrigatória assumam valores nulos.

Capítulo 4

123

Banco de Dados I

• Integridade de Chaves. Especifica a unicidade dos valores para a chave primária e candidatas.

• Integridade Referencial. Frequentemente, desejamos assegurar que um valor que aparece em uma relação para um dado conjunto de atributos apareça também para um certo conjunto de atributos em outra relação, o que se denomina Integridade Referencial. A existência de uma chave estrangeira impede que anomalias ocor-ram em função de alterações executadas no banco de dados, confor-me elencadas abaixo:

• ao incluir uma linha na tabela que contém a chave estran-geira, o valor inserido tem que fazer parte da tabela em que ela é chave primária. O único valor diferente desse que é permitido é o valor nulo, quando for possível;

• ao excluir uma linha da tabela que contém chave primária referenciada por outras tabelas, pode-se implementar os seguintes cenários: excluir em cascata as linhas nas tabelas relacionadas em que se encontram as chaves estrangeiras referentes a essa chave primária ou impedir que a exclusão seja feita;

• ao alterar o valor da chave primária referenciada por outras tabelas, pode-se implementar os seguintes cenários: alterar em cascata os valores das chaves estrangeiras nas tabelas re-lacionadas ou impedir que a alteração seja feita;

• ao se alterar o valor da chave estrangeira, deve-se ter garan-tia de que o novo valor esteja constante na tabela em que ela é chave primária. Se não for, haverá bloqueio na alteração.

Implementando Integridade Referencial em SQL

A SQL original padrão não incluiu instruções para especificar chaves estrangeiras. Um subsequente “recurso de aperfeiçoamento de integri-dade” foi aprovado como uma adição ao padrão. Esse recurso permite a especificação de chaves primárias, candidatas e estrangeiras como parte da instrução create table.

• a cláusula primary key da instrução create table inclui uma lista de atributos que compreende a chave primária;

• a cláusula unique da instrução create table inclui uma lista de atri-butos que compreende a chave candidata;

• a cláusula foreign key da instrução create table inclui uma lista de atributos que compreende a chave estrangeira e o nome da relação referida pela chave estrangeira.


124


Criando as relações clientes, agências e depósitos para o esquema bancário.

CREATE TABLE Clientes (codigoCli int not null, nome varchar(30) not null, rua varchar(30) not null, cidade varchar(30) not null,cpf numeric(11,0) not null,PRIMARY KEY (codigoCli),UNIQUE (CPF))

CREATE TABLE Agencias (codigoAg int not null, nomeAg varchar(30) not null, cidadeAg varchar(30) not null,PRIMARY KEY (CodigoAg))

CREATE TABLE Depositos (codigoAg int not null, numeroCont int not null, codigoCli int not null, saldo real,PRIMARY KEY (codigoAg,numeroCont),FOREIGN KEY (codigoCli) REFERENCES Clientes,FOREIGN KEY (codigoAg) REFERENCES Agencias,CHECK (Saldo >=0) )

A cláusula Check garante integridade aos valores dos atributos e pode fazer referência, inclusive, a valores de atributos em outras tabelas.

Embora tenhamos incluído a cláusula not null para os campos que compõem a chave primária de cada tabela, não é necessário. A SQL assume que todos os campos chaves (primária) não permitam va-lores nulos.

Capítulo 4

125

Banco de Dados I

Existe também a possibilidade de criar as tabelas sem integridade re-ferencial e incluir essa implementação usando a instrução Alter Table.

Existe uma propriedade, implementada pela maioria dos SGBDs disponíveis no mercado, que possibilita que um campo tenha seu va-lor incrementado automaticamente. A sintaxe, porém, difere para cada um. O MS SQL Server, por exemplo, implementa a proprieda-de identity(x,y), onde x define o valor inicial e y, o incremento. No exemplo de criação da tabela Agencias, considerando o código da agência como auto incrementável, pode ser escrita como se segue:

CREATE TABLE Agencias

(codigoAg int identity(1,1) not null,

nomeAg char(30),

cidadeAg char(30),

PRIMARY KEY (codigoAg))

Ao inserir uma agência, não deve ser passado valor para o código da agência, considerando que este valor será gerado pelo sistema, como mostra o exemplo a seguir:

INSERT INTO Agencias (nomeAg, cidadeAg)

VALUES (‘Centro’, ‘Vitória’)

A primeira agência inserida terá o código igual a um e a seguinte, igual a 2, considerando que o valor do incremento foi definido como 1.


126


As restrições Default e Check serão mais exploradas na disciplina Banco de Dados II.

ATIVIDADE 8

Dados os esquemas abaixo, faça comandos SQL DDL padrão para criar as estruturas das tabelas, usando o tipo de dados que melhor se aplique a cada atributo e impondo integridade referencial.

a) Alunos (codigoAl, nomeAl, codigoCurso, telefone, coeficienteRendimento)

codigoCurso referencia Cursos

Cursos (codigoC, nomeC)

Disciplinas (codigoDisc, codigoCurso, nomeDisc)

codigoCurso referencia Cursos

Historico (codigoAl, codigoDisc, Periodo, nota)

codigoAl referencia Alunos

codigoDisc referencia Disciplinas

Pre_Requisitos (codigoDiscPos, codigoDiscPre)

codigoDiscPos referencia Disciplinas

codigoDiscPre referencia Disciplinas

b) Clientes (codCliente, nomeCliente, telefone, dtNascimento)

Filmes (codFilme, nomeFilme, lancamento, dtAquisi-cao, codClasse)

codClasse referencia Classes

Fitas (codFilme, numeroFita, dublada)

codFilme referencia Filmes

Locacoes (codFilme, numeroFita, codCliente, dtLocacao, dtDevolucao, vlrLocacao, multa)

(codFilme, numeroFita) referencia Fitas

codCliente referencia Clientes

Reservas (codfilme, codCliente, dtReserva, situacao)

codFilme referencia Filmes

codCliente referencia Clientes

Capítulo 4

127

Banco de Dados I

Classes (codClasse, nome, valor)

Obs.: Considere a entrada obrigatória de todos os campos, exceto os campos: telefones, data de devolução de fitas e valor de multa.

Não permita valores diferentes de ‘S’ ou ‘N’ nos campos “lanca-mento”, na tabela “Filmes”, e “dublada”, na tabela “Fitas”.

Este capítulo teve como objetivo o de apresentar conceitos de lin-guagens de consultas formais e comerciais para Bancos de Dados Relacionais. Em especial, foram exploradas as linguagens: Álgebra Relacional e SQL.

Banco de Dados é uma disciplina com um leque muito grande de conteúdos a serem explorados. Banco de Dados I, como uma pri-meira disciplina relacionada com a área, incluiu conceitos introdu-tórios e essenciais de Banco de Dados. A próxima disciplina explo-rará aspectos relacionados com programação dentro dos Bancos de Dados e outros conceitos mais avançados.


128


NAVATHE, Elmasri. Sistemas de Bancos de dados. 4. ed. São Paulo: Pearson Addison Wesley, 2005.

DATE, Christopher. J. Bancos de dados: introdução aos sistemas de bancos de dados. 8. ed. Rio de Janeiro: Campus, 2004.

SILBERSCHATZ, Abraham. Sistema de banco de dados. 5. ed. São Paulo: Campus, 2006.

CHEN, Peter. Modelagem de Dados - A abordagem Entidade-Relacionamento para Pro-jeto Lógico. São Paulo: Makron Books, 1990.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. Porto Alegre: Sagra Luzzato, 2004.

FALBO, Ricardo Almeida. Projeto de Sistemas – Notas de Aula. Disponível em http://www.inf.ufes.br/%7Efalbo/disciplinas/projeto.html. Acesso em 23 de março de 2009.

COUGO, Paulo. Modelagem Conceitual e Projeto de Banco de Dados. Rio de Janeiro: Campus, 1997.

POMPILHO, S. Análise Essencial – guia prático de Análise de Sistemas. Rio de Janeiro: Editora Ciência Moderna Ltda, 2002.

SHLAER, S., MELLOR, S. J. Análise de Sistemas Orientada para Objetos. São Paulo: McGraw-Hill : Newstec, 1990.

apostila - banco de dados i 2011-03 (1)

Documents