Apostila - Banco de Dados I 2011-03

PROF.
CLAUDINETE VICENTE BORGES FERREIRA
BANCO DE DADOS I
SERRA 2011
Governo Federal Ministro de Educao Fernando Haddad Ifes Instituto Federal do Esprito Santo Reitor Denio Rebello Arantes Pr-Reitora de Ensino Cristiane Tenan Schlittler dos Santos Coordenadora do CEAD Centro de Educao a Distncia Yvina Pavan Baldo Coordenadores da UAB Universidade Aberta do Brasil Elton Siqueira Moura Danielli Veiga Carneiro Sondermann Curso de Tecnologia em Anlise e Desenvolvimento de Sistemas Coordenao de Curso Andromeda Gorete Correa de Menezes Designer Instrucional Aline Freitas da Silva Professor Especialista/Autor Claudinete Vicente Borges Ferreira
Catalogao da fonte: Rogria Gomes Belchior - CRB 12/417 F383b Ferreira, Claudinete Vicente Borges Banco de dados I. / Claudinete Vicente Borges Ferreira. Vitria: Ifes, 2011. 129 p. : il. 1. Banco de dados. I. Instituto Federal do Esprito Santo. II. Ttulo. CDD 005.74
DIREITOS RESERVADOS Ifes Instituto Federal do Esprito Santo Avenida Rio Branco, n 50 Santa Lcia - CEP. 29056-255 Vitria ES - Telefone: 3227-5564 Crditos de autoria da editorao Capa: Juliana Cristina da Silva Projeto grfico: Juliana Cristina e Nelson Torres Iconografia: Nelson Torres Editorao eletrnica: Duo Translations Reviso de texto: Esther Ortlibe Faria de Almeida COPYRIGHT proibida a reproduo, mesmo que parcial, por qualquer meio, sem autorizao 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 Anlise e Desenvolvimento de Sistemas, na modalidade a distncia. Apesar de este curso ser ofertado a distncia, esperamos que haja proximidade entre ns, pois, hoje, graas aos recursos da tecnologia da informao (e-mail, chat, videoconferncia, etc.), podemos manter uma comunicao efetiva. importante que voc conhea toda a equipe envolvida neste curso: coordenadores, professores especialistas, tutores a distncia e tutores presenciais, porque, quando precisar de algum tipo de ajuda, saber a quem recorrer. Na EaD - Educao a Distncia, voc o grande responsvel pelo sucesso a aprendizagem. Por isso, necessrio que voc se organize para os estudos e para a realizao de todas as atividades, nos prazos estabelecidos, conforme orientao dos Professores Especialistas e Tutores. Fique atento s orientaes de estudo que se encontram no Manual do Aluno. A EaD, pela sua caracterstica de amplitude e pelo uso de tecnologias modernas, representa uma nova forma de aprender, respeitando, sempre, o seu tempo. Desejamos-lhe sucesso e dedicao! Equipe do Ifes
ICONOGRAFIA
Veja, abaixo, alguns smbolos utilizados neste material para gui-lo em seus estudos
Fala do Professor
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por voc, aps a leitura dos textos.
Indicao de leituras complemtares, referentes ao contedo estudado.
Destaque de algo importante, referente ao contedo apresentado. Ateno!
Reflexo/questionamento sobre algo importante referente ao contedo apresentado.
Espao reservado para as anotaes que voc julgar necessrias.
BANCO DE DADOS I
Cap. 1 - CONCEITOS DE BANCOS DE DADOS 9
1.1 Definio 9 1.2 Objetivos 10 1.3 Sistemas de arquivos convencionais 11 1.4 Usurios de banco de dados 12 1.6 Independncia de Dados 14 1.7 Arquitetura de sistemas de banco de dados 15 1.7.1 Sistemas Centralizados 15 1.7.2 Sistemas cliente-servidor 15 1.7.3 Sistemas Paralelos 16 1.7.4 Sistemas Distribudos 16 1.8 Modelos de bancos de dados 17 1.8.1 Modelo em rede 17 1.8.2 Modelo herrquico 18 1.8.3 Modelo relacional 19 1.8.4 Modelo objeto-relacional 20 1.8.5 Modelo orientado a objeto 20 1.9 Estrutura geral do sistema 21 1.9.1 Componentes de processamentos de consultas 21 1.9.2 Componentes para administrao do armazenamento de dados 21 1.9.3 Outras estruturas de dados 22 1.10 Linguagem de definio de dados (DDL) 23 1.11 Linguagem de manipulao de dados (DML) 24 1.12 Projetando bancos de dados 24
Cap. 2 - MODELAGEM DE DADOS 29

2.1 Introduo 29 2.2 Modelos 29 2.3 Motivos para construo de modelos 30 2.4 Modelo de entidades e relacionamentos - E/R 30 2.4.1 Entidades 31 2.4.2 Atributos 32 2.4.3 Relacionamentos 36 2.5 Dicionrio de dados 45 2.6 Exemplo de um modelo de dados 46 2.7 Ferramentas case 48 2.8 Modelo ER estendido - EER 48
Cap. 3 - PROJETO LGICO DE BANCO DE DADOS 51

3.1 Definio 51 3.2 Estrutura dos bancos de dados relacionais 51 3.3 Chaves 53 3.4 Propriedades do modelo relacional 55 3.5 Traduo do modelo ER para o relacional 56 3.5.1 Relacionamento 1:1 58 3.5.2 Relacionamento 1:N 59 3.5.3 Relacionamento 1:N - identificado 59 3.5.4 Relacionamento N:N 60 3.5.5 Generalizao e especializao 61 3.5.6 Autorrelacionamento 1:N 63 3.5.7 Autorrelacionamento N:N 63 3.5.8 Atributos multivalorados 64 3.6 Exemplo de projeto lgico 65 3.7 Normalizao 66 3.7.1 Primeira forma normal (1FN) 67 3.7.2 Segunda forma normal (2FN) 67 3.7.3 Terceira forma normal (3FN) 68
Cap. 4 - LINGUAGENS DE CONSULTA 71

4.1 Definio 71 4.2 lgebra Relacional 72 4.2.1 Operaes fundamentais 73 4.2.2 Operaes no-fundamentais 88 4.3 SQL 95 4.3.1 Linguagem de manipulao de dados SQL DML 96 4.3.2 Linguagem de definio de dados SQL DDL 120
REFERNCIAS 129
APRESENTAO
Ol!
Meu nome Claudinete Borges, responsvel pela disciplina Banco de Dados I. Atuo como professora do Ifes h cinco anos e j lecionei em outras instituies de ensino superior, como Ufes, UVV e Unilinhares. Sou graduada em Cincia da Computao (1995) e mestre em Informtica (2001), ambos pela UFES. Minhas reas de interesse so Banco de Dados e Engenharia de Software. Nesta disciplina voc conhecer conceitos de modelagem e de bancos de dados. Os Bancos de Dados so responsveis por manter a persistncia dos sistemas de informaes existentes no mercado, o que nos mostra a importncia da disciplina em um curso de Anlise de Sistemas. Este material tem como objetivo o de orient-lo no estudo da disciplina Banco de Dados I, por meio de dicas e sugestes, com destaque aos pontos mais importantes. Aqui voc encontrar conceitos com os quais trabalharemos ao longo do Curso, tendo sido elaborado tomando como referncia livros clssicos das reas correlatas, tais como Abraham Silberschatz, Peter Chen, Carlos Alberto Heuser, Elmasri Navathe e outros. Alm destes autores, teve a contribuio valiosa da professora e amiga Eliana Caus que muito enriqueceu com suas notas de aula e sugestes. Apesar disso, este material impresso no dispensa a utilizao dos livros referenciados na bibliografia, que trazem diversos exemplos adicionais e aprofundamento maior em vrios aspectos. Os conceitos aqui apresentados devem ser bem assimilados, pois serviro de base para a disciplina Banco de Dados II, a ser ofertada no prximo semestre, e para sua vida profissional, caso voc faa a opo por trabalhar na rea de Anlise de Sistemas. Foi preparado para voc com muito carinho! Sucesso!!!
Profa. Claudinete Vicente Borges Ferreira
Tecnologia em Anlise e Desenvolvimento de Sistemas
CONCEITOS DE BANCOS DE DADOS
Ol, Neste captulo voc ter um primeiro contato com a disciplina Banco de Dados. A proposta de apresentar conceitos importantes que serviro de base para o restante do curso. Bom estudo! Profa. Claudinete Vicente Borges
1.1
Definio
Um banco de dados, tambm conhecido como base de dados, um conjunto de arquivos estruturados de forma a facilitar o acesso a conjuntos de dados. Esses arquivos encontram-se, de alguma forma, relacionados. Por exemplo, em um banco de dados de funcionrios de uma empresa podemos encontrar alguns arquivos, tais como: dados pessoais (nome, endereo, dados de documentos, lotao), dados funcionais (cargo, data de admisso, etc.) e dados para pagamento (salrio base, faixas, etc.). Para obter informaes sobre um dado funcionrio, como nome, cargo e salrio, ser necessrio consultar os trs arquivos, que devem estar relacionados. Segundo Heuser, um banco de dados um conjunto de dados integrados, cujo objetivo atender uma comunidade de usurios [HEUSER, 2004]. Com o crescimento do volume e dos tipos de dados nas organizaes, preciso utilizar softwares especiais para gerenci-los, os chamados SGBDs (Sistemas Gerenciadores de Banco de Dados). Um SGBD um software de carter geral para a manipulao eficiente de grandes colees de informaes estruturadas e armazenadas de uma forma consistente e integrada. Tais sistemas incluem mdulos para consulta, atualizao e as interfaces entre o sistema e o usurio. Podemos afirmar, ento, que um SGBD constitudo por um conjunto de dados associados a um conjunto de programas para acesso a estes dados [SILBERSCHATZ, 2006]. A figura 1 abaixo representa este conceito de forma grfica.
10
Captulo 1
conjunto de programas
arquivos interrelacionados
Figura 1 - Ilustrao do conceito de um SGBD.
Um banco de dados um conjunto de dados integrados, cujo objetivo atender uma comunidade de usurios [ HEUSER, 2004]. Um SGBD um software de carter geral, usado para manipulao eficiente de grandes colees de informaes estruturadas e armazenadas de uma forma consistente e integrada [SILBERSCHATZ, 2006]. SGBD = Conjunto de programas + Conjunto de dados.
1.2
Objetivos
Dentre os principais objetivos do uso de Sistemas Gerenciadores de Bancos de Dados, destacam-se: Disponibilizar dados integrados para uma grande variedade de usurios e aplicaes por meio de interfaces amigveis; garantir a privacidade dos dados por meio de medidas de segurana dentro do sistema (como vises, permisses, senhas de acesso); permitir compartilhamento dos dados de forma organizada, mediando a comunicao entre aplicaes e banco de dados e administrando acessos concorrentes; possibilitar independncia dos dados, poupando ao usurio a necessidade de conhecer detalhes de implementao interna, organizao de arquivos e estruturas de armazenamento.
Conceitos de Bancos de Dados
11
1.3
Sistemas de arquivos convencionais
Os sistemas de processamento de arquivos caracterizam-se por uma srie de registros guardados em diversos arquivos e uma srie de programas aplicativos para extrair e adicionar registros nos arquivos apropriados. Podemos citar como desvantagens desse sistema (arquivos), em relao aos SGBDs [SILBERSCHATZ,2006]:
Redundncia e inconsistncia de dados: considerando que diferentes
programadores tm a possibilidade de criar arquivos com estruturas diferentes e aplicaes para acess-los, a possibilidade de se redundar dados por esses arquivos muito grande. Alm disso, em funo dessa redundncia, podero ocorrer as inconsistncias, considerando que os dados podero ser atualizados em alguns arquivos e em outros no;
Dificuldade no acesso aos dados: diferentemente dos SGBDs, os siste-
mas de arquivos no possuem um ambiente para recuperao dos dados armazenados. Com isso, para cada informao a ser gerada, necessrio construir uma aplicao;
Isolamento de dados: considerando a diversidade de formatos existentes
dos arquivos e, consequentemente, dos dados armazenados neles, torna-se uma tarefa difcil a construo de aplicaes para a recuperao desses dados;
Problemas de atomicidade: o conceito de atomicidade est altamente
relacionado ao de tomo, que se caracteriza como algo indivisvel. Quando se fala em atomicidade em banco de dados, fala-se de uma unidade de trabalho que se deve executar totalmente ou que no se deve executar. Um exemplo clssico de atomicidade seria uma transferncia de dinheiro entre duas contas, A e B. Se desejarmos transferir, por exemplo, R$ 100,00 da conta A para a Conta B, ou este valor ser transferido integralmente ou no ocorrer a transferncia. No cabvel que o dinheiro saia da conta A e no entre na conta B, por exemplo!
Anomalias de acesso concorrente: considerando o acesso simultneo aos
arquivos, por diferentes aplicaes ou por diferentes usurios de uma mesma aplicao, pode-se gerar inconsistncias nesses arquivos devido a esses acessos. Tomemos como exemplo que uma conta conjunta A - com saldo igual a R$ 1000,00 - foi acessada de forma simultnea pelos correntistas Gabriel e Luiza. Gabriel sacou R$100,00 e Luiza, R$200,00. Pergunta-se: qual o saldo da conta aps os saques? Se ambos leram o valor do saldo igual a R$1000,00, podemos ter como possveis valores : R$900,00, R$800,00, levando-se em conta qual valor foi esBanco de Dados I
12
Captulo 1
crito por ltimo. Nesse caso, nenhum dos dois valores so os corretos. O correto seria ter um saldo igual a R$700,00.
Problemas de segurana:. nem todos os usurios possuem perfil para
acessar todos os dados disponveis em um arquivo. Tomemos como exemplo um arquivo de funcionrios, que possui, entre outros dados, o valor do salrio do funcionrio. Embora tenhamos a curiosidade de saber o salrio dos nossos colegas, principalmente do nosso chefe, no politicamente correto que desrespeitemos seu direito privacidade. No entanto, no possivel definir, para um arquivo, que alguns campos podero ser visveis por um usurio e por outros no, o que gera vulnerabilidade nesses sistemas;
Problemas de integridade: para explicar melhor esse item, tomemos
como exemplo dois arquivos, um de scios e outro de dependentes, de uma locadora de vdeo. Um dependente est relacionado a um scio e, por consequncia, a existncia daquele depende da existncia deste, ao qual estar subordinado. Desse modo, a excluso de um scio acarreta a excluso de seus dependentes. Esse tipo de integridade denomina-se de integridade referencial, porm, existem outras mais simples que os arquivos no comportam.
Considerando que as caractersticas descritas no so includas nos arquivos convencionais, elas devem ser includas nas aplicaes. Imagine a complexidade das aplicaes escritas para implement-las! Os Sistemas de Bancos de Dados de mdio e grande porte existentes no mercado implementam esses conceitos com muita robustez.
Voc deve estar pensando: ser que existem vantagens em usar os sistemas de arquivos? O custo mais baixo pode ser considerado uma vantagem.
1.4
Usurios de banco de dados
Basicamente so quatro os tipos de usurios de sistemas de bancos de dados: Usurios leigos: interagem com o banco de dados por meio das interfaces de aplicaes escritas por programadores de aplicaes;
13
Usurios avanados: interagem com os bancos de dados por meio de interfaces disponveis nesse ambiente. Escrevem consultas SQL e as submetem execuo sem a necessidade de escrever uma aplicao para esse fim; Programadores aplicaes: usurios com formao em computao e que se propem a construir aplicaes, por meio de ferramentas (compiladores) destinadas para esse fim. Utilizando essas ferramentas, constroem interfaces para as aplicaes, incluindo formulrios e relatrios, acessando bancos de dados; Administrador de Banco de Dados (DBA): usurios mais especializados para um banco de dados. Cabe a eles a administrao dessas bases, definio da melhor estrutura de armazenamento desses dados, definio de aspectos de segurana, programao de cpias de segurana (backups), dentre outros.
O DBA pode ser comparado com um profissional da rea mdica. Se for responsvel por sistemas que requerem alta disponibilidade, deve ficar de planto 24 h por dia.
1.5 Abstrao de dados

Considerando que o nvel de conhecimento dos usurios de bancos de dados muito varivel, oscilando entre aqueles que conhecem muito e outros que so leigos, os Sistemas de Bancos de Dados devem prover de mecanismos que administrem essa complexidade, simplificando as interaes dos usurios com o sistema. Para isso, trs nveis de abstrao so considerados: Nvel de Viso: diz respeito forma como os dados so vistos pelos usurios (individualmente). Diferentes usurios podero ter diferentes vises de um mesmo banco de dados. Um determinado usurio, tanto pode ser um programador de aplicaes quanto um usurio final. O DBA um caso especialmente importante. Ao contrrio dos usurios comuns, o DBA ter de se interessar pelos nveis lgico e fsico. Lgico: o nvel lgico descreve quais dados esto armazenados no banco de dados e qual a relao existente entre eles. Podemos dizer que a viso lgica a viso dos dados como realmente so e no como os usurios so forados a v-los devido s restries de linguagem ou hardware.
Banco de Dados I
14
Captulo 1
Fsico: diz respeito forma como os dados esto armazenados fisicamente. Preocupa-se em descrever as estruturas de dados complexas de baixo nvel.
Os SGBDs possibilitam aos usurios uma viso abstrata dos dados, ou seja, os usurios no precisam saber como os dados so armazenados e mantidos para us-los. A figura 2 representa graficamente os nveis listados acima.
Viso 1
Viso 2
---
Viso n
Nvel Lgico
Nvel Fsico
Figura 2 - Nveis de abstrao de dados Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptao.
1.6
Independncia de dados
A independncia de dados pode ser definida como a imunidade das aplicaes s alteraes feitas, seja no nvel fsico ou no nvel lgico de um banco de dados. O objetivo alcanar o mximo de independncia possvel. Pode ser classificada em: Independncia Fsica de dados: habilidade de modificar o esquema fsico, sem a necessidade de reescrever os programas aplicativos. As modificaes no nvel fsico so ocasionalmente necessrias para melhorar o desempenho. Independncia Lgica de dados: habilidade de modificar o esquema conceitual, sem a necessidade de reescrever os programas aplicativos. As modificaes no nvel conceitual so necessrias quando a estrutura lgica do banco de dados alterada.
15
Normalmente, modificaes no nvel fsico visam melhoria de desempenho, como a criao de ndices!
Qual abordagem mais fcil de ser alcanada: independncia fsica ou lgica de dados? Normalmente, a independncia fsica de dados mais fcil de ser alcanada do que a lgica. Ao criar um ndice, como em uma tabela, as aplicaes que referenciam essa tabela devem continuar funcionando, a despeito da alterao feita!
1.7
Arquitetura de sistemas de banco de dados
A arquitetura de um sistema de banco de dados est altamente relacionada s caractersticas do sistema operacional sobre o qual o SGBD ser executado [SILBERSCHATZ, 2006]. 1.7.1 Sistemas centralizados
Os sistemas centralizados so os executados sobre um nico sistema operacional, no interagindo com outros sistemas. Eles podem ter a envergadura de um sistema de banco de dados de um s usurio, executado em um computador pessoal ou em sistemas de alto desempenho, denominados de grande porte. 1.7.2 Sistemas cliente-servidor Como os computadores pessoais tm se tornado mais rpidos, mais potentes e baratos, h uma tendncia de ampliar o seu uso nos sistemas centralizados, por isso terminais conectados a sistemas centralizados esto sendo substitudos por computadores pessoais. Como resultado, os sistemas centralizados atualmente agem como sistemas servidores que atendem a solicitaes de sistemas-cliente. A computao cliente-servidor um processamento cooperativo de informaes de negcio por um conjunto de processadores, no qual mltiplos clientes iniciam requisies que so realizadas por um ou mais servidores centrais. O termo cliente-servidor usado para descrever software que executado em mais de um hardware de modo a realizar uma tarefa do negcio. A separao de hardware a norma em aplicaes cliente-servidor, embora algumas pessoas utilizem o termo para descrever diferentes
Banco de Dados I
16
Captulo 1
componentes de software se comunicando uns com os outros, ainda que rodando em uma mesma mquina. A distncia entre processadores remotos varia desde computadores localizados na mesma sala ou prdio, at aqueles localizados em diferentes prdios, 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 otimizao de consultas, o controle de concorrncia e a recuperao. O frontend consiste em ferramentas como formulrios, gerador de relatrios e recursos de interface grfica. A interface entre o front-end e o back-end feita por meio de SQL ou de um programa de aplicao. 1.7.3 Sistemas paralelos Sistemas paralelos imprimem velocidade ao processamento e CPU, por meio do uso em paralelo de CPUs e discos. No processamento paralelo muitas operaes so realizadas ao mesmo tempo, ao contrrio do processamento serial, no qual os passos do processamento so sucessivos. Um equipamento paralelo de granulaogrossa consiste em poucos e poderosos processadores (a maioria dos servidores atuais), enquanto um paralelismo intensivo ou de granulao fina usa milhares de pequenos processadores, com capacidade menor de processamento. Computadores paralelos com centenas de processadores j esto disponveis comercialmente. As duas principais formas de avaliar o desempenho de um sistema de banco de dados so pelo throughput e pelo tempo de resposta. O primeiro diz respeito ao nmero de tarefas que podem ser executadas em um dado intervalo de tempo. Um sistema que processa um grande nmero de pequenas transaes pode aumentar o throughput por meio do processamento de diversas transaes 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 transaes pode reduzir o tempo de resposta por meio de processamento em paralelo. 1.7.4 Sistemas distribudos Em um sistema distribudo, o banco de dados armazenado, geograficamente, em diversos computadores denominados sites. Os computadores de um sistema de banco de dados distribudos comunicam-se com outros por intermdio de vrios meios de comunicao, como redes de alta velocidade ou linhas telefnicas.
17
As principais diferenas entre os bancos de dados paralelos e os bancos de dados distribudos so que, nos bancos de dados distribudos, h a distribuio fsica geogrfica, a administrao ocorre de forma separada e h uma intercomunicao menor. Outra grande diferena que nos sistemas distribudos distinguimos transaes locais (acessa um nico computador, em que a transao foi iniciada) e globais (envolve mais de um computador, sendo necessria a participao de um coordenador). H diversas razes para a utilizao de sistemas de bancos de dados distribudos, dentre as quais: compartilhamento dos dados (usurios de um local podem ter acesso a dados residentes em outros por exemplo: bancos), autonomia (cada local administra seus prprios dados) e disponibilidade (se porventura um SGBD sair do ar, os demais podem continuar em operao). H, no entanto, algumas desvantagens relacionadas ao seu uso, dentre as quais: custo de desenvolvimento de software, maior possibilidade de bugs e aumento do processamento e sobrecarga.
1.8
Modelos de bancos de dados
Os modelos de bancos de dados definem a forma como os dados encontram-se organizados internamente. Em ordem cronolgica, os modelos de banco de dados classificam-se em redes, hierrquicos, relacionais, objeto-relacionais e orientados a objetos. A seguir, h uma breve descrio sobre cada um desses modelos. 1.8.1 Modelo em rede Um banco de dados em rede consiste em uma coleo de registros que so concatenados uns aos outros por meio de ligaes. Um registro , em muitos aspectos, similar a uma entidade no modelo entidade-relacionamento. Uma ligao uma associao entre dois registros. Assim, uma ligao pode ser vista como um relacionamento binrio no modelo ER [SILBERSCHATZ, 2006]. Tanto o Modelo Rede como o Modelo Hierrquico podem ser considerados como estruturas de dados em nvel lgico mais prximo do nvel fsico. Devido a essa proximidade ao nvel fsico, as estruturas de dados rede e hierrquica exibem as rotas lgicas de acesso de dados de forma acentuada, possibilitando a localizao lgica de um determinado registro no banco de dados. O Modelo Relacional, quando comparado Estrutura Rede e Hierrquica, mais orientado para modelagem do que como modelo com rotas de
Banco de Dados I
18
Captulo 1
acesso, embora possamos considerar as diversas redundncias existentes em diversas tabelas como sendo uma forma de rota de acesso. O Modelo Rede utiliza como elemento bsico de dados a ocorrncia de registro. Um conjunto de ocorrncia de registro de um mesmo tipo determina um tipo de registro. Um conjunto de tipos de registros relacionados entre si, por meio de referncias especiais, forma uma estrutura de dados em rede. As referncias especiais so conhecidas como ligaes, que, por sua vez, podem ser implementadas sob a forma de ponteiros. As referncias esto normalmente inseridas junto com as ocorrncias de registro; assim, todo o acesso a um prximo registro utiliza o ponteiro inserido no registro corrente disponvel. Considere um banco de dados com registros de DEPARTAMENTO e EMPREGADO, em que EMPREGADO possui as seguintes caractersticas: matrcula, nome e cidade; e DEPARTAMENTO: cdigo e nome. A figura 3 mostra um exemplo do banco de dados, considerando os dois tipos de registros informados.
01 02 03
Informtica Geografia Portugus
100 101 102 103
Luiza
Vitria
Matheus Vila Velha Gabriel Serra Joana Aracruz
Figura 3 - Exemplo de Banco de Dados Modelo Redes.
O modelo de banco de dados da Figura 3 mostra as ligaes entre os registros de departamento e empregado. Luiza, por exemplo, est lotada no Departamento de Informtica, enquanto o Departamento de Geografia, por exemplo, possui dois funcionrios lotados, Matheus e Gabriel. 1.8.2 Modelo hierrquico Um banco de dados hierrquico consiste em uma coleo de registros relacionados, uns aos outros, por meio de ligaes, como no modelo em redes. A diferena entre eles se d pelo fato de o banco de dados hierrquico organizar esses registros como colees de rvores, em vez de grafos arbitrrios. Um banco de dados hierrquico compe-se de um conjunto ordenado
19
de rvores, mais precisamente, de um conjunto ordenado de ocorrncias mltiplas de um tipo nico de rvore. O tipo rvore compe-se de um nico tipo de registro raiz, juntamente com um conjunto ordenado de zero ou mais (nvel inferior) tipos de sub-rvores dependentes. Um tipo de subrvore, por sua vez, tambm se compe de um nico tipo de registro. A associao entre tipos de registros segue uma hierarquia estabelecida por diversos nveis. No primeiro nvel, o superior, situa-se o tipo de registro Raiz . Subordinado a ele, em nvel 2, uma srie de outros tipos de registros em nvel 2. A cada tipo de registro em nvel 2 subordina-se um outro conjunto de tipos de registros. A prpria estrutura hierrquica define as suas rotas de acesso, facilitando, portanto, a manuteno do banco de dados. importante notar que um determinado tipo de registro B, num determinado nvel K, possui ligao com um e somente um tipo de registro A, de nvel K-1 (superior). Nessas condies, 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 nvel de B. Todas as ocorrncias de um dado tipo de filho que compartilham uma ocorrncia de pai comum so chamadas de gmeas. Uma vantagem dos bancos de dados hierrquicos o tempo de resposta em consultas. No entanto, a atualizao pode ser bastante custosa. A figura 4 abaixo ilustra um exemplo do modelo Hierrquico.
01 01
Informtica Informtica 02 01 Informtica Geografia
03
Portugus
100
Luiza
Vitria 102 Gabriel Vila Velha 103 Serra
101
Matheus
Joana
Aracruz
Figura 4 - Exemplo de Banco de Dados Modelo Hierrquico.
1.8.3 Modelo relacional O modelo relacional, diferentemente dos modelos redes e hierrquico, usa um conjunto de tabelas para representar tanto os dados quanto a relao entre eles. As ligaes entre as tabelas feita por meio dos valores dos atributos ou colunas, conforme descrito posteriormente. Cada tabela possui mltiplas colunas e pode possuir mltiplas linhas. As tabelas 1 e 2 abaixo mostram exemplos de Tabelas do modelo relacional.
Banco de Dados I
20
Captulo 1
Tabela 1 - Tabela EMPREGADOS Matricula 01 02 03 04 Nome Maria Matheus Gabriel Joana Cidade Vitria Vila Velha Serra Aracruz CodDepto 01 02 02 03
Tabela 2 - Tabela DEPARTAMENTOS CodDepto 01 02 03 NomeDepto Informtica Geografia Portugus
1.8.4 Modelo objeto-relacional O modelo objeto-relacional, tambm conhecido como relacional estendido, um modelo intermedirio entre o relacional e o orientado a objetos. Na verdade, os bancos de dados que se enquadram nesse modelo caracterizam-se por usar a estrutura bsica do modelo relacional, incorporando algumas caractersticas dos bancos de dados orientados a objetos. Estas caractersticas incluem : herana de tipos e tabelas e definio 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, hierrquico e redes foram muito bem sucedidos no desenvolvimento da tecnologia de banco de dados necessria para a maioria das aplicaes convencionais de bancos de dados comerciais, possuindo, entretanto, algumas limitaes quando aplicaes mais complexas precisam ser projetadas e implementadas, tais como sistemas de informaes geogrficas e multimdias. Essas aplicaes tm requisitos e caractersticas que as diferenciam das tradicionais aplicaes comerciais, tais como estruturas complexas para objetos, armazenamento de imagens e textos longos, dentre outras, alm da necessidade de definir operaes no 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 linguagens de consulta disponveis em sistemas de banco de dados tradicionais. Nesses bancos, o projetista especifica a estrutura de objetos complexos bem como as operaes que incidem sobre esses objetos.
21
Outra razo para o uso de banco de dados orientados a objetos a predominncia das linguagens orientadas a objetos. No caso de uma aplicao orientada a objetos utilizar um banco de dados relacional para persistir os dados, necessrio fazer um mapeamento entre esses dois mundos, o que d trabalho, considerando as limitaes impostas pelo modelo relacional. Embora existam muitos benefcios para a adoo do modelo orientado a objetos, esses bancos de dados no foram muito bem aceitos no mercado em funo da simplicidade do modelo relacional. Com isso, h uma proposta de um modelo hbrido, denominado objeto-relacional ou relacional estendido, que se prope a implementar alguns conceitos de orientao a objetos sobre a estrutura de um banco de dados relacional. Alguns SGBDs proprietrios e livres disponveis no mercado enquadram-se nesse modelo, a exemplo do Oracle e do PostgreSQL.
1.9
Estrutura geral do sistema
O sistema de banco de dados dividido em mdulos especficos, de modo a atender a todas as suas funes, algumas delas fornecidas pelo sistema operacional. Esses mdulos podem ser organizados em dois grandes grupos: o de processamentos de consultas e o de administrao 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 consulta em instrues de baixo nvel, inteligveis ao componente de execuo de consultas. Interpretador DDL: interpreta os comandos DDL e registra-os em um conjunto de tabelas que contm metadados, ou seja, dados sobre dados. Componentes para o tratamento de consultas: executam instrues de baixo nvel geradas pelo compilador DML. 1.9.2 Componentes para administrao do armazenamento de dados Gerenciamento de autorizaes e integridade: testa o cumprimento das regras de integridade e a permisso ao usurio no acesso aos dados. Gerenciamento de transaes: garante que o banco de dados permanecer em estado consistente, a despeito de falhas no sistema, e que
Banco de Dados I
22
Captulo 1
as transaes concorrentes sero executadas sem conflitos em seus procedimentos. Gerenciador de arquivos: gerencia a alocao de espao no armazenamento em disco e as estruturas de dados usadas para representar essas informaes armazenadas em disco. Gerenciador de buffer: intermedia os dados entre o disco e a memria principal e decide quais dados colocar em cach. 1.9.3 Outras estruturas de dados Diversas outras estruturas de dados so requeridas como parte da implementao do sistema fsico, incluindo: Arquivo de Dados: armazena o banco de dados. Dicionrio de Dados: armazena informaes sobre os dados do banco de dados. ndices: permite o acesso mais rpido aos dados. Estatsticas: armazenam informaes sobre o banco de dados e so usadas pelo seletor de estratgias.

Usurios Leigos (caixas, agentes, usurios da Web) usa Interfaces de aplicao Usurios avanados (analistas) usa Ferramenta de consulta
23
Programadores de aplicao escreve Programas de aplicao
Administrador de banco de adados usa Ferramentas de Administrao
Compitaldor e linkeditor
Consultas de DML
Interpretador de DDL
Cdigo de objetos do programa de aplicao
Compilador e organizador de DML
Mecanismo de avaliao de consulta
Processador de consulta
Gerenciador de buffer
Gerenciador de arquivos
Gerenciador de autorizao e integridade
Gerenciador de transao
Gerenciador de armazenamento
Dados
Indices
Dicionrio de dados
Armazenamento de disco
Dados estatsitcos
Figura 5 - Estrutura Geral do Sistema Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptao.
1.10 Linguagem de definio de dados (DDL)

Contm a especificao dos esquemas dos bancos de dados. O resultado da compilao de uma consulta de definio de dados (DDL) armazenado em um conjunto de tabelas que constituem um arquivo especial chamado dicionrio de dados. Um dicionrio de dados um arquivo de metadados.
Principais comandos SQL-DDL: CREATE TABLE; ALTER TABLE; DROP TABLE; CREATE INDEX; ALTER INDEX; DROP INDEX;
Banco de Dados I
24
Captulo 1
1.11
Linguagem de manipulao de dados (DML)
A linguagem de manipulao de dados (DML) a linguagem que viabiliza o acesso aos dados ou a sua manipulao de forma compatvel com o modelo de dados apropriado. So responsveis pela: recuperao da informao armazenada no banco de dados (SELECT); insero de novos dados nos bancos de dados (INSERT); eliminao de dados nos bancos de dados (DELETE); modificao de dados armazenados no banco de dados (UPDATE). Os comandos DDL so responsveis por definir as estruturas dos dados, enquanto os comandos DML so responsveis por manipular os dados armazenados nessas estruturas!
1.12 Projetando bancos de dados

Antes de criarmos o banco de dados propriamente dito, devemos identificar uma forma de planej-lo. Esse planejamento extremamente importante para a estabilidade de todo o sistema. Estudos indicam que quanto maior o tempo gasto no projeto do banco de dados, menor ser o tempo despendido na manuteno do modelo. Podemos comparar a criao de um sistema de banco de dados com a construo de uma casa. Imagine que seja construda 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 manuteno, o proprietrio teria o inconveniente de construir quartos do lado da cozinha ou mesmo ter que fazer puxadinhas para realizar a ampliao da mesma. O mesmo acontece com sistemas mal-projetados ou no-projetados. Eles tornam-se pouco flexveis a manutenes futuras, quando for necessrio agregar novas informaes, ou mesmo quando submetidos a correes. O processo de projetar um banco de dados inclui trs fases distintas e integradas. A primeira delas consiste na construo de um modelo conceitual. O Modelo Conceitual inclui caractersticas a serem includas no sistema, mas que independem da tecnologia a ser utilizada, tanto de banco de dados quanto de linguagem de programao. A segunda fase pressupe a construo de um modelo lgico, tendo como base o ModeTecnologia em Anlise e Desenvolvimento de Sistemas
25
lo Conceitual criado e inclui a definio de tabelas, campos, restries de integridade, etc. Neste modelo, considera-se a tecnologia do banco de dados a ser usado, como: relacional, orientado a objetos, etc. A terceira fase, que extrapola a fase de projeto, consiste na criao fsica do banco de dados, tendo a preocupao com estruturas de armazenamento e recuperao dos dados a serem armazenados. Nos captulos que se seguem sero explorados a modelagem conceitual e o projeto lgico de banco de dados, considerando o modelo relacional.
ATIVIDADE 1 Faa os exerccios de fixao abaixo, referentes ao capitulo 1. 1) Defina SGBDs. 2) Cite duas desvantagens do uso de sistemas de arquivos em relao a SGBDs. 3) Defina uma vantagem de se usar sistemas de arquivos em relao a SGBD. 4) Cite as quatro arquiteturas de banco de dados existentes no mercado. Descreva, em poucas linhas, as caractersticas de cada uma delas. 5) Quais so os nveis de abstrao proporcionados por um SGBD? Enquadre, para cada grupo de usurio abaixo listados, o nvel em que o mesmo se encontra. a. Administrador de Banco de Dados b. Usurio de aplicaes c. Programador e Analista de Aplicaes 6) Liste, em ordem cronolgica, os modelos de bancos de dados existentes no mercado. Qual modelo de banco de dados ser utilizado em nossa disciplina?
Banco de Dados I
26
Captulo 1
ATIVIDADE 2 1) Dadas as relaes abaixo, responda ao que se pede. Funcionrios matricula 01 02 03 04 05 06 Cargos codigo 01 02 03 04 05 nomeCargo Programador Topgrafo Engenheiro Pedreiro Motorista nome Ana Maria Jos Pedro Joana Joo CPF 123 234 245 125 435 467 cargo 2 1 3 1 2 1
Liste os nomes dos funcionrios para os seguintes cargos: Topgrafo; Engenheiro; Programador. Para quais cargos no h funcionrios 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...
27
ATIVIDADE 3 1) Numere a segunda coluna de acordo com a primeira. 1. Possibilidade de erros de acesso concorrente 2. Abstrao de dados ( ) Refere-se preciso ou validade dos dados. ( ) Tarefa de um SGBD. ( ) Se alterar o esquema 3. Integridade conceitual, no necessrio reescrever aplicaes. ( ) Responsvel pela modi4. Instncia ficao de dados armazenados no banco de dados. ( ) Se alterar o esquema fsi5. Independncia lgica co, no necessrio reescrever de dados aplicaes. 6. Independncia fsica ( ) Contm a especificao de dados dos esquemas de banco. ( ) Conjunto de informaes contidas em determinado 7. Controle de concorrncia banco de dados, em um determinado momento. 8. Linguagem de Definio de ( ) Trata-se de um modelo de Dados (DDL) banco de dados. ( ) Os usurios no precisam 9. Linguagem de Manipulao saber como os dados so armade Dados (DML) zenados e mantidos. ( ) Desvantagem de sistemas 10. Objeto-Relacional de arquivos.
O objetivo deste captulo foi de introduzir conceitos de bancos de dados. So conceitos importantes que serviro de base para entendimento dos conceitos explorados nos captulos subseqentes.
Banco de Dados I
28
MODELAGEM DE DADOS
Ol! Neste captulo voc estudar conceitos de modelagem conceitual de dados. Um modelo conceitual objetiva modelar os requisitos de negcio segundo a viso do usurio, 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
Introduo
O principal objetivo da modelagem conceitual de dados construir modelos que representem os requerimentos das informaes do negcio, segundo a perspectiva do usurio. Partindo desse princpio, ao construir modelos conceituais no h uma preocupao com a tecnologia a ser adotada para a sua implementao. Um modelo de dados consiste em uma coleo de ferramentas conceituais para descrio de dados, relacionamento entre os dados, semntica e restries [SILBERSCHATZ,2006]. Neste captulo, exploraremos o modelo de entidades e relacionamentos (ER) para construo de modelos de dados, considerando que se trata da tcnica de modelagem mais difundida para representao de modelos conceituais.
2.2
Modelos
Um modelo a representao 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 definio, no estamos condicionando que o modelo seja computadorizado. Qualquer ambiente do mundo real passvel de ser modelado, j que o mesmo busca expressar o objeto observado algumas vezes, mesmo antes da existncia fsica, tangvel de tal objeto. Seguem alguns exemplos de modelos:
30
Captulo 2
as plantas de apartamentos dos jornais; o manequim da vitrine; um aeromodelo sendo usado para testes de aerodinmica; o desenho em perspectiva de uma nova cozinha; o molde de uma roupa obtido em uma revista.
O importante, contudo, perceber que atravs de algum meio, seja uma maquete, desenho ou descrio, pode-se antecipar ou substituir a existncia de uma realidade qualquer.
2.3
Motivos para construo de modelos
Segundo Cougo [COUGO,1997], os principais motivos para elaborarmos modelos so: focalizar caractersticas importantes de sistemas, deixando de lado as menos importantes; discutir alteraes e correes nos requisitos do usurio a baixo custo e com mnimo risco; confirmar que o ambiente do usurio foi entendido; representar o ambiente observado; servir de instrumento de comunicao; favorecer o processo de verificao e validao; capturar aspectos de relacionamento entre os objetos observados; servir de referencial para a gerao de estruturas de dados.
2.4 Modelo de entidades e relacionamentos - E/R

O modelo ER uma tcnica de modelagem conceitual utilizada para representar os dados a serem armazenados em um sistema de informao, tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos de dados [CHEN,1990]. Esse modelo foi criado em 1976 por Peter Chen e pode ser considerado como padro para a modelagem conceitual. Basicamente, o modelo ER representa as entidades (coisas) e os relacionamentos (fatos) do mundo real, em que h o interesse de monitorar o comportamento no sistema de informao em tese.
Modelagem de Dados
31
2.4.1 Entidades Entidades so representaes abstratas de coisas, objetos do mundo real modelado, para os quais temos interesse em manter informaes no banco de dados. Podem representar tanto objetos concretos quanto abstratos. Quando se trata de conjuntos de objetos com caractersticas semelhantes, usualmente se denomina conjunto de entidades. Por exemplo: quando nos referimos ao conjunto de entidade Departamentos, estamos falando de um conjunto de departamentos; quando nos referimos ao departamento de informtica, estamos falando da entidade, de uma instncia do conjunto. Um conjunto de entidades ser representado por meio de um retngulo contendo o nome do conjunto de entidades, em letra maiscula e no plural, conforme mostra exemplo da Figura 6. A frase ...para os quais temos interesse em manter informaes no banco de dados... do pargrafo acima, significa dizer que um conjunto de entidades que relevante para um determinado contexto pode no ser para outro. O foco incluir no modelo apenas aqueles conjuntos de entidades que so de interesse para o contexto em questo. Por exemplo: considerando um sistema para uma biblioteca, no h porque modelar as cadeiras como um conjunto de entidades. Agora, se tratarmos de um sistema para controle de patrimnios, as cadeiras so alvo de controle, sendo, ento, modeladas como Conjunto de entidades.
Ex: FUNCIONRIOS, CARGOS, PESSOAS ...
FUNCIONRIOS
CARGOS
Figura 6 - Exemplo de representao de conjunto de entidades
Caractersticas dos conjuntos de entidades [FALBO, 2009]: so substantivos e perduram no tempo; cada elemento de um conjunto de entidades s ocorre uma nica vez e a ordenao do conjunto irrelevante; a princpio so representados em um conjunto de entidades todos os elementos do mundo real referidos pelo conjunto. Ex: FUNCIONRIOS = todos os funcionrios de uma empresa;
Banco de Dados I
32
Captulo 2
para estabelecermos uma padronizao, usaremos nomes de conjuntos de entidades sempre no plural e escritos em letras maisculas. No entanto, isso no representa uma regra.
2.4.2 Atributos A identificao de entidades est diretamente relacionada necessidade de se armazenar dados (caractersticas ou propriedades) a seu respeito. Tais caractersticas ou propriedades so denominadas atributos. O papel do atributo o de descrever caractersticas ou propriedades relevantes de um conjunto de Entidades. Os atributos podem ser representados no diagrama ou em um dicionrio de dados. Adotaremos esta ltima abordagem com o intuito de mantermos um modelo mais legvel. Deseja-se que o processo de identificao de atributos alcance um elenco de atributos que sejam completos, fatorados e independentes [SHLAER,1990]. Completo: Deve abranger todas as informaes pertinentes ao objeto que est sendo definido. Os atributos devem contemplar todas as caractersticas que proporcionem uma perfeita identificao das entidades s quais esteja associado. Assim, ao se definir a entidade PESSOAS, deve-se prever todos os atributos que me permitam caracterizar completamente os elementos (pessoas) que comporo esta entidade. Ex.: Entidade: PESSOAS Atributos: nome, rua, nmero, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil. Fatorado: cada atributo deve ser responsvel por um aspecto. No se deve agrupar responsabilidades acessrias aos atributos. Cada parte, cada caracterstica, deve significar um trao, uma particularidade da entidade e no estar agregando um conjunto de informaes em um nico elemento, em um nico atributo. Ex.: Entidade: PESSOAS Atributos: nome, rua, nmero, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.
Modelagem de Dados
33
Note que o endereo est fracionado nas suas partes constituintes e no agrupado num nico elemento denominado endereo. Independente: os valores que um atributo pode receber (domnio) devem ser independentes uns dos outros. Isso no significa que no possamos ter atributos distintos com o mesmo domnio. Cada atributo possui um conjunto dos possveis valores que pode assumir e isso independe dos demais atributos da entidade. Ex.: Entidade: PESSOAS Atributos: data de nascimento Domnio: deve ter as caractersticas de data e ser menor que a data corrente Consideraes adicionais sobre os atributos: Ainda sobre a identificao 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. So atributos que possuem cardinalidade mxima 1. Ex.: Entidade: FORNECEDORES Atributos: cdigo, CNPJ, razo social, logradouro, nmero, complemento, cidade, estado, cep Atributos Multivalorados: um atributo que pode assumir vrios valores para cada entidade, ao mesmo tempo. Ex.: Entidade: FORNECEDORES Atributos: telefone(0,n) Neste caso, um fornecedor pode ter nenhum ou vrios telefones. Atributos Obrigatrios: um atributo que obriga a existncia de valor para cada entidade. Ex.: Entidade: FORNECEDORES Atributos: cdigo, cnpj, razo social, logradouro, nmero, cidade, estado, cep
Banco de Dados I
34
Captulo 2
Atributos Opcionais: um atributo que NO obriga a existncia de valor para cada entidade. Normalmente so representados no dicionrio de dados entre parnteses. Ex.: Entidade: FORNECEDORES Atributos: (complemento) Atributo Composto: so atributos formados por um ou mais atributos, ou seja, so atributos que abrigam uma estrutura de dado. O atributo nome em uma entidade pessoa tambm poder ser visto como composto se for possvel e necessrio separlos nas suas vrias partes (primeiro-nome, nome-intermedirio, ltimo-nome). Quando no so compostos, os atributos so denominados simples. Ex.: Entidade: FORNECEDORES Atributos: endereo Os atributos compostos sero representados no dicionrio de dados em maisculo e devero ser fatorados, como mostra o exemplo abaixo no qual o ENDERECO um atributo composto: FORNECEDORES = codigo + cnpj + razo social + ENDERECO + telefone(0,n) ENDERECO = logradouro + nmero + (complemento) + cidade + estado + CEP Atributo Determinante ou Identificador: atributo que identifica, de modo nico, uma Entidade. Sero sublinhados no diagrama como forma de distingui-lo dos demais. H quem j chame o atributo identificador de Chave Candidata. Por exemplo: a matrcula de um funcionrio pode ser um atributo identificador, considerando que cada funcionrio ter uma matrcula nica. O atributo nome, no entanto, no pode ser usado para identificar um funcionrio, considerando que existem homnimos. Ex.: Entidade: FORNECEDORES Atributos cdigo
Modelagem de Dados
35
Domnio de um atributo: o conjunto dos possveis valores que um atributo pode assumir. No domnio de um atributo, especificamos o Formato desse atributo, seu tamanho, os valores especificamente. Por exemplo: um atributo nome para uma classe de entidades PESSOAS poder ter como domnio uma cadeia de caracteres, j o atributo sexo poder ter como domnio as opes Masculino ou Feminino. Ex.: Entidade: PESSOAS Atributo: Sexo do Empregado Domnio: Campo Alfanumrico, 1 caracter, s pode assumir os valores F e M As figuras 7, 8 e 9 abaixo mostram exemplos de diferentes formas de representao de Diagramas de Entidades e Relacionamentos.
Atributos tambm descrevem caractersticas de relacionamentos, que veremos na prxima seo.
complemento numero logradouro cidade rua cep estado
cnpj codigo
razao social
endereco nome preco unt codigo
telefone
FORNECEDORES
FORNECIMENTO
PRODUTOS
Figura 7 - Notao para Diagrama Entidade-Relacionamento proposto originalmente por Chen
Banco de Dados I
36
Captulo 2
FORNECEDORES
FORNECIMENTO
PRODUTOS
DICIONRIOS DE DADOS
FORNECEDORES = cdigo + cnpj + razo social + ENDEREO + {telefone} PRODUTOS = codigo + nome + preo unit ENDEREO = RUA + cidade + estado + cep RUA = logradouro + numero + (complemento)
Figura 8 - Notao alternativa para Diagrama Entidade-Relacionamento
complemento (0,1) nmero logradouro cidade rua cep estado
CNPJ
razao social
endereo nome preco unit codigo
codigo
telefone (0,n) FORNECEDORES

FORNECIMENTO PRODUTOS
Figura 9- Outra notao para Diagrama Entidade-Relacionamento
2.4.3 Relacionamentos Na seo anterior descrevemos atributos de conjuntos de entidades, que so propriedades dos objetos a serem armazenados em um banco de dados. Alm dos atributos, os conjuntos de entidades caracterizam-se por relacionar-se com outros conjuntos de entidades, inclusive com elas mesmas. A essas associaes denominamos relacionamentos, ou seja, conjunto de associaes entre entidades [HEUSER, 2004]. Neste texto adotaremos a seguinte notao: um relacionamento ser representado por um losango, com um verbo para indicar a ao e uma seta para informar o sentido de leitura, conforme mostra a Figura 10 abaixo.
Modelagem de Dados
37
FUNCIONRIOS
So enquadrados em
CARGOS
Figura 10 - Exemplo de representao de relacionamento
A leitura feita para o relacionamento da Figura 10 funcionrios so enquadrados em cargos. Todo relacionamento possui uma leitura inversa; assim, uma outra leitura do relacionamento seria cargos enquadram funcionrios. O relacionamento existente entre os conjuntos de entidades funcionrios e cargos um relacionamento binrio, pois se trata de uma associao entre dois conjuntos de entidades. Quando o relacionamento envolve trs conjuntos de entidades conhecido como ternrio. Outros exemplos de relacionamentos: Alunos cursam disciplinas / Disciplinas so cursadas por alunos; Editoras publicam livros / Livros so publicados por editoras; Autores escrevem livros / Livros so escritos por autores. Para facilitar a visualizao foi construdo um diagrama de ocorrncia referente ao modelo ER da Figura 10. Esse diagrama se prope a mostrar as ocorrncias de entidades do conjunto funcionrios, representadas por : f1, f2, ..., fn; as ocorrncias do conjunto cargos, representadas por : c1, c2, .., cn e os relacionamentos existentes entre as entidades do conjunto de funcionrios e de cargos. O funcionrio f1 est enquadrado no cargo c1 atravs do relacionamento r1. O cargo c1, por outro lado, possui os funcionrios f1 e f3, nele enquadrados atravs dos relacionamentos r1 e r3. A figura 11 representa o diagrama de ocorrncia supra citado.
ENQUADRAMENTOS FUNCIONRIOS f1 f2 f3 f4 f5 f6 f7 r1 r2 r3 r4 r5 r6 r7 CARGOS c1 c2 c3
Figura 11 - Diagrama de ocorrncias Fonte: Heuser, 2004. Adaptao. Banco de Dados I
38
Captulo 2
Entre duas entidades, podem existir vrios tipos de relacionamentos. A Figura 12 mostra os relacionamentos de alocao e de gerncia entre os mesmos conjuntos de entidades: FUNCIONRIOS e PROJETOS.
FUNCIONRIOS
So alocados em
PROJETOS
Gerenciam
Figura 12 - Entidades com dois tipos de relacionamento
Alm 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, denomina-se que h um autorrelacionamento do conjunto de entidades FUNCIONRIOS.
FUNCIONRIOS
So alocados em
PROJETOS
Gerenciam Chefiam
Figura 13 - Exemplo de autorrelacionamento
Cardinalidade de relacionamento A cardinalidade indica o nmero mnimo (cardinalidade mnima) e mximo (cardinalidade mxima) de ocorrncias possveis entre dois conjuntos de entidades em um relacionamento. No diagrama de ocorrncia da Figura 11, observa-se que um cargo pode enquadrar vrios funcionrios, enquanto que um funcionrio deve ser enquadrado em apenas um cargo. A Figura 14 mostra a representao de cardinalidade no modelo ER. A leituTecnologia em Anlise e Desenvolvimento de Sistemas
Modelagem de Dados
39
ra feita da seguinte forma: um funcionrio enquadrado em, no mnimo 1 e no mximo 1, cargo enquanto um cargo pode enquadrar no mnimo zero e no mximo n funcionrios. N um nmero arbitrrio. Quando conhecemos esse nmero podemos represent-lo, em vez de o determinarmos pela letra N. Para efeito de projeto de banco de dados, o tratamento dado para esse nmero arbitrrio o mesmo, para qualquer valor maior que 1.
FUNCIONRIOS
(0,n)
So enquadrados em
(1,1)
CARGOS
Figura 14 - Ilustrao do uso de cardinalidade
Observe que, embora parea pouco natural, a cardinalidade vai anotada do outro lado do relacionamento a que se refere. No exemplo acima, um funcionrio enquadrado, no mximo, em um cargo e um cargo, por sua vez, pode enquadrar at n funcionrios.
O relacionamento enquadram total em relao a FUNCIONRIOS e parcial em relao a CARGOS. Esse conceito baseado na cardinalidade mnima do relacionamento. Ele total em relao a FUNCIONRIOS, pois todo funcionrio participa do relacionamento pelo menos uma vez; e parcial em relao a CARGOS, pois pode existir um cargo que no participe do relacionamento nenhuma vez.
Tipos de Relacionamentos O tipo de relacionamento uma classificao baseada na cardinalidade mxima do relacionamento, podendo ser : 1:1, 1:N, N:1 e N:N. A seguir, sero explorados todos os tipos de relacionamentos sobre um relacionamento existente entre os conjuntos de entidades : FUNCIONRIOS E PROJETOS.
Os tipos de relacionamentos podem ser enquadrados em 3 grandes grupos, e l-se conforme descrio feita entre parnteses: 1:1 1:N N:N (Um-para-um), (Um-para-Muitos) e, (Muitos-para-Muitos).
Banco de Dados I
40
Captulo 2
Relacionamento 1:1 A Figura 15 mostra um exemplo de relacionamento do tipo 1:1 no qual cada Funcionrio ou Projeto podem aparecer no mximo em um nico par do relacionamento Gerenciam (Funcionrio, Departamento). Nesse caso, podemos dizer que um funcionrio pode gerenciar no mximo um projeto, ou mesmo nenhum, enquanto um projeto s deve ter um gerente. A figura 16 tem uma representao simblica deste tipo de relacionamento.
FUNCIONRIOS
(1,1)
Gerenciam
(0,1)
PROJETOS
Figura 15 - Exemplo de relacionamento 1:1
Figura 16 - Representao simblica do relacionamento 1:1 (um-para-um)
Observe que todo projeto gerenciado por algum funcionrio porm, nem todo funcionrio gerencia projetos. Esta informao dada pela cardinalidade mnima do relacionamento.
Relacionamento 1:N A Figura 17 mostra um exemplo de relacionamento do tipo 1:N no qual cada Projeto pode aparecer no mximo em um nico par do relacionamento Gerenciam, enquanto um Funcionrio pode aparecer em um nmero arbitrrio de vezes. Nesse caso, podemos dizer que um funcionrio pode gerenciar vrios projetos, enquanto um projeto s pode ter um gerente (tem que haver pelo menos 1!). A figura 18 tem uma representao simblica deste tipo de relacionamento.
Modelagem de Dados
41
FUNCIONRIOS
(1,1)
Gerenciam
(0,n)
PROJETOS
Figura 17: Exemplo de relacionamento 1:N
Figura 18 - Representao simblica 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 Funcionrio ou Projeto podem aparecer em um nmero arbitrrio de vezes do relacionamento Gerenciam. Nesse caso, podemos dizer que um funcionrio pode gerenciar vrios projetos, enquanto um projeto pode ter vrios gerentes. A figura 20 tem uma representao simblica deste tipo de relacionamento.
FUNCIONRIOS
(1,n)
Gerenciam
(0,n)
PROJETOS
Figura 19 - Exemplo de relacionamento N:N
Banco de Dados I
42
Captulo 2
Conjunto simblico da entidade FUNCIONRIOS Conjunto simblico da entidade PROJETOS
Figura 20 - Representao simblica do relacionamento N:N (muitos-para-muitos)
Um outro conceito relacionado aos relacionamentos N:N o de Entidade Associativa, tambm referenciada por alguns autores, como Agregao. Uma Entidade Associativa uma abstrao por meio da qual relacionamentos entre duas entidades so tratados como entidades em um nvel mais alto de abstrao. Essa nova entidade, a associativa, pode, ento, relacionar-se com outras entidades do modelo, como mostra a Figura 21. Um correntista uma agregao envolvendo os conjuntos de entidades Clientes e Contas Correntes.
CORRENTISTAS (1,N) CLIENTES possuem (1,1) so emitidos para (0,1) CARTES MAGNTICOS
Figura 21 - Exemplo de agregao N:N [Falbo, 2009]
(0,N)
CONTAS CORRENTES
Os exemplos acima mostram os diferentes tipos de relacionamentos aplicados a conjuntos de entidades diferentes, porm tambm se aplicam a autorrelacionamentos.
Modelagem de Dados
43
Relacionamentos N:N geram Entidades Associativas e, estas, por sua vez, possuem os mesmos privilgios de um conjunto de entidades do modelo. Podem ter atributos e relacionar-se com outras entidades do modelo! Atributos de Relacionamentos Assim como as entidades, os relacionamentos tambm podem ter atributos, porm apenas os atributos de relacionamentos N:N so caracterizados como atributos de relacionamentos, enquanto os demais podem ser enquadrados em um dos conjuntos de entidades envolvidos no relacionamento [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 entidades, porque este no atributo do primeiro conjunto de entidades, no caso MATERIAIS. O Procedimento anlogo deve ser feito, agora, para a outra entidade. Fixando-se um fornecedor e variando-se os materiais temos: A Eletrocity vende uma impressora por R$ 350,00 e um microcomputador por R$ 2.000,00. O fato de o valor do atributo ter variado para a mesma entidade indica que ele no atributo de FORNECEDORES. Se no atributo nem de MATERIAIS, nem de FORNECEDORES, ento um atributo do relacionamento entre os dois conjuntos de entidades.
(0,N) FORNECEDORES
(1,N) MATERIAIS fornecem
Figura 22 - Exemplo de relacionamento N:N [Falbo, 2009]
Generalizao / Especializao de conjuntos de entidades Por muitas vezes, inclumos nos modelos ERs conjuntos de entidades com diversas caractersticas em comum, diferenciando apenas em algumas delas. Nesse caso, usando o conceito de generalizao, pode-se
Banco de Dados I
44
Captulo 2
criar um conjunto de entidades genrico, contendo as caractersticas em comum, e especializam-se as demais com caractersticas parcialmente distintas. Um exemplo clssico o de pessoa fsica em jurdica. Observe que existem vrias caractersticas em comum entre ambas as pessoas, a exemplo de: nome, endereo e telefone. Uma pessoa fsica, no entanto, alm dessas caractersticas comuns, possui: sexo e CPF. Uma pessoa jurdica, alm dessas caractersticas comuns, possui CNPJ e atividade principal. A Figura 23 mostra a representao desse conceito no modelo ER.
CLIENTES
PESS0AS FSICAS
PESSOAS JURDICAS
Figura 23 - Exemplo de generalizao / especializao
As entidades PESSOAS FSICAS e PESSOAS JURDICAS herdam as caractersticas de clientes e incorporam outras adicionais, que so peculiares de cada um. Um cliente pode ser pessoa fsica, jurdica ou nenhum dos dois, mas toda pessoa fsica ou jurdica cliente.
Generalizao: entidades de um nvel mais baixo de abstrao, com caractersticas comuns, so agrupadas dando origem a uma entidade de nvel mais alto.
Especializao: uma entidade de nvel mais alto de abstrao desmembrada em vrias entidades de nvel mais baixo, com caractersticas parcialmente distintas.
Modelagem de Dados
45
Entidade Fraca Um outro conceito referenciado nos modelos ERs o de Entidade Fraca. Uma entidade fraca uma entidade que no tem existncia prpria. Ela s aparece no modelo quando relacionada a outra entidade intitulada como forte , sendo seus atributos identificadores compostos por, pelo menos, dois campos, sendo um deles um atributo da entidade forte. A Figura 24 mostra um exemplo em que o conjunto de entidades DEPENDENTES denominada entidade fraca. Para a identificao de um dependente necessrio que se tenha informao do scio. Os relacionamentos com essa caracterstica so denominados identificados.
SCIOS
(1,1)
Possuem
(0,N)
DEPENDENTES
Figura 24 - Exemplo de entidade fraca
2.5
Dicionrio de dados
O Dicionrio de Dados uma listagem organizada de todos os elementos de dados pertinentes ao sistema, com definies precisas para que os usurios e desenvolvedores possam conhecer o significado de todos os itens de dados manipulados pelo sistema. Em se tratando de Modelos de Dados, essa listagem contm, em ordem alfabtica, as entidades e os relacionamentos com atributos de um DER. Considerando que no h uma padronizao sobre a definio de dicionrio de dados, no ser explorado neste material uma formulao na representao destes, mesmo por que as ferramentas CASE normalmente incluem relatrios para gerao desses dicionrios.
Para complementar os conceitos discutidos at esta seo, indicamos o livro Projeto de Banco de Dados, de Carlos Alberto Heuser, captulos 02 e 03.
Banco de Dados I
46
Captulo 2
2.6
Exemplo de um modelo de dados
A seguir eis um estudo de caso referente a um campeonato de frmula 1 e o modelo ER construdo para representar o cenrio supracitado. Deseja-se desenvolver um sistema para controlar os resultados de um campeonato de corridas de Frmula 1. O sistema dever manter informaes sobre as equipes que participam do campeonato. De cada equipe deseja-se saber: cdigo e nome. Alm disso, necessrio controlar os pilotos que pertencem a cada equipe. De cada piloto deseja-se saber: cdigo, nome, data de nascimento, altura e peso. Ao longo do campeonato, um piloto pode pertencer a apenas uma equipe. Uma equipe, por outro lado, poder ter vrios pilotos (sendo este nmero mximo normalmente igual a 02 pilotos), podendo no ter nenhum, em um dado momento. necessrio ter um controle dos pases dos atletas (pilotos), dos quais deseja-se armazenar as seguintes informaes: uma sigla, o nome e o Hino Nacional. Um piloto sempre representa um pas, enquanto que um pas pode ter vrios pilotos participando do campeonato ou at mesmo nenhum. Uma equipe tambm representa um pas, enquanto que um pas pode ter vrias equipes participando do campeonato ou mesmo nenhuma. Para cada corrida realizada, necessrio saber a data em que ocorreu, o nome do circuito, a durao em minutos, a relao de pilotos que participaram da prova e a posio que cada um obteve na corrida. Para caracterizar uma corrida necessrio que haja pelo menos 01 piloto habilitado a participar. O primeiro passo para construo de um modelo identificar os elementos do contexto para os quais temos o interesse de manter informaes a respeito, ou seja, identificar os possveis conjuntos de entidades. Se fizermos uma leitura novamente do texto, iremos destacar os seguintes conjuntos de entidades: equipes, pilotos, pases e corridas. Lembrese de que s faz sentido caracterizar um elemento como um conjunto de entidades se ele possuir atributos prprios! Com relao ao conjunto de entidades Corridas, cabem algumas observaes importantes. A primeira diz respeito relao de pilotos que participaram da prova. Observe que esta relao de pilotos no foi includa como um atributo de corrida (verifique no dicionrio de dados) e sim como um relacionamento entre corridas. Se inclusse como atributo estaria sendo redundante, considerando que o modelo contempla um conjunto de entidades denominado Pilotos. A segunda observao refere-se a posio que cada um obteve na corrida, a qual, embora esteja no texto referenciado quando trata-se da corrida em si, mas esta informao est relacionada ao piloto e a corrida, ou seja, ao relacionamento entre estes dois conjuntos de entidades.
Modelagem de Dados
47
A figura 25 mostra o modelo ER correspondente ao contexto descrito anteriormente.
PILOTOS
(1,n) (0,n)
(0,n)
Possuem
(1,1)
EQUIPES
(0,n)
participaes participam de
so de
So de
(0,n)
CORRIDAS
(1,1) (1,1)
PAISES
Figura 25 - Modelo ER referente ao estudo de caso Campeonato de Frmula 1
Dicionrio de Dados: EQUIPES = PILOTOS = Peso PAISES = codEquipe + nomeEquipe codPiloto + nomePiloto + dtNascimento + Altura + codPais + sigla + nome
CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito PARTICIPACOES = posicaoPilotoProva
O dicionrio de dados acima representa em estilo sublinhado os atributos determinantes para cada conjunto de entidades.
Banco de Dados I
48
Captulo 2
Ao construirmos modelos de dados comum termos dvida sobre a representao de conjuntos de entidades, como no exemplo a seguir: se estamos construindo um modelo para uma locadora de vdeo, 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 No! 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, no faz sentido. Seria construir um conjunto de entidades para representar uma entidade apenas! O mesmo raciocnio 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 mo? A resposta simples: existem vrias ferramentas computadorizadas destinadas a auxiliar na construo de modelos e projetos de bancos de dados, as quais so denominadas ferramentas CASE. Dentre outras, podemos citar Doctor CASE, ERWin e brModelo. Esta ltima uma ferramenta desenvolvida sob a orientao do professor Carlos Heuser, professor de Banco de Dados da UFRGS, e encontrase disponvel para download na Internet. Embora seja uma ferramenta simples, permite trabalharmos com a construo de modelos conceituais e lgicos (tratados no prximo captulo).
2.8 Modelo ER estendido - EER

O modelo ER possui um poder de expresso muito grande, principalmente quando se trata de modelagem de aplicaes convencionais, porm alguns recursos so mais bem representados por extenses feitas ao modelo bsico. Recursos estes necessrios para modelagem de aplicaes mais complexas, como Sistemas de Informaes Geogrficas e CAD. Vrios modelos semnticos de dados tm sido propostos na literatura, sendo denominados de modelo ER estendidos ou EER. No h uma notao padro para representao desses modelos, como ocorre com a UML. Segundo Navathe Navathe [NAVATHE, 2005], o modelo EER engloba todos os conceitos do modelo ER bsico, acrescidos dos conceitos de subclasse e superclasse, especializao e generalizao, tipo unio e herana de atributo/relacionamento.
Modelagem de Dados
49
Uma boa leitura para complementar os conceitos tratados nesta seo o livro Sistemas de Banco de Dados, de Esmasri e Navathe, captulo 4, que descreve uma forma de representao do modelo EER.
Este captulo teve como objetivo o de apresentar conceitos relacionados com modelagem conceitual de dados. Ressalto que os modelos conceituais representam os requisitos de negcio independente de tecnologia. No captulo seguinte, trabalharemos com projeto lgico de banco de dados. Para estes, algumas caractersticas tecnolgicas sero consideradas.
Banco de Dados I
50
PROJETO LGICO DE BANCO DE DADOS
Ol! Neste captulo voc estudar conceitos de projeto lgico de banco de dados. Um modelo lgico faz uma adequao do modelo conceitual, incluindo restries tecnolgicas, impostas pelo modelo de banco de dados a ser usado. Trata-se de um modelo com maior nvel de detalhe do que o conceitual. Bom estudo! Prof Claudinete Vicente Borges
3.1
Definio
Quando construmos um modelo conceitual, focamos apenas no que o usurio deseja, abstraindo da plataforma em que este ser implementado. No que se refere aos projetos de Banco de Dados, a preocupao centrada em estabelecer de que forma os dados sero armazenados no sistema. Em funo do modelo de banco de dados a ser usado, diferentes solues de projeto devem ser adotadas, ou seja, se o software for implementado em um banco de dados hierrquico, por exemplo, um modelo hierrquico deve ser produzido, adequando-se a modelagem conceitual de dados (ER ou diagrama de classes) a essa plataforma de implementao. Considerando que o modelo de banco de dados que predomina no mercado, atualmente, o relacional, este captulo se prope a discutir conceitos 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 flexvel, de simples compreenso. Est fortemente baseado na teoria matemtica sobre relaes, da o nome relacional. Um banco de dados relacional consiste em uma coleo de tabelas, cada uma das quais com um nome nico. Uma linha em uma tabela representa um relacionamento entre um conjunto de valores. Uma vez que
52
Captulo 3
essa tabela uma coleo de tais relacionamentos, h uma estreita correspondncia entre o conceito de tabela e o conceito matemtico de relao, da a origem do nome desse modelo de dados. Considere a tabela EMPREGADOS Tabela 3. Ela possui trs colunas: matrcula, nome e cidade. Seguindo a terminologia do modelo relacional, tratamos os nomes dessas colunas como atributos. Para cada atributo h um conjunto de valores permitidos, chamado domnio da coluna em questo. Para o atributo Matricula, por exemplo, o domnio o conjunto de todas as matrculas de funcionrios. Suponha que D1 denote esse conjunto, D2 o conjunto de todos os nomes de pessoas e D3 o conjunto de todas as cidades. Qualquer linha da tabela EMPREGADOS consiste necessariamente de uma tupla (v1, v2, v3), em que v1 a matricula, (isto , v1 est no domnio D1), v2 um nome do funcionrio e assim por diante. Em geral, um empregado um conjunto de D1 x D2 x D3. Tabela 3 - Tabela EMPREGADOS
matricula 01 02 03 04 nome Maria Matheus Gabriel Joana cidade Vitria Vila Velha Serra Aracruz
Matematicamente, define-se uma relao como um subconjunto de um produto cartesiano de uma lista de domnios. Essa definio corresponde quase exatamente definio de uma tabela. A nica diferena que designamos nomes aos atributos, ao passo que matematicamente se usam apenas nomes numricos. Como as tabelas em essncia so relaes, podemos usar os termos matemticos relao e tupla no lugar de tabela e linhas, respectivamente.
possvel que tenhamos, em uma mesma tabela, atributos diferentes criados sob o mesmo domnio, a exemplo de Endereo de correspondncia e Endereo comercial (se existissem nessa tabela EMPREGADOS).
Um valor de domnio que pertence a qualquer domnio possvel o valor nulo, que indica que um valor desconhecido ou no existe. Por
Projeto Lgico de Banco de Dados
53
exemplo, suponhamos que incluamos o atributo numeroTelefone na tabela Empregado, pode ser que um Empregado no possua telefone ou que o seu nmero seja desconhecido.
3.3
Chaves
importante especificar como as entidades dentro de um dado conjunto de entidades podem ser identificadas. Conceitualmente, entidades e relacionamentos individuais so distintos, entretanto, na perspectiva do banco de dados, a diferena entre ambos deve ser estabelecida em termos de seus atributos. O conceito de chaves nos permite fazer tais distines. Uma superchave um conjunto de um ou mais atributos que, tomados coletivamente, permitem identificar, de maneira unvoca, uma entidade em um conjunto de entidades. Considere a incluso de uma nova coluna na tabela EMPREGADOS, o (CPF) do empregado. Os atributos (matricula, nome) e (nome, CPF) so 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) no pode ser considerado como superchave, porque algumas pessoas podem ter o mesmo nome. Nosso interesse maior por superchaves para as quais nenhum subconjunto possa ser uma superchave. Essas chaves so chamadas de chaves candidatas. Das superchaves mencionadas anteriormente, somente (nome, CPF) no poderia ser considerada uma chave candidata, visto que o CPF, sozinho, j o . Podemos usar o termo chave primria para caracterizar a chave candidata, que escolhida pelo projetista do banco de dados como de significado principal para a identificao de entidades dentro de um conjunto de entidades. Quaisquer duas entidades individuais em um conjunto de entidades no podem ter, simultaneamente, os mesmos valores em seus atributos-chave. Em SGBDs, apenas os conceitos de chaves primrias e chaves candidatas so de fato implementados! A tabela 4 mostra uma listra de atributos de uma relao Alunos e um indicativo da possibilidade destes serem considerados atributos-chaves. Cabe ressaltar que os atributos implementados como Chave Candidata so atributos possveis de serem implementados como Chave Primria, porm, pode-se criar um atributo extra, como por exemplo um nmero seqencial para ser a chave primria da tabela.
Banco de Dados I
54
Captulo 3
Tabela 4 - Exemplo de atributos chave

Atributos matricula CPF (CI, UF) (CPF,Nome) Superchave Chave Candidata Chave Primria X X
Em uma mesma tabela pode haver mltiplas chaves candidatas, a exemplo de (matrcula) e (CPF) de EMPREGADOS. No que se refere chave primria, apenas uma possvel.
Uma chave candidata pode assumir um valor nulo (apenas um, pois do contrrio haveria repetio de valores). Uma chave primria no pode assumir valor nulo.
Alguns autores defendem que uma chave primria seja escolhida entre as chaves candidatas de uma tabela. Eventualmente, pode-se adotar uma soluo de projeto em que a chave primria no seja escolhida entre as chaves candidatas e sim um atributo que no diz respeito ao negcio em si. Particularmente, prefiro adotar essa soluo. importante lembrar a todos que o negcio muda e com isso os valores dos atributos tambm. Uma alterao feita em valores de chaves primrias implica propagao para inmeras tabelas relacionadas, 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 combinao de atributos) de uma tabela que constitui a chave primria de uma tabela, da o nome de estrangeira. a estratgia usada para implementar os relacionamentos dos modelos conceituais. Essa tabela referenciada pode ser a prpria tabela, para os casos de autorrelacionamento, ou outras quaisquer do modelo. Outras denominaes tambm so usadas para essas chaves, a exemplo de chaves externas e chaves transpostas. A Tabela 5 mostra um exemplo de chave estrangeira, o codDepto. Os valores possveis para essa coluna devem constar na Tabela referenciada por esse atributo, no caso, a de DEPARTAMENTOS. Alm desses valores, dependendo do modelo de dados, nulo pode ser um valor possvel.
55
Tabela 5 - Tabela EMPREGADOS, destacando a chave estrangeira (codDepto)

matricula 01 02 03 04 nome Maria Matheus Gabriel Joana cidade Vitria Vila Velha Serra Aracruz codDepto 01 02 02 03
Tabela 6 - Tabela DEPARTAMENTOS

codDepto 01 02 03 nomeDepto Informtica Geografia Portugus
3.4
Propriedades do modelo relacional
Falbo [FALBO,2009] relaciona as seguintes propriedades do modelo relacional: nenhum campo componente de uma chave primria pode ser nulo; cada clula de uma relao pode ser vazia (exceto de uma chave primria) ou, ao contrrio, conter no mximo um nico valor; a ordem das linhas irrelevante; no h duas linhas iguais; cada coluna tem um nome e colunas distintas devem ter nomes distintos; usando-se os nomes para se fazer referncia s colunas, a ordem delas torna-se irrelevante; cada relao recebe um nome prprio distinto do nome de qualquer outra relao da base de dados; os valores de uma coluna so retirados todos de um mesmo conjunto, denominado domnio da coluna; duas ou mais colunas distintas podem ser definidas sobre um mesmo domnio; 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 primria.
Banco de Dados I
56
Captulo 3
3.5
Traduo do modelo ER para o relacional
O objetivo desta seo apresentar como se procede na elaborao do projeto lgico de bancos de dados relacionais a partir de modelos conceituais no caso o ER. O modelo lgico um modelo menos abstrato que o conceitual e prov um nvel maior de detalhes. Para os diferentes modelos de bancos de dados (redes, hierrquicos, relacionais...) diferentes solues de projetos devem ser adotadas. Assim, este material ter como foco apenas o projeto de banco de dados relacional. A traduo 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 generalizaes e especializaes; mapeamento de atributos multivalorados. Diferentes autores usam diferentes representaes para a especificao dos modelos lgicos de bancos de dados relacionais, sendo alguns representados de forma grfica e outros textuais. A abordagem usada neste material ser a de Carlos Heuser [HEUSER,2004], que usa uma notao resumida para definio do esquema, denominado Esquema Relacional, contendo as seguintes informaes : tabelas que formam o banco de dados; colunas que compem cada tabela; restries de integridade (no caso, apenas as restries referentes s chaves primrias e estrangeiras so representadas). Para o exemplo das Tabelas 5 e 6 (EMPREGADOS e DEPARTAMENTOS), teremos a seguinte representao: Empregados (matricula, nome, cidade, codDepto) codDepto referencia Departamentos Departamentos (codDepto , nomeDepto) Os atributos sublinhados representam as chaves primrias das tabelas Empregados e Departamentos, respectivamente. CodDepto uma chave estrangeira e que referencia a chave primria da tabela Departamentos. Para os casos das chaves estrangeiras compostas, a representaTecnologia em Anlise e Desenvolvimento de Sistemas
57
o fica da seguinte forma: (coluna1, coluna2, ... colunaN) referencia <NomeTabela>. A fim de facilitar o entendimento, sero usados os mesmos exemplos de modelos descritos no captulo 2 para exemplificar os diferentes tipos de relacionamentos. Consideremos tambm os atributos abaixo listados para os conjuntos de entidades Funcionrios e Projetos, pois a opo foi de no represent-los no modelo ER. Funcionarios = matrcula + nome + cidade + data de admisso Projetos = cdigo + nome + data de incio Seguindo os passos para elaborao do modelo conceitual temos, como passo 1, a definio das Tabelas que formam o banco de dados. Via de regra, todo conjunto de entidades gerar uma tabela no banco de dados relacional. As excees sero tratadas, quando ocorrerem. Com relao nomenclatura usada na tabela, ela no deve, necessariamente, ser a mesma do conjunto de entidades, considerando que no pode haver espaos em branco e que devemos evitar nomes extensos para facilitar o trabalho dos programadores. No que se refere aos atributos dos conjuntos de entidades, eles devem ser mapeados em colunas das respectivas tabelas, porm, h algumas diretrizes para definio dessas colunas, conforme especificaes a seguir: evite usar nomes extensos. Ao fazer referncia ao nome de uma coluna, normalmente escreve-se nomedaTabela.nomedaColuna o que estende ainda mais o nome do atributo; considerando que a referncia s colunas ocorre do modo acima descrito, no se faz necessrio 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 padres de projeto para dar nomes s colunas, a exemplo de dtAdmissao e dtInicio. Evite usar prefixos diferentes para colunas com mesmo tipo de informao, como: Data_Admisso e dtInicio; ao definir a chave primria, escolha a coluna ou combinao destas colunas com o menor tipo de dados possvel. Sobre os campos chaves, seja chave primria, candidata, seja estrangeira, so criados ndices, e esses ndices ocupam muito espao em disco; embora devamos evitar redundncias nos modelos conceituais, a redundncia, muitas vezes, til em um banco de dados por questes de performance. Por exemplo: o valor de um pedido pode ser obtido por meio dos valores dos seus itens, porm, se guardarmos o valor total do pedido como uma coluna na tabela de pedidos, evitamos alguns acessos a disco, melhorando, assim, a performance das aplicaes.
Banco de Dados I
58
Captulo 3
Notao resumida para especificao de banco de dados relacional: tabelas que formam o banco de dados; colunas que compem cada tabela; restries de integridade (no caso, apenas as restries referentes s chaves primrias e estrangeiras so representadas).
Os relacionamentos do modelo conceitual ER so mapeados em chaves estrangeiras em um banco de dados relacional. Via de regra, para cada relacionamento uma chave estrangeira deve ser criada.
Eu, particularmente, no uso acentuaes 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 soluo de projeto a se considerar : incluir a chave estrangeira na relao PROJETOS, em vez de coloc-la em empregados, derivando o seguinte esquema : Funcionarios (matricula, nome, cidade, dtAdmissao) Projetos (codigo, nome, dtInicio, matriculaGerente) matriculaGerente referencia Funcionrios
FUNCIONRIOS
(1,1)
Gerenciam
(0,1)
PROJETOS
Figura 26 - Exemplo de relacionamento 1:1
Essa soluo foi adotada, considerando-se que todo projeto tem um gerente; porm, nem todo funcionrio gerencia um projeto. Ainda assim, se a chave estrangeira fosse criada em Funcionrios, no teramos proTecnologia em Anlise e Desenvolvimento de Sistemas
59
blemas na implementao dessa soluo, embora essa no seja a melhor abordagem. Se o relacionamento Gerenciam fosse total em relao a Funcionrios e a Projetos, ou seja, se a cardinalidade mnima fosse 1 (um) para ambos, poderamos 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 mxima 1. No caso da Figura 27, a chave estrangeira deve ser colocada em Projetos, pois cada projeto participa do relacionamento Gerenciam no mximo 1 (uma) vez. O esquema gerado ficaria da seguinte forma: Funcionarios (matricula, nome, cidade, dtAdmissao) Projetos (codigo, nome, dtInicio, matriculaGerente) matriculaGerente referencia Funcionrios
FUNCIONRIOS
(1,1)
Gerenciam
(0,n)
PROJETOS
Figura 27 - Exemplo de relacionamento 1:N
A criao da chave estrangeira na tabela Funcionrios geraria um erro de projeto, considerando que para os funcionrios que gerenciam mais de um projeto todas as informaes de funcionrios 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 identificao de um elemento da entidade, dita fraca (DEPENDENTES), requer a identificao da entidade, dita forte (SOCIOS). Resumindo, temos nesses casos a chave estrangeira fazendo parte da chave primria da tabela mapeada pela entidade fraca. O esquema gerado ficaria da seguinte forma:
Banco de Dados I
60
Captulo 3
Socios (matricula, nome, sexo, dtCadastro) Dependentes (matricula, numDependente, sexo, dtNascimento) Matricula referencia Scios
SCIOS
(1,1)
(0,N) Possuem
DEPENDENTES
Figura 28 - Exemplo de entidade fraca relacionamento identificado
Nesse caso, apenas o nmero do dependente no suficiente para identific-lo, considerando que diferentes scios possuem dependentes de nmero 01, 02, 03, etc. 3.5.4 Relacionamento N:N Os bancos de dados relacionais no implementam ligaes diretas para os relacionamentos N:N, como para os demais tipos de relacionamentos: 1:1 e 1:N. Nesse caso, o relacionamento tambm deve ser mapeado em uma tabela do banco de dados. A chave primria dessa nova tabela deve ser composta, no mnimo, pela chave primria das tabelas relacionadas, ou seja, tem-se pelo menos 02 chaves estrangeiras, e elas fazem parte da chave primria da tabela criada. s vezes necessrio incluir mais um atributo para compor a chave primria da tabela, pois apenas as chaves estrangeiras no so suficientes para identific-los. Considere o exemplo da Figura 29, agora com relacionamento N:N. Considere tambm que o relacionamento Gerenciam possui os seguintes atributos : Data de Incio de Atividade e Percentual de dedicao.
FUNCIONRIOS
(1,n)
Gerenciam
(0,n)
PROJETOS
Figura 29 - Exemplo de relacionamento N:N
O esquema gerado ficaria da seguinte forma:
61
Funcionarios (matricula, nome, cidade, dtAdmissao) Projetos (codigo, nome, dtInicio) Gerenciam (matricula, codigo, dtInicioAtividade, percDedicacao) matricula referencia Funcionrios codigo referencia Projetos
Os relacionamentos N:N normalmente visam a gerao de histrico, assim sendo, comum encontrarmos um campo data como parte da chave primria da tabela derivada da entidade associativa.
3.5.5 Generalizao e especializao Considere a Figura 30 para as discusses que se seguem. Considere tambm que um cliente possui as seguintes caractersticas (atributos ): Cdigo e Nome. Um cliente pessoa fsica possui, adicionalmente, um CPF e Carteira de Identidade; e um cliente pessoa jurdica possui, adicionalmente, um CNPJ e uma atividade principal.
CLIENTES
PESS0AS FSICAS
PESSOAS JURDICAS
Figura 30 - Exemplo de generalizao / especializao
Para os casos em que h generalizao / especializao, h trs opes de projeto que podem ser adotadas:
Banco de Dados I
62
Captulo 3
Opo 1: criar uma tabela nica, fundindo os trs conjuntos de entidades. Nesse caso, os campos oriundos das tabelas especializadas devem ter a possibilidade de assumirem valores nulos. O esquema gerado ficaria da seguinte forma: Clientes (codigo, nome, CPF, carteiraIdentidade, CNPJ, atividadePrincipal) Opo 2: criar uma tabela para cada entidade da especializao, como Pessoas Fsicas e Pessoas Jurdicas. Nesse caso, os atributos do conjunto de entidades genrico Clientes devem ser includos 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) Opo 3: criar uma tabela para cada conjunto de entidade da hierarquia. Nesse caso, a chave primria das tabelas filhas (pessoas fsicas e jurdicas) devem ser chaves estrangeiras e as mesmas do conjunto mais genrico, 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 opo tem como vantagem a reduo do nmero de junes entre tabelas e como desvantagem possuir colunas que s tero valores associados quando tratarem de elementos correspondentes especializao. Por exemplo, em se tratando de pessoa fsica, no haver preenchimento de CNPJ e Atividade. Para a opo 02 temos como desvantagem a repetio de atributos comuns aos dois conjuntos de entidades especializados; j para a terceira opo h uma organizao maior da estrutura hierrquica, embora possamos ter uma menor performance, se considerarmos as opes anteriores. Como costumo dizer, no d para se ter tudo! Eu, particularmente costumo adotar a terceira soluo: criar uma tabela para cada conjunto de entidade da hierarquia.
63
3.5.6 Autorrelacionamento 1:N Para os autorrelacionamentos 1:N, como existe um relacionamento entre o mesmo conjunto de entidades, deve-se criar a chave estrangeira na nica tabela que representa o conjunto de entidades. Nesse caso, deve-se ficar atento em alterar o nome do campo chave estrangeira , pois no possvel 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 Funcionrios
FUNCIONRIOS
(1,1)
(0,n)
Chefiam
Figura 31 - Exemplo de Autorrelacionamento 1:N
3.5.7 Autorrelacionamento N:N Para os autorrelacionamentos N:N, assim como para os relacionamentos N:N tradicionais, cria-se uma nova tabela para mapear o relacionamento. Essa tabela ter duas chaves estrangeiras, agora, porm, vindas da mesma tabela. Essas chaves estrangeiras compem a chave primria 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
Banco de Dados I
64
Captulo 3
codigoDisciplinaPos referencia Disciplinas
DISCIPLINAS
(0,n)
(0,n)
So pr-requisitos para
Figura 32 - Exemplo de Autorrelacionamento N:N
3.5.8 Atributos multivalorados Os atributos multivalorados de conjunto de entidades tambm devem ser tratados, considerando-se que o modelo relacional no comporta mltiplos valores em uma clula de uma tabela. Para ilustrar, consideremos que telefone (0,n) seja um atributo multivalorado de Funcionrios. Para esses atributos, uma soluo de projeto adotada a criao de uma tabela para cada um deles. Para a tabela criada, deve ser aplicada a mesma soluo dos relacionamentos 1:N identificados. Para o exemplo em tese, o esquema gerado ficaria da seguinte forma: Funcionarios (matricula, nome, cidade, dtAdmissao) Telefones (matricula, numeroTelefone) matricula referencia Funcionarios
Nesse caso, no h limites de telefones para um funcionrio, tanto pode no haver nenhum, como um ou vrios.
65
A soluo acima adotada para representao de atributos multivalorados, embora seja elegante, no amplamente aceita por projetistas de banco de dados. Considerando que dificilmente se registra um nmero grande de telefones para cada pessoa, costume se criar colunas adicionais na tabela de funcionrios para representar esses valores (exemplo : telefone01 e telefone02). Essa soluo, quando adotada, visa melhoria de performance, pois evita junes entre tabelas nas consultas que devem retornar os telefones de funcionrios.
3.6
Exemplo de projeto lgico
Tomando como base o estudo de caso usado no Captulo 2, referente ao campeonato de Frmula 1, vamos agora gerar o projeto lgico para o mesmo cenrio, atravs da representao de Esquema Relacional. Observaes importantes: Observe que cada conjunto de entidades foi mapeado em uma tabela no Esquema Relacional e que para chaves primrias, aproveitamos os atributos determinantes de cada conjunto de entidades. Para definio das chaves estrangeiras, necessrio avaliar cada tipo de relacionamento para cada conjunto de entidades do modelo. Modelo E/R:
PILOTOS
(1,n) (0,n) (0,n)
Possuem
(1,1)
EQUIPES
(0,n)
participaes participam de
so de
So de
(0,n)
CORRIDAS
(1,1) (1,1)
PAISES
Dicionrio de Dados: EQUIPES = codEquipe + nomeEquipe PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso
Banco de Dados I
66
Captulo 3
PAISES =
codPais + sigla + nome + dtCorrida + duracaoProva +
CORRIDAS = codCorrida 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
Normalizao
Uma vez concludo o projeto lgico de banco de dados relacional, com gerao do esquema correspondente, deve-se avaliar, para cada tabela, se a projeo foi bem feita. Esse processo de verificao, composto por um conjunto de regras, denomina-se forma normal. H diversas formas normais usadas no processo de verificao; porm, na nossa disciplina, sero exploradas apenas as trs primeiras formas normais, denominadas 1FN, 2FN e 3FN. Normalmente, as formas normais visam a eliminar informaes redundantes nas tabelas, cujo processo denominado normalizao.
67
3.7.1 Primeira forma normal (1FN) Um banco de dados est na Primeira Forma Normal quando no existem dados repetidos em nenhuma das linhas da tabela. Segundo DATE (2004), uma relao R existe na primeira forma normal (1FN) se, e somente se, todos os domnios subjacentes contiverem apenas valores atmicos. Para ilustrar esse conceito, tomemos como exemplo a relao Funcionrios, com a seguinte definio de esquema: Funcionarios (matricula, nome, cidade, dtAdmissao, telefones) No caso dessa relao, nem todos os domnios contm valores atmicos, como o caso de telefones. Nesse caso, os valores no atmicos devem estar contidos em uma outra tabela, relacionada original. Passando pelo processo de normalizao (1FN), temos o seguinte esquema: Funcionarios (matricula, nome, cidade, dtAdmissao) Telefones (matricula, numTelefone) matricula referencia Funcionarios Com isso, as duas tabelas geradas encontram-se normalizadas na primeira 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 no de apenas uma parte dela. Caso ocorra essa dependncia parcial, dizemos que a tabela viola a segunda forma normal. Segundo DATE (2004), uma relao R existe na segunda forma normal (2FN) se, e somente se, estiver na (1FN) e todos os atributos no chaves forem dependentes da chave principal. Exemplo: considere o esquema de uma relao filmes, de um banco de dados de uma locadora de vdeo, com o seguinte esquema: Filmes (codigoFilme, codigoAtor, titulo, nomedoAtor) A coluna Ttulo depende somente do cdigo do filme e Nome do Ator, depende somente do Nmero do Ator. Quase sempre a soluo dividir
Banco de Dados I
68
Captulo 3
as colunas em duas tabelas e criar uma terceira tabela que correlacione as linhas das duas tabelas. Nesse caso, geraramos 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 primria 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 colunas dependerem de toda a chave principal e no houver interdependncia entre as colunas que no so chaves da tabela. Segundo DATE (2004), uma relao R existe na terceira forma normal (3FN) se, e somente se, estiver na (2FN) e todos os atributos no chave forem intransitivamente dependentes da chave principal. Exemplo: considere o esquema modificado da relao filmes de um banco de dados de uma locadora de vdeo com o seguinte esquema: Filmes (codigoFilme, titulo, categoria, preco) Suponha que a loja determine o preo dos filmes por categoria: filmes de Terror, Drama e Comdia custam R$2,00; Musicais, R$2,50 e; Lanamentos, R$3,00. Nesse caso, a coluna Preo dependeria no s da coluna Cdigo do filme, como tambm da coluna Categoria. Essa tabela no est na Terceira Forma Normal, ento a soluo seria criar uma tabela adicional para armazenar os valores por categoria do filme. Aps normalizao, os seguintes esquemas so gerados: Filmes (codigoFilme, titulo,codigoCategoria) codigoCategoria referencia Categorias Categorias (codigoCategoria, Preco)
69
Com o passar do tempo, voc vai adquirindo experincia e no necessitar avaliar mais essas regras para as tabelas projetadas. Muitas vezes, usamos essa experincia para construir modelos desnormalizados, buscando melhoria de desempenho das aplicaes. Mais uma vez volto a dizer que tudo tem seu preo! s vezes, no conseguimos ter projeto perfeito e alta performance, por isso acabamos abrindo mo de uma coisa para termos o que mais importante no cenrio exposto. ATIVIDADE 1 Muitas vezes, o DBA se depara com situaes em que possui o esquema do banco de dados, porm no tem o modelo conceitual equivalente. Baseado nisso, dada a definio 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
Banco de Dados I
70
Captulo 3
ATIVIDADE 2 a) Dada a relao Perifericos, coloquem a mesma na terceira forma normal, passo a passo. Perifericos (codPeriferico, codModelo, noConfig, quantidade, nomeModelo, codCPU, nomeCPU) As dependncias funcionais que existem nesta tabela so 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 relao PEDIDOS, coloquem a mesma na terceira forma normal, passo a passo. PEDIDOS (numeroPedido, dtPedido, codCliente, nomeCliente, enderecoCliente, codProduto(1,n), nomeProduto(1,n), valorProduto(1,n), quantidadeProduto(1,n), matriculaEntregador, nomeEntregador, placaVeiculoEntregador) Este captulo teve como objetivo o de apresentar conceitos relacionados com projeto lgico de bancos de dados, mais especificamente no que se refere ao modelo relacional. No prximo captulo trabalharemos com linguagens de consultas aplicadas ao este modelo.
LINGUAGENS DE CONSULTA
Ol! Neste captulo voc ter conceitos de linguagens de consultas formais e comerciais para bancos de dados relacionais. Bom estudo! Prof Claudinete Vicente Borges
4.1
Definio
Uma linguagem de consulta uma linguagem na qual o usurio requisita informaes do banco de dados. So classificadas como procedurais e no procedurais. Numa linguagem procedural, um usurio instrui o sistema para executar uma sequncia de operaes no banco de dados a fim de computar o resultado desejado. Numa linguagem no-procedural, o usurio descreve a informao desejada, sem fornecer um procedimento especfico para obter tal informao. A lgebra relacional uma linguagem de consulta procedural, enquanto o clculo relacional uma linguagem no-procedural. Navathe [NAVATHE, 2005] afirma que qualquer expresso escrita em lgebra relacional pode ser representada tambm no clculo, dando o mesmo poder de expresso para ambas as linguagens. Como o nosso propsito de usar uma linguagem de consulta formal o de entendermos o que ocorre nos bastidores da execuo de uma consulta, focaremos apenas na lgebra relacional. A Linguagem SQL uma linguagem de consulta comercial, intitulada padro pelo comit ANSI, desde 1986. uma linguagem declarativa, com comandos muito mais amigveis do que as linguagens formais, embora seja fundamentada nessas linguagens formais (na lgebra e no clculo). Nas sees seguintes exploraremos a lgebra Relacional e a linguagem SQL.
72
Captulo 4
Uma linguagem de consulta uma linguagem na qual um usurio requisita informaes do banco de dados. So classificadas como procedurais e no procedurais. lgebra Relacional uma linguagem de consulta formal e procedural. SQL uma linguagem de consulta comercial e inclui elementos de uma linguagem procedural e no-procedural.
4.2
lgebra relacional
A lgebra relacional uma linguagem de consulta procedural. Ela consiste em um conjunto de operaes que tomam uma ou duas relaes (tabelas) como entrada e produz uma nova relao como sada. Inclui um conjunto de operaes, classificadas como fundamentais e no fundamentais. As operaes fundamentais da lgebra relacional so: selecionar, projetar, renomear, (unrias) - produto cartesiano, unio e diferena de conjuntos (binrias). Alm das operaes fundamentais, existem outras operaes, a saber: interseo de conjuntos, ligao natural e diviso que so definidas em termos das operaes fundamentais. As operaes no fundamentais so usadas para simplificar consultas, considerando que uma operao no fundamental engloba operaes fundamentais. A Figura 33 mostra uma representao grfica para cada uma das operaes da lgebra. As operaes da lgebra relacional atuam sobre uma ou duas relaes, sendo classificadas como unrias ou binrias. As relaes unrias recebem como argumento apenas uma relao e as binrias recebem duas relaes. Caso seja necessrio usar mais de duas relaes em uma consulta, as operaes devem ser usadas de forma encadeada. Como o resultado de uma consulta da lgebra uma nova relao, esta pode ser usada como argumento para a prxima operao.
Linguagens de Consulta
73
Produto Selecionar Projetar a b c x y a a b b c c x y x y x y
Unio
Interseco
Diferena
Ligao (natural) a1 b1 a2 b2 a3 b3 b1 c1 b2 c2 b3 c3 a1 b1 c1 a2 b1 c1 a3 b3 c3
a a a b c x y z x y
Dividir
x y a
Figura 33 - Viso geral das operaes da lgebra Relacional Fonte: Heuser, 2004. Adaptao.
4.2.1 Operaes fundamentais Considere o seguinte esquema de banco de dados para exemplos posteriores, ao longo deste captulo. Trata-se de um esquema bancrio, composto de quatro tabelas: AGNCIAS, CLIENTES, DEPSITOS e EMPRSTIMOS. Este esquema foi adaptado de Silberschatz [SILBERSCHATZ, 2006].
Banco de Dados I
74
Captulo 4
Lembre-se sempre da definio deste esquema Bancrio para quando a ele nos referirmos ao longo deste captulo. 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 operaes da lgebra Relacional, os esquemas daro lugar representao em tabelas de valores, conforme mostra abaixo : AGENCIAS codigoAg 50 51 52 53 CLIENTES codigoCli 01 02 03 04 05 06 nome Ana Lara Joo Jos Luisa Lucas rua Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita cidade Vitria Vitria Vila Velha Viana Vila Velha Vitria nomeAg Centro Princesa Isabel Praia Avenida cidadeAg Vitria Vitria Vila Velha Viana
75
DEPOSITOS codigoAg 50 51 51 53 codigoAg 51 52 numeroCont 999 991 992 993 codigoCli 02 03 codigoCli 01 02 03 04 numeroEmp 888 881 saldo 1000 3200 2300 1200 quantia 2000 4000
EMPRESTIMOS
Operao selecionar A operao selecionar seleciona tuplas (linhas) em uma relao, que satisfazem a um dado predicado. uma operao unria. Usamos a letra minscula grega sigma () para representar a seleo. O predicado aparece subscrito a (). A relao argumento (entrada) aparece entre parnteses, seguindo o (). A Figura 34 representa graficamente essa operao. Sintaxe: <predicado>(Relao)
A B
R=
A1 A2 A3 A4
B1 B2 B3 B4
A=A1(R) =
A B
A1 B1
Figura 34 - Operao seleo
Usando o esquema exemplo, vamos construir uma consulta para selecionar os Clientes que moram em Vitria. Para tanto, escreve-se: cidade=Vitria(CLIENTES) A relao resultante da consulta exibida na tabela 7 abaixo: Tabela 7 - Relao resultante da seleo sobre CLIENTES. codigoCli 01 02 06 nome Ana Lara Lucas Rua Amlia Nasser Das Flores Santa Rita
Banco de Dados I
cidade Vitria Vitria Vitria
76
Captulo 4
Observe que a seleo elimina linhas, assim sendo, todas as colunas da tabela CLIENTES foram projetadas.
As comparaes so permitidas, usando os operadores: igual (=); diferente (); menor (<); menor ou igual (); maior ou igual (); e os conectivos: e (); ou ().
Operao Projetar A operao projetar uma operao unria que retorna sua relao argumento, com certas colunas deixadas de fora. A projeo representada pela letra grega pi (). A Figura 35 representa graficamente essa operao. Sintaxe: <lista de atributos>(Relao)
R=
A B C
A1 A2 A3 A4 B1 C1 B2 C2 B3 C3 B4 C4
A C
A,C(R)
A1 A2 A3 A4
C1 C2 C3 C4
Figura 35 - Operao projeo
Usando o esquema exemplo, vamos construir uma consulta para projetar os Clientes e as cidades onde moram. Para tanto, escreve-se:
77
nome,cidade(Clientes) A relao resultante da consulta exibida na tabela 8 abaixo: Tabela 8 - Relao resultante da projeo sobre CLIENTES. nome Ana Lara Joo Jos Luisa Lucas cidade Vitria Vitria Vila Velha Viana Vila Velha Vitria
Alterando levemente a consulta acima, agora desejamos encontrar todos os nomes de clientes que moram em Vitria. Para realizar esta consulta, devemos fazer uma seleo de todos os clientes que moram em Vitria e, em seguida, projetar os seus nomes. nome(clientes.cidade=Vitria (CLIENTES)) A relao resultante da consulta exibida na tabela 9 indicada abaixo: Tabela 9 - Relao resultante da seleo seguida de projeo sobre CLIENTES. Nome Ana Lara Lucas Quando houver encadeamento de operaes em uma consulta, a ordem de execuo destas da direita para a esquerda. No exemplo acima, primeiro executa-se a operao de seleo e, depois, sobre o resultado da seleo, aplica-se a projeo.
Operao Produto Cartesiano A operao produto cartesiano, representada por (X), capaz de combinar informaes a partir de diversas relaes. Trata-se de uma operao binria. Essa operao nos mostra todos os atributos das relaes envolvidas no produto. A Figura 36 representa graficamente esta operao.
Banco de Dados I
78
Captulo 4
Sintaxe: (Relao1 Relao2)
Figura 36 - Operao produto cartesiano
Cuidado com ambiguidade de nomes de atributos. Quando houver atributos com mesmo nome nas relaes usadas em uma consulta necessrio referenci-los usando o nome da relao antes do nome do atributo a fim de diferenci-los. Exemplo : Quando se escreve Clientes.codigoCli referencia-se coluna codigoCli da tabela Clientes
Usando o esquema exemplo, vamos construir uma consulta para selecionar os nomes de Clientes que possuam emprstimo na agncia cujo cdigo 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 relaes intermedirias geradas durante a execuo da consulta em ordem cronolgica. Cabe ressaltar que, a ordem de execuo da consulta : 1- Produto cartesiano; 2- Seleo e; 3- Projeo.
79
Tabela 10 - Tabela resultante da operao produto cartesiano (CLIENTES X EMPRSTIMOS).
Clientes. Clientes. codigoCli nome
Clientes. rua
Clientes. cidade
EmprsEmprs- Emprstimos. timos. timos. numerocodigoAg codigoCli Emp
Emprstimos. quantia
01 02 03 04 05 06 01 02 03 04 05 06
Ana Lara Joo Jos Luisa Lucas Ana Lara Joo Jos Luisa Lucas
Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita
Vitria Vitria Vila Velha Viana Vila Velha Vitria Vitria Vitria Vila Velha Viana Vila Velha Vitria
51 51 51 51 51 51 52 52 52 52 52 52
02 02 02 02 02 02 03 03 03 03 03 03
888 888 888 888 888 888 881 881 881 881 881 881
2000 2000 2000 2000 2000 2000 4000 4000 4000 4000 4000 4000
Banco de Dados I
80
Captulo 4
Tabela 11 - Tabela resultante da operao seleo sobre produto cartesiano Emprestimos.codigoAg=51 ^ Clientes.codigoCli =Emprestimos.codigoCli (CLIENTES X EMPRSTIMOS).
Clientes. Clientes. Clientes. codigoCli nome rua 02 Lara Das Flores
Clientes. cidade Vitria
Emprs- Emprstimos. timos. codigoAg codigoCli 51 02
Emprstimos.numeroEmp 888
Emprstimos. quantia 2000
Tabela 12: Tabela resultante da operao projeo sobre seleo. Clientes.nome (Emprestimos.codigoAg=51 ^ Clientes.codigoCli =Emprestimos.codigoCli (CLIENTES X EMPRESTIMOS)) Clientes.nome Lara Aps a execuo da consulta, a relao resultante a da tabela 12, ou seja, apenas Lara possui emprstimo na agncia 51.
Operao Unio (binria) A operao unio de conjuntos, representada por (), uma operao binria que nos permite encontrar tuplas que esto em uma das relaes envolvidas. A Figura 37 representa graficamente a operao. Sintaxe: (Relao1 Relao2)
R1 A B
A1 A2 A3 A4 B1 B2 B3 B4
R2 A B
A1 B1 A5 B5
R1
R2
B1 B2 B3 B4 B5
A B
A1 A2 A3 A4 A5
Figura 37 - Operao unio
81
Usando o esquema exemplo, vamos supor que quisssemos conhecer todas as pessoas que possuam Depsitos ou Emprstimos, ou ambos, numa determinada agncia. Nesta situao, devemos fazer a unio de todos os clientes que possuam depsitos com todos os que possuam emprstimos nessa agncia, como veremos no exemplo a seguir: Ex. Selecionar todos os clientes que possuam depsitos, emprstimos ou ambos, na agncia 51. Clientes.nome (Depositos.codigoAg=51 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 possuem depsitos na agncia 51. A segunda parte refere-se s pessoas que possuem emprstimos na agncia 51. O resultado a unio de ambas. Usando o raciocnio anlogo ao exemplo utilizado para a operao produto cartesiano, vamos fazer a primeira parte da consulta. A tabela 13 mostra a relao resultado da consulta. Tabela 13 - Clientes que possuem depsitos na agncia 51 Clientes.nome Lara Joo A tabela 14 mostra os clientes que possuem emprstimos na agncia 51, que constitui a segunda parte da consulta. Tabela 14 - Clientes que possuem emprstimos na agncia 51 Clientes.nome Lara Fazendo a unio destas duas relaes temos como resultado a tabela 15 Tabela 15 - Clientes que possuem depsitos e/ou emprstimos na agncia 51 Clientes.nome Lara Joo
Banco de Dados I
^ Clientes.codigoCli=Depositos.CodigoCli
(CLIENTES X
82
Captulo 4
Para uma operao Unio r s ser vlida, necessrio que duas condies sejam satisfeitas: 1. as relaes r e s precisam ter a mesma paridade. Isto , elas precisam ter o mesmo nmero de atributos e; 2. os domnios do i-simo atributo de r e do i-simo atributo de s devem ser os mesmos.
Observe que a operao Unio da lgebra relacional segue exatamente os mesmos princpios da unio de conjuntos, assim sendo, no h duplicidade de linhas iguais na relao resultante.
Operao Diferena de conjuntos A operao diferena de conjuntos, representada por (-), uma operao binria e nos permite encontrar tuplas que esto em uma relao e no esto em outra. A expresso r - s resulta em uma relao que contm todas as tuplas que esto em r e no em s. A Figura 38 representa graficamente esta operao. Sintaxe: (Relao1 - Relao2)
R1 A B
A1 A2 A3 A4 B1 B2 B3 B4
R2 A B
R1 - R2 A B
A1 B1 A3 B3 A5 B5
A2 B2 A4 B4
Figura 38 - Operao diferena de conjuntos
Usando o esquema exemplo, vamos consultar todos os clientes que possuam um depsito, mas no possuem um emprstimo na agncia 51. Para isto, faremos uma consulta que resulte todos os clientes que possuem depsitos na agncia 51, e uma segunda consulta resultando todos os clientes que possuam emprstimos na agncia 51. O resultado desejado a diferena da primeira menos a segunda relao.
83
Clientes.nome(Depositos.codigoAg=51 DEPOSITOS)) -
^ Clientes.codigoCli = Depositos.codigoCli
(CLIENTES X
Clientes.nome (Emprestimos.codigoAg=51 ^ Clientes.codigoCli = Emprestimos.codigoCli (CLIENTES X EMPRESTIMOS))
importante observar que, ao contrrio das operaes unio e interseco de conjuntos, na operao diferena a ordem das relaes importante, ou seja, r s diferente de s r.
Relembremos que a tabela 16 abaixo (equivalente a tabela 13) contm todos os clientes que possuem depsitos na agncia 51, conforme mostra abaixo, e a tabela 17 (equivalente a tabela 14) contm todos os clientes que possuem emprstimos na mesma agncia. Tabela 16 - Clientes que possuem depsitos na agncia 51 Clientes.nome Lara Joo Tabela 17 - Clientes que possuem emprstimos na agncia 51 Clientes.nome Lara Fazendo a diferena destas duas relaes, temos como relao resultante a tabela 18, que contm todos os clientes que possuem depsitos mas no possuem emprstimos na agncia 51. Tabela 18 - Clientes que possuem depsitos e no possuem emprstimos na agncia 51 Clientes.nome Joo
Banco de Dados I
84
Captulo 4
Operao Renomear A operao renomear, representada pela letra grega R (), necessria sempre que uma relao aparece mais de uma vez em uma consulta. Ela faz uma cpia da relao original. Sintaxe: NomeNovo (Relao) Ex. Encontre todos os clientes que moram na mesma rua e cidade que Joo. Para obter a rua e a cidade de Joo, faa da seguinte forma: t rua, cidade (nome=Joo (Clientes)) A tabela 19 mostra a relao resultante da consulta acima. Tabela 19 - Relao t contendo rua e cidade onde Joo mora Rua Champagnart Cidade Vila Velha
Entretanto, para encontrar outros clientes com essa rua e cidade, devemos referir-nos relao Clientes pela segunda vez. Perceba que inserir novamente uma relao clientes na consulta gerar ambiguidade. Por isso ser necessrio renome-la. A consulta abaixo, alm de renomear a relao Clientes para Clientes2, faz em seguida um produto cartesiano com t, que contm a rua e cidade em que Joo mora. cliente2..nome (Clientes.cidade = Clientes2.cidade ^ Clientes.rua = Clientes2.rua ^ Clientes2.nome <> Joo (t X Clientes2 (Clientes))
Observe que, embora o produto cartesiano na consulta acima tenha sido feito com t, a seleo referencia clientes e no t.
As tabelas 20, 21, 22, 23 e 24 abaixo mostram, em ordem cronolgica, as relaes intermedirias geradas no processamento da consulta
85
Tabela 20 - Relao CLIENTES codigoCli 01 02 03 04 05 06 nome Ana Lara Joo Jos Luisa Lucas Rua Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita cidade Vitria Vitria Vila Velha Viana Vila Velha Vitria
Tabela 21: Relao CLIENTES2 resultante da operao Clientes2 (CLIENTES) Clientes2. codigoCli 01 02 03 04 05 06 Clientes2. nome Ana Lara Joo Jos Luisa Lucas Clientes2.rua Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita Clientes2. cidade Vitria Vitria Vila Velha Viana Vila Velha Vitria
Tabela 22: Relao resultante da operao produto cartesiano (t X CLIENTES2 (CLIENTES)) ClienClientes2. tes2. codigoCli nome 01 02 03 04 05 06 Ana Lara Joo Jos Luisa Lucas Clientes2.rua Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita Clientes2. cidade Vitria Vitria Vila Velha Viana Vila Velha Vitria Clientes. rua Champagnart Champagnart Champagnart Champagnart Champagnart Champagnart Clientes. cidade Vila Velha Vila Velha Vila Velha Vila Velha Vila Velha Vila Velha
Banco de Dados I
86
Captulo 4
Tabela 23 - Relao resultante da operao seleo clientes.cidade = clientes2.cidade ^ clientes.rua = clientes2.rua ^ clientes2.nome <> Joo (t X Clientes2 (CLIENTES))
(
ClienClientes2. tes2. codigoCli nome 05 Luisa
Clientes2.rua Champagnart
Clientes2. cidade Vila Velha
Clientes. rua Champagnart
Clientes. cidade Vila Velha
Tabela 24 - Relao resultante da operao projeo cliente2..nome ((clientes. (t X CLIENTES2 cidade = clientes2.cidade ^ clientes.rua = clientes2.rua ^ clientes2.nome <> Joo (CLIENTES)) Clientes2. nome Luisa Concluindo, somente Luisa mora na mesma rua e cidade que Joo.
ATIVIDADE 1 Considere o esquema bancrio abordado anteriormente e construa expresses em lgebra relacional para as questes que se seguem. 1. Consultar todos os clientes (nomes) que possuam depsitos. 2. Consultar todos os clientes que possuam depsito na mesma cidade onde moram. 3. Consultar todas as agncias que possuam clientes com nome Maria (depsitos ou emprstimos). 4. Consultar a conta com maior saldo.
87
ATIVIDADE 2 Considere o esquema seguinte para construir expresses, usando operaes fundamentais da lgebra relacional para as questes 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 funcionrios que ganham menos que um salrio mnimo (considere o valor do salrio de R$400,00). 7. Consultar todas as pessoas (nomes) que trabalham em Vitria. 8. Consultar todas as pessoas (nomes) que trabalham na mesma cidade onde moram. 9. Consultar todas as pessoas (nomes) que moram na mesma cidade do chefe. 10. Consultar todas as empresas (nomes) que funcionam em cidades em que no moram Maria. 11. Consultar todas as pessoas (nomes) que no trabalham em Vitria e que ganham acima de R$ 2.000,00. 12. Consultar o nome do funcionrio da empresa de cdigo 01 que possui o menor salrio.
Banco de Dados I
88
Captulo 4
4.2.2 Operaes no-fundamentais Utilizando as operaes fundamentais da lgebra relacional podemos expressar qualquer consulta. Entretanto, algumas consultas so longas ou complexas demais para serem expressas. Neste caso, o uso das operaes no-fundamentais pode reduzir o tamanho e a complexidade dessas consultas.
Operao Interseco de conjuntos A operao Interseco de conjuntos, representada por (), uma operao binria e nos permite encontrar tuplas que esto nas duas relaes envolvidas na consulta. Pode ser expressa em funo das operaes fundamentais da seguinte forma: r s = r (r s). A Figura 39 representa graficamente essa operao. Sintaxe: (Relao1 Relao2)
R1 A B
A1 A2 A3 A4 B1 B2 B3 B4
R2 A B
A1 B1 A4 B4
R1 R2 A B
A1 B1 A4 B4
Figura 39 - Operao Interseco de conjuntos
Usando o esquema exemplo, vamos consultar todos os clientes que possuam depsito e emprstimo na agncia 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 depsitos e os que possuem emprstimos na agncia 51.
89
Tabela 25 - Clientes que possuem depsitos na agncia 51 Clientes.nome Lara Joo Tabela 26 - Clientes que possuem emprstimos na agncia 51 Clientes.nome Lara Se fizermos a interseco destes dois conjuntos, teremos todos os clientes que se encontram nos dois conjuntos, ou seja, apenas Lara possui depsito e emprstimo na agncia 51, conforme mostra a tabela 27. Tabela 27 - Clientes que possuem depsito e emprstimos na agncia 51 Clientes.nome Lara Operao Ligao natural A operao ligao natural, representada pelo smbolo (|X|), uma operao binria que permite combinar certas selees e um produto cartesiano em uma operao. A operao ligao natural forma um produto cartesiano de seus dois argumentos e faz uma seleo, forando uma equidade sobre os atributos que aparecem em ambos os esquemas relao. A Figura 40 representa graficamente a operao. Sintaxe: (Relao1 |X| Relao2)
Figura 40 - Operao Ligao Natural Usando o esquema exemplo, encontre todos os clientes que tm emprstimos. Retorne os nomes dos clientes e a cidade em que vivem. Para tanto, escreve-se:
Banco de Dados I
90
Captulo 4
Clientes.nome, Clientes.cidade (EMPRESTIMOS |X| CLIENTES) As tabelas 28 e 29 mostram, em ordem cronolgica, as relaes intermedirias geradas durante o processamento da consulta. Cabe ressaltar que a relao resultante da ligao natural baseada no produto cartesiano entre Clientes e Emprstimos, seguida de uma seleo, ligando a chave primria de Clientes com a Chave estrangeira de Emprstimos. Na tabela 28 destaca-se em vermelho todas as linhas que sero excludas, restando apenas 2 linhas, referentes aos clientes Lara e Joo. Tabela 28 - Tabela resultante da operao Ligao Natural (CLIENTES |X| EMPRESTIMOS).
Clientes. Clientes. Clientes. codigoCli nome rua
Clientes. cidade
EmprsEmprs- Emprstimos. timos. timos. numerocodigoAg codigoCli Emp 51 02 888
Emprstimos. quantia
01
Ana
Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita
Vitria
2000
02
Lara
Vitria
51
02
888
2000
03
Joo
Vila Velha
51
02
888
2000
04
Jos
Viana
51
02
888
2000
05
Luisa
Vila Velha
51
02
888
2000
06
Lucas
Vitria
51
02
888
2000
91
01
Ana
Amlia Nasser Das Flores Champagnart Maira Santos Champagnart Santa Rita
Vitria
52
03
881
4000
02
Lara
Vitria Vila Velha Viana Vila Velha Vitria
52
03
881
4000
03
Joo
52
03
881
4000
04
Jos
52
03
881
4000
05
Luisa
52
03
881
4000
06
Lucas
52
03
881
4000
Tabela 29 - Tabela resultante da operao projeo Clientes.nome, Clientes.cidade (CLIENTES |X| EMPRESTIMOS). Clientes.nome Lara Joo Clientes.cidade Vitria Vila Velha
Resumindo, a tabela 29 mostra o nome e cidade de todos os clientes que possuem emprstimos. Se desejssemos encontrar todos os clientes que tm emprstimos e que moram em Vitria, teramos que executar uma operao de seleo sobre a relao resultante da ligao natural tabela 28. Neste caso, retornaria apenas Lara, considerando que, das pessoas que possuem emprstimos, apenas ela mora em Vitria. Clientes.nome (Clientes,cidade=Vitria (EMPRESTIMOS |X| CLIENTES))
Banco de Dados I
92
Captulo 4
Operao Diviso A operao diviso, representada por (), uma operao binria e usada em consultas em que os atributos da relao final so os atributos da relao1 que no existem na relao2. As linhas da relao final contm 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 operao. Sintaxe: (Relao1 Relao2)
Figura 41 - Operao Diviso
Usando o esquema exemplo, suponha que desejemos encontrar todos os clientes que tm uma conta em todas as agncias localizadas em Vitria. Podemos obter todas as agncias de Vitria por meio da expresso: r1 codigoAg (cidade=Vitria (AGNCIAS)) A tabela 30 mostra a relao resultante da consulta acima. Tabela 30 - Tabela resultante da consulta codigoAg (cidade=Vitria (AGNCIAS)) codigoAg 50 51 Podemos encontrar todos os pares Nome, CodigoAg, nos quais um cliente possui uma conta em uma agncia, escrevendo: r2 Clientes.nome, Depositos.codigoAg (CLIENTES |X| DEPOSITOS) A tabela 31 mostra a relao resultante da consulta.
93
Tabela 31 - Tabela resultante da consulta codigoAg (cidade=Vitria (AGNCIAS)) nome Ana Lara Joo Jos codigoAg 50 51 51 53
Agora precisamos encontrar clientes que apaream em r2 com cada cdigo de agncia em r1. Escrevemos essa consulta da seguinte forma: Clientes.Nome, Depositos.codigoAg (DEPOSITOS |X| CLIENTES) codigoAg (cidade=Vitria (AGNCIAS)) Neste caso, nenhum cliente ser retornado, pois ningum possui conta em todas as agncias de Vitria. Operao de Remoo A operao remoo se faz necessria sempre que houver necessidade de excluir tuplas de uma relao. Sintaxe: R = R E , onde E uma consulta da lgebra relacional Exemplo1: Excluir todos os depsitos do cliente de cdigo 01 Depositos = Depositos - (codigoCli = 01 (DEPOSITOS)) Exemplo2: Excluir todas as contas de joo E codigoAg, CLIENTES))
numeroCont, codigoCli, saldo
(nome=joo
(DEPOSITOS |X|
DEPOSITOS = DEPOSITOS - E Operao de Insero A operao insero se faz necessria sempre que houver a necessidade de incluir tuplas em uma relao. Sintaxe: R = R E , onde E uma consulta da lgebra relacional Exemplo1: DEPOSITOS = DEPOSITOS {(51, 980987, 1, 1200)}
Banco de Dados I
94
Captulo 4
Exemplo2: Gerar um depsito para todas as pessoas que possuem emprstimos. A conta gerada ter o mesmo nmero do emprstimo e o valor do depsito ser igual ao da quantia emprestada. DEPOSITOS = DEPOSITOS codigoAg, numeroEmp, codigoCli, quantia (EMPRESTIMOS |X| CLIENTES)
Observe que as operaes de insero e remoo utilizam-se como base as operaes diferena e unio de conjuntos, assim sendo, as condies necessrias para estas operaes serem vlidas tambm se aplicam s operaes de insero e remoo. Digo: para uma operao unio e diferena de conjunto ser vlida, necessrio que duas condies sejam satisfeitas: 1. as relaes r e s precisam ter a mesma paridade. Isto , elas precisam ter o mesmo nmero de atributos e; 2. os domnios do i-simo atributo de r e do i-simo atributo de s devem ser os mesmos.
Operao de Atualizao A operao atualizao, representada pela letra grega delta (), faz-se necessria sempre que houver a necessidade de alterar valores de tuplas em uma relao. 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 ))
95
Neste captulo tratamos apenas da lgebra Relacional, no tendo sido abordado o Clculo relacional de Tupla. Uma boa fonte de pesquisa para os estudos sobre clculo relacional de tupla o livro Sistemas de Banco de Dados, de Abraham Silberchatz, captulo 5.
ATIVIDADE 3 Considere o esquema seguinte para construir expresses, usando operaes da lgebra relacional para as questes 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 automveis (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 automvel). 5. Consultar as pessoas (nomes) que no compraram Ford. 6. Consultar as pessoas (nomes) que compraram Ford e no compraram Volks. 7. Consultar o nome do carro mais caro. 8. Atualizar os valores dos automveis 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 razes para a consolidao dos bancos de dados relacionais no mercado. Desde sua definio como paBanco de Dados I
96
Captulo 4
dro, em 1986, passou por diversas revises, gerando publicaes de novas verses. A verso original, denominada Sequel, foi desenvolvida no Laboratrio de Pesquisa da IBM e implementada como parte do projeto System R no incio dos anos 70. A linguagem evoluiu desde ento, e seu nome foi alterado para SQL (Structured Query Language). A primeira verso ficou conhecida como SQL-86 ou SQL1, a segunda verso foi denominada SQL-92 ou SQL2 e a ltima verso publicada, que incluiu recursos para dar suporte aos bancos de dados objetos-relacionais e orientados a objetos, ficou conhecida como SQL-99 ou SQL3. A maioria dos sistemas gerenciadores de bancos de dados comerciais implementam suporte ao padro SQL. Alm disso, incorporam uma srie de funes adicionais visando a facilitar o trabalho dos desenvolvedores. Estas facilidades precisam ser usadas com cautela, pois, se apenas o padro for utilizado, garante-se a portabilidade, caso haja a necessidade de troca de SGBD. A linguagem SQL possui diversas partes: linguagem de Definio de Dados (DDL) - Inclui comandos para definio de esquemas de relaes (criao, excluso, alterao), criao de ndices dentre outros; linguagem de manipulao de dados (DML) - Inclui comandos para consulta, insero, excluso e modificao de tuplas em uma relao do banco de dados; incorporao DML (SQL Embutida) - Uso de SQL em linguagens de programao de uso geral, como Pascal, C,...; definio de Vises - A SQL DDL inclui comandos para definio de vises; autorizao - A SQL DDL inclui comandos para especificao de direitos de acesso a relaes e vises; integridade - A SQL DDL inclui comandos para especificao de regras de integridade que os dados que sero armazenados no banco de dados devem satisfazer; controle de Transaes - A SQL DDL inclui comandos para especificao de iniciao e finalizao de transaes.
4.3.1 Linguagem de manipulao de dados SQL DML Consultas SELECT O comando SELECT responsvel por consultar dados em um banco de dados que satisfazem aos predicados (critrios) informados. A estrutura bsica de uma expresso SQL SELECT consiste em trs clusulas: select, from e where.
97
a clusula select corresponde operao projeo da lgebra relacional. usada para listar os atributos desejados no resultado de uma consulta; a clusula from corresponde operao produto cartesiano da lgebra relacional. Ela lista as relaes a serem examinadas na avaliao da expresso; a clusula where corresponde ao predicado de seleo da lgebra relacional. Consiste em um predicado envolvendo atributos de relaes que aparecem na clusula from. Uma tpica consulta SQL SELECT tem a seguinte forma:
SELECT A1, A2, ..., An FROM r1, r2, ..., rn [WHERE P]
3 1 2
Cada Ai representa um atributo e cada ri uma relao. P um predicado. Essa consulta equivalente expresso da lgebra relacional: A1, A2, ..., An (P (r1 x r2 x ...x rn)) A lista de atributos A1, A2, ..., An pode ser substituda por um (*) para selecionar todos os atributos (colunas) presentes nas tabelas da clusula from.
3 1 2
A numerao constante no final de cada linha da consulta representa a ordem de execuo desta linha, dentro da consulta como um todo. Mesmo que o otimizador altere a ordem de execuo, buscando por melhoria de performance e para facilitar o aprendizado interessante termos em mente esta ordem.
Para execuo da consulta acima, forma-se o produto cartesiano das relaes referenciadas na clusula from, executa-se uma seleo da lgebra relacional usando o predicado da clusula where e, ento, projeta o resultado para os atributos da clusula select. Na prtica, o otimizador de consultas da linguagem SQL pode converter essa expresso em uma forma
Banco de Dados I
98
Captulo 4
equivalente que pode ser processada mais eficientemente, mas para efeito didtico iremos manter esta ordem de execuo. Uma consulta completa pode ter as clusulas abaixo, sendo que apenas as clusulas SELECT e FROM so obrigatrias. O nmero que segue cada linha sugere a ordem de execuo. O conhecimento desta ordem importante para efeito didtico pois facilita o entendimento do comando.
6 1 2
[GROUP BY A1, A2, ..., An] 3 [HAVING Condio] [ORDER BY A1, A2, ..., An] 5
Cada uma das clusulas da consulta acima ser explorada nas subsees seguintes.
Assim como na lgebra relacional, o resultado de uma consulta SQL uma relao!
Vamos considerar uma primeira consulta simples, usando nosso esquema exemplo. Encontre os nomes de todos os clientes na relao clientes. A consulta SQL pode ser escrita da seguinte forma: SELECT Nome FROM Clientes Linhas (tuplas) duplicadas Em algumas situaes, uma consulta SQL pode retornar uma relao que contenha tuplas (linhas) duplicadas. Nessa situao, inserimos a palavra-chave distinct depois da clusula select para elimin-las.
99
Aproveitando o exemplo anterior, a relao resultante poder ter clientes que possuam o mesmo nome. Nesse caso, podemos eliminar essas duplicaes usando a clusula distinct: SELECT DISTINCT Nome FROM Clientes
A clusula distinct aplica-se linha a ser retornada, embora seja colocada antes do primeiro atributo.
Predicados e ligaes A SQL no tem uma representao da operao ligao natural. No entanto, uma vez que a ligao natural definida em termos de produto cartesiano, seleo e projeo, relativamente simples escrever uma expresso SQL para representar a operao ligao natural. Ex.: Encontre os nomes e cidades de clientes que possuam emprstimos em alguma agncia. Esta consulta pode ser escrita da seguinte forma: SELECT DISTINCT Clientes.nome, Clientes.cidade FROM Clientes, Emprestimos WHERE Clientes.codigoCli=Emprestimos.codigoCli
Observe que na consulta acima, apenas necessita-se saber se o cliente possui emprstimo, por isto apenas as tabelas Clientes e Emprstimos foram includas. Se alm disso, tivesse a necessidade de saber qual a agncia em que o emprstimo foi feito, seria necessrio a incluso da relao Agncias.
Banco de Dados I
100
Captulo 4
Outro recurso disponvel na linguagem SQL para estabelecer ligaes entre tabelas so as operaes de join. A consulta acima poderia ser escrita da seguinte forma, usando join: SELECT DISTINCT Clientes.nome, Clientes .cidade FROM Clientes JOIN Emprestimos codigoCli=Emprestimos.codigoCli ON Clientes.
Uma boa fonte de pesquisa para complementar os estudos sobre os conceitos tratados nesta seo consultar o livro Sistemas de Banco de Dados, de Elmasri Navathe, captulo 8, que oferece outras opes de join .
A SQL inclui os conectores and, or e not ; caracteres especiais: (, ), ., :, _, %,<, >, <= , >= , = , <>, +, - ,* e /; operador para comparao: between, como mostra o exemplo a seguir. Ex.: Selecionar todas as contas que possuam saldo entre 10000 e 20000. SELECT numeroCont FROM Depositos WHERE saldo BETWEEN 10000 AND 20000 Que equivale a consulta SELECT numeroCont FROM Depositos WHERE saldo >= 10000 AND saldo <= 20000 A SQL inclui tambm um operador para comparaes 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 subcadeia na.
101
SELECT distinct nome FROM Clientes WHERE rua LIKE %na% Ou tambm Ex.: Encontre os nomes de todos os clientes cujas ruas onde moram finalizem com a subcadeia na.
SELECT distinct nome FROM Clientes WHERE rua LIKE %na Para que o padro possa incluir os caracteres especiais ( isto , % , _ , etc...), a SQL permite a especificao 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 comparao like, usando a palavra-chave escape. Para ilustrar, considere os padres seguintes, que utilizam uma barra invertida como caractere de escape. Like ab\%cd% escape \ substitui todas as cadeias comeando com ab%cd; Like ab\_cd% escape \ substitui todas as cadeias comeando com ab_cd. A procura por no-substituies em vez de substituies se d por meio do operador not like.
Embora a clusula Like seja muito til, deve ser utilizada com cuidado. Quando fixar o incio da cadeia, como iniciar com Maria, no h problemas, porm, quando for aplicada em consultas para procurar caracteres no meio ou no final de cadeias, nas quais no se conhece o incio, teremos problemas! Nesse caso no usar o ndice, caso haja para a coluna, podendo implicar em baixa performance das aplicaes.
Banco de Dados I
102
Captulo 4
Operaes de conjunto A SQL inclui o operador de conjunto union que opera em relaes e corresponde operao da lgebra relacional. Uma vez que as relaes so conjuntos, na unio destas relaes, as linhas duplicadas so eliminadas.
Para uma operao Unio (Union) r s ser vlida, duas condies devem ser atendidas: as relaes r e s precisam ter a mesma paridade, isto , elas precisam ter o mesmo nmero de atributos; e os domnios 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 emprstimos na agncia de cdigo 51, fazemos: SELECT DISTINCT Clientes.nome FROM Clientes, Emprestimos WHERE Clientes.codigoCli=Emprestimos.codigoCli AND Emprestimos.codigoAg = 51 Da mesma forma, se quisermos consultar todos os clientes que possuem depsitos na agncia de cdigo 51, fazemos: SELECT DISTINCT Clientes.nome FROM Clientes, Depositos WHERE Clientes.codigoCli= Depositos.codigoCli AND Depositos.codigoAg = 51 Para encontrar todos os clientes que possuem depsito, emprstimo ou ambos, na agncia de cdigo 51, fazemos: SELECT DISTINCT Clientes.nome FROM Clientes, Depositos WHERE Clientes.codigoCli=Depositos.codigoCli AND Depositos.codigoAg =51
103
UNION SELECT DISTINCT Clientes.nome FROM Clientes, Emprestimos WHERE Clientes.codigoCli=Emprestimos.codigoCli AND Emprestimos.codigoAg = 51 Ordenando a exibio de tuplas A clusula order by organiza o resultado de uma consulta em uma ordem determinada. Para listar em ordem alfabtica todos os clientes do banco, fazemos:
SELECT DISTINCT nome FROM Clientes ORDER BY nome Como padro, a clusula order by lista tuplas na ordem ascendente. Para especificar a ordem de classificao, podemos especificar asc para ordem ascendente e desc para descendente. Podemos ordenar uma relao 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 alfabtica, utilize a clusula Order By. s vezes, construmos consultas e o resultado apresentado em ordem alfabtica, conforme esperado, e no nos preocupamos em usar a clusula Order by. Isso acontece provavelmente porque h um ndice ordenado criado sobre essa coluna; porm, se o DBA resolver criar esse ndice sobre outra coluna, sua ordenao vai se perder!
Banco de Dados I
104
Captulo 4
Membros de conjuntos O conectivo in/not in testa os membros de conjunto em que o conjunto uma coleo de valores produzidos por uma clusula select. Para ilustrar, considere a consulta Encontre todos os clientes que possuem uma conta (Depsito) e no possuem emprstimo na agncia Princesa Isabel. A consulta SQL poder ser escrita da seguinte forma:
SELECT DISTINCT Clientes.nome FROM Clientes WHERE Clientes.codigoCli IN (SELECT CodigoCli FROM Depositos, Agencias WHERE Depositos.codigoAg = Agencias. codigoAg AND NomeAg = Princesa Isabel) AND Clientes.codigoCli NOT IN (SELECT codigoCli FROM Emprestimos, Agencias WHERE emprestimos.codigoAg = agencias.codigoAg AND nomeAg = Princesa Isabel) Esta consulta equivalente consulta abaixo. Ela foi construda desta forma para exemplificar o uso do operador IN.
SELECT DISTINCT Clientes.nome FROM Clientes, Depositos, Agencias WHERE Clientes.codigoCli = Depositos.codigoCli AND Depositos.codigoAg = Agencias.codigoAg AND Agencias.NomeAg = Princesa Isabel AND Clientes.codigoCli NOT IN (SELECT codigoCli FROM Emprestimos, Agencias WHERE emprestimos.codigoAg = agencias.codigoAg AND nomeAg = Princesa Isabel)
105
Renomeao de Tabelas em uma consulta A renomeao sempre ser necessria quando precisarmos usar a mesma tabela mais de uma vez na mesma consulta, assim como na operao renomear da lgebra relacional. Muitas vezes usamos este recurso com o objetivo de reduzir o tamanho das expresses SQL. A renomeao feita usando a palavra reservada AS, aps o nome da tabela na clusula FROM, como mostra o exemplo a seguir.
Ex: encontre o nome e a cidade de todos os clientes que possuem depsito. SELECT DISTINCT C.nome, C.cidade FROM Clientes AS C, Depositos AS D WHERE C.codigoCli = D.codigoCli Uma vez que as relaes Clientes e Depsitos foram renomeadas para C e D, quaisquer referncias a essas tabelas, na consulta, devem ser feitas a C e D, e no mais aos nomes originais. Lembre-se da ordem de execuo de uma consulta SELECT!
Redefinindo a relao Agncias para uso em exemplos posteriores. Agencias = (CodigoAg, NomeAg, CidadeAg, ativos)
Comparao de conjuntos Considere a consulta encontre todas as agncias que possuem ativos maiores que alguma agncia de Vitria. Esta consulta poder ser escrita em SQL da seguinte forma: SELECT DISTINCT Agencias.nomeAg FROM Agencias , Agencias AS ag WHERE agencias.ativos > ag.ativos AND ag.cidade = Vitria Uma vez que a consulta usa uma comparao maior que, no podemos escrever a expresso usando a construo in. Observe tambm que, como houve necessidade de usar a mesma tabela (Agncias) duas vezes na consulta, ela teve que ser renomeada.
Banco de Dados I
106
Captulo 4
A mesma consulta acima poderia ser escrita usando o operador any (pelo menos um), conforme ser abordado a seguir. Comparaes do tipo >any, <any, >=any, <=any, =any so aceitas pela linguagem. A consulta anterior pode ser escrita da seguinte forma: SELECT Agencias.NomeAg FROM Agencias WHERE ativos > ANY (SELECT ativos FROM Agencias WHERE Agencias.cidade = Vitria) Vamos modificar a consulta anterior levemente para encontrar todas as agncias que possuem ativos maiores do que todas as agncias de Vitria. A construo > all corresponde frase maior que todos. A consulta fica como se segue: SELECT Agencias.nomeAg FROM Agencias WHERE ativos > ALL (SELECT ativos FROM Agencias WHERE Agencias.cidade = Vitria) Como o operador Any, o operador all pode ser usado como: >all, <all, >=all, <=all, =all e <> all.
107
Sempre que houver necessidade de comparar um atributo com o resultado de uma subconsulta necessrio usar um operador de conjunto, seja o operador ALL seja o ANY, como ilustrado no exemplo acima. Testando relaes vazias A SQL possui um recurso para testar se uma subconsulta retorna alguma tupla. A construo exists retorna true se a subconsulta retornar alguma tupla. Para ilustrar, vamos escrever a consulta Encontre todos os clientes que possuem depsito e no possuem emprstimo na agncia Princesa Isabel . SELECT Clientes.Nome FROM Clientes WHERE EXISTS (SELECT * FROM Depositos, Agencias WHERE Depositos.codigoCli= Clientes.codigoCli AND Depositos.codigoAg = Agencias.codigoAg AND Agencias.nomeAg = Princesa Isabel) WHERE NOT EXISTS (SELECT * FROM Emprestimos, Agencias WHERE Emprestimos.codigoCli= Clientes.codigoCli AND Emprestimos.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 consulta. Na verdade, algumas consultas mais complexas so resolvidas com o operador EXISTS/NOT EXISTS, sendo esse operador um pouco mais abrangente que os operadores IN / NOT IN.
Banco de Dados I
108
Captulo 4
Considerando que o objetivo do operador EXISTS verificar a existncia de tuplas na consulta seguinte, no importa o contedo retornado. 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 expresses seguintes, usando a linguagem SQL. PESSOAS (codigoPessoa, nomePessoa, cidade, chefe) Chefe referencia PESSOAS EMPRESAS (codigoEmpresa, nomeEmpresa, cidade) TRABALHA (codigoPessoa, codigoEmpresa, salario) codigoPessoa referencia Pessoas codigoEmpresa referencia Empresas 1. Consulte todas as pessoas que moram em Vitria. 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 no moram pessoas cujo primeiro nome seja Maria (usar operaes de conjunto). 5. Consulte todas as pessoas que no trabalham em Vitria e que ganham acima de R$2000,00 em ordem decrescente. 6. Consulte todas as pessoas que no trabalham na empresa cujos nomes comecem com inf_. O resultado dever ser apresentado em ordem alfabtica.
109
ATIVIDADE 5 Considere o esquema abaixo para construir as expresses seguintes, usando a linguagem SQL.
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 automveis do fabricante Ford. 3. Consultar as pessoas que no compraram Ford. 4. Consultar as pessoas que compraram carro com gio. O resultado dever ser apresentado em ordem alfabtica. 5. Consultar as pessoas que compraram Ford e no compraram Volks.
Funes agregadas A SQL oferece a habilidade para computar funes em grupos de tuplas, usando a clusula group by. O(s) atributo(s) informado(s) na clusula group by so usados para formar grupos. Tuplas com o mesmo valor em todos os atributos na clusula group by so colocados em um grupo.
Funes agregadas: Mdia: AVG Mnimo: MIN Mximo: MAX Soma: SUM Contar: COUNT
Banco de Dados I
110
Captulo 4
Para ilustrar, considere a consulta: Encontre o saldo mdio das contas em cada agncia.
SELECT Agencias.nomeAg, AVG(Depositos.saldo) AS saldoMedio FROM Depositos, Agencias WHERE Depositos.codigoAg = Agencias.codigoAg GROUP BY Agencias.nomeAg A tabela 32 abaixo mostra o resultado parcial da execuo da consulta (antes do agrupamento), tomando como base o conjunto de valores definidos no incio deste captulo para o esquema bancrio. Tabela 32 - Tabela resultante do produto cartesiano e seleo (clusula FROM e WHERE) Agencias. codigoAg 50 51 Agencias .nomeAg Centro Princesa Isabel Princesa Isabel Agencias .cidadeAg Vitria Vitria
codigo- numeAg roCont 50 51 999 991
codigosaldo Cli 01 02 1000 3200
51 53
992 993
03 04
2300 1200
51 53
Vitria
Avenida Vitria
Uma vez que o agrupamento feito, cada agncia (nomeAg) constituir um grupo, sobre o qual incidir a funo agregada (AVG). Com isto, temos o resultado na consulta exibido na tabela 33. Tabela 33 - Tabela resultante da consulta encontre o saldo mdio das contas em cada agncia.
111
nomeAg Centro Princesa Isabel Avenida
saldoMedio 1000 2750 1200
Quando escrevemos a clusula GROUP BY em uma expresso SQL, a clusula SELECT s poder retornar atributos que constam no grupo. Alm deles, apenas funes agregadas so permitidas. Caso contrrio, dar erro!
Se, alm do saldo mdio por cada agncia, quisssemos retornar a quantidade 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 clusula COUNT importante o uso da clusula distinct , pois um cliente pode ter mais de uma conta em uma agncia e dever ser contado uma nica vez. A tabela 34 abaixo mostra o resultado da consulta. Tabela 34 - Tabela resultante da consulta encontre o saldo mdio e quantidade de clientes em cada agncia. nomeAg Centro Princesa Isabel Avenida saldoMedio 1000 2750 1200 qtdClientes 1 2 1
Banco de Dados I
112
Captulo 4
A consulta abaixo mostra o maior saldo para cada agncia. SELECT Agencias.nomeAg, MAX(Depositos.saldo) AS maiorSaldo FROM Depositos, Agencias WHERE Depositos.codigoAg= Agencias.codigoAg GROUP BY Agencias.nomeAg A tabela 35 mostra o resultado da execuo da consulta. Tabela 35 - Tabela resultante da consulta encontre o maior saldo para cada agncia. nomeAg Centro Princesa Isabel Avenida maiorSaldo 1000 3200 1200
Muitas vezes necessrio definir uma condio que se aplique a grupos em vez de tuplas. Por exemplo, poderamos estar interessados apenas em agncias em que a mdia dos saldos seja superior a R$1200,00. Essa condio ser aplicada a cada grupo e no a tuplas simples, e definida pela clusula having. Podemos escrever essa expresso SQL assim: SELECT Agencias.nomeAg, AVG(Depositos.saldo) AS saldoMedio FROM Depositos, Agencias WHERE Depositos.codigoAg= Agencias.codigoAg GROUP BY Agencias.nomeAg HAVING AVG(saldo)>1200 A tabela 36 mostra o resultado da execuo da consulta. No caso, apenas a agncia Princesa Isabel ser retornada. Tabela 36 - Tabela resultante da consulta encontre as agncias onde a mdia de saldo seja superior a 1200. nomeAg Princesa Isabel saldoMedio 2750
A clusula WHERE elimina linhas em uma consulta. A clusula HAVING elimina grupos. s vezes, desejamos tratar a relao inteira como um grupo simples. Nesses casos, no usamos a clusula group by. Para encontrar a mdia de saldos de todas as contas, escrevemos:
113
SELECT AVG (Depositos.saldo) FROM Depositos No exemplo anterior, a coluna projetada por meio de uma funo agregada, a mdia de saldos, no possui um nome, ou seja, no foi renomeada como nos exemplos anteriores. sempre recomendado que se d um nome para identific-la. Para criar este nome, tambm chamado de Alias usa-se a clusula AS, assim como para renomeao de tabelas. Caso contrrio, ao execut-la, a coluna aparecer com o nome EXPR, por exemplo.
ATIVIDADE 6 Considere o esquema bancrio para construir as expresses seguintes, usando a linguagem SQL. 1. Consultar todos os clientes que possuem contas em agncia(s) que possui(em) o maior ativo. 2. Consultar o total de agncias por cidade, classificado por cidade. 3. Consultar, por agncias, o(s) cliente(s) com o maior saldo. 4. Consultar o valor mdio de emprstimos efetuados por cada agncia, em ordem crescente das cidades onde essas agncias se situam. 5. Consultar a(s) agncia(s) que possui(em) a maior mdia de quantia emprestada. 6. Consultar todas as agncias situadas fora de Vitria que possuem a mdia de depsitos maior do que alguma agncia localizada em Vitria. 7. Consultar o menor saldo de clientes, por agncias. 8. Consultar o saldo de cada cliente, caso ele possua mais de uma conta no banco.
Banco de Dados I
114
Captulo 4
Removendo linhas de uma tabela O comando Delete usado para remover tuplas em uma dada relao. Lembre-se de que s podemos remover tuplas inteiras, no podemos remover valores apenas em atributos particulares. Sintaxe: DELETE FROM r [WHERE P] Onde r representa uma relao e P um predicado. Note que o comando delete opera em apenas uma relao. O predicado da clusula where pode ser to complexo quanto o predicado where do comando select. Ex1.: Fazer uma consulta para excluir todas as tuplas de emprstimo. DELETE FROM Emprestimos Ex2.: Remover todos os depsitos de joo DELETE FROM Depositos.Depositos WHERE Depositos.codigoCli in (SELECT codigoCli FROM Clientes WHERE nome=joo) Ex3.: Remover todos os emprstimos com nmeros entre 1300 e 1500. DELETE FROM Emprestimos WHERE numero between 1300 AND 1500 Ex4.: Remover todos os depsitos de agncias localizadas em Vitria. DELETE FROM Depositos WHERE depositos.codigoAg in (SELECT codigoAg FROM Agencias WHERE cidade=Vitoria)
115
O comando DELETE um comando da Linguagem DML; por isso, se usar o comando DELETE FROM Tabela sem predicado na clusula WHERE, todas as linhas sero excludas; a tabela, no entanto, permanecer criada, porm vazia.
Inserindo linhas em uma tabela Para inserir um dado em uma relao, 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 domnio do atributo. Sintaxe: INSERT INTO r (A1, A2, ..., An) VALUES (V1, V2, ..., Vn) Onde r representa uma relao A atributos e V valores a serem inseridos. Suponha que desejamos inserir um novo depsito de Joo (cdigo = 1), cujo valor seja R$1200,00, na conta 9000 da agncia de cdigo=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 insero seja escrita da seguinte forma: Insert into depositos Values (2,9000,1,1200), omitindo a relao de atributos. Essa abordagem, porm, no recomendada, tendo em vista que, se houver alterao do esquema da relao, a exemplo da incluso de um novo atributo, a consulta falhar e, consequentemente, a aplicao que a utiliza acarretar em erros.
Banco de Dados I
116
Captulo 4
Podemos querer tambm inserir tuplas baseadas no resultado de uma consulta. Suponha que desejemos inserir todos os clientes que possuam emprstimos na agncia Princesa Isabel na relao depsitos, com um saldo de R$200,00. INSERT INTO Depositos (codigoAg, numeroCont, codigoCli, saldo) SELECT Emprestimos.codigoAg, Emprstimos.numeroEmp, Emprstimos.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 migrao de banco de dados.
Atualizando valores Em certas situaes, 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 relao, 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 no 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 acrescentados 5% em todos os saldos. Escrevemos UPDATE Depositos SET saldo = saldo * 1.05
117
Suponha que todas as contas com saldo superior a R$10000,00 recebam aumento de 6% e as demais de 5%. UPDATE Depositos SET saldo = saldo * 1.06 WHERE saldo >10000 UPDATE Depositos SET saldo = saldo * 1.05 WHERE saldo<=10000
A clusula where pode conter uma srie de comandos select aninhados. Considere, por exemplo, que todas as contas de pessoas que possuem emprstimos no banco tero acrscimo de 1%. UPDATE Depositos SET saldo = saldo * 1.01 WHERE codigoCli IN (SELECT codigoCli FROM Emprestimos) Como voc deve ter observado, os comandos de atualizao INSERT, UPDATE e DELETE atuam sempre sobre uma nica tabela. No possvel inserir linhas em mais de uma tabela em um comando.
Valores Nulos possvel para tuplas inseridas em uma dada relao atribuir valores a apenas alguns atributos do esquema. Os atributos restantes so designados como nulos. Considere a expresso cujo objetivo o de incluir uma nova agncia: INSERT INTO Agencias (codigoAg, nomeAg, cidadeAg, ativos) VALUES (2,Centro, Vitria, NULL) Nesse caso, est sendo atribudo 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, Vitria)
Banco de Dados I
118
Captulo 4
A consulta acima s ser vlida se o campo ativos puder assumir valor nulo. Caso contrrio, 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 relao emprstimos com valores nulos para quantia, escrevemos: SELECT DISTINCT nome FROM Clientes, Emprestimos WHERE Clientes.codigoCli = Emprestimos.codigoCli AND quantia IS NULL O predicado IS NOT NULL testa a ausncia de um valor nulo.
119
ATIVIDADE 7 Considere o esquema abaixo para construir as expresses seguintes, usando a linguagem SQL. PESSOAS (codigoPessoa, nomePessoa, cidade, chefe) Chefe referencia PESSOAS EMPRESAS (codigoEmpresa, nomeEmpresa, cidade) TRABALHA (codigoPessoa, codigoEmpresa, salario) codigoPessoa referencia Pessoas codigoEmpresa referencia Empresas Observao: estas atividades foram elaboradas para exercitar os comandos de atualizao. Desconsidere a integridade referencial dos dados. 1. Exclua todas as pessoas que possuem salrio = R$1000,00. 2. Exclua todas as pessoas que trabalham em empresas situadas em Vitria. 3. Inclua na empresa de cdigo 01, com um salrio= R$100,00, todos os moradores de Vitria 4. Uma determinada empresa de cdigo x vai contratar todos os funcionrios da empresa de cdigo y que ganham acima de R$1000,00, dando um aumento de salrio de 10%. Faa comando(s) SQL para que tal transao seja efetuada. Obs: As pessoas sero remanejadas. 5. Uma determinada empresa de cdigo xyz quer contratar todos que moram em Vitria e esto desempregados. Sero contratados com salrio = R$200,00. Faa comando(s) SQL para efetuar tal transao. 6. Faa um comando SQL para ajustar o salrio de todos os funcionrios da empresa Campana em 5%. 7. Todas as pessoas que moram em Colatina e trabalham na empresa Campana devero se mudar para Vitria, devido aos requisitos do diretor da empresa. Faa comando(s) SQL para efetivar a atualizao da cidade.
Banco de Dados I
120
Captulo 4
4.3.2 Linguagem de Definio de dados SQL DDL O conjunto de relaes de um Banco de Dados precisa ser especificado ao sistema por meio de uma linguagem de definio de dados (DDL). A SQL DDL permite a especificao no apenas de um conjunto de relaes, mas tambm de informaes sobre cada relao, incluindo: o esquema para cada relao; o domnio de valores associados a cada atributo; o conjunto de ndices a ser mantido para cada relao; restries de integridade; a estrutura fsica de armazenamento de cada relao no disco.
Tipos de Domnios da Linguagem SQL A linguagem SQL inclui diversos tipos de domnios, conforme lista abaixo [SILBERSCHATZ, 2006]: Char(n): cadeia de caracteres de tamanho fixo, igual a n, definido pelo usurio; Varchar(n): cadeia de caracteres de tamanho varivel, no mximo igual a n, definido pelo usurio; Int: inteiro (subconjunto finito dos inteiros que depende do equipamento). Smallint: inteiro pequeno (um subconjunto do domnio dos inteiros que depende do equipamento); Numeric(p,d): nmero de ponto fixo cuja preciso definida pelo usurio. O nmero consiste de p dgitos, sendo que d dos p dgitos esto direita do ponto decimal; Real: nmeros de ponto flutuante cuja preciso depende do equipamento em questo; Float(n): nmero de ponto flutuante com a preciso definida pelo usurio em pelo menos n dgitos; Date: calendrio contendo um ano (com quatro dgitos), ms e dia do ms; Time: representa horrio, em horas, minutos e segundos.
121
Se voc definir um campo de uma tabela como varchar(50), por exemplo, e se o espao necessrio para alocar um valor para esse campo tiver 10 caracteres, apenas 10 espaos sero alocados. Se, no entanto, esse campo for definido como char(50), usando ou no, sero alocados os 50 espaos.
Ao definir um campo de uma tabela, se ocupar sempre a mesma quantidade de caracteres, melhor definir como char. Se o tamanho for varivel, use varchar.
Uma relao SQL definida usando a instruo CREATE TABLE. CREATE TABLE r (A1 D1, ..., An Dn) Em que r uma relao, cada Ai o nome de um atributo no esquema de relao r e Di o tipo de dados de valores no domnio de atributo Ai. O comando create table inclui opes para especificar certas restries de integridade, conforme veremos adiante. A relao criada acima est inicialmente vazia. O comando insert poder ser usado para carregar os dados para uma relao. Para remover uma relao de banco de dados SQL, usamos o comando drop table, que remove todas as informaes sobre a relao retirada do banco de dados. DROP TABLE r Ex. : para excluir a relao Depsitos, podemos escrever a seguinte expresso SQL. DROP TABLE Depositos
Ao excluir uma tabela, caso exista outra tabela com chave estrangeira que faa referncia tabela que est sendo excluda, ocorrer erro. necessrio excluir antes a tabela referenciada ou usar excluso em cascata, como mostra o exemplo: DROP TABLE Depositos CASCADE Neste caso, caso haja uma tabela que faa referncia tabela Depositos, esta tambm ser eliminada do banco de dados.
Banco de Dados I
122
Captulo 4
O comando alter table usado para alterar a estrutura de uma relao existente. Ao alterar a estrutura de uma tabela, possvel incluir novos campos, excluir campos existentes ou incluir restries, a exemplo de chaves primrias e estrangeiras. Exemplo de um comando alter table incluindo uma coluna cpf na relao Clientes: ALTER TABLE Clientes ADD cpf NUMERIC(11,0) NULL
Ao adicionar uma coluna em uma tabela existente, se esta tabela possuir registros, a coluna includa necessariamente dever ser NULL.
Exemplo de um comando alter table excluindo a coluna cpf , recm includa na relao Clientes: ALTER TABLE Clientes drop column cpf Exemplo de um comando alter table incluindo uma restrio, a chave primria da relao Clientes: ALTER TABLE Clientes ADD CONSTRAINT PK_Clientes PRIMARY KEY (CodigoCli) Integridade Quando se fala em manter a integridade de dados, considera-se no s a Integridade Fsica dos arquivos portadores do banco de dados, como tambm manuteno da qualidade dos dados armazenados em termos de preciso e consistncia. As restries de integridade fornecem meios para assegurar que mudanas feitas no banco de dados por usurios autorizados no resultem na perda da consistncia dos dados. So vrios os tipos de integridade, os quais costumam ser classificados da seguinte forma: Integridade de Domnio. Domnio uma lista de valores que precisa estar associada a todo atributo. Constitui a forma mais elementar de restrio 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 no assumir valor nulo. No pode permitir que os campos com entrada obrigatria assumam valores nulos.
123
Integridade de Chaves. Especifica a unicidade dos valores para a chave primria e candidatas. Integridade Referencial. Frequentemente, desejamos assegurar que um valor que aparece em uma relao para um dado conjunto de atributos aparea tambm para um certo conjunto de atributos em outra relao, o que se denomina Integridade Referencial. A existncia de uma chave estrangeira impede que anomalias ocorram em funo de alteraes executadas no banco de dados, conforme elencadas abaixo: ao incluir uma linha na tabela que contm a chave estrangeira, o valor inserido tem que fazer parte da tabela em que ela chave primria. O nico valor diferente desse que permitido o valor nulo, quando for possvel; ao excluir uma linha da tabela que contm chave primria referenciada por outras tabelas, pode-se implementar os seguintes cenrios: excluir em cascata as linhas nas tabelas relacionadas em que se encontram as chaves estrangeiras referentes a essa chave primria ou impedir que a excluso seja feita; ao alterar o valor da chave primria referenciada por outras tabelas, pode-se implementar os seguintes cenrios: alterar em cascata os valores das chaves estrangeiras nas tabelas relacionadas ou impedir que a alterao seja feita; ao se alterar o valor da chave estrangeira, deve-se ter garantia de que o novo valor esteja constante na tabela em que ela chave primria. Se no for, haver bloqueio na alterao. Implementando Integridade Referencial em SQL A SQL original padro no incluiu instrues para especificar chaves estrangeiras. Um subsequente recurso de aperfeioamento de integridade foi aprovado como uma adio ao padro. Esse recurso permite a especificao de chaves primrias, candidatas e estrangeiras como parte da instruo create table. a clusula primary key da instruo create table inclui uma lista de atributos que compreende a chave primria; a clusula unique da instruo create table inclui uma lista de atributos que compreende a chave candidata; a clusula foreign key da instruo create table inclui uma lista de atributos que compreende a chave estrangeira e o nome da relao referida pela chave estrangeira.
Banco de Dados I
124
Captulo 4
Criando as relaes clientes, agncias e depsitos para o esquema bancrio. 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 clusula Check garante integridade aos valores dos atributos e pode fazer referncia, inclusive, a valores de atributos em outras tabelas.
Embora tenhamos includo a clusula not null para os campos que compem a chave primria de cada tabela, no necessrio. A SQL assume que todos os campos chaves (primria) no permitam valores nulos.
125
Existe tambm a possibilidade de criar as tabelas sem integridade referencial e incluir essa implementao usando a instruo Alter Table.
Existe uma propriedade, implementada pela maioria dos SGBDs disponveis no mercado, que possibilita que um campo tenha seu valor incrementado automaticamente. A sintaxe, porm, difere para cada um. O MS SQL Server, por exemplo, implementa a propriedade identity(x,y), onde x define o valor inicial e y, o incremento. No exemplo de criao da tabela Agencias, considerando o cdigo da agncia como auto incrementvel, 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 agncia, no deve ser passado valor para o cdigo da agncia, considerando que este valor ser gerado pelo sistema, como mostra o exemplo a seguir: INSERT INTO Agencias (nomeAg, cidadeAg) VALUES (Centro, Vitria) A primeira agncia inserida ter o cdigo igual a um e a seguinte, igual a 2, considerando que o valor do incremento foi definido como 1.
Banco de Dados I
126
Captulo 4
As restries Default e Check sero mais exploradas na disciplina Banco de Dados II.
ATIVIDADE 8 Dados os esquemas abaixo, faa comandos SQL DDL padro 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 Disciplinas Historico (codigoC, nomeC) (codigoDisc, codigoCurso, nomeDisc) (codigoAl, codigoDisc, Periodo, nota) codigoCurso referencia Cursos codigoAl referencia Alunos codigoDisc referencia Disciplinas Pre_Requisitos (codigoDiscPos, codigoDiscPre) codigoDiscPos referencia Disciplinas codigoDiscPre referencia Disciplinas b) Clientes (codCliente, dtNascimento) nomeCliente, telefone,
Filmes (codFilme, nomeFilme, lancamento, dtAquisicao, codClasse) codClasse referencia Classes Fitas (codFilme, numeroFita, dublada) codFilme referencia Filmes Locacoes (codFilme, numeroFita, codCliente, dtLocacao, dtDevolucao, vlrLocacao, multa) (codFilme, numeroFita) referencia Fitas codCliente referencia Clientes Reservas (codfilme, codCliente, dtReserva, situacao) codFilme referencia Filmes codCliente referencia Clientes
127
Classes
(codClasse, nome, valor)
Obs.: Considere a entrada obrigatria de todos os campos, exceto os campos: telefones, data de devoluo de fitas e valor de multa. No permita valores diferentes de S ou N nos campos lancamento, na tabela Filmes, e dublada, na tabela Fitas.
Este captulo teve como objetivo o de apresentar conceitos de linguagens 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 contedos a serem explorados. Banco de Dados I, como uma primeira disciplina relacionada com a rea, incluiu conceitos introdutrios e essenciais de Banco de Dados. A prxima disciplina explorar aspectos relacionados com programao dentro dos Bancos de Dados e outros conceitos mais avanados.
Banco de Dados I
128
NAVATHE, Elmasri. Sistemas de Bancos de dados. 4. ed. So Paulo: Pearson Addison Wesley, 2005. DATE, Christopher. J. Bancos de dados: introduo aos sistemas de bancos de dados. 8. ed. Rio de Janeiro: Campus, 2004. SILBERSCHATZ, Abraham. Sistema de banco de dados. 5. ed. So Paulo: Campus, 2006. CHEN, Peter. Modelagem de Dados - A abordagem Entidade-Relacionamento para Projeto Lgico. So 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. Disponvel em http:// www.inf.ufes.br/%7Efalbo/disciplinas/projeto.html. Acesso em 23 de maro de 2009. COUGO, Paulo. Modelagem Conceitual e Projeto de Banco de Dados. Rio de Janeiro: Campus, 1997. POMPILHO, S. Anlise Essencial guia prtico de Anlise de Sistemas. Rio de Janeiro: Editora Cincia Moderna Ltda, 2002. SHLAER, S., MELLOR, S. J. Anlise de Sistemas Orientada para Objetos. So Paulo: McGraw-Hill : Newstec, 1990.

Apostila - Banco de Dados I 2011-03

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila - Banco de Dados I 2011-03

Enviado por

Direitos autorais:

Formatos disponíveis

PROF.

CLAUDINETE VICENTE BORGES FERREIRA

Conceitos importantes. Fique atento!

Indicao de leituras complemtares, referentes ao contedo estudado.

Destaque de algo importante, referente ao contedo apresentado. Ateno!

Reflexo/questionamento sobre algo importante referente ao contedo apresentado.

Espao reservado para as anotaes que voc julgar necessrias.

Cap. 2 - MODELAGEM DE DADOS 29

Cap. 3 - PROJETO LGICO DE BANCO DE DADOS 51

Cap. 4 - LINGUAGENS DE CONSULTA 71

Profa. Claudinete Vicente Borges Ferreira

Tecnologia em Anlise e Desenvolvimento de Sistemas

CONCEITOS DE BANCOS DE DADOS

Figura 1 - Ilustrao do conceito de um SGBD.

Tecnologia em Anlise e Desenvolvimento de Sistemas

Conceitos de Bancos de Dados

Sistemas de arquivos convencionais

Usurios de banco de dados

Conceitos de Bancos de Dados

1.5 Abstrao de dados

Tecnologia em Anlise e Desenvolvimento de Sistemas

Conceitos de Bancos de Dados

Arquitetura de sistemas de banco de dados

Conceitos de Bancos de Dados

Modelos de bancos de dados

Informtica Geografia Portugus

100 101 102 103

Matheus Vila Velha Gabriel Serra Joana Aracruz

Figura 3 - Exemplo de Banco de Dados Modelo Redes.

Conceitos de Bancos de Dados

Informtica Informtica 02 01 Informtica Geografia

Vitria 102 Gabriel Vila Velha 103 Serra

Figura 4 - Exemplo de Banco de Dados Modelo Hierrquico.

Tabela 2 - Tabela DEPARTAMENTOS CodDepto 01 02 03 NomeDepto Informtica Geografia Portugus

Conceitos de Bancos de Dados

Estrutura geral do sistema

Tecnologia em Anlise e Desenvolvimento de Sistemas

Conceitos de Bancos de Dados

Programadores de aplicao escreve Programas de aplicao

Administrador de banco de adados usa Ferramentas de Administrao

Cdigo de objetos do programa de aplicao

Compilador e organizador de DML

Mecanismo de avaliao de consulta

Gerenciador de autorizao e integridade

1.10 Linguagem de definio de dados (DDL)

Linguagem de manipulao de dados (DML)

1.12 Projetando bancos de dados

Conceitos de Bancos de Dados

Tecnologia em Anlise e Desenvolvimento de Sistemas

Conceitos de Bancos de Dados

Tecnologia em Anlise e Desenvolvimento de Sistemas

Motivos para construo de modelos

2.4 Modelo de entidades e relacionamentos - E/R

Tecnologia em Anlise e Desenvolvimento de Sistemas

Ex: FUNCIONRIOS, CARGOS, PESSOAS ...

Figura 6 - Exemplo de representao de conjunto de entidades

Tecnologia em Anlise e Desenvolvimento de Sistemas

Tecnologia em Anlise e Desenvolvimento de Sistemas

Atributos tambm descrevem caractersticas de relacionamentos, que veremos na prxima seo.

complemento numero logradouro cidade rua cep estado

endereco nome preco unt codigo

Figura 7 - Notao para Diagrama Entidade-Relacionamento proposto originalmente por Chen

Figura 8 - Notao alternativa para Diagrama Entidade-Relacionamento