Apostila Banco de Dados

Banco de Dados I
PROF. CLAUDINETE VICENTE BORGES FERREIRA
BANCO DE DADOS
VITRIA 2013
IFes Instituto Federal do Esprito Santo
Banco de Dados I
Governo Federal Ministro de Educao Fernando Haddad Ifes Instituto Federal do Esprito Santo Reitor Dnio Rebello Arantes Pr-Reitora de Ensino Cristiane Tenan Schlittler dos Santos
Banco de Dados I
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 complementares, 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
Sumrio
1. CONCEITOS DE BANCOS DE DADOS ................................................................................................................... 8 1.1. DEFINIO ........................................................................................................................................................... 8 1.2. OBJETIVOS ........................................................................................................................................................... 9 1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS................................................................................................. 9 1.4. USURIOS DE BANCO DE DADOS ................................................................................................................. 11 1.5. ABSTRAO DE DADOS .................................................................................................................................. 11 1.6. INDEPENDNCIA DE DADOS .......................................................................................................................... 12 1.7. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS ............................................................................... 13 1.7.1. Sistemas Centralizados ................................................................................................................................. 13 1.7.2. Sistemas Cliente-Servidor ............................................................................................................................. 13 1.7.3. Sistemas Paralelos ........................................................................................................................................ 14 1.7.4. Sistemas Distribudos .................................................................................................................................... 14 1.8. MODELOS DE BANCOS DE DADOS ................................................................................................................ 14 1.8.1. Modelo em Rede ............................................................................................................................................ 15 1.8.2. Modelo Hierrquico ...................................................................................................................................... 16 1.8.3. Modelo Relacional ........................................................................................................................................ 16 1.8.4. Modelo Objeto-Relacional ........................................................................................................................... 17 1.8.5. Modelo Orientado a Objeto .......................................................................................................................... 17 1.9. ESTRUTURA GERAL DO SISTEMA ................................................................................................................. 18 1.9.1. Componentes de processamentos de consultas ............................................................................................. 18 1.9.2. Componentes para administrao do armazenamento de dados .................................................................. 18 1.9.3. Outras estruturas de dados ........................................................................................................................... 18 1.10. LINGUAGEM DE DEFINIO DE DADOS (DDL) ........................................................................................ 19 1.11. LINGUAGEM DE MANIPULAO DE DADOS (DML) ............................................................................... 20 1.12. PROJETANDO BANCOS DE DADOS ............................................................................................................. 20 2. MODELAGEM DE DADOS ..................................................................................................................................... 24 2.1. INTRODUO .................................................................................................................................................... 24 2.2. MODELOS ........................................................................................................................................................... 24 2.3. MOTIVOS PARA CONSTRUO DE MODELOS ........................................................................................... 25 2.4. MODELO DE ENTIDADES E RELACIONAMENTOS E/R ........................................................................... 25 2.4.1. Entidades ....................................................................................................................................................... 25 2.4.2. Atributos ........................................................................................................................................................ 26 2.4.3. Relacionamentos ........................................................................................................................................... 30 2.5. DICIONRIO DE DADOS .................................................................................................................................. 37 2.6. EXEMPLO DE UM MODELO DE DADOS ........................................................................................................ 38 2.7. FERRAMENTAS CASE ...................................................................................................................................... 40 2.8. MODELO ER ESTENDIDO - EER ...................................................................................................................... 40 3. PROJETO LGICO DE BANCO DE DADOS ....................................................................................................... 42 3.1. DEFINIO ......................................................................................................................................................... 42 3.2. ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS .............................................................................. 42 3.3. CHAVES ............................................................................................................................................................... 43 3.4. PROPRIEDADES DO MODELO RELACIONAL............................................................................................... 45 3.5. TRADUO DO MODELO ER PARA O RELACIONAL ................................................................................. 46 3.5.1. Relacionamento 1:1....................................................................................................................................... 48 3.5.2. Relacionamento 1:N ...................................................................................................................................... 48 3.5.3. Relacionamento 1:N - identificado................................................................................................................ 49 3.5.4. Relacionamento N:N ..................................................................................................................................... 49 3.5.5. Generalizao e Especializao ................................................................................................................... 50 3.5.6. Autorrelacionamento 1:N .............................................................................................................................. 51 3.5.7. Autorrelacionamento N:N ............................................................................................................................. 52 3.5.8. Atributos Multivalorados .............................................................................................................................. 52 3.6. EXEMPLO DE PROJETO LGICO .................................................................................................................... 54
3.7. NORMALIZAO .............................................................................................................................................. 55 3.7.1. Primeira Forma Normal (1FN) ..................................................................................................................... 55 3.7.2. Segunda Forma Normal (2FN) ..................................................................................................................... 55 3.7.3. Terceira Forma Normal (3FN) ..................................................................................................................... 56 4. LINGUAGENS DE CONSULTA .............................................................................................................................. 58 4.1. DEFINIO ......................................................................................................................................................... 58 4.2. SQL ....................................................................................................................................................................... 58 4.2.1. Linguagem de Manipulao de Dados SQL DML ..................................................................................... 59 4.2.2. Linguagem de Definio de dados SQL DDL ............................................................................................ 75 REFERNCIAS .............................................................................................................................................................. 82
Ol! Meu nome Claudinete Borges, responsvel pela disciplina Banco de Dados. 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
1. 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.
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.
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 sistemas 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 escrito 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; 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. 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.
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 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 front-end 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. 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 encontramse 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 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.
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 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 subrvores 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 K1 (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.
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.
Tabela 1: Tabela EMPREGADOS
Matricula 01 02 03 04 CodDepto 01 02 03
Nome Luiza Matheus Gabriel Joana
Cidade Vitria Vila Velha Serra Aracruz NomeDepto Informtica Geografia Portugus
CodDepto 01 02 02 03
Tabela 2: Tabela DEPARTAMENTOS
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 caracterizamse 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. 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 armazenamento de dados
administrao
do
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 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.
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;
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 noprojetados. 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 Modelo 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 01 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?
Atividade 02 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
nome Ana Maria Jos Pedro Joana Joo
CPF 123 234 245 125 435 467
cargo 2 1 3 1 2 1
nomeCargo Programador Topgrafo Engenheiro Pedreiro Motorista
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...
Atividade 03
1) Numere a segunda coluna de acordo com a primeira.
1. Possibilidade de erros de acesso concorrente 2. Abstrao dados 3. Integridade de
( ) Refere-se preciso ou validade dos dados. ( ) Tarefa de um SGBD. ( ) Se alterar o esquema conceitual, no necessrio reescrever aplicaes. ( ) Responsvel pela modificao de dados armazenados no banco de dados. ( ) Se alterar o esquema fsico, no necessrio reescrever aplicaes. ( ) Contm a especificao dos esquemas de banco. ( ) Conjunto de informaes contidas em determinado banco de dados, em um determinado momento. ( ) Trata-se de um modelo de banco de dados. ( ) Os usurios no precisam saber como os dados so armazenados e mantidos. ( ) Desvantagem de sistemas de arquivos.
4. Instncia
5. Independncia lgica de dados 6. Independncia fsica de dados 7. Controle concorrncia de
8. Linguagem de Definio de Dados (DDL) 9. Linguagem de Manipulao de Dados (DML) 10. ObjetoRelacional
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.
2. 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: 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 RELACIONAMENTOS E/R
ENTIDADES
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.
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 ...
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; 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 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. 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
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 separ-los 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 Atributo: cdigo
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.
Figura 7: Notao para Diagrama Entidade-Relacionamento proposto originalmente por Chen
Figura 8: Notao alternativa para Diagrama Entidade-Relacionamento
logradouro
Complemento (0,1) numero cidade estado rua Razao social endereco codigo cep
codigo
CNPJ
nome
Preco unit
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.
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.
Figura 11: Diagrama de ocorrncias

Fonte: Heuser, 2004. Adaptao.
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.
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.
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 leitura 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.
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 (Um-para-um), 1:N (Um-para-Muitos) e, N:N (Muitos-para-Muitos).
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.
Figura 15: Exemplo de relacionamento 1:1
Conjunto simblico da entidade FUNCIONRIOS
Conjunto simblico da entidade PROJETOS
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.
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.
Figura 19: Exemplo de relacionamento N:N
Figura 20: Representao simblica do relacionamento N:N (muitos-paramuitos)
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.
Figura 21: Exemplo de agregao N:N [Falbo, 2009]
Os exemplos acima mostram os diferentes tipos de relacionamentos aplicados a conjuntos de entidades diferentes, porm tambm se aplicam a autorrelacionamentos.
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.
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 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.
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.
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.
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.
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. Lembre-se 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. A figura 25 mostra o modelo ER correspondente ao contexto descrito anteriormente.
Figura 25: Modelo ER referente ao estudo de caso Campeonato de Frmula 1
Dicionrio de Dados: EQUIPES = codEquipe + nomeEquipe PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso PAISES = 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.
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 encontra-se 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.
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.
3. 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. Tratase 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 RELACIONAIS
DOS
BANCOS
DE
DADOS
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 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 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.
Tabela 4: Exemplo de atributos chave
Atributos matricula CPF (CI, UF) (CPF,Nome)
Superchave
Chave Candidata X
Chave Primria 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.
Tabela 5: Tabela EMPREGADOS, destacando a chave estrangeira (codDepto)
matricula 01 02 03 04 codDepto 01 02 03
nome Maria Matheus Gabriel Joana
cidade Vitria Vila Velha Serra Aracruz nomeDepto Informtica Geografia Portugus
codDepto 01 02 02 03
Tabela 6: Tabela DEPARTAMENTOS
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.
3.5. TRADUO RELACIONAL
DO
MODELO
ER
PARA
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). e
Para o exemplo das Tabelas 5 e 6 (EMPREGADOS 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 representao 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.
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
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 problemas 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
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: Socios (matricula, nome, sexo, dtCadastro) Dependentes (matricula, numDependente, sexo, dtNascimento) Matricula referencia Scios
Figura 28: Exemplo de entidade fraca relacionamento identificado
Nesse caso, apenas o nmero do dependente no suficiente para identificlo, 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.
Figura 29: Exemplo de relacionamento N:N
O esquema gerado ficaria da seguinte forma: 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.
Figura 30: Exemplo de generalizao / especializao
Para os casos em que h generalizao / especializao, h trs opes de projeto que podem ser adotadas: 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.
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
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 codigoDisciplinaPos referencia Disciplinas
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.
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:
Dicionrio de Dados:
EQUIPES = codEquipe + nomeEquipe PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso PAISES = codPais + sigla + nome CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito PARTICIPACOES = posicaoPilotoProva
Esquema Relacional equivalente :

PAISES (codPais, 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.
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 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) 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 01 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
Atividade 02 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.
4. 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 linguagem SQL. 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. SQL
A linguagem SQL foi uma das grandes razes para a consolidao dos bancos de dados relacionais no mercado. Desde sua definio como padro, 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.2.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.
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.
SELECT A1, A2, ..., An FROM r1, r2, ..., rn [WHERE P]
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 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. SELECT A1, A2, ..., An FROM r1, r2, ..., rn [WHERE P] [GROUP BY A1, A2, ..., An] [HAVING Condio] [ORDER BY A1, A2, ..., An] 6 1 2 3 4 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 palavrachave distinct depois da clusula select para elimin-las. 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.
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 ON Clientes.codigoCli=Emprestimos.codigoCli
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. 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.
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 isimo 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 Emprestimos.codigoAg = 51
AND
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.codigoAg = 51
Depositos.codigoCli
AND
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 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!
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) 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. 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.
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 Agencias.nomeAg = Princesa Isabel)
AND
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.
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 01 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.
Atividade 02 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
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)
codigo Ag 50 51 51 53
numeroCo nt 999 991 992 993
codigoC li 01 02 03 04
saldo 1000 3200 2300 1200
Agencias. codigoAg 50 51 51 53
Agencias .nomeAg Centro Princesa Isabel Princesa Isabel Avenida
Agencias .cidadeAg Vitria Vitria Vitria 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.
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 COUNT(DISTINCT Depositos.codigoCli) AS qtdClientes FROM Depositos, Agencias WHERE Depositos.codigoAg = Agencias.codigoAg GROUP BY Agencias.nomeAg saldoMedio,
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.
saldoMedio 1000 2750 1200
qtdClientes 1 2 1
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.
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: 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 03 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. 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) 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.
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 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)
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.
Atividade 04 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.
4.2.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. 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. 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. 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.
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.
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.
As restries Default e Check sero mais exploradas na disciplina Banco de Dados II.
Atividade 05 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, coeficienteRendimento) codigoCurso referencia Cursos Cursos (codigoC, nomeC) Disciplinas (codigoDisc, codigoCurso, nomeDisc) codigoCurso referencia Cursos Historico (codigoAl, codigoDisc, Periodo, nota) codigoAl referencia Alunos codigoDisc referencia Disciplinas Pre_Requisitos (codigoDiscPos, codigoDiscPre) codigoDiscPos referencia Disciplinas codigoDiscPre referencia Disciplinas
telefone,
b) Clientes (codCliente, nomeCliente, telefone, dtNascimento) Filmes (codFilme, nomeFilme, lancamento, dtAquisicao, codClasse) codClasse referencia Classes Fitas (codFilme, numeroFita, dublada) codFilme referencia Filmes Locacoes (codFilme, numeroFita, codCliente, dtLocacao, dtDevolucao, vlrLocacao, multa) (codFilme, numeroFita) referencia Fitas codCliente referencia Clientes Reservas (codfilme, codCliente, dtReserva, situacao) codFilme referencia Filmes codCliente referencia Clientes Classes (codClasse, nome, valor) Obs.: Considere a entrada 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.
REFERNCIAS
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 EntidadeRelacionamento 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

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Apostila Banco de Dados

Загружено:

Авторское право:

Доступные форматы

Banco de Dados I

PROF. CLAUDINETE VICENTE BORGES FERREIRA

IFes Instituto Federal do Esprito Santo

IFes Instituto Federal do Esprito Santo

Conceitos importantes. Fique atento!

Indicao de leituras complementares, 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.

IFes Instituto Federal do Esprito Santo

IFes Instituto Federal do Esprito Santo

1. CONCEITOS DE BANCOS DE DADOS

Figura 1: Ilustrao do conceito de um SGBD.

1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS

1.4. USURIOS DE BANCO DE DADOS

1.5. ABSTRAO DE DADOS

A figura 2 representa graficamente os nveis listados acima.

1.6. INDEPENDNCIA DE DADOS

1.7. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS

1.7.1. Sistemas Centralizados

1.7.2. Sistemas Cliente-Servidor

1.7.3. Sistemas Paralelos

1.7.4. Sistemas Distribudos

1.8. MODELOS DE BANCOS DE DADOS

1.8.1. Modelo em Rede

Figura 3: Exemplo de Banco de Dados Modelo Redes.

1.8.2. Modelo Hierrquico

Figura 4: Exemplo de Banco de Dados Modelo Hierrquico.

1.8.3. Modelo Relacional

Tabela 1: Tabela EMPREGADOS

Nome Luiza Matheus Gabriel Joana

Tabela 2: Tabela DEPARTAMENTOS

1.8.4. Modelo Objeto-Relacional

1.8.5. Modelo Orientado a Objeto

1.9. ESTRUTURA GERAL DO SISTEMA

1.9.1. Componentes de processamentos de consultas

1.9.2. Componentes para armazenamento de dados

1.9.3. Outras estruturas de dados

Figura 5: Estrutura Geral do Sistema

1.10. LINGUAGEM DE DEFINIO DE DADOS (DDL)

1.11. LINGUAGEM DE MANIPULAO DE DADOS (DML)

1.12. PROJETANDO BANCOS DE DADOS

nome Ana Maria Jos Pedro Joana Joo

CPF 123 234 245 125 435 467

nomeCargo Programador Topgrafo Engenheiro Pedreiro Motorista

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

1. Possibilidade de erros de acesso concorrente 2. Abstrao dados 3. Integridade de

5. Independncia lgica de dados 6. Independncia fsica de dados 7. Controle concorrncia de

2.3. MOTIVOS PARA CONSTRUO DE MODELOS

2.4. MODELO DE RELACIONAMENTOS E/R

Figura 6: Exemplo de representao de conjunto de entidades

Caractersticas dos conjuntos de entidades [FALBO, 2009]:

Neste caso, um fornecedor pode ter nenhum ou vrios telefones.

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

Figura 8: Notao alternativa para Diagrama Entidade-Relacionamento

Figura 9: Outra notao para Diagrama Entidade-Relacionamento

Figura 10: Exemplo de representao de relacionamento

Figura 11: Diagrama de ocorrncias

Figura 12: Entidades com dois tipos de relacionamento

Figura 13: Exemplo de autorrelacionamento

Figura 14: Ilustrao do uso de cardinalidade

Figura 15: Exemplo de relacionamento 1:1

Conjunto simblico da entidade FUNCIONRIOS

Conjunto simblico da entidade PROJETOS