Banco de Dados I
PROF. CLAUDINETE VICENTE BORGES FERREIRA
BANCO DE DADOS
VITÓRIA 2013
IFes – Instituto Federal do Espírito Santo
1
Banco de Dados I Governo Federal Ministro de Educação Fernando Haddad Ifes – Instituto Federal do Espírito Santo Reitor Dênio Rebello Arantes Pró-Reitora de Ensino Cristiane Tenan Schlittler dos Santos
IFes – Instituto Federal do Espírito Santo
2
Banco de Dados I
ICONOGRAFIA Veja, abaixo, alguns símbolos utilizados neste material para guiá-lo em seus estudos.
Fala do professor.
Conceitos importantes. Fique atento!
Atividades que devem ser elaboradas por você, após a leitura dos textos.
Indicação de leituras complementares, referentes ao conteúdo estudado.
Destaque de algo importante, referente ao conteúdo apresentado. Atenção!
Reflexão/questionamento sobre algo importante, referente ao conteúdo apresentado.
Espaço reservado para as anotações que você julgar necessárias.
IFes – Instituto Federal do Espírito Santo
3
Banco de Dados I
Sumário 1. CONCEITOS DE BANCOS DE DADOS ..................................................... ........................................................... ... 8 1.1. DEFINIÇÃO ........................................................................................................................................................... 8 1.2. OBJETIVOS ........................................................................................................................................................... 9 1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS CONVENCION AIS....................................................... .......................................... 9 1.4. USUÁRIOS DE BANCO DE DADOS ................................................................................................................. 11 1.5. ABSTRAÇÃO DE DADOS .................................................................................................................................. 11 1.6. INDEPENDÊNCIADE INDEPENDÊNCIA DE DADOS .......................................................................................................................... 12 1.7. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS ............................................................................... 13 1.7.1. Sistemas Centralizados ................................................................................................................................. 13 1.7.2. Sistemas Cliente-Servidor .............................................................................................. ............................... 13 1.7.3. Sistemas Paralelos ........................................................................................................................................ 14 1.7.4. Sistemas Distribuídos .................................................... ........................................................... ..................... 14
1.8. MODELOS DE BANCOS DE DADOS .................................................... ........................................................... . 14 1.8.1. Modelo em R ede .................................................. ........................................................... ............................... 15 1.8.2. Modelo Hierárquico ...................................................... ........................................................... ..................... 16 1.8.3. Modelo Relacional ........................................................................................................................................ 16 1.8.4. Modelo Objeto-Relacional ..................................................... ........................................................... ........... 17 1.8.5. Modelo Orientado a Objeto .......................................................................................................................... 17
1.9. ESTRUTURA GERAL DO SISTEMA ..................................................... ........................................................... . 18
1.9.1. Componentes de processamentos de consultas ............................................................................................ . 18 1.9.2. Componentes para administração do armazenamento de dados ....................................................... ........... 18 1.9.3. Outras estruturas de dados ............................................................... ........................................................... . 18
1.10. LINGUAGEM DE DEFINIÇÃO DE DADOS (DDL) ............................................................................. ........... 19 1.11. LINGUAGEM DE MANIPULAÇÃO DE DADOS (DML) ............................................................................... 20 1.12. PROJETANDO BANCOS DE DADOS ........................................................... .................................................. 20
2. MODELAGEM DE DADOS ..................................................................................................................................... 24 2.1. INTRODUÇÃO .................................................................................................................................................... 24 2.2. MODELOS ........................................................................................................................................................... 24 2.3. MOTIVOS PARA CONSTRUÇÃO DE MODELOS ........................................................................................... 25 2.4. MODELO DE ENTIDADES E RELACIONAMENTOS – E/R ........................................................................... 25 2.4.1. Entidades ................................................... ............................................................ ........................................ 25 2.4.2. Atributos .................................................... ............................................................ ........................................ 26 2.4.3. Relacionamentos ........................................................................................................................................... 30
2.5. DICIONÁRIO DE DADOS .................................................................................................................................. 37 2.6. EXEMPLO DE UM MODELO DE DADOS ........................................................................................................ 38 2.7. FERRAMENTAS CASE ...................................................................................................................................... 40 2.8. MODELO ER ESTENDIDO - EER ...................................................................................................................... 40
3. PROJETO LÓGICO DE BANCO DE DADOS ..................................................... .................................................. 42 3.1. DEFINIÇÃO ......................................................................................................................................................... 42 3.2. ESTRUTURA DOS BANCOS DE DADOS RELACIONAIS .............................................................................. 42 3.3. CHAVES ........................................................... ............................................................ ........................................ 43 3.4. PROPRIEDADES DO MODELO RELACIONAL ....................................................... ........................................ 45 3.5. TRADUÇÃO DO MODELO ER PARA O RELACIONAL ................................................................................. 46 3.5.1. Relacionamento 1:1....................................................................................................................................... 48 3.5.2. Relacionamento 1:N ...................................................... ........................................................... ..................... 48 3.5.3. Relacionamento 1:N - identificado .................................................... ........................................................... . 49 3.5.4. Relacionamento N:N ..................................................................................................................................... 49 3.5.5. Generalização e Especialização .................................................................................... ............................... 50 3.5.6. Autorrelacionamento 1 :N ........................................................ ........................................................... ........... 51 3.5.7. Autorrelacionamento N:N .............................................................................................. ............................... 52 3.5.8. Atributos Multivalorados .............................................................................................................................. 52
3.6. EXEMPLO DE PROJETO LÓGICO .................................................................................................................... 54
IFes – Instituto Federal do Espírito Santo
4
3.7. NORMALIZAÇÃO .............................................................................................................................................. 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. DEFINIÇÃO ......................................................................................................................................................... 58 4.2. SQL ....................................................................................................................................................................... 58 4.2.1. Linguagem de Manipulação de Dados – SQL DML ..................................................................................... 59 4.2.2. Linguagem de Definição d e dados – SQL DDL .................................................... ........................................ 75
REFERÊNCIAS.......................................................... ............................................................ ........................................ 82
Olá! Meu nome é Claudinete Borges, responsável pela disciplina Banco de Dados. Atuo como professora do Ifes há cinco anos e já lecionei em outras instituições de ensino superior, como Ufes, UVV e Unilinhares. Sou graduada em Ciência da Computação (1995) e mestre em Informática (2001), ambos pela UFES. Minhas áreas de interesse são Banco de Dados e Engenharia de Software. Nesta disciplina você conhecerá conceitos de modelagem e de bancos de dados. Os Bancos de Dados são responsáveis por manter a persistência dos sistemas de informações existentes no mercado, o que nos mostra a importância da disciplina em um curso de Análise de Sistemas. Este material tem como objetivo o de orientá-lo no estudo da disciplina Banco de Dados I, por meio de dicas e sugestões, com destaque aos pontos mais importantes. Aqui você encontrará conceitos com os quais trabalharemos ao longo do Curso, tendo sido elaborado tomando como referência livros clássicos das áreas correlatas, tais como Abraham Silberschatz, Peter Chen, Carlos Alberto Heuser, Elmasri Navathe e outros. Além destes autores, teve a contribuição valiosa da professora e amiga Eliana Caus que muito enriqueceu com suas notas de aula e sugestões. Apesar disso, este material impresso não dispensa a utilização dos livros referenciados na bibliografia, que trazem diversos exemplos adicionais e aprofundamento maior em vários aspectos. Os conceitos aqui apresentados devem ser bem assimilados, pois servirão de base para a disciplina Banco de Dados II, a ser ofertada no próximo semestre, e para sua vida profissional, caso você faça a opção por trabalhar na área de Análise de Sistemas. Foi preparado para você com muito carinho! Sucesso!!! Profa. Claudinete Vicente Borges Ferreira
1. CONCEITOS DE BANCOS DE DADOS
Olá, Neste capítulo você terá um primeiro contato com a disciplina Banco de Dados. A proposta é de apresentar conceitos importantes que servirão de base para o restante do curso. Bom estudo! Prof a. Claudinete Vicente Borges
1.1. DEFINIÇÃO Um banco de dados, também conhecido como base de dados, é um conjunto de arquivos estruturados de forma a facilitar o acesso a conjuntos de dados. Esses arquivos encontram-se, de alguma alguma forma, relacionados. Por exemplo, em um banco de dados de funcionários funcionários de uma empresa empresa podemos encontrar alguns arquivos, tais como: dados pessoais (nome, endereço, dados de documentos, lotação), dados funcionais (cargo, data de admissão, etc.) e dados para pagamento (salário base, faixas, etc.). Para obter informações sobre um dado funcionário, como nome, cargo e salário, será será necessário consultar os três arquivos, que devem estar relacionados. Segundo Heuser, um banco de dados é um conjunto de dados integrados, cujo objetivo é atender uma comunidade de usuários [HEUSER, 2004]. Com o crescimento do volume e dos tipos de dados nas organizações, é preciso utilizar softwares especiais para gerenciá-los, os chamados SGBDs (Sistemas Gerenciadores de Banco de Dados). Um SGBD é um software de caráter geral para a manipulação eficiente de grandes coleções de informações estruturadas e armazenadas de uma forma consistente e integrada. Tais sistemas incluem módulos para consulta, atualização e as interfaces entre o sistema e o usuário. Podemos afirmar, então, que um SGBD é constituído por um conjunto de dados associados a um conjunto de programas para acesso a estes dados [SILBERSCHATZ, 2006]. A figura 1 abaixo representa este conceito de forma gráfica.
Figura 1: Ilustração do conceito de um SGBD.
Um banco de dados é um conjunto de dados integrados, cujo objetivo é atender uma comunidade de usuários [ HEUSER, HEUSER, 2004]. Um SGBD é um software de caráter geral, usado para manipulação eficiente de grandes coleções de informações estruturadas e armazenadas de uma forma consistente e integrada [SILBERSCHATZ, 2006]. SGBD = Conjunto de programas + Conjunto de dados.
1.2. OBJETIVOS Dentre os principais objetivos do uso de Sistemas Gerenciadores de Bancos de Dados, destacam-se: •
Disponibilizar dados integrados para uma grande variedade de usuários e aplicações por meio de interfaces amigáveis;
•
garantir a privacidade dos dados por meio de medidas de segurança dentro do sistema (como visões, permissões, senhas de acesso);
•
permitir compartilhamento dos dados de forma organizada, mediando a comunicação entre aplicações e banco de dados e administrando acessos concorrentes; possibilitar independência dos dados, poupando ao usuário a necessidade de conhecer detalhes de implementação interna, organização de arquivos e estruturas de armazenamento.
•
1.3. SISTEMAS DE ARQUIVOS CONVENCIONAIS Os sistemas de processamento de arquivos caracterizam-se por uma série de registros guardados em diversos arquivos e uma série de programas aplicativos para extrair e adicionar registros nos arquivos apropriados. Podemos citar como desvantagens desse sistema (arquivos), em relação aos SGBD’s [SILBERSCHATZ,2006]: [SILBERSCHATZ,2006]:
Redundância e inconsistência de dados: considerando que diferentes programadores têm a possibilidade de criar arquivos com estruturas diferentes e aplicações para acessá-los, a possibilidade de se redundar dados por esses arquivos é muito grande. Além disso, em função dessa redundância, poderão ocorrer as inconsistências, inconsistências, considerando que os dados poderão ser atualizados em alguns arquivos e em outros não; Dificuldade no acesso aos dados : diferentemente dos SGBDs, os sistemas de arquivos não possuem um ambiente para recuperação dos dados armazenados. Com isso, para cada informação a ser gerada, é necessário construir uma aplicação; Isolamento de dados: considerando a diversidade de formatos existentes dos arquivos e, consequentemente, dos dados armazenados neles, torna-se uma tarefa difícil a construção de aplicações para a recuperação desses dados;
Problemas de atomicidade: o conceito de atomicidade está altamente relacionado ao de “átomo”, que se caracteriza como algo indivisível. Quando se fala em atomicidade em banco de dados, fala-se de uma unidade de trabalho que se deve executar totalmente ou que não se deve executar. Um exemplo clássico de atomicidade seria uma transferência de dinheiro entre duas contas, A e B. Se desejarmos transferir, por exemplo, R$ 100,00 da conta A para a Conta B, ou este valor será transferido integralmente ou não ocorrerá a transferência. Não é cabível que o dinheiro saia da conta A e não entre na conta B, por exemplo! Anomalias de acesso concorrente: considerando o acesso simultâneo aos arquivos, por diferentes aplicações ou por diferentes usuários de uma mesma aplicação, pode-se gerar inconsistências nesses arquivos devido a esses acessos. Tomemos como exemplo que uma conta conjunta A - com saldo igual a R$ 1000,00 - foi acessada de forma simultânea pelos correntistas Gabriel e Luiza. Gabriel sacou R$100,00 e Luiza, R$200,00. Pergunta-se: qual o saldo da conta após os saques? Se ambos leram o valor do saldo igual a R$1000,00, podemos ter como possíveis valores : R$900,00, R$800,00, levando-se em conta qual valor foi escrito por último. Nesse caso, nenhum dos dois valores são os corretos. O correto seria ter um saldo igual a R$700,00. Problemas de segurança:. nem todos os usuários possuem perfil para acessar todos os dados disponíveis em um arquivo. Tomemos como exemplo um arquivo de funcionários, que possui, entre outros dados, o valor do salário do funcionário. Embora tenhamos a curiosidade de saber o salário dos nossos colegas, principalmente do nosso chefe, não é politicamente correto que desrespeitemos seu direito à privacidade. No entanto, não é possivel definir, para um arquivo, que alguns campos poderão ser visíveis por um usuário e por outros não, o que gera vulnerabilidade nesses sistemas; Problemas de integridade: para explicar melhor esse item, tomemos como exemplo dois arquivos, um de sócios e outro de dependentes, de uma locadora de vídeo. Um dependente está relacionado a um sócio e, por consequência, a existência daquele depende da existência deste, ao qual estará subordinado. Desse modo, a exclusão de um sócio acarreta a exclusão de seus dependentes. Esse tipo de integridade denomina-se de “integridade referencial”, porém, existem outras mais simples que os arquivos não comportam. Considerando que as características descritas não são incluídas nos arquivos convencionais, elas devem ser incluídas nas aplicações. Imagine a complexidade das aplicações escritas para implementá-las! Os Sistemas de Bancos de Dados de médio e grande porte existentes no mercado implementam esses conceitos com muita robustez.
Você deve estar pensando: será que existem vantagens em usar os sistemas de arquivos? O custo mais baixo pode ser considerado uma vantagem.
1.4. USUÁRIOS DE BANCO DE DADOS Basicamente são quatro os tipos de usuários de sistemas de bancos de dados:
Usuários leigos: interagem com o banco de dados por meio das interfaces de aplicações escritas por programadores de aplicações; Usuários avançados : interagem com os bancos de dados por meio de interfaces disponíveis nesse ambiente. Escrevem consultas SQL e as submetem à execução sem a necessidade de escrever uma aplicação para esse fim; Programadores aplicações: usuários com formação em computação e que se propõem a construir aplicações, por meio de ferramentas (compiladores) destinadas para esse fim. Utilizando essas ferramentas, constroem interfaces para as aplicações, incluindo formulários e relatórios, acessando bancos de dados; Administrador de Banco de Dados (DBA): usuários mais especializados para um banco de dados. Cabe a eles a administração dessas bases, definição da melhor estrutura de armazenamento desses dados, definição de aspectos de segurança, programação de cópias de segurança (backup’s), dentre outros. O DBA pode ser comparado com um profissional da área médica. Se for responsável por sistemas que requerem alta disponibilidade, deve ficar de plantão 24 h por dia.
1.5. ABSTRAÇÃO DE DADOS Considerando que o nível de conhecimento dos usuários de bancos de dados é muito variável, oscilando entre aqueles que conhecem muito e outros que são leigos, os Sistemas de Bancos de Dados devem prover de mecanismos que administrem essa complexidade, simplificando as interações dos usuários com o sistema. Para isso, três níveis ní veis de abstração são considerados:
Nível de Visão: diz respeito à forma como os dados são vistos pelos usuários (individualmente). Diferentes usuários poderão ter diferentes visões de um mesmo banco de dados. Um determinado usuário, tanto pode ser um programador de aplicações quanto um usuário final. O DBA é um caso especialmente importante. Ao contrário dos usuários comuns, o DBA terá de se interessar pelos níveis lógico e físico. Lógico: o nível lógico descreve quais dados estão armazenados no banco de dados e qual a relação existente entre eles. Podemos Podemos dizer que a visão lógica é a visão dos dados “como realmente são” e não como os usuários são forçados a vê-los devido às restrições re strições de linguagem ou hardware. Físico: diz respeito à forma como os dados estão armazenados fisicamente. Preocupa-se em descrever as estruturas de dados complexas de baixo nível.
Os SGBD’s possibilitam aos usuários uma visão abstrata dos dados, ou seja, os usuários não precisam saber como os dados são armazenados e mantidos para usá-los. A figura 2 representa graficamente os níveis listados acima.
Visão 1
Visão 2
...
Visão n
Nível Lógico
Nível Físico Figura 2: Níveis de abstração de dados
Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptação.
1.6. INDEPENDÊNCIA DE DADOS A independência de dados pode ser definida como a imunidade das aplicações às alterações feitas, seja no nível físico ou no nível lógico de um banco de dados. O objetivo é alcançar o máximo de independência possível. Pode ser classificada em:
Independência Física de dados : habilidade de modificar o esquema físico, sem a necessidade de reescrever os programas aplicativos. As modificações no nível físico são ocasionalmente necessárias para melhorar o desempenho. Independência Lógica de dados : habilidade de modificar o esquema conceitual, sem a necessidade de reescrever os programas aplicativos. As modificações no nível conceitual são necessárias quando a estrutura lógica do banco de dados é alterada.
Normalmente, modificações no nível físico visam à melhoria de desempenho, como a criação de índices!
Qual abordagem é mais fácil de ser alcançada: independência física ou lógica de dados? Normalmente, a independência física de dados é mais fácil de ser alcançada do que a lógica. Ao criar um índice, como em uma tabela, as aplicações que referenciam essa tabela devem continuar funcionando, a despeito da alteração feita!
1.7. ARQUITETURA DE SISTEMAS DE BANCO DE DADOS A arquitetura de um sistema de banco de dados está altamente relacionada às características do sistema operacional sobre o qual o SGBD será executado [SILBERSCHATZ, 2006].
1.7.1. Sistemas Centralizados Os sistemas centralizados são os executados sobre um único sistema operacional, não interagindo com outros sistemas. Eles podem ter a envergadura de um sistema de banco de dados de um só usuário, 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 têm se tornado mais rápidos, mais potentes e baratos, há uma tendência de ampliar o seu uso nos sistemas centralizados, por isso terminais conectados a sistemas centralizados estão sendo substituídos por computadores pessoais. Como resultado, os sistemas centralizados atualmente agem como sistemas servidores que atendem a solicitações de sistemas-cliente. A computação cliente-servidor é um processamento cooperativo de informações de negócio por um conjunto de processadores, no qual múltiplos clientes iniciam requisições que são realizadas por um ou mais servidores centrais. O termo cliente-servidor é usado para descrever software que é executado em mais de um hardware de modo a realizar uma tarefa do negócio. A separação de hardware é a norma em aplicações cliente-servidor, embora algumas pessoas utilizem o termo para descrever diferentes componentes de software se comunicando uns com os outros, ainda que rodando em uma mesma máquina. A distância entre processadores remotos varia desde computadores localizados na mesma sala ou prédio, até aqueles localizados em diferentes prédios, cidades ou mesmo espalhados pelo planeta. Nessa arquitetura, as funcionalidades de um banco de dados podem ser superficialmente divididas em duas categorias: front-end e back-end . O back-end gerencia as estruturas de acesso, o desenvolvimento e a otimização de consultas, o controle de concorrência e a recuperação. O front-end consiste em ferramentas como formulários, gerador de relatórios e recursos de interface gráfica. A interface entre o front-end e o back-end é feita por meio de SQL ou de um programa de aplicação.
1.7.3. Sistemas Paralelos Sistemas paralelos imprimem velocidade ao processamento e à CPU, por meio do uso em paralelo de CPU’s e discos. No processamento paralelo muitas operações são realizadas ao mesmo tempo, ao contrário do processamento serial, no qual os passos do processamento são sucessivos. Um equipamento paralelo de granulaçãogrossa consiste em poucos e poderosos processadores (a maioria dos servidores atuais), enquanto um paralelismo intensivo ou de granulação fina usa milhares de pequenos processadores, com capacidade menor de processamento. Computadores paralelos com centenas de processadores já estão disponíveis comercialmente. As duas principais formas de avaliar o desempenho de um sistema de banco de dados são pelo throughput e pelo tempo de resposta. O primeiro diz respeito ao número de tarefas que podem ser executadas em um dado intervalo de tempo. Um sistema que processa um grande número de pequenas transações pode aumentar o throughput por meio do processamento de diversas transações em paralelo. Já o tempo de resposta diz respeito ao tempo total que o sistema pode levar para executar uma única tarefa. Um sistema que processa um grande volume de transações pode reduzir o tempo de resposta por meio de processamento em paralelo.
1.7.4. Sistemas Distribuídos Em um sistema distribuído, o banco de dados é armazenado, geograficamente, em diversos computadores denominados sites. Os computadores de um sistema de banco de dados distribuídos comunicam-se com outros por intermédio de vários meios de comunicação, como redes de alta velocidade ou linhas telefônicas. As principais diferenças entre os bancos de dados paralelos e os bancos de dados distribuídos são que, nos bancos de dados distribuídos, há a distribuição física geográfica, a administração ocorre de forma separada e há uma intercomunicação menor. Outra grande diferença é que nos sistemas distribuídos distinguimos transações locais (acessa um único computador, em que a transação foi iniciada) e globais (envolve mais de um computador, sendo necessária a participação de um coordenador). Há diversas razões para a utilização de sistemas de bancos de dados distribuídos, dentre as quais: compartilhamento dos dados (usuários de um local podem ter acesso a dados residentes em outros – por exemplo: bancos), autonomia (cada local administra seus próprios dados) e disponibilidade (se porventura um SGBD sair do ar, os demais podem continuar em operação). Há, no entanto, algumas desvantagens relacionadas ao seu uso, dentre as quais: custo de desenvolvimento de software, maior possibilidade de bugs e aumento do processamento e sobrecarga.
1.8. MODELOS DE BANCOS DE DADOS Os modelos de bancos de dados definem a forma como os dados encontramse organizados internamente. Em ordem cronológica, os modelos de banco de dados classificam-se em redes, hierárquicos, relacionais, objeto-
relacionais e orientados a objetos. A seguir, há uma breve descrição sobre cada um desses modelos.
1.8.1. Modelo em Rede Um banco de dados em rede consiste em uma coleção de registros que são concatenados uns aos outros por meio de ligações. Um registro é, em muitos aspectos, similar a uma entidade no modelo entidade-relacionamento. Uma ligação é uma associação entre dois registros. Assim, uma ligação pode ser vista como um relacionamento binário no modelo ER [SILBERSCHATZ, 2006]. Tanto o Modelo Rede como o Modelo Hierárquico podem ser considerados como estruturas de dados em nível lógico mais próximo do nível físico. Devido a essa proximidade ao nível físico, as estruturas de dados rede e hierárquica exibem as rotas lógicas de acesso de dados de forma acentuada, possibilitando a localização lógica de um determinado registro no banco de dados. O Modelo Relacional, quando comparado à Estrutura Rede e Hierárquica, é mais orientado para modelagem do que como modelo com rotas de acesso, embora possamos considerar as diversas redundâncias existentes em diversas tabelas como sendo uma forma de rota de acesso. O Modelo Rede utiliza como elemento básico de dados a ocorrência de registro. Um conjunto de ocorrência de registro de um mesmo tipo determina um tipo de registro. Um conjunto de tipos de registros relacionados entre si, por meio de referências especiais, forma uma estrutura de dados em rede. As referências especiais são conhecidas como ligações, que, por sua vez, podem ser implementadas sob a forma de ponteiros. As referências estão normalmente inseridas junto com as ocorrências de registro; assim, todo o acesso a um próximo registro utiliza o ponteiro inserido no registro corrente disponível. Considere um banco de dados com registros de DEPARTAMENTO e EMPREGADO, em que EMPREGADO possui as seguintes características: matrícula, nome e cidade; e DEPARTAMENTO: código e nome. A figura 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 ligações entre os registros de departamento e empregado. Luiza, por exemplo, está lotada no Departamento de Informática, enquanto o Departamento de Geografia, por exemplo, possui dois funcionários lotados, Matheus e Gabriel.
1.8.2. Modelo Hierárquico Um banco de dados hierárquico consiste em uma coleção de registros relacionados, uns aos outros, por meio de ligações, como no modelo em redes. A diferença entre eles se dá pelo fato de o banco de dados hierárquico organizar esses registros como coleções de árvores, em vez de grafos arbitrários. Um banco de dados hierárquico compõe-se de um conjunto ordenado de árvores, mais precisamente, de um conjunto ordenado de ocorrências múltiplas de um tipo único de árvore. O tipo árvore compõe-se de um único tipo de registro “raiz”, juntamente com um conjunto ordenado de zero ou mais (nível inferior) tipos de subárvores dependentes. Um tipo de subárvore, por sua vez, também se compõe de um único tipo de registro. A associação entre tipos de registros segue uma hierarquia estabelecida por diversos níveis. No primeiro nível, o superior, situa-se o tipo de registro “Raiz” . Subordinado a ele, em nível 2, uma série de outros tipos de registros em nível 2. A cada tipo de registro em nível 2 subordina-se um outro conjunto de tipos de registros. A própria estrutura hierárquica define as suas rotas de acesso, facilitando, portanto, a manutenção do banco de dados. É importante notar que um determinado tipo de registro B, num determinado nível K, possui ligação com um e somente um tipo de registro A, de nível K1 (superior). Nessas condições, A é denominado registro PAI de B, que, por sua vez, é registro FILHO de A . No entanto, um tipo de registro A pode estar ligado a diversos filhos no nível de B. Todas as ocorrências de um dado tipo de filho que compartilham uma ocorrência de pai comum são chamadas de gêmeas. Uma vantagem dos bancos de dados hierárquicos é o tempo de resposta em consultas. No entanto, a atualização pode ser bastante custosa. A figura 4 abaixo ilustra um exemplo do modelo Hierárquico.
Figura 4: Exemplo de Banco de Dados – Modelo Hierárquico.
1.8.3. Modelo Relacional O modelo relacional, diferentemente dos modelos redes e hierárquico, usa um conjunto de tabelas para representar tanto os dados quanto a relação entre eles. As ligações entre as tabelas é feita por meio dos valores dos atributos ou colunas, conforme descrito posteriormente. Cada tabela possui múltiplas colunas e pode possuir múltiplas linhas. As tabelas 1 e 2 abaixo mostram exemplos de Tabelas do modelo relacional.
Tabela 1: Tabela EMPREGADOS
Matricula 01 02 03 04
Nome Luiza Matheus Gabriel Joana
Cidade Vitória Vila Velha Serra Aracruz
CodDepto 01 02 02 03
Tabela 2: Tabela DEPARTAMENTOS
CodDepto 01 02 03
NomeDepto Informática Geografia Português
1.8.4. Modelo Objeto-Relacional O modelo objeto-relacional, também conhecido como relacional estendido, é um modelo intermediário entre o relacional e o orientado a objetos. Na verdade, os bancos de dados que se enquadram nesse modelo caracterizamse por usar a estrutura básica do modelo relacional, incorporando algumas características dos bancos de dados orientados a objetos. Estas características incluem: herança de tipos e tabelas e definição de novos tipos complexos. A SQL-99 inclui recursos para dar suporte a esse modelo de banco de dados.
1.8.5. Modelo Orientado a Objeto O modelo relacional, hierárquico e redes foram muito bem sucedidos no desenvolvimento da tecnologia de banco de dados necessária para a maioria das aplicações convencionais de bancos de dados comerciais, possuindo, entretanto, algumas limitações quando aplicações mais complexas precisam ser projetadas e implementadas, tais como sistemas de informações geográficas e multimídias. Essas aplicações têm requisitos e características que as diferenciam das tradicionais aplicações comerciais, tais como estruturas complexas para objetos, armazenamento de imagens e textos longos, dentre outras, além da necessidade de definir operações não convencionais [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 disponíveis em sistemas de banco de dados tradicionais. Nesses bancos, o projetista especifica a estrutura de objetos complexos bem como as operações que incidem sobre esses objetos. Outra razão para o uso de banco de dados orientados a objetos é a predominância das linguagens orientadas a objetos. No caso de uma aplicação orientada a objetos utilizar um banco de dados relacional para persistir os dados, é necessário fazer um mapeamento entre esses dois mundos, o que dá trabalho, considerando as limitações impostas pelo modelo relacional.
Embora existam muitos benefícios para a adoção do modelo orientado a objetos, esses bancos de dados não foram muito bem aceitos no mercado em função da simplicidade do modelo relacional. Com isso, há uma proposta de um modelo híbrido, denominado objeto-relacional ou relacional estendido, que se propõe a implementar alguns conceitos de orientação a objetos sobre a estrutura de um banco de dados relacional. Alguns SGBD´s proprietários e livres disponíveis no mercado enquadram-se nesse modelo, a exemplo do Oracle e do PostgreSQL.
1.9. ESTRUTURA GERAL DO SISTEMA O sistema de banco de dados é dividido em módulos específicos, de modo a atender a todas as suas funções, algumas delas fornecidas pelo sistema operacional. Esses módulos podem ser organizados em dois grandes grupos: o de processamentos de consultas e o de administração do armazenamento de dados. A Figura 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 instruções de baixo nível, inteligíveis ao componente de execução de consultas. Interpretador DDL: interpreta os comandos DDL e registra-os em um conjunto de tabelas que contêm metadados, ou seja, “dados sobre dados”. Componentes para o tratamento de consultas : executam instruções de baixo nível geradas pelo compilador DML.
1.9.2. Componentes para armazenamento de dados
administração
do
Gerenciamento de autorizações e integridade: testa o cumprimento das regras de integridade e a permissão ao usuário no acesso aos dados. Gerenciamento de transações: garante que o banco de dados permanecerá em estado consistente, a despeito de falhas no sistema, e que as transações concorrentes serão executadas sem conflitos em seus procedimentos. Gerenciador de arquivos: gerencia a alocação de espaço no armazenamento em disco e as estruturas de dados usadas para representar essas informações armazenadas em disco. Gerenciador de buffer: intermedia os dados entre o disco e a memória principal e decide quais dados colocar em cachê.
1.9.3. Outras estruturas de dados Diversas outras estruturas de dados são requeridas como parte da implementação do sistema físico, incluindo:
Arquivo de Dados: armazena o banco de dados.
Dicionário de Dados: armazena informações sobre os dados do banco de dados. Índices: permite o acesso mais rápido aos dados. Estatísticas: armazenam informações sobre o banco de dados e são usadas pelo seletor de estratégias.
Figura 5: Estrutura Geral do Sistema Fonte: Silberschatz, Korth e Sudarshan, 2006. Adaptação.
1.10. LINGUAGEM DE DEFINIÇÃO DE DADOS (DDL) Contém a especificação dos esquemas dos bancos de dados. O resultado da compilação de uma consulta de definição de dados (DDL) é armazenado em um conjunto de tabelas que constituem um arquivo especial chamado dicionário de dados . Um dicionário de dados é um arquivo de metadados. Principais comandos SQL-DDL: CREATE TABLE; ALTER TABLE; DROP TABLE; CREATE INDEX; ALTER INDEX; DROP INDEX;
1.11. LINGUAGEM DE MANIPULAÇÃO DE DADOS (DML) A linguagem de manipulação de dados (DML) é a linguagem que viabiliza o acesso aos dados ou a sua manipulação de forma compatível com o modelo de dados apropriado. São responsáveis pela:
•
recuperação da informação armazenada no banco de dados (SELECT); inserção de novos dados nos bancos de dados (INSERT);
•
eliminação de dados nos bancos de dados (DELETE);
•
modificação de dados armazenados no banco de dados (UPDATE).
•
Os comandos DDL são responsáveis por definir as estruturas dos dados, enquanto os comandos DML são responsáveis 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 manutenção do modelo. Podemos comparar a criação de um sistema de banco de dados com a construção de uma casa. Imagine que seja construída uma casa sem que antes tenha sido feito um projeto de arquitetura, incluindo plantas baixas, cortes e fachadas. Provavelmente, no futuro, ao submeter essa casa à manutenção, o proprietário teria o inconveniente de construir quartos do lado da cozinha ou mesmo ter que fazer “puxadinhas” para realizar a ampliação da mesma. O mesmo acontece com sistemas mal-projetados ou nãoprojetados. Eles tornam-se pouco flexíveis a manutenções futuras, quando for necessário agregar novas informações, ou mesmo quando submetidos a correções. O processo de projetar um banco de dados inclui três fases distintas e integradas. A primeira delas consiste na construção de um modelo conceitual. O Modelo Conceitual inclui características a serem incluídas no sistema, mas que independem da tecnologia a ser utilizada, tanto de banco de dados quanto de linguagem de programação. A segunda fase pressupõe a construção de um modelo lógico, tendo como base o Modelo Conceitual criado e inclui a definição de tabelas, campos, restrições de integridade, etc. 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 criação física do banco de dados, tendo a preocupação com estruturas de armazenamento e recuperação dos dados a serem armazenados. Nos capítulos que se seguem serão explorados a modelagem conceitual e o projeto lógico de banco de dados, considerando o modelo relacional.
Atividade 01 Faça os exercícios de fixação abaixo, referentes ao capitulo 1. 1) Defina SGBD´s. 2) Cite duas desvantagens do uso de sistemas de arquivos em relação a SGBD´s. 3) Defina uma vantagem de se usar sistemas de arquivos em relação a SGBD. 4) Cite as quatro arquiteturas de banco de dados existentes no mercado. Descreva, em poucas linhas, as características de cada uma delas. 5) Quais são os níveis de abstração proporcionados por um SGBD? Enquadre, para cada grupo de usuário abaixo listados, o nível em que o mesmo se encontra. a. Administrador de Banco de Dados b. Usuário de aplicações c. Programador e Analista de Aplicações 6) Liste, em ordem cronológica, os modelos de bancos de dados existentes no mercado. Qual modelo de banco de dados será utilizado em nossa disciplina?
Atividade 02 1) Dadas as relações abaixo, responda ao que se pede. Funcionários matricula 01 02 03 04 05 06 Cargos codigo 01 02 03 04 05
nome Ana Maria José Pedro Joana João
CPF 123 234 245 125 435 467
cargo 2 1 3 1 2 1
nomeCargo Programador Topógrafo Engenheiro Pedreiro Motorista
Liste os nomes dos funcionários para os seguintes cargos: Topógrafo; Engenheiro; Programador. Para quais cargos não há funcionários lotados? 2) Informe se cada uma das consultas abaixo será executada pelo Compilador DML ou pelo Interpretador DDL. a) create table... b) create view... c) insert into tabela... d) alter table... e) delete from tabela... f) update tabela set campo 1 = valor 1, campo2 = valor2...
Atividade 03 1) Numere a segunda coluna de acordo com a primeira. 1. Possibilidade de erros de acesso concorrente
( ) Refere-se à precisão ou validade dos dados.
2. Abstração de dados
( ) Tarefa de um SGBD.
3. Integridade
( ) Se alterar o esquema conceitual, não é necessário reescrever aplicações.
4. Instância
( ) Responsável pela modificação de dados armazenados no banco de dados.
5. Independência lógica de dados
( ) Se alterar o esquema físico, não é necessário reescrever aplicações.
6. Independência física de dados
( ) Contém a especificação dos esquemas de banco.
7. Controle concorrência
de
( ) Conjunto de informações contidas em determinado banco de dados, em um determinado momento.
8. Linguagem de Definição de Dados (DDL)
( ) Trata-se de um modelo de banco de dados.
9. Linguagem de Manipulação de Dados (DML)
( ) Os usuários não precisam saber como os dados são armazenados e mantidos.
10. ObjetoRelacional
( ) Desvantagem de sistemas de arquivos.
O objetivo deste capítulo foi de introduzir conceitos de bancos de dados. São conceitos importantes que servirão de base para entendimento dos conceitos explorados nos capítulos subseqüentes.
2. MODELAGEM DE DADOS
Olá! Neste capítulo você estudará conceitos de modelagem conceitual de dados. Um modelo conceitual objetiva modelar os requisitos de negócio segundo a visão do usuário, ou seja, independentemente de tecnologia. Trabalharemos, com especial destaque, com o Modelo de Entidade e Relacionamentos (ER). Bom estudo! Profª Claudinete Vicente Borges
2.1. INTRODUÇÃO O principal objetivo da modelagem conceitual de dados é construir modelos que representem os requerimentos das informações do negócio, segundo a perspectiva do usuário. Partindo desse princípio, ao construir modelos conceituais não há uma preocupação com a tecnologia a ser adotada para a sua implementação. Um modelo de dados consiste em uma coleção de ferramentas conceituais para descrição de dados, relacionamento entre os dados, semântica e restrições [SILBERSCHATZ,2006]. Neste capítulo, exploraremos o modelo de entidades e relacionamentos (ER) para construção de modelos de dados, considerando que se trata da técnica de modelagem mais difundida para representação de modelos conceituais.
2.2. MODELOS Um modelo é a representação abstrata e simplificada de um sistema real, com a qual se pode explicar ou testar o seu comportamento, em seu todo ou em parte. Observe que, nessa definição, não estamos condicionando que o modelo seja computadorizado. Qualquer ambiente do mundo real é passível de ser modelado, já que o mesmo busca expressar o objeto observado algumas vezes, mesmo antes da existência física, tangível de tal objeto. Seguem alguns exemplos de modelos: •
as plantas de apartamentos dos jornais;
•
o manequim da vitrine;
•
um aeromodelo sendo usado para testes de aerodinâmica;
•
o desenho em perspectiva de uma nova cozinha;
•
o molde de uma roupa obtido em uma revista.
O importante, contudo, é perceber que através de algum meio, seja uma maquete, desenho ou descrição, pode-se antecipar ou substituir a existência de uma realidade qualquer.
2.3. MOTIVOS PARA CONSTRUÇÃO DE MODELOS Segundo Cougo [COUGO,1997], os principais motivos para elaborarmos modelos são: •
focalizar características importantes de sistemas, deixando de lado as menos importantes;
•
discutir alterações e correções nos requisitos do usuário a baixo custo e com mínimo risco;
•
confirmar que o ambiente do usuário foi entendido;
•
representar o ambiente observado;
•
servir de instrumento de comunicação;
•
favorecer o processo de verificação e validação;
•
capturar aspectos de relacionamento entre os objetos observados;
•
servir de referencial para a geração de estruturas de dados.
2.4. MODELO DE RELACIONAMENTOS – E/R
ENTIDADES
E
O modelo ER é uma técnica de modelagem conceitual utilizada para representar os dados a serem armazenados em um sistema de informação, tendo sido desenvolvida originalmente para dar suporte ao projeto de bancos de dados [CHEN,1990]. Esse modelo foi criado em 1976 por Peter Chen e pode ser considerado como padrão para a modelagem conceitual. Basicamente, o modelo ER representa as entidades (coisas) e os relacionamentos (fatos) do mundo real, em que há o interesse de monitorar o comportamento no sistema de informação em tese.
2.4.1. Entidades Entidades são representações abstratas de “coisas”, “objetos” do mundo real modelado, para os quais temos interesse em manter informações no banco de dados. Podem representar tanto objetos concretos quanto abstratos. Quando se trata de conjuntos de objetos com características semelhantes, usualmente se denomina conjunto de entidades. Por exemplo: quando nos referimos ao conjunto de entidade “Departamentos”, estamos falando de um conjunto de departamentos; quando nos referimos ao departamento de informática, estamos falando da entidade, de uma instância do conjunto. Um conjunto de entidades será representado por meio de um retângulo contendo o nome do conjunto de entidades, em letra maiúscula e no plural, conforme mostra exemplo da Figura 6.
A frase “...para os quais temos interesse em manter informações no banco de dados...” do parágrafo acima, significa dizer que um conjunto de entidades que é relevante para um determinado contexto pode não ser para outro. O foco é incluir no modelo apenas aqueles conjuntos de entidades que são de interesse para o contexto em questão. Por exemplo: considerando um sistema para uma biblioteca, não há porque modelar as cadeiras como um conjunto de entidades. Agora, se tratarmos de um sistema para controle de patrimônios, as cadeiras são alvo de controle, sendo, então, modeladas como Conjunto de entidades. Ex: FUNCIONÁRIOS, CARGOS, PESSOAS ...
Figura 6: Exemplo de representação de conjunto de entidades
Características dos conjuntos de entidades [FALBO, 2009]: • são substantivos e perduram no tempo; • cada elemento de um conjunto de entidades só ocorre uma única vez e a ordenação do conjunto é irrelevante; • a princípio são representados em um conjunto de entidades todos os elementos do mundo real referidos pelo conjunto. Ex: FUNCIONÁRIOS = todos os funcionários de uma empresa; • para estabelecermos uma padronização, usaremos nomes de conjuntos de entidades sempre no plural e escritos em letras maiúsculas. No entanto, isso não representa uma regra.
2.4.2. Atributos A identificação de entidades está diretamente relacionada à necessidade de se armazenar dados (características ou propriedades) a seu respeito. Tais características ou propriedades são denominadas atributos. O papel do atributo é o de descrever características ou propriedades relevantes de um conjunto de Entidades. Os atributos podem ser representados no diagrama ou em um dicionário de dados. Adotaremos esta última abordagem com o intuito de mantermos um modelo mais legível. Deseja-se que o processo de identificação de atributos alcance um elenco de atributos que sejam completos, fatorados e independentes [SHLAER,1990]. •
Completo: “Deve abranger todas as informações pertinentes ao objeto que está sendo definido”. Os atributos devem contemplar todas as características que proporcionem uma perfeita identificação 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 comporão esta entidade. Ex.:
Entidade: PESSOAS Atributos: nome, rua, número, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil.
•
Fatorado: cada atributo deve ser responsável por um aspecto. Não se deve agrupar responsabilidades acessórias aos atributos. Cada parte, cada característica, deve significar um traço, uma particularidade da entidade e não estar agregando um conjunto de informações em um único elemento, em um único atributo. Ex.: Entidade: PESSOAS Atributos: nome, rua, número, bairro, cidade, estado, uf, data de nascimento, sexo, estado civil. Note que o endereço está fracionado nas suas partes constituintes e não agrupado num único elemento denominado endereço.
•
Independente: os valores que um atributo pode receber (domínio) devem ser independentes uns dos outros. Isso não significa que não possamos ter atributos distintos com o mesmo domínio. Cada atributo possui um conjunto dos possíveis valores que pode assumir e isso independe dos demais atributos da entidade. Ex.: Entidade: PESSOAS Atributos: data de nascimento Domínio: deve ter as características de data e ser menor que a data corrente
Considerações adicionais sobre os atributos: Ainda sobre a identificação dos atributos, é interessante que se distinga alguns elementos adicionais, conforme descritos abaixo. [POMPILHO, 2002]: •
Atributos Monovalorados ou Univalorado: é um atributo que recebe um único valor para cada entidade. São atributos que possuem cardinalidade máxima 1. Ex.: Entidade: FORNECEDORES Atributos: código, CNPJ, razão social, logradouro, número, complemento, cidade, estado, cep
•
Atributos Multivalorados: é um atributo que pode assumir vários valores para cada entidade, ao mesmo tempo. Ex.: Entidade: FORNECEDORES Atributos: telefone(0,n)
Neste caso, um fornecedor pode ter nenhum ou vários telefones. •
Atributos Obrigatórios: é um atributo que obriga a existência de valor para cada entidade. Ex.: Entidade: FORNECEDORES Atributos: código, cnpj, razão social, logradouro, número, cidade, estado, cep
•
Atributos Opcionais: é um atributo que NÃO obriga a existência de valor para cada entidade. Normalmente são representados no dicionário de dados entre parênteses. Ex.: Entidade: FORNECEDORES Atributos: (complemento)
•
Atributo Composto: são atributos formados por um ou mais atributos, ou seja, são atributos que abrigam uma estrutura de dado. O atributo nome em uma entidade pessoa também poderá ser visto como composto se for possível e necessário separá-los nas suas várias partes (primeiro-nome, nome-intermediário, último-nome). Quando não são compostos, os atributos são denominados simples. Ex.: Entidade: FORNECEDORES Atributos: endereço Os atributos compostos serão representados no dicionário de dados em maiúsculo e deverão ser fatorados, como mostra o exemplo abaixo no qual o ENDERECO é um atributo composto: FORNECEDORES = codigo + cnpj + razão social + ENDERECO + telefone(0,n) ENDERECO = logradouro + número + (complemento) + cidade + estado + CEP
•
Atributo Determinante ou Identificador: atributo que identifica, de modo único, uma Entidade. Serão sublinhados no diagrama como forma de distingui-lo dos demais. Há quem já chame o atributo identificador de Chave Candidata. Por exemplo: a matrícula de um funcionário pode ser um atributo identificador, considerando que cada funcionário terá uma matrícula única. O atributo nome, no entanto, não pode ser usado para identificar um funcionário, considerando que existem homônimos. Ex.: Entidade: FORNECEDORES Atributo: código
•
Domínio de um atributo: é o conjunto dos possíveis valores que um atributo pode assumir. No domínio 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 domínio uma “cadeia de caracteres”, já o atributo sexo poderá ter como domínio as opções “Masculino” ou “Feminino”.
Entidade: PESSOAS Atributo: Sexo do Empregado Domínio: Campo Alfanumérico, 1 caracter, só pode assumir os valores “F” e “M” As figuras 7, 8 e 9 abaixo mostram exemplos de diferentes formas de representação de Diagramas de Entidades e Relacionamentos. Ex.:
. Atributos também descrevem características de relacionamentos, que veremos na próxima seção.
Figura 7: Notação para Diagrama Entidade-Relacionamento proposto originalmente por Chen
Figura 8: Notação alternativa para Diagrama Entidade-Relacionamento
logradouro
Complemento (0,1) numero cidade estado cep
rua codigo CNPJ
Razao social endereco
nome
codigo
Preco unit
Telefone (0,n) FORNECEDORES
FORNECIMENTO
PRODUTOS
Figura 9: Outra notação para Diagrama Entidade-Relacionamento
2.4.3. Relacionamentos Na seção anterior descrevemos atributos de conjuntos de entidades, que são propriedades dos objetos a serem armazenados em um banco de dados. Além dos atributos, os conjuntos de entidades caracterizam-se por relacionar-se com outros conjuntos de entidades, inclusive com elas mesmas. A essas associações denominamos relacionamentos, ou seja, conjunto de associações entre entidades [HEUSER, 2004]. Neste texto adotaremos a seguinte notação: um relacionamento será representado por um losango, com um verbo para indicar a ação e uma seta para informar o sentido de leitura, conforme mostra a Figura 10 abaixo.
Figura 10: Exemplo de representação de relacionamento
A leitura feita para o relacionamento da Figura 10 é “funcionários são enquadrados em cargos”. Todo relacionamento possui uma leitura inversa; assim, uma outra leitura do relacionamento seria “cargos enquadram funcionários”. O relacionamento existente entre os conjuntos de entidades funcionários e cargos é um relacionamento binário, pois se trata de uma associação entre dois conjuntos de entidades. Quando o relacionamento envolve três conjuntos de entidades é conhecido como ternário. Outros exemplos de relacionamentos: •
Alunos cursam disciplinas / Disciplinas são cursadas por alunos;
•
Editoras publicam livros / Livros são publicados por editoras;
•
Autores escrevem livros / Livros são escritos por autores.
Para facilitar a visualização foi construído um diagrama de ocorrência referente ao modelo ER da Figura 10. Esse diagrama se propõe a mostrar as ocorrências de entidades do conjunto funcionários, representadas por : f1, f2, ..., fn; as ocorrências do conjunto cargos, representadas por : c1, c2, .., cn e os relacionamentos existentes entre as entidades do conjunto de funcionários e de cargos. O funcionário f1 está enquadrado no cargo c1 através do relacionamento r1. O cargo c1, por outro lado, possui os funcionários f1 e f3, nele enquadrados através dos relacionamentos r1 e r3. A figura 11 representa o diagrama de ocorrência supra citado.
Figura 11: Diagrama de ocorrências Fonte: Heuser, 2004. Adaptação.
Entre duas entidades, podem existir vários tipos de relacionamentos. A Figura 12 mostra os relacionamentos de alocação e de gerência entre os mesmos conjuntos de entidades: FUNCIONÁRIOS e PROJETOS.
Figura 12: Entidades com dois tipos de relacionamento
Além disso, uma entidade pode participar de relacionamentos com quaisquer outras entidades do modelo, inclusive com ela mesma, como mostra o relacionamento “chefiam”, na Figura13. Nesse caso, denomina-se que há um autorrelacionamento do conjunto de entidades FUNCIONÁRIOS.
Figura 13: Exemplo de autorrelacionamento
Cardinalidade de relacionamento A cardinalidade indica o número mínimo (cardinalidade mínima) e máximo (cardinalidade máxima) de ocorrências possíveis entre dois conjuntos de entidades em um relacionamento. No diagrama de ocorrência da Figura 11, observa-se que um cargo pode enquadrar vários funcionários, enquanto que um funcionário deve ser enquadrado em apenas um cargo. A Figura 14 mostra a representação de cardinalidade no modelo ER. A leitura é feita da seguinte forma: um funcionário é enquadrado em, no mínimo 1 e no máximo 1, cargo enquanto um cargo pode enquadrar no mínimo zero e no máximo n funcionários. N é um número arbitrário. Quando conhecemos esse número podemos representá-lo, em vez de o determinarmos pela letra N. Para efeito de projeto de banco de dados, o tratamento dado para esse número arbitrário é o mesmo, para qualquer valor maior que 1.
Figura 14: Ilustração do uso de cardinalidade
Observe que, embora pareça pouco natural, a cardinalidade vai anotada do outro lado do relacionamento a que se refere. No exemplo acima, um funcionário é enquadrado, no máximo, em um cargo e um cargo, por sua vez, pode enquadrar até n funcionários. O relacionamento “enquadram” é total em relação a FUNCIONÁRIOS e parcial em relação a CARGOS. Esse conceito é baseado na cardinalidade mínima do relacionamento. Ele é total em relação a FUNCIONÁRIOS, pois todo funcionário participa do relacionamento pelo menos uma vez; e parcial em relação a CARGOS, pois pode existir um cargo que não participe do relacionamento nenhuma vez.
Tipos de Relacionamentos O tipo de relacionamento é uma classificação baseada na cardinalidade máxima do relacionamento, podendo ser : 1:1, 1:N, N:1 e N:N. A seguir, serão explorados todos os tipos de relacionamentos sobre um relacionamento existente entre os conjuntos de entidades : FUNCIONÁRIOS E PROJETOS. Os tipos de relacionamentos podem ser enquadrados em 3 grandes grupos, e lê-se conforme descrição feita entre parênteses: 1:1 (Um-para-um), 1:N (Um-para-Muitos) e, N:N (Muitos-para-Muitos).
Relacionamento 1:1 A Figura 15 mostra um exemplo de relacionamento do tipo 1:1 no qual cada Funcionário ou Projeto podem aparecer no máximo em um único par do relacionamento Gerenciam (Funcionário, Departamento). Nesse caso, podemos dizer que um funcionário pode gerenciar no máximo um projeto, ou mesmo nenhum, enquanto um projeto só deve ter um gerente. A figura 16 tem uma representação simbólica deste tipo de relacionamento. •
Figura 15: Exemplo de relacionamento 1:1
Conjunto simbólico da entidade FUNCIONÁRIOS
Conjunto simbólico da entidade PROJETOS
Figura 16: Representação simbólica do relacionamento 1:1 (um-para-um)
Observe que todo projeto é gerenciado por algum funcionário porém, nem todo funcionário gerencia projetos. Esta informação é dada pela cardinalidade mínima do relacionamento.
Relacionamento 1:N A Figura 17 mostra um exemplo de relacionamento do tipo 1:N no qual cada Projeto pode aparecer no máximo em um único par do relacionamento Gerenciam, enquanto um Funcionário pode aparecer em um número arbitrário de vezes. Nesse caso, podemos dizer que um funcionário pode gerenciar vários projetos, enquanto um projeto só pode ter um gerente (tem que haver pelo menos 1!). A figura 18 tem uma representação simbólica deste tipo de relacionamento. •
Figura 17: Exemplo de relacionamento 1:N
Conjunto simbólico da entidade FUNCIONÁRIOS
Conjunto simbólico da entidade PROJETOS
Figura 18: Representação simbólica do relacionamento 1:N (um-para-muitos)
Relacionamento N:N A Figura 19 mostra um exemplo de relacionamento do tipo N:N no qual cada Funcionário ou Projeto podem aparecer em um número arbitrário de vezes do relacionamento Gerenciam. Nesse caso, podemos dizer que um funcionário pode gerenciar vários projetos, enquanto um projeto pode ter vários gerentes. A figura 20 tem uma representação simbólica deste tipo de relacionamento. •
Figura 19: Exemplo de relacionamento N:N
Conjunto simbólico da entidade FUNCIONÁRIOS
Conjunto simbólico da entidade PROJETOS
Figura 20: Representação simbólica do relacionamento N:N (muitos-paramuitos)
Um outro conceito relacionado aos relacionamentos N:N é o de “Entidade Associativa”, também referenciada por alguns autores, como “Agregação”. Uma Entidade Associativa é uma abstração por meio da qual relacionamentos entre duas entidades são tratados como entidades em um nível mais alto de abstração. Essa “nova entidade”, a associativa, pode, então, relacionar-se com outras entidades do modelo, como mostra a Figura 21. Um correntista é uma agregação envolvendo os conjuntos de entidades Clientes e Contas Correntes.
Figura 21: Exemplo de agregação N:N [Falbo, 2009]
Os exemplos acima mostram os diferentes tipos de relacionamentos aplicados a conjuntos de entidades diferentes, porém também se aplicam a autorrelacionamentos.
Relacionamentos N:N geram Entidades Associativas e, estas, por sua vez, possuem os mesmos privilégios 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 também podem ter atributos, porém apenas os atributos de relacionamentos N:N são 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 não é atributo do primeiro conjunto de entidades, no caso MATERIAIS. O Procedimento análogo deve ser feito, agora, para a outra entidade. Fixando-se um fornecedor e variando-se os materiais temos: A Eletrocity vende uma impressora por R$ 350,00 e um microcomputador por R$ 2.000,00. O fato de o valor do atributo ter variado para a mesma entidade indica que ele não é atributo de FORNECEDORES. Se não é atributo nem de MATERIAIS, nem de FORNECEDORES, então é um atributo do relacionamento entre os dois conjuntos de entidades. •
Figura 22: Exemplo de relacionamento N:N [Falbo, 2009]
Generalização / Especialização de conjuntos de entidades Por muitas vezes, incluímos nos modelos ER’s conjuntos de entidades com diversas características em comum, diferenciando apenas em algumas delas. Nesse caso, usando o conceito de generalização, pode-se criar um conjunto de entidades genérico, contendo as características em comum, e especializam-se as demais com características parcialmente distintas. Um exemplo clássico é o de pessoa física em jurídica. Observe que existem várias características em comum entre ambas as pessoas, a exemplo de: nome, endereço e telefone. Uma pessoa física, no entanto, além dessas características comuns, possui: sexo e CPF. Uma pessoa jurídica, além dessas características comuns, possui CNPJ e atividade principal. A Figura 23 mostra a representação desse conceito no modelo ER. •
Figura 23: Exemplo de generalização / especialização
As entidades PESSOAS FÍSICAS e PESSOAS JURÍDICAS herdam as características de clientes e incorporam outras adicionais, que são peculiares de cada um. Um cliente pode ser pessoa física, jurídica ou nenhum dos dois, mas toda pessoa física ou jurídica é cliente. Generalização: entidades de um nível mais baixo de abstração, com características comuns, são agrupadas dando origem a uma entidade de nível mais alto. Especialização: uma entidade de nível mais alto de abstração é desmembrada em várias entidades de nível mais baixo, com características parcialmente distintas.
Entidade Fraca Um outro conceito referenciado nos modelos ER’s é o de Entidade Fraca. Uma entidade fraca é uma entidade que não tem existência própria. Ela só aparece no modelo quando relacionada a outra entidade – intitulada como forte –, sendo seus atributos identificadores compostos por, pelo menos, dois campos, sendo um deles um atributo da entidade forte. A Figura 24 mostra um exemplo em que o conjunto de entidades DEPENDENTES é denominada “entidade fraca”. Para a identificação de um dependente é necessário que se tenha informação do sócio. Os relacionamentos com essa característica são denominados identificados.
Figura 24: Exemplo de entidade fraca
2.5. DICIONÁRIO DE DADOS O Dicionário de Dados é uma listagem organizada de todos os elementos de dados pertinentes ao sistema, com definições precisas para que os usuários e
desenvolvedores possam conhecer o significado de todos os itens de dados manipulados pelo sistema. Em se tratando de Modelos de Dados, essa listagem contém, em ordem alfabética, as entidades e os relacionamentos com atributos de um DER. Considerando que não há uma padronização sobre a definição de dicionário de dados, não será explorado neste material uma formulação na representação destes, mesmo por que as ferramentas CASE normalmente incluem relatórios para geração desses dicionários. Para complementar os conceitos discutidos até esta seção, indicamos o livro Projeto de Banco de Dados, de Carlos Alberto Heuser, capítulos 02 e 03.
2.6. EXEMPLO DE UM MODELO DE DADOS A seguir eis um estudo de caso referente a um campeonato de fórmula 1 e o modelo ER construído para representar o cenário supracitado. “Deseja-se desenvolver um sistema para controlar os resultados de um campeonato de corridas de Fórmula 1. O sistema deverá manter informações sobre as equipes que participam do campeonato. De cada equipe deseja-se saber: código e nome. Além disso, é necessário controlar os pilotos que pertencem a cada equipe. De cada piloto deseja-se saber: código, nome, data de nascimento, altura e peso. Ao longo do campeonato, um piloto pode pertencer a apenas uma equipe. Uma equipe, por outro lado, poderá ter vários pilotos (sendo este número máximo normalmente igual a 02 pilotos), podendo não ter nenhum, em um dado momento. É necessário ter um controle dos países dos atletas (pilotos), dos quais deseja-se armazenar as seguintes informações: uma sigla, o nome e o Hino Nacional. Um piloto sempre representa um país, enquanto que um país pode ter vários pilotos participando do campeonato ou até mesmo nenhum. Uma equipe também representa um país, enquanto que um país pode ter várias equipes participando do campeonato ou mesmo nenhuma. Para cada corrida realizada, é necessário saber a data em que ocorreu, o nome do circuito, a duração em minutos, a relação de pilotos que participaram da prova e a posição que cada um obteve na corrida. Para caracterizar uma corrida é necessário que haja pelo menos 01 piloto habilitado a participar.” O primeiro passo para construção de um modelo é identificar os elementos do contexto para os quais temos o interesse de manter informações a respeito, ou seja, identificar os possíveis conjuntos de entidades. Se fizermos uma leitura novamente do texto, iremos destacar os seguintes conjuntos de entidades: equipes, pilotos, países e corridas. Lembre-se de que só faz sentido caracterizar um elemento como um conjunto de entidades se ele possuir atributos próprios! Com relação ao conjunto de entidades “Corridas”, cabem algumas observações importantes. A primeira diz respeito à “relação de pilotos que participaram da prova”. Observe que esta relação de pilotos não foi incluída como um atributo de corrida (verifique no dicionário de dados) e sim como um relacionamento entre corridas. Se incluísse como atributo estaria sendo redundante, considerando que o modelo contempla um conjunto de entidades denominado “Pilotos”. A segunda observação refere-se a “posição que cada um obteve na corrida”, a qual, embora esteja no texto referenciado quando
trata-se da corrida em si, mas esta informação 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 Fórmula 1
Dicionário de Dados: EQUIPES = codEquipe + nomeEquipe PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso PAISES = codPais + sigla + nome CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito PARTICIPACOES = posicaoPilotoProva
O dicionário de dados acima representa em estilo sublinhado os atributos determinantes para cada conjunto de entidades.
Ao construirmos modelos de dados é comum termos dúvida sobre a representação de conjuntos de entidades, como no exemplo a seguir: se estamos construindo um modelo para uma locadora de vídeo, a Locadora deverá ser modelada como sendo um conjunto de entidades? Se estamos construindo um modelo para uma Escola, a Escola deverá ser modelada como sendo um conjunto de entidades? Em ambos os casos a resposta é Não! Se no primeiro caso tratar de uma rede de locadoras, aí sim devemos modelar a locadora como um conjunto de entidades, mas se for apenas uma, não faz sentido. Seria construir um conjunto de entidades para representar uma entidade apenas! O mesmo raciocínio vale para o segundo caso, o da Escola.
2.7. FERRAMENTAS CASE Você deve estar se perguntando como desenhar um diagrama ER. Será no Paint ou à mão? A resposta é simples: existem várias ferramentas computadorizadas destinadas a auxiliar na construção de modelos e projetos de bancos de dados, as quais são denominadas ferramentas CASE. Dentre outras, podemos citar Doctor CASE, ERWin e brModelo. Esta última é uma ferramenta desenvolvida sob a orientação do professor Carlos Heuser, professor de Banco de Dados da UFRGS, e encontra-se disponível para download na Internet. Embora seja uma ferramenta simples, permite trabalharmos com a construção de modelos conceituais e lógicos (tratados no próximo capítulo).
2.8. MODELO ER ESTENDIDO - EER O modelo ER possui um poder de expressão muito grande, principalmente quando se trata de modelagem de aplicações convencionais, porém alguns recursos são mais bem representados por extensões feitas ao modelo básico. Recursos estes necessários para modelagem de aplicações mais complexas, como Sistemas de Informações Geográficas e CAD. Vários modelos semânticos de dados têm sido propostos na literatura, sendo denominados de modelo ER estendidos ou EER. Não há uma notação padrão para representação desses modelos, como ocorre com a UML. Segundo Navathe Navathe [NAVATHE, 2005], o modelo EER engloba todos os conceitos do modelo ER básico, acrescidos dos conceitos de subclasse e superclasse, especialização e generalização, tipo união e herança de atributo/relacionamento.
Uma boa leitura para complementar os conceitos tratados nesta seção é o livro Sistemas de Banco de Dados, de Esmasri e Navathe, capítulo 4, que descreve uma forma de representação do modelo EER.
Este capítulo teve como objetivo o de apresentar conceitos relacionados com modelagem conceitual de dados. Ressalto que os modelos conceituais representam os requisitos de negócio independente de tecnologia. No capítulo seguinte, trabalharemos com projeto lógico de banco de dados. Para estes, algumas características tecnológicas serão consideradas.
3. PROJETO LÓGICO DE BANCO DE DADOS
Olá! Neste capítulo você estudará conceitos de projeto lógico de banco de dados. Um modelo lógico faz uma adequação do modelo conceitual, incluindo restrições tecnológicas, impostas pelo modelo de banco de dados a ser usado. Tratase de um modelo com maior nível de detalhe do que o conceitual. Bom estudo! Profª Claudinete Vicente Borges
3.1. DEFINIÇÃO Quando construímos um modelo conceitual, focamos apenas no que o usuário deseja, abstraindo da plataforma em que este será implementado. No que se refere aos projetos de Banco de Dados, a preocupação é centrada em estabelecer de que forma os dados serão armazenados no sistema. Em função do modelo de banco de dados a ser usado, diferentes soluções de projeto devem ser adotadas, ou seja, se o software for implementado em um banco de dados hierárquico, por exemplo, um modelo hierárquico deve ser produzido, adequando-se a modelagem conceitual de dados (ER ou diagrama de classes) a essa plataforma de implementação. Considerando que o modelo de banco de dados que predomina no mercado, atualmente, é o relacional, este capítulo se propõe a discutir conceitos de projetos relacionados a esse modelo de bancos de dados.
3.2. ESTRUTURA RELACIONAIS
DOS
BANCOS
DE
DADOS
O modelo relacional consolidou-se no mercado por ser flexível, de simples compreensão. Está fortemente baseado na teoria matemática sobre relações, daí o nome relacional. Um banco de dados relacional consiste em uma coleção de tabelas, cada uma das quais com um nome único. Uma linha em uma tabela representa um relacionamento entre um conjunto de valores. Uma vez que essa tabela é uma coleção de tais relacionamentos, há uma estreita correspondência entre o conceito de tabela e o conceito matemático de relação, daí a origem do nome desse modelo de dados. Considere a tabela EMPREGADOS – Tabela 3. Ela possui três colunas: matrícula, nome e cidade. Seguindo a terminologia do modelo relacional, tratamos os nomes dessas colunas como atributos. Para cada atributo há um conjunto de valores permitidos, chamado domínio da coluna em questão. Para o atributo Matricula, por exemplo, o domínio é o conjunto de todas as matrículas de funcionários. Suponha que D1 denote esse conjunto, D2 o
conjunto de todos os nomes de pessoas e D3 o conjunto de todas as cidades. Qualquer linha da tabela EMPREGADOS consiste necessariamente de uma tupla (v1, v2, v3), em que v1 é a matricula, (isto é, v1 está no domínio D1), v2 é um nome do funcionário e assim por diante. Em geral, um empregado é um conjunto de D1 x D2 x D3. Tabela 3: Tabela EMPREGADOS
matricula 01 02 03 04
nome Maria Matheus Gabriel Joana
cidade Vitória Vila Velha Serra Aracruz
Matematicamente, define-se uma relação como um subconjunto de um produto cartesiano de uma lista de domínios. Essa definição corresponde quase exatamente à definição de uma tabela. A única diferença é que designamos nomes aos atributos, ao passo que matematicamente se usam apenas "nomes" numéricos. Como as tabelas em essência são relações, podemos usar os termos matemáticos relação e tupla no lugar de tabela e linhas, respectivamente. É possível que tenhamos, em uma mesma tabela, atributos diferentes criados sob o mesmo domínio, a exemplo de Endereço de correspondência e Endereço comercial (se existissem nessa tabela EMPREGADOS). Um valor de domínio que pertence a qualquer domínio possível é o valor nulo, que indica que um valor é desconhecido ou não existe. Por exemplo, suponhamos que incluamos o atributo numeroTelefone na tabela Empregado, pode ser que um Empregado não possua telefone ou que o seu número seja desconhecido.
3.3. CHAVES É importante especificar como as entidades dentro de um dado conjunto de entidades podem ser identificadas. Conceitualmente, entidades e relacionamentos individuais são distintos, entretanto, na perspectiva do banco de dados, a diferença entre ambos deve ser estabelecida em termos de seus atributos. O conceito de chaves nos permite fazer tais distinções. Uma superchave é um conjunto de um ou mais atributos que, tomados coletivamente, permitem identificar, de maneira unívoca, uma entidade em um conjunto de entidades. Considere a inclusão de uma nova coluna na tabela EMPREGADOS, o (CPF) do empregado. Os atributos (matricula, nome) e (nome, CPF) são suficientes para distinguir cada elemento do conjunto, podendo ser considerados como superchaves. Da mesma forma, podemos considerar o atributo (CPF) como superchave de empregado. O atributo (nome) não pode ser considerado como superchave, porque algumas pessoas podem ter o mesmo nome. Nosso interesse maior é por superchaves para as quais nenhum subconjunto possa ser uma superchave. Essas chaves são chamadas de chaves candidatas. Das superchaves mencionadas
anteriormente, somente (nome, CPF) não poderia ser considerada uma chave candidata, visto que o CPF, sozinho, já o é. Podemos usar o termo chave primária para caracterizar a chave candidata, que é escolhida pelo projetista do banco de dados como de significado principal para a identificação de entidades dentro de um conjunto de entidades. Quaisquer duas entidades individuais em um conjunto de entidades não podem ter, simultaneamente, os mesmos valores em seus atributos-chave. Em SGBD’s, apenas os conceitos de chaves primárias e chaves candidatas são de fato implementados! A tabela 4 mostra uma listra de atributos de uma relação Alunos e um indicativo da possibilidade destes serem considerados atributos-chaves. Cabe ressaltar que os atributos implementados como “Chave Candidata” são atributos possíveis de serem implementados como “Chave Primária”, porém, pode-se criar um atributo extra, como por exemplo um número seqüencial para ser a chave primária da tabela. Tabela 4: Exemplo de atributos chave
Atributos matricula CPF (CI, UF) (CPF,Nome)
Superchave
Chave Candidata
Chave Primária
√ √ √ √
√ √ √
√ √ √
X
X
Em uma mesma tabela pode haver múltiplas chaves candidatas, a exemplo de (matrícula) e (CPF) de EMPREGADOS. No que se refere à chave primária, apenas uma é possível.
Uma chave candidata pode assumir um valor nulo (apenas um, pois do contrário haveria repetição de valores). Uma chave primária não pode assumir valor nulo.
Alguns autores defendem que uma chave primária seja escolhida entre as chaves candidatas de uma tabela. Eventualmente, pode-se adotar uma solução de projeto em que a chave primária não seja escolhida entre as chaves candidatas e sim um atributo que não diz respeito ao negócio em si. Particularmente, prefiro adotar essa solução. É importante lembrar a todos que o negócio muda e com isso os valores dos atributos também. Uma alteração feita em valores de chaves primárias implica propagação para inúmeras tabelas 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
combinação de atributos) de uma tabela que constitui a chave primária de uma tabela, daí o nome de estrangeira. É a estratégia usada para implementar os relacionamentos dos modelos conceituais. Essa tabela referenciada pode ser a própria tabela, para os casos de autorrelacionamento, ou outras quaisquer do modelo. Outras denominações também são usadas para essas chaves, a exemplo de chaves externas e chaves transpostas. A Tabela 5 mostra um exemplo de chave estrangeira, o codDepto. Os valores possíveis para essa coluna devem constar na Tabela referenciada por esse atributo, no caso, a de DEPARTAMENTOS. Além desses valores, dependendo do modelo de dados, nulo pode ser um valor possível. Tabela 5: Tabela EMPREGADOS, destacando a chave estrangeira (codDepto)
matricula 01 02 03 04
nome Maria Matheus Gabriel Joana
cidade Vitória Vila Velha Serra Aracruz
codDepto 01 02 02 03
Tabela 6: Tabela DEPARTAMENTOS
codDepto 01 02 03
nomeDepto Informática Geografia Português
3.4. PROPRIEDADES DO MODELO RELACIONAL Falbo [FALBO,2009] relaciona as seguintes propriedades do modelo relacional: •
nenhum campo componente de uma chave primária pode ser nulo;
•
cada célula de uma relação pode ser vazia (exceto de uma chave primária) ou, ao contrário, conter no máximo um único valor;
•
a ordem das linhas é irrelevante;
•
não há duas linhas iguais;
•
cada coluna tem um nome e colunas distintas devem ter nomes distintos;
•
usando-se os nomes para se fazer referência às colunas, a ordem delas torna-se irrelevante;
•
cada relação recebe um nome próprio distinto do nome de qualquer outra relação da base de dados;
•
os valores de uma coluna são retirados todos de um mesmo conjunto, denominado domínio da coluna;
•
duas ou mais colunas distintas podem ser definidas sobre um mesmo domínio;
•
um campo que seja uma chave estrangeira ou um item transposto só pode assumir valor nulo ou um valor para o qual exista um registro na tabela em que ela é chave primária.
3.5. TRADUÇÃO DO MODELO ER PARA O RELACIONAL O objetivo desta seção é apresentar como se procede na elaboração do projeto lógico de bancos de dados relacionais a partir de modelos conceituais – no caso o ER. O modelo lógico é um modelo menos abstrato que o conceitual e provê um nível maior de detalhes. Para os diferentes modelos de bancos de dados (redes, hierárquicos, relacionais...) diferentes soluções de projetos devem ser adotadas. Assim, este material terá como foco apenas o projeto de banco de dados relacional. A tradução do modelo ER para o relacional seguirá os seguintes passos: • mapeamento das entidades e atributos; •
mapeamento dos relacionamentos, considerando cada tipo {1:1, 1:N, N:N};
•
mapeamento de generalizações e especializações;
•
mapeamento de atributos multivalorados.
Diferentes autores usam diferentes representações para a especificação dos modelos lógicos de bancos de dados relacionais, sendo alguns representados de forma gráfica e outros textuais. A abordagem usada neste material será a de Carlos Heuser [HEUSER,2004], que usa uma notação resumida para definição do esquema, denominado Esquema Relacional, contendo as seguintes informações : •
tabelas que formam o banco de dados;
•
colunas que compõem cada tabela;
•
restrições de integridade (no caso, apenas as restrições referentes às chaves primárias e estrangeiras são representadas).
Para o exemplo das Tabelas 5 e 6 (EMPREGADOS DEPARTAMENTOS), teremos a seguinte representação:
e
Empregados (matricula, nome, cidade, codDepto) codDepto referencia Departamentos Departamentos (codDepto , nomeDepto) Os atributos sublinhados representam as chaves primárias das tabelas Empregados e Departamentos, respectivamente. CodDepto é uma chave estrangeira e que referencia a chave primária da tabela Departamentos. Para os casos das chaves estrangeiras compostas, a representação fica da seguinte forma: (coluna1, coluna2, ... colunaN) referencia
. A fim de facilitar o entendimento, serão usados os mesmos exemplos de modelos descritos no capítulo 2 para exemplificar os diferentes tipos de relacionamentos. Consideremos também os atributos abaixo listados para os conjuntos de entidades Funcionários e Projetos, pois a opção foi de não representá-los no modelo ER. Funcionarios = matrícula + nome + cidade + data de admissão Projetos = código + nome + data de início
Seguindo os passos para elaboração do modelo conceitual temos, como passo 1, a definição das Tabelas que formam o banco de dados. Via de regra, todo conjunto de entidades gerará uma tabela no banco de dados relacional. As exceções serão tratadas, quando ocorrerem. Com relação à nomenclatura usada na tabela, ela não deve, necessariamente, ser a mesma do conjunto de entidades, considerando que não pode haver espaços em branco e que devemos evitar nomes extensos para facilitar o trabalho dos programadores. No que se refere aos atributos dos conjuntos de entidades, eles devem ser mapeados em colunas das respectivas tabelas, porém, há algumas diretrizes para definição dessas colunas, conforme especificações a seguir: •
evite usar nomes extensos. Ao fazer referência ao nome de uma coluna, normalmente escreve-se nomedaTabela.nomedaColuna o que estende ainda mais o nome do atributo;
•
considerando que a referência às colunas ocorre do modo acima descrito, não se faz necessário incluir o nome da tabela nos nomes das colunas dessas tabelas. A exemplo da coluna (nome), da tabela PROJETOS, algumas pessoas escrevem Nome_Projeto;
•
crie padrões de projeto para dar nomes às colunas, a exemplo de dtAdmissao e dtInicio. Evite usar prefixos diferentes para colunas com mesmo tipo de informação, como: Data_Admissão e dtInicio;
•
ao definir a chave primária, escolha a coluna ou combinação destas colunas com o menor tipo de dados possível. Sobre os campos chaves, seja chave primária, candidata, seja estrangeira, são criados índices, e esses índices ocupam muito espaço em disco;
•
embora devamos evitar redundâncias nos modelos conceituais, a redundância, muitas vezes, é útil em um banco de dados por questões de performance. Por exemplo: o valor de um pedido pode ser obtido por meio dos valores dos seus itens, porém, se guardarmos o valor total do pedido como uma coluna na tabela de pedidos, evitamos alguns acessos a disco, melhorando, assim, a performance das aplicações. Notação resumida para especificação de banco de dados relacional: • tabelas que formam o banco de dados; • colunas que compõem cada tabela; • restrições de integridade (no caso, apenas as restrições referentes às chaves primárias e estrangeiras são representadas). Os relacionamentos do modelo conceitual ER são mapeados em chaves estrangeiras em um banco de dados relacional. Via de regra, para cada relacionamento uma chave estrangeira deve ser criada.
Eu, particularmente, não uso acentuações e cedilhas em nomes de tabelas, colunas ou quaisquer outros objetos de um banco de dados. Com isso, evito transtornos com teclados desconfigurados.
3.5.1. Relacionamento 1:1 Considerando o relacionamento Gerenciam, da Figura 26, a melhor solução de projeto a se considerar é: incluir a chave estrangeira na relação PROJETOS, em vez de colocá-la em empregados, derivando o seguinte esquema : Funcionarios (matricula, nome, cidade, dtAdmissao) Projetos (codigo, nome, dtInicio, matriculaGerente) matriculaGerente referencia Funcionários
Figura 26: Exemplo de relacionamento 1:1
Essa solução foi adotada, considerando-se que todo projeto tem um gerente; porém, nem todo funcionário gerencia um projeto. Ainda assim, se a chave estrangeira fosse criada em Funcionários, não teríamos problemas na implementação dessa solução, embora essa não seja a melhor abordagem. Se o relacionamento Gerenciam fosse total em relação a Funcionários e a Projetos, ou seja, se a cardinalidade mínima fosse 1 (um) para ambos, poderíamos optar por criar uma única tabela contendo todos os atributos.
3.5.2. Relacionamento 1:N Para os relacionamentos 1:N deve-se criar a chave estrangeira na tabela que representa o conjunto de entidades cuja cardinalidade máxima é 1. No caso da Figura 27, a chave estrangeira deve ser colocada em Projetos, pois cada projeto participa do relacionamento Gerenciam no máximo 1 (uma) vez. O esquema gerado ficaria da seguinte forma: Funcionarios (matricula, nome, cidade, dtAdmissao) Projetos (codigo, nome, dtInicio, matriculaGerente) matriculaGerente referencia Funcionários
Figura 27: Exemplo de relacionamento 1:N
A criação da chave estrangeira na tabela Funcionários geraria um erro de projeto, considerando que para os funcionários que gerenciam mais de um projeto todas as informações de funcionários apareceriam de forma duplicada.
3.5.3. Relacionamento 1:N - identificado Para os relacionamentos 1:N, denominados identificados, como mostra o exemplo da Figura 28, a identificação de um elemento da entidade, dita fraca (DEPENDENTES), requer a identificação da entidade, dita forte (SOCIOS). Resumindo, temos nesses casos a chave estrangeira fazendo parte da chave primária 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 Sócios
Figura 28: Exemplo de entidade fraca – relacionamento identificado
Nesse caso, apenas o número do dependente não é suficiente para identificálo, considerando que diferentes sócios possuem dependentes de número 01, 02, 03, etc.
3.5.4. Relacionamento N:N Os bancos de dados relacionais não implementam ligações diretas para os relacionamentos N:N, como para os demais tipos de relacionamentos: 1:1 e 1:N. Nesse caso, o relacionamento também deve ser mapeado em uma tabela do banco de dados. A chave primária dessa nova tabela deve ser composta, no mínimo, pela chave primária das tabelas relacionadas, ou seja, tem-se pelo menos 02 chaves estrangeiras, e elas fazem parte da chave primária da tabela criada. Às vezes é necessário incluir mais um atributo para compor a chave primária da tabela, pois apenas as chaves estrangeiras não são suficientes para identificá-los.
Considere o exemplo da Figura 29, agora com relacionamento N:N. Considere também que o relacionamento Gerenciam possui os seguintes atributos : Data de Início de Atividade e Percentual de dedicação.
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 Funcionários codigo referencia Projetos Os relacionamentos N:N normalmente visam a geração de histórico, assim sendo, é comum encontrarmos um campo “data” como parte da chave primária da tabela derivada da entidade associativa.
3.5.5. Generalização e Especialização Considere a Figura 30 para as discussões que se seguem. Considere também que um cliente possui as seguintes características (atributos ): Código e Nome. Um cliente pessoa física possui, adicionalmente, um CPF e Carteira de Identidade; e um cliente pessoa jurídica possui, adicionalmente, um CNPJ e uma atividade principal.
Figura 30: Exemplo de generalização / especialização
Para os casos em que há generalização / especialização, há três opções de projeto que podem ser adotadas:
Opção 1: criar uma tabela única, fundindo os três conjuntos de entidades. Nesse caso, os campos oriundos das tabelas especializadas devem ter a
possibilidade de assumirem valores nulos. O esquema gerado ficaria da seguinte forma: Clientes (codigo, nome, CPF, carteiraIdentidade, CNPJ, atividadePrincipal)
Opção 2: criar uma tabela para cada entidade da especialização, como Pessoas Físicas e Pessoas Jurídicas. Nesse caso, os atributos do conjunto de entidades genérico – Clientes – devem ser incluídos em cada uma das tabelas criadas. O esquema gerado ficaria da seguinte forma: Clientes_PFisica (codigo, nome, CPF, carteiraIdentidade) Clientes_PJuridica (codigo, nome, CNPJ, atividadePrincipal) Opção 3: criar uma tabela para cada conjunto de entidade da hierarquia. Nesse caso, a chave primária das tabelas filhas (pessoas físicas e jurídicas) devem ser chaves estrangeiras e as mesmas do conjunto mais genérico, no caso, de Clientes. O esquema gerado ficaria da seguinte forma: Clientes (codigo, nome) Clientes_PFisica (codigo, CPF, carteiraIdentidade) codigo referencia Clientes Clientes_PJuridica (codigo, CNPJ, atividadePrincipal) codigo referencia Clientes Cada uma das abordagens acima tem vantagens e desvantagens. Ou seja, a primeira opção tem como vantagem a redução do número de junções entre tabelas e como desvantagem possuir colunas que só terão valores associados quando tratarem de elementos correspondentes à especialização. Por exemplo, em se tratando de pessoa física, não haverá preenchimento de CNPJ e Atividade. Para a opção 02 temos como desvantagem a repetição de atributos comuns aos dois conjuntos de entidades especializados; já para a terceira opção há uma organização maior da estrutura hierárquica, embora possamos ter uma menor performance, se considerarmos as opções anteriores. Como costumo dizer, não dá para se ter tudo! Eu, particularmente costumo adotar a terceira solução: criar uma tabela para cada 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 não é possível ter colunas diferentes e com o mesmo nome em uma tabela. A Figura 31
representa um modelo ER com esse tipo de relacionamento. O esquema gerado ficaria da seguinte forma: Funcionarios (matricula, nome, cidade, dtAdmissao, matriculaChefe) matriculaChefe referencia Funcionários
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, porém, vindas da mesma tabela. Essas chaves estrangeiras compõem a chave primária da tabela criada. Por isso, o nome de pelo menos um campo deve ser alterado para evitar que haja dois atributos com o mesmo nome em uma mesma tabela. A Figura 32 representa um modelo ER com esse tipo de relacionamento. O esquema gerado ficaria da seguinte forma: Disciplinas (codigo, nome, ementa) Pre_Requisitos (codigoDisciplinaPos, codigoDisciplinaPre) codigoDisciplinaPre referencia Disciplinas codigoDisciplinaPos referencia Disciplinas
Figura 32: Exemplo de Autorrelacionamento N:N
3.5.8. Atributos Multivalorados Os atributos multivalorados de conjunto de entidades também devem ser tratados, considerando-se que o modelo relacional não comporta múltiplos valores em uma célula de uma tabela. Para ilustrar, consideremos que telefone (0,n) seja um atributo multivalorado de Funcionários. Para esses
atributos, uma solução de projeto adotada é a criação de uma tabela para cada um deles. Para a tabela criada, deve ser aplicada a mesma solução dos relacionamentos 1:N – identificados. Para o exemplo em tese, o esquema gerado ficaria da seguinte forma: Funcionarios (matricula, nome, cidade, dtAdmissao) Telefones (matricula, numeroTelefone) matricula referencia Funcionarios Nesse caso, não há limites de telefones para um funcionário, tanto pode não haver nenhum, como um ou vários. A solução acima adotada para representação de atributos multivalorados, embora seja elegante, não é amplamente aceita por projetistas de banco de dados. Considerando que dificilmente se registra um número grande de telefones para cada pessoa, é costume se criar colunas adicionais na tabela de funcionários para representar esses valores (exemplo : telefone01 e telefone02). Essa solução, quando adotada, visa à melhoria de performance, pois evita junções entre tabelas nas consultas que devem retornar os telefones de funcionários.
3.6. EXEMPLO DE PROJETO LÓGICO Tomando como base o estudo de caso usado no Capítulo 2, referente ao campeonato de Fórmula 1, vamos agora gerar o projeto lógico para o mesmo cenário, através da representação de Esquema Relacional. Observações importantes: Observe que cada conjunto de entidades foi mapeado em uma tabela no Esquema Relacional e que para chaves primárias, aproveitamos os atributos determinantes de cada conjunto de entidades. Para definição das chaves estrangeiras, é necessário avaliar cada tipo de relacionamento para cada conjunto de entidades do modelo.
Modelo E/R:
Dicionário de Dados:
EQUIPES = codEquipe + nomeEquipe PILOTOS = codPiloto + nomePiloto + dtNascimento + Altura + Peso PAISES = codPais + sigla + nome CORRIDAS = codCorrida + dtCorrida + duracaoProva + nomeCircuito PARTICIPACOES = posicaoPilotoProva
Esquema Relacional equivalente : PAISES (codPais, sigla, nome)
EQUIPES (codEquipe , nomeEquipe, codPais) codPais referencia PAISES PILOTOS (codPiloto, nomePiloto, dtNascimento, altura, peso, codPais, codEquipe) codPais referencia PAISES codEquipe referencia EQUIPES CORRIDAS (codCorrida, dtCorrida, duracaoProva, nomeCircuito) PARTICIPACOES (codPiloto, codCorrida , posicaoPilotoProva) codPiloto referencia PILOTOS codCorrida referencia CORRIDAS
3.7. NORMALIZAÇÃO Uma vez concluído o projeto lógico de banco de dados relacional, com geração do esquema correspondente, deve-se avaliar, para cada tabela, se a projeção foi bem feita. Esse processo de verificação, composto por um conjunto de regras, denomina-se “forma normal”. Há diversas formas normais usadas no processo de verificação; porém, na nossa disciplina, serão exploradas apenas as três primeiras formas normais, denominadas 1FN, 2FN e 3FN. Normalmente, as formas normais visam a eliminar informações redundantes nas tabelas, cujo processo é denominado normalização.
3.7.1. Primeira Forma Normal (1FN) Um banco de dados está na Primeira Forma Normal quando não existem dados repetidos em nenhuma das linhas da tabela. Segundo DATE (2004), uma relação R existe na primeira forma normal (1FN) se, e somente se, todos os domínios subjacentes contiverem apenas valores atômicos. Para ilustrar esse conceito, tomemos como exemplo a relação Funcionários, com a seguinte definição de esquema: Funcionarios (matricula, nome, cidade, dtAdmissao, telefones) No caso dessa relação, nem todos os domínios contêm valores atômicos, como é o caso de telefones. Nesse caso, os valores não atômicos devem estar contidos em uma outra tabela, relacionada à original. Passando pelo processo de normalização (1FN), temos o seguinte esquema: 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 não de apenas uma parte dela. Caso ocorra essa dependência parcial, dizemos que a tabela viola a segunda forma normal. Segundo DATE (2004), uma relação R existe na segunda forma normal (2FN) se, e somente se, estiver na (1FN) e todos os atributos não chaves forem dependentes da chave principal. Exemplo: considere o esquema de uma relação filmes, de um banco de dados de uma locadora de vídeo, com o seguinte esquema: Filmes (codigoFilme, codigoAtor, titulo, nomedoAtor) A coluna Título depende somente do código do filme e Nome do Ator, depende somente do Número do Ator. Quase sempre a solução é dividir as colunas em duas tabelas e criar uma terceira tabela que correlacione as linhas das duas tabelas. Nesse caso, geraríamos os seguintes esquemas:
Filmes (codigoFilme, titulo) Atores (codigoAtor, nomedoAtor) AtoresFilmes (codigoFilme, codigoAtor) codigoFilme referencia Filmes codigoAtor referencia Atores A 2FN deve ser verificada sempre que a tabela possuir uma chave primária composta de 2 ou mais campos.
3.7.3. Terceira Forma Normal (3FN) Uma tabela encontra-se na Terceira Forma Normal se todas as suas colunas dependerem de toda a chave principal e não houver interdependência entre as colunas que não são chaves da tabela. Segundo DATE (2004), uma relação R existe na terceira forma normal (3FN) se, e somente se, estiver na (2FN) e todos os atributos não chave forem intransitivamente dependentes da chave principal. Exemplo: considere o esquema modificado da relação filmes de um banco de dados de uma locadora de vídeo com o seguinte esquema: Filmes (codigoFilme, titulo, categoria, preco) Suponha que a loja determine o preço dos filmes por categoria: filmes de Terror, Drama e Comédia custam R$2,00; Musicais, R$2,50 e; Lançamentos, R$3,00. Nesse caso, a coluna Preço dependeria não só da coluna Código do filme, como também da coluna Categoria. Essa tabela não está na Terceira Forma Normal, então a solução seria criar uma tabela adicional para armazenar os valores por categoria do filme. Após normalização, os seguintes esquemas são gerados: Filmes (codigoFilme, titulo,codigoCategoria) codigoCategoria referencia Categorias Categorias (codigoCategoria, Preco) Com o passar do tempo, você vai adquirindo experiência e não necessitará avaliar mais essas regras para as tabelas projetadas. Muitas vezes, usamos essa experiência para construir modelos desnormalizados, buscando melhoria de desempenho das aplicações. Mais uma vez volto a dizer que tudo tem seu preço! Às vezes, não conseguimos ter projeto perfeito e alta performance, por isso acabamos abrindo mão de uma coisa para termos o que é mais importante no cenário exposto.
Atividade 01 Muitas vezes, o DBA se depara com situações em que possui o esquema do banco de dados, porém não tem o modelo conceitual equivalente. Baseado nisso, dada a definição do esquema abaixo, gere o modelo conceitual equivalente (esse processo denomina-se Engenharia Reversa). 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 relação Perifericos, coloquem a mesma na terceira forma normal, passo a passo. (codPeriferico, codModelo, noConfig, quantidade, nomeModelo, codCPU, nomeCPU) Perifericos
As dependências funcionais que existem nesta tabela são as seguintes: ♦ (codPeriferico, codModelo, noConfig) Quantidade ♦ codCPU NomeCPU ♦ codModelo NomeModelo ♦ codModelo CodCPU ♦ codModelo NomeCPU X Y, significa dizer que : Y depende de X b) Dada a relação PEDIDOS, coloquem a mesma na terceira 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 capítulo teve como objetivo o de apresentar conceitos relacionados com projeto lógico de bancos de dados, mais especificamente no que se refere ao modelo relacional. No próximo capítulo trabalharemos com linguagens de consultas aplicadas ao este modelo.
4. LINGUAGENS DE CONSULTA
Olá! Neste capítulo você terá conceitos de linguagens de consultas formais e comerciais para bancos de dados relacionais. Bom estudo! Profª Claudinete Vicente Borges
4.1. DEFINIÇÃO Uma linguagem de consulta é uma linguagem na qual o usuário requisita informações do banco de dados. São classificadas como procedurais e não procedurais. Numa linguagem procedural, um usuário instrui o sistema para executar uma sequência de operações no banco de dados a fim de computar o resultado desejado. Numa linguagem não-procedural, o usuário descreve a informação desejada, sem fornecer um procedimento específico para obter tal informação. A Álgebra relacional é uma linguagem de consulta procedural, enquanto o cálculo relacional é uma linguagem não-procedural. Navathe [NAVATHE, 2005] afirma que qualquer expressão escrita em álgebra relacional pode ser representada também no cálculo, dando o mesmo poder de expressão para ambas as linguagens. Como o nosso propósito de usar uma linguagem de consulta formal é o de entendermos o que ocorre nos “bastidores” da execução de uma consulta, focaremos apenas na álgebra relacional. A Linguagem SQL é uma linguagem de consulta comercial, intitulada padrão pelo comitê ANSI, desde 1986. É uma linguagem declarativa, com comandos muito mais amigáveis do que as linguagens formais, embora seja fundamentada nessas linguagens formais (na álgebra e no cálculo). Nas seções seguintes exploraremos a linguagem SQL. Uma linguagem de consulta é uma linguagem na qual um usuário requisita informações do banco de dados. São classificadas como procedurais e não procedurais. Álgebra Relacional é uma linguagem de consulta formal e procedural. SQL é uma linguagem de consulta comercial e inclui elementos de uma linguagem procedural e não-procedural.
4.2. SQL A linguagem SQL foi uma das grandes razões para a consolidação dos bancos de dados relacionais no mercado. Desde sua definição como padrão, em 1986, passou por diversas revisões, gerando publicações de novas versões. A versão original, denominada Sequel, foi desenvolvida no
Laboratório de Pesquisa da IBM e implementada como parte do projeto System R no início dos anos 70. A linguagem evoluiu desde então, e seu nome foi alterado para SQL (Structured Query Language). A primeira versão ficou conhecida como SQL-86 ou SQL1, a segunda versão foi denominada SQL-92 ou SQL2 e a última versão publicada, que 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 padrão SQL. Além disso, incorporam uma série de funções adicionais visando a facilitar o trabalho dos desenvolvedores. Estas facilidades precisam ser usadas com cautela, pois, se apenas o padrão for utilizado, garante-se a portabilidade, caso haja a necessidade de troca de SGBD. A linguagem SQL possui diversas partes: •
linguagem de Definição de Dados (DDL) - Inclui comandos para definição de esquemas de relações (criação, exclusão, alteração), criação de índices dentre outros;
•
linguagem de manipulação de dados (DML) - Inclui comandos para consulta, inserção, exclusão e modificação de tuplas em uma relação do banco de dados;
•
incorporação DML (SQL Embutida) - Uso de SQL em linguagens de programação de uso geral, como Pascal, C,...;
•
definição de Visões - A SQL DDL inclui comandos para definição de visões;
•
autorização - A SQL DDL inclui comandos para especificação de direitos de acesso a relações e visões;
•
integridade - A SQL DDL inclui comandos para especificação de regras de integridade que os dados que serão armazenados no banco de dados devem satisfazer; controle de Transações - A SQL DDL inclui comandos para especificação de iniciação e finalização de transações.
•
4.2.1. Linguagem de Manipulação de Dados – SQL DML Consultas SELECT O comando SELECT é responsável por consultar dados em um banco de dados que satisfazem aos predicados (critérios) informados. A estrutura básica de uma expressão SQL SELECT consiste em três cláusulas: select, from e where. • a cláusula select corresponde à operação projeção da álgebra relacional. É usada para listar os atributos desejados no resultado de uma consulta; • a cláusula from corresponde à operação produto cartesiano da álgebra relacional. Ela lista as relações a serem examinadas na avaliação da expressão; • a cláusula where corresponde ao predicado de seleção da álgebra relacional. Consiste em um predicado envolvendo atributos de relações que aparecem na cláusula from. Uma típica consulta SQL SELECT tem a seguinte forma:
SELECT A1, A2, ..., An 3 FROM r1, r2, ..., rn 1 [WHERE P] 2 Cada Ai representa um atributo e cada ri é uma relação. P é um predicado. Essa consulta é equivalente à expressão da álgebra relacional: π A1, A2, ..., An (σP (r1 x r2 x ...x rn))
A lista de atributos A1, A2, ..., An pode ser substituída por um (*) para selecionar todos os atributos (colunas) presentes nas tabelas da cláusula from.
SELECT A1, A2, ..., An FROM r1, r2, ..., rn [WHERE P]
3 1 2
A numeração constante no final de cada linha da consulta representa a ordem de execução desta linha, dentro da consulta como um todo. Mesmo que o otimizador altere a ordem de execução, buscando por melhoria de performance e para facilitar o aprendizado é interessante termos em mente esta ordem. Para execução da consulta acima, forma-se o produto cartesiano das relações referenciadas na cláusula from, executa-se uma seleção da álgebra relacional usando o predicado da cláusula where e, então, projeta o resultado para os atributos da cláusula select. Na prática, o otimizador de consultas da linguagem SQL pode converter essa expressão em uma forma equivalente que pode ser processada mais eficientemente, mas para efeito didático iremos manter esta ordem de execução. Uma consulta completa pode ter as cláusulas abaixo, sendo que apenas as cláusulas SELECT e FROM são obrigatórias. O número que segue cada linha sugere a ordem de execução. O conhecimento desta ordem é importante para efeito didático pois facilita o entendimento do comando.
SELECT A1, A2, ..., An FROM r1, r2, ..., rn [WHERE P] [GROUP BY A1, A2, ..., An] [HAVING Condição] [ORDER BY A1, A2, ..., An]
6 1 2
3
4
5
Cada uma das cláusulas da consulta acima será explorada nas subseções seguintes.
Assim como na álgebra relacional, o resultado de uma consulta SQL é uma relação!
Vamos considerar uma primeira consulta simples, usando nosso esquema exemplo. “Encontre os nomes de todos os clientes na relação clientes”. A consulta SQL pode ser escrita da seguinte forma: SELECT Nome FROM Clientes
Linhas (tuplas) duplicadas Em algumas situações, uma consulta SQL pode retornar uma relação que contenha tuplas (linhas) duplicadas. Nessa situação, inserimos a palavrachave distinct depois da cláusula select para eliminá-las. Aproveitando o exemplo anterior, a relação resultante poderá ter clientes que possuam o mesmo nome. Nesse caso, podemos eliminar essas duplicações usando a cláusula distinct: SELECT DISTINCT Nome FROM Clientes A cláusula distinct aplica-se à linha a ser retornada, embora seja colocada antes do primeiro atributo.
Predicados e ligações A SQL não tem uma representação da operação ligação natural. No entanto, uma vez que a ligação natural é definida em termos de produto cartesiano, seleção e projeção, é relativamente simples escrever uma expressão SQL para representar a operação ligação natural. Ex.: Encontre os nomes e cidades de clientes que possuam empréstimos em alguma agência. Esta consulta pode ser escrita da seguinte forma: SELECT DISTINCT Clientes.nome, Clientes.cidade FROM Clientes, Emprestimos WHERE Clientes.codigoCli=Emprestimos.codigoCli Observe que na consulta acima, apenas necessita-se saber se o cliente possui empréstimo, por isto apenas as tabelas Clientes e Empréstimos foram incluídas. Se além disso, tivesse a necessidade de saber qual a agência em que o empréstimo foi feito, seria necessário a inclusão da relação Agências.
Outro recurso disponível na linguagem SQL para estabelecer ligações entre tabelas são as operações de join. A consulta acima poderia ser escrita da seguinte forma, usando join: SELECT DISTINCT Clientes.nome, Clientes .cidade FROM Clientes JOIN Emprestimos ON Clientes.codigoCli=Emprestimos.codigoCli
Uma boa fonte de pesquisa para complementar os estudos sobre os conceitos tratados nesta seção é consultar o livro Sistemas de Banco de Dados, de Elmasri Navathe, capítulo 8, que oferece outras opções de join . A SQL inclui os conectores and, or e not ; caracteres especiais: (, ), ., :, _, %,<, >, <= , >= , = , <>, +, - ,* e /; operador para comparação: between, como mostra o exemplo a seguir. Ex.: Selecionar todas as contas que possuam saldo entre 10000 e 20000. SELECT numeroCont FROM Depositos WHERE saldo BETWEEN 10000 AND 20000 Que equivale a consulta SELECT numeroCont FROM Depositos WHERE saldo >= 10000 AND saldo <= 20000 A SQL inclui também um operador para comparações de cadeias de caracteres, o like. Ele é usado em conjunto com dois caracteres especiais: Por cento (%). Substitui qualquer subcadeia de caracteres. Sublinhado (_). Substitui 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 também 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 padrão possa incluir os caracteres especiais ( isto é, % , _ , etc...), a SQL permite a especificação de um caractere de escape. O caractere de escape é precedido do caractere especial para indicar que este último deverá ser tratado como um caractere normal. Definimos o caractere de escape para uma comparação like, usando a palavra-chave escape. Para ilustrar, considere os padrões seguintes, que utilizam uma barra invertida como caractere de escape.
Like “ ab\%cd%” escape “\” substitui todas as cadeias começando com “ ab%cd”; Like “ ab\_cd%” escape “\” substitui todas as cadeias começando com “ ab_cd”. A procura por não-substituições em vez de substituições se dá por meio do operador not like. Embora a cláusula Like seja muito útil, deve ser utilizada com cuidado. Quando fixar o início da cadeia, como iniciar com “Maria”, não há problemas, porém, quando for aplicada em consultas para procurar caracteres no meio ou no final de cadeias, nas quais não se conhece o início, teremos problemas! Nesse caso não usará o índice, caso haja para a coluna, podendo implicar em baixa performance das aplicações.
Operações de conjunto A SQL inclui o operador de conjunto union que opera em relações e corresponde à operação ∪ da álgebra relacional. Uma vez que as relações são conjuntos, na união destas relações, as linhas duplicadas são eliminadas. Para uma operação União (Union) r ∪ s ser válida, duas condições devem ser atendidas: as relações r e s precisam ter a mesma paridade, isto é, elas precisam ter o mesmo número de atributos; e os domínios do iésimo atributo de r e do i-ésimo atributo de s devem ser os mesmos. Ex. Se quisermos saber todos os clientes que possuem empréstimos na agência de código 51, fazemos: SELECT DISTINCT Clientes.nome FROM Clientes, Emprestimos WHERE Clientes.codigoCli=Emprestimos.codigoCli Emprestimos.codigoAg = 51
AND
Da mesma forma, se quisermos consultar todos os clientes que possuem depósitos na agência de código 51, fazemos: SELECT DISTINCT Clientes.nome FROM Clientes, Depositos WHERE Clientes.codigoCli= Depositos.codigoCli AND Depositos.codigoAg = 51 Para encontrar todos os clientes que possuem depósito, empréstimo ou ambos, na agência de código 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 exibição de tuplas A cláusula order by organiza o resultado de uma consulta em uma ordem determinada. Para listar em ordem alfabética todos os clientes do banco, fazemos: SELECT DISTINCT nome FROM Clientes ORDER BY nome Como padrão, a cláusula order by lista tuplas na ordem ascendente. Para especificar a ordem de classificação, podemos especificar asc para ordem ascendente e desc para descendente. Podemos ordenar uma relação por mais de um elemento. Como se segue: SELECT * FROM Emprestimos ORDER BY quantia DESC, codigoAg ASC Se desejar que o resultado de uma consulta SQL seja exibido em ordem alfabética, utilize a cláusula Order By. Às vezes, construímos consultas e o resultado é apresentado em ordem alfabética, conforme esperado, e não nos preocupamos em usar a cláusula Order by. Isso acontece provavelmente porque há um índice ordenado criado sobre essa coluna; porém, se o DBA resolver criar esse índice sobre outra coluna, sua ordenação vai se perder!
Membros de conjuntos O conectivo in / not in testa os membros de conjunto em que o conjunto é uma coleção de valores produzidos por uma cláusula select. Para ilustrar, considere a consulta “Encontre todos os clientes que possuem uma conta (Depósito) e não possuem empréstimo na agência “Princesa Isabel””. A consulta SQL poderá ser escrita da seguinte forma: SELECT DISTINCT Clientes.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 construída 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”)
Renomeação de Tabelas em uma consulta A renomeação sempre será necessária quando precisarmos usar a mesma tabela mais de uma vez na mesma consulta, assim como na operação renomear da álgebra relacional. Muitas vezes usamos este recurso com o objetivo de reduzir o tamanho das expressões SQL. A renomeação é feita usando a palavra reservada “AS”, após o nome da tabela na cláusula FROM, como mostra o exemplo a seguir. Ex: “encontre o nome e a cidade de todos os clientes que possuem depósito”. SELECT DISTINCT C.nome, C.cidade FROM Clientes AS C, Depositos AS D WHERE C.codigoCli = D.codigoCli Uma vez que as relações Clientes e Depósitos foram renomeadas para C e D, quaisquer referências a essas tabelas, na consulta, devem ser feitas a C e D, e não mais aos nomes originais. Lembre-se da ordem de execução de uma consulta SELECT! Redefinindo a relação Agências para uso em exemplos posteriores. Agencias = (CodigoAg, NomeAg, CidadeAg, ativos)
Comparação de conjuntos Considere a consulta “encontre todas as agências que possuem ativos maiores que alguma agência de Vitória”. Esta consulta poderá ser escrita em SQL da seguinte forma: SELECT DISTINCT Agencias.nomeAg FROM Agencias , Agencias AS ag WHERE agencias.ativos > ag.ativos AND ag.cidade = “Vitória”
Uma vez que a consulta usa uma comparação “maior que”, não podemos escrever a expressão usando a construção in. Observe também que, como houve necessidade de usar a mesma tabela (Agências) duas vezes na consulta, ela teve que ser renomeada. A mesma consulta acima poderia ser escrita usando o operador any (pelo menos um), conforme será abordado a seguir. Comparações do tipo >any, =any, <=any, =any são 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 = “Vitória”) Vamos modificar a consulta anterior levemente para encontrar todas as agências que possuem ativos maiores do que todas as agências de Vitória. A construção > all corresponde à frase “maior que todos”. A consulta fica como se segue: SELECT Agencias.nomeAg FROM Agencias WHERE ativos > ALL (SELECT ativos FROM Agencias WHERE Agencias.cidade = “Vitória”)
Como o operador Any, o operador all pode ser usado como: >all, =all, <=all, =all e <> all. Sempre que houver necessidade de comparar um atributo com o resultado de uma subconsulta é necessário usar um operador de conjunto, seja o operador ALL seja o ANY, como ilustrado no exemplo acima.
Testando relações vazias A SQL possui um recurso para testar se uma subconsulta retorna alguma tupla. A construção exists retorna true se a subconsulta retornar alguma tupla. Para ilustrar, vamos escrever a consulta “Encontre todos os clientes que possuem depósito e não possuem empréstimo na agência “Princesa Isabel” ”. SELECT Clientes.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 são 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 existência de tuplas na consulta seguinte, não importa o conteúdo 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 expressões 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 Vitória. 2. Consulte todas as pessoas que trabalham na mesma cidade onde moram. 3. Consulte todas as pessoas que moram na mesma cidade do chefe. 4. Consulte todas as empresas que funcionam em cidades em que não moram pessoas cujo primeiro nome seja Maria (usar operações de conjunto). 5. Consulte todas as pessoas que não trabalham em Vitória e que ganham acima de R$2000,00 em ordem decrescente. 6. Consulte todas as pessoas que não trabalham na empresa cujos nomes comecem com “inf_”. O resultado deverá ser apresentado em ordem alfabética.
Atividade 02 Considere o esquema abaixo para construir as expressões 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 automóveis do fabricante “Ford”. 3. Consultar as pessoas que não compraram “Ford”. 4. Consultar as pessoas que compraram carro com ágio. O resultado deverá ser apresentado em ordem alfabética. 5. Consultar as pessoas que compraram “Ford” e não compraram “Volks”.
Funções agregadas A SQL oferece a habilidade para computar funções em grupos de tuplas, usando a cláusula group by. O(s) atributo(s) informado(s) na cláusula group by são usados para formar grupos. Tuplas com o mesmo valor em todos os atributos na cláusula group by são colocados em um grupo. Funções agregadas: Média: AVG Mínimo: MIN Máximo: MAX Soma: SUM Contar: COUNT Para ilustrar, considere a consulta: Encontre o saldo médio das contas em cada agência. 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 execução da consulta (antes do agrupamento), tomando como base o conjunto de valores definidos no início deste capítulo para o esquema bancário.
Tabela 32: Tabela resultante do produto cartesiano e seleção (cláusula FROM e WHERE)
codigo Ag 50 51
numeroCo nt 999 991
codigoC li 01 02
saldo 1000 3200
Agencias. codigoAg 50 51
51
992
03
2300
51
53
993
04
1200
53
Agencias .nomeAg Centro Princesa Isabel Princesa Isabel Avenida
Agencias .cidadeAg Vitória Vitória Vitória Vitória
Uma vez que o agrupamento é feito, cada agência (nomeAg) constituirá um grupo, sobre o qual incidirá a função agregada (AVG). Com isto, temos o resultado na consulta exibido na tabela 33. Tabela 33: Tabela resultante da consulta “encontre o saldo médio das contas em cada agência”.
nomeAg Centro Princesa Isabel Avenida
saldoMedio 1000 2750 1200
Quando escrevemos a cláusula GROUP BY em uma expressão SQL, a cláusula SELECT só poderá retornar atributos que constam no grupo. Além deles, apenas funções agregadas são permitidas. Caso contrário, dará erro! Se, além do saldo médio por cada agência, quiséssemos retornar a quantidade de clientes que possuem conta, a consulta poderia ser levemente modificada, conforme mostra a seguir: SELECT Agencias.nomeAg, AVG(Depositos.saldo) AS saldoMedio, COUNT(DISTINCT Depositos.codigoCli) AS qtdClientes FROM Depositos, Agencias WHERE Depositos.codigoAg = Agencias.codigoAg GROUP BY Agencias.nomeAg Note que para a cláusula COUNT é importante o uso da cláusula distinct , pois um cliente pode ter mais de uma conta em uma agência e deverá ser contado uma única vez. A tabela 34 abaixo mostra o resultado da consulta. Tabela 34: Tabela resultante da consulta “encontre o saldo médio e quantidade de clientes em cada agência”.
nomeAg Centro Princesa Isabel Avenida
saldoMedio 1000 2750 1200
qtdClientes 1 2 1
A consulta abaixo mostra o maior saldo para cada agência. 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 execução da consulta. Tabela 35: Tabela resultante da consulta “encontre o maior saldo para cada agência”.
nomeAg Centro Princesa Isabel Avenida
maiorSaldo 1000 3200 1200
Muitas vezes é necessário definir uma condição que se aplique a grupos em vez de tuplas. Por exemplo, poderíamos estar interessados apenas em agências em que a média dos saldos seja superior a R$1200,00. Essa condição será aplicada a cada grupo e não a tuplas simples, e é definida pela cláusula having. Podemos escrever essa expressão SQL assim: SELECT Agencias.nomeAg, AVG(Depositos.saldo) AS saldoMedio FROM Depositos, Agencias WHERE Depositos.codigoAg= Agencias.codigoAg GROUP BY Agencias.nomeAg HAVING AVG(saldo)>1200 A tabela 36 mostra o resultado da execução da consulta. No caso, apenas a agência “Princesa Isabel” será retornada. Tabela 36: Tabela resultante da consulta “encontre as agências onde a média de saldo seja superior a 1200”.
nomeAg Princesa Isabel
saldoMedio 2750
A cláusula WHERE elimina linhas em uma consulta. A cláusula HAVING elimina grupos.
Às vezes, desejamos tratar a relação inteira como um grupo simples. Nesses casos, não usamos a cláusula group by. Para encontrar a média de saldos de todas as contas, escrevemos: SELECT AVG (Depositos.saldo) FROM Depositos
No exemplo anterior, a coluna projetada por meio de uma função agregada, a média de saldos, não possui um nome, ou seja, não foi renomeada como nos exemplos anteriores. É sempre recomendado que se dê um nome para identificá-la. Para criar este nome, também chamado de “Alias” usa-se a cláusula “AS”, assim como para renomeação de tabelas. Caso contrário, ao executá-la, a coluna aparecerá com o nome EXPR, por exemplo.
Atividade 03 Considere o esquema bancário para construir as expressões seguintes, usando a linguagem SQL. 1) Consultar todos os clientes que possuem contas em agência(s) que possui(em) o maior ativo. 2) Consultar o total de agências por cidade, classificado por cidade. 3) Consultar, por agências, o(s) cliente(s) com o maior saldo. 4) Consultar o valor médio de empréstimos efetuados por cada agência, em ordem crescente das cidades onde essas agências se situam. 5) Consultar a(s) agência(s) que possui(em) a maior média de quantia emprestada. 6) Consultar todas as agências situadas fora de Vitória que possuem a média de depósitos maior do que alguma agência localizada em Vitória. 7) Consultar o menor saldo de clientes, por agências. 8) Consultar o saldo de cada cliente, caso ele possua mais de uma conta no banco.
Removendo linhas de uma tabela O comando Delete é usado para remover tuplas em uma dada relação. Lembre-se de que só podemos remover tuplas inteiras, não podemos remover valores apenas em atributos particulares. Sintaxe: DELETE FROM r [WHERE P] Onde r representa uma relação e P um predicado. Note que o comando delete opera em apenas uma relação. O predicado da cláusula where pode ser tão complexo quanto o predicado where do comando select. Ex1.: Fazer uma consulta para excluir todas as tuplas de empréstimo. DELETE FROM Emprestimos
Ex2.: Remover todos os depósitos de “joão” DELETE FROM Depositos.Depositos WHERE Depositos.codigoCli in (SELECT codigoCli FROM Clientes WHERE nome=”joão”) Ex3.: Remover todos os empréstimos com números entre 1300 e 1500. DELETE FROM Emprestimos WHERE numero between 1300 AND 1500 Ex4.: Remover todos os depósitos de agências localizadas em “Vitória”. DELETE FROM Depositos WHERE depositos.codigoAg in
(SELECT codigoAg FROM Agencias WHERE cidade=’Vitoria’)
O comando DELETE é um comando da Linguagem DML; por isso, se usar o comando DELETE FROM Tabela sem predicado na cláusula WHERE, todas as linhas serão excluídas; a tabela, no entanto, permanecerá criada, porém vazia.
Inserindo linhas em uma tabela Para inserir um dado em uma relação, ou especificamos uma tupla para ser inserida ou escrevemos uma consulta cujo resultado seja um conjunto de tuplas a serem inseridas. Obviamente, os valores dos atributos para tuplas inseridas precisam ser membros do mesmo domínio do atributo. Sintaxe: INSERT INTO r (A1, A2, ..., An) VALUES (V1, V2, ..., Vn) Onde r representa uma relação A atributos e V valores a serem inseridos. Suponha que desejamos inserir um novo depósito de João (código = 1), cujo valor seja R$1200,00, na conta 9000 da agência de código=2. Para isso, fazemos o seguinte comando: INSERT INTO depositos (codigoAg, numeroCont, codigoCli, saldo) VALUES (2,9000,1,1200) A SQL permite que essa mesma inserção seja escrita da seguinte forma: Insert into depositos Values (2,9000,1,1200), omitindo a relação de atributos. Essa abordagem, porém, não é recomendada, tendo em vista que, se houver alteração do esquema da relação, a exemplo da inclusão de um novo atributo, a consulta falhará e, consequentemente, a aplicação que a utiliza acarretará em erros.
Podemos querer também inserir tuplas baseadas no resultado de uma consulta. Suponha que desejemos inserir todos os clientes que possuam empréstimos na agência “Princesa Isabel” na relação depósitos, com um saldo de R$200,00. INSERT INTO Depositos (codigoAg, numeroCont, codigoCli, saldo) SELECT Emprestimos.codigoAg, Empréstimos.numeroEmp, Empréstimos.codigoCli, 200 FROM Emprestimos, Agencias WHERE Emprestimos.codigoAg=Agencias.codigoAg AND Agencias.nomeAg=”Princesa Isabel” Essa possibilidade de consultar dados em tabelas e inserir em outra pode ser muito útil para trabalhar com migração de banco de dados.
Atualizando valores Em certas situações, podemos desejar mudar valores em tuplas. Nesse caso, o comando update deve ser aplicado. Sintaxe: UPDATE r SET a1 = v1, a2 = v2, ..., an = vn [WHERE p] Em que r representa uma relação, a atributos, p predicado e v os novos valores para os respectivos atributos. O comando UPDATE é um comando da Linguagem DML. Altera valores de campos e não a estrutura da tabela. Os alunos costumam confundir isso. Por isso, esteja atento! Suponha que esteja sendo feito o pagamento de juros e que sejam acrescentados 5% em todos os saldos. Escrevemos UPDATE Depositos SET saldo = saldo * 1.05 Suponha que todas as contas com saldo superior a R$10000,00 recebam aumento de 6% e as demais de 5%. UPDATE Depositos SET saldo = saldo * 1.06 WHERE saldo >10000 UPDATE Depositos SET saldo = saldo * 1.05 WHERE saldo<=10000
A cláusula where pode conter uma série de comandos select aninhados. Considere, por exemplo, que todas as contas de pessoas que possuem empréstimos no banco terão acréscimo de 1%. UPDATE Depositos SET saldo = saldo * 1.01 WHERE codigoCli IN (SELECT codigoCli FROM Emprestimos) Como você deve ter observado, os comandos de atualização – INSERT, UPDATE e DELETE – atuam sempre sobre uma única tabela. Não é possível inserir linhas em mais de uma tabela em um comando.
Valores Nulos É possível para tuplas inseridas em uma dada relação atribuir valores a apenas alguns atributos do esquema. Os atributos restantes são designados como nulos. Considere a expressão cujo objetivo é o de incluir uma nova agência: INSERT INTO Agencias (codigoAg, nomeAg, cidadeAg, ativos) VALUES (2,”Centro”, ”Vitória”, NULL) Nesse caso, está sendo atribuído o valor nulo para o atributo “ativos”. A mesma consulta poderia ser reescrita omitindo esse atributo. Nesse caso, automaticamente ele assumiria o valor nulo. INSERT INTO Agencias (codigoAg, nomeAg, cidadeAg) VALUES (2, ”Centro”, ”Vitória”) A consulta acima só será válida se o campo ativos puder assumir valor nulo. Caso contrário, ocasionará erro.
A palavra chave null pode ser usada em um predicado para testar se um valor é nulo. Assim, para achar todos os clientes que aparecem na relação empréstimos com valores nulos para quantia, escrevemos: SELECT DISTINCT nome FROM Clientes, Emprestimos WHERE Clientes.codigoCli = Emprestimos.codigoCli AND quantia IS NULL O predicado IS NOT NULL testa a ausência de um valor nulo.
Atividade 04 Considere o esquema abaixo para construir as expressões 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 Observação: estas atividades foram elaboradas para exercitar os comandos de atualização. Desconsidere a integridade referencial dos dados. 1. Exclua todas as pessoas que possuem salário = R$1000,00. 2. Exclua todas as pessoas que trabalham em empresas situadas em Vitória. 3. Inclua na empresa de código “01”, com um salário= R$100,00, todos os moradores de Vitória 4. Uma determinada empresa de código “x” vai contratar todos os funcionários da empresa de código “y” que ganham acima de R$1000,00, dando um aumento de salário de 10%. Faça comando(s) SQL para que tal transação seja efetuada. Obs: As pessoas serão remanejadas. 5. Uma determinada empresa de código “xyz” quer contratar todos que moram em Vitória e estão desempregados. Serão contratados com salário = R$200,00. Faça comando(s) SQL para efetuar tal transação. 6. Faça um comando SQL para ajustar o salário de todos os funcionários da empresa “Campana” em 5%. 7. Todas as pessoas que moram em Colatina e trabalham na empresa “Campana” deverão se mudar para Vitória, devido aos requisitos do diretor da empresa. Faça comando(s) SQL para efetivar a atualização da cidade.
4.2.2. Linguagem de Definição de dados – SQL DDL O conjunto de relações de um Banco de Dados precisa ser especificado ao sistema por meio de uma linguagem de definição de dados (DDL). A SQL DDL permite a especificação não apenas de um conjunto de relações, mas também de informações sobre cada relação, incluindo: •
o esquema para cada relação;
•
o domínio de valores associados a cada atributo;
•
o conjunto de índices a ser mantido para cada relação;
•
restrições de integridade;
•
a estrutura física de armazenamento de cada relação no disco.
Tipos de Domínios da Linguagem SQL A linguagem SQL inclui diversos tipos de domínios, conforme lista abaixo [SILBERSCHATZ, 2006]: Char(n): cadeia de caracteres de tamanho fixo, igual a n, definido pelo usuário; Varchar(n): cadeia de caracteres de tamanho variável, no máximo igual a n, definido pelo usuário; Int: inteiro (subconjunto finito dos inteiros que depende do equipamento). Smallint: inteiro pequeno (um subconjunto do domínio dos inteiros que depende do equipamento); Numeric(p,d): número de ponto fixo cuja precisão é definida pelo usuário. O número consiste de p dígitos, sendo que d dos p dígitos estão à direita do ponto decimal; Real: números de ponto flutuante cuja precisão depende do equipamento em questão; Float(n): número de ponto flutuante com a precisão definida pelo usuário em pelo menos n dígitos; Date: calendário contendo um ano (com quatro dígitos), mês e dia do mês; Time: representa horário, em horas, minutos e segundos. Se você definir um campo de uma tabela como varchar(50), por exemplo, e se o espaço necessário para alocar um valor para esse campo tiver 10 caracteres, apenas 10 espaços serão alocados. Se, no entanto, esse campo for definido como char(50), usando ou não, serão alocados os 50 espaços.
Ao definir um campo de uma tabela, se ocupar sempre a mesma quantidade de caracteres, é melhor definir como char. Se o tamanho for variável, use varchar. Uma relação SQL é definida usando a instrução CREATE TABLE . CREATE TABLE r (A1 D1, ..., An Dn) Em que r é uma relação, cada Ai é o nome de um atributo no esquema de relação r e Di é o tipo de dados de valores no domínio de atributo Ai. O comando create table inclui opções para especificar certas restrições de integridade, conforme veremos adiante. A relação criada acima está inicialmente vazia. O comando insert poderá ser usado para carregar os dados para uma relação. Para remover uma relação de banco de dados SQL, usamos o comando drop table, que remove todas as informações sobre a relação retirada do banco de dados. DROP TABLE r Ex. : para excluir a relação Depósitos, podemos escrever a seguinte expressão SQL.
DROP TABLE Depositos Ao excluir uma tabela, caso exista outra tabela com chave estrangeira que faça referência à tabela que está sendo excluída, ocorrerá erro. É necessário excluir antes a tabela referenciada ou usar exclusão em cascata, como mostra o exemplo: DROP TABLE Depositos CASCADE Neste caso, caso haja uma tabela que faça referência à tabela Depositos, esta também será eliminada do banco de dados. O comando alter table é usado para alterar a estrutura de uma relação existente. Ao alterar a estrutura de uma tabela, é possível incluir novos campos, excluir campos existentes ou incluir restrições, a exemplo de chaves primárias e estrangeiras. Exemplo de um comando alter table incluindo uma coluna “cpf” na relação Clientes: ALTER TABLE Clientes ADD cpf NUMERIC(11,0) NULL Ao adicionar uma coluna em uma tabela existente, se esta tabela possuir registros, a coluna incluída necessariamente deverá ser NULL. Exemplo de um comando alter table excluindo a coluna “cpf”, recém incluída na relação Clientes: ALTER TABLE Clientes drop column cpf Exemplo de um comando alter table incluindo uma restrição, a chave primária da relação Clientes: ALTER TABLE Clientes ADD CONSTRAINT PK_Clientes PRIMARY KEY (CodigoCli)
Integridade Quando se fala em manter a integridade de dados, considera-se não só a Integridade Física dos arquivos portadores do banco de dados, como também manutenção da qualidade dos dados armazenados em termos de precisão e consistência. As restrições de integridade fornecem meios para assegurar que mudanças feitas no banco de dados por usuários autorizados não resultem na perda da consistência dos dados. São vários os tipos de integridade, os quais costumam ser classificados da seguinte forma: •
Integridade de Domínio. Domínio é uma lista de valores que precisa estar associada a todo atributo. Constitui a forma mais elementar de restrição de integridade. É facilmente testado pelo
sistema cada vez que um novo item de dado é inserido no banco de dados. •
Integridade de Vazio. Especifica se um campo de uma coluna pode ou não assumir valor nulo. Não pode permitir que os campos com entrada obrigatória assumam valores nulos.
•
Integridade de Chaves. Especifica a unicidade dos valores para a chave primária e candidatas.
Integridade Referencial. Frequentemente, desejamos assegurar que um valor que aparece em uma relação para um dado conjunto de atributos apareça também para um certo conjunto de atributos em outra relação, o que se denomina Integridade Referencial. A existência de uma chave estrangeira impede que anomalias ocorram em função de alterações executadas no banco de dados, conforme elencadas abaixo: • ao incluir uma linha na tabela que contém a chave estrangeira, o valor inserido tem que fazer parte da tabela em que ela é chave primária. O único valor diferente desse que é permitido é o valor nulo, quando for possível; • ao excluir uma linha da tabela que contém chave primária referenciada por outras tabelas, pode-se implementar os seguintes cenários: excluir em cascata as linhas nas tabelas relacionadas em que se encontram as chaves estrangeiras referentes a essa chave primária ou impedir que a exclusão seja feita; • ao alterar o valor da chave primária referenciada por outras tabelas, pode-se implementar os seguintes cenários: alterar em cascata os valores das chaves estrangeiras nas tabelas relacionadas ou impedir que a alteração seja feita; • ao se alterar o valor da chave estrangeira, deve-se ter garantia de que o novo valor esteja constante na tabela em que ela é chave primária. Se não for, haverá bloqueio na alteração. Implementando Integridade Referencial em SQL A SQL original padrão não incluiu instruções para especificar chaves estrangeiras. Um subsequente “recurso de aperfeiçoamento de integridade” foi aprovado como uma adição ao padrão. Esse recurso permite a especificação de chaves primárias, candidatas e estrangeiras como parte da instrução create table. • a cláusula primary key da instrução create table inclui uma lista de atributos que compreende a chave primária; • a cláusula unique da instrução create table inclui uma lista de atributos que compreende a chave candidata; • a cláusula foreign key da instrução create table inclui uma lista de atributos que compreende a chave estrangeira e o nome da relação referida pela chave estrangeira. •
Criando as relações clientes, agências e depósitos para o esquema bancário. CREATE TABLE Clientes (codigoCli int not null, nome varchar(30) not null, rua varchar(30) not null, cidade varchar(30) not null, cpf numeric(11,0) not null, PRIMARY KEY (codigoCli), UNIQUE (CPF)) CREATE TABLE Agencias (codigoAg int not null, nomeAg varchar(30) not null, cidadeAg varchar(30) not null, PRIMARY KEY (CodigoAg))
CREATE TABLE Depositos (codigoAg int not null, numeroCont int not null, codigoCli int not null, saldo real, PRIMARY KEY (codigoAg,numeroCont), FOREIGN KEY (codigoCli) REFERENCES Clientes, FOREIGN KEY (codigoAg) REFERENCES Agencias, CHECK (Saldo >=0) ) A cláusula Check garante integridade aos valores dos atributos e pode fazer referência, inclusive, a valores de atributos em outras tabelas. Embora tenhamos incluído a cláusula not null para os campos que compõem a chave primária de cada tabela, não é necessário. A SQL assume que todos os campos chaves (primária) não permitam valores nulos.
Existe também a possibilidade de criar as tabelas sem integridade referencial e incluir essa implementação usando a instrução Alter Table.
Existe uma propriedade, implementada pela maioria dos SGBDs disponíveis no mercado, que possibilita que um campo tenha seu valor incrementado automaticamente. A sintaxe, porém, 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 criação da tabela Agencias, considerando o código da agência como auto incrementável, pode ser escrita como se segue: CREATE TABLE Agencias (codigoAg int identity(1,1) not null, nomeAg char(30), cidadeAg char(30), PRIMARY KEY (codigoAg)) Ao inserir uma agência, não deve ser passado valor para o código da agência, considerando que este valor será gerado pelo sistema, como mostra o exemplo a seguir: INSERT INTO Agencias (nomeAg, cidadeAg) VALUES (‘Centro’, ‘Vitória’) A primeira agência inserida terá o código igual a um e a seguinte, igual a 2, considerando que o valor do incremento foi definido como 1.
As restrições Default e Check serão mais exploradas na disciplina Banco de Dados II.
Atividade 05 Dados os esquemas abaixo, faça comandos SQL DDL padrão para criar as estruturas das tabelas, usando o tipo de dados que melhor se aplique a cada atributo e impondo integridade referencial. a) Alunos (codigoAl, nomeAl, codigoCurso, 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 obrigatória de todos os campos, exceto os campos: telefones, data de devolução de fitas e valor de multa. Não permita valores diferentes de ‘S’ ou ‘N’ nos campos “lancamento”, na tabela “Filmes”, e “dublada”, na tabela “Fitas”.