livro de banco de dados - ufscar
TRANSCRIPT
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 1/67
Livro Virtual de Sistemas de Banco deDados
Neste livro virtual você encontra notas de aula, slides utilizados nas videoaulas e webconferencias, exercícios complementares e sugestões de leituras. Espero que faça bomproveito! Profa. Marilde
Site: EaD - SEaD
Curso: Sistemas de Banco de Dados (G4)
Livro: Livro Virtual de Sistemas de Banco de Dados
Impresso por: Richard Vital da Silva 435716
Data: Thursday, 18 April 2013, 14:47
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 2/67
Sumário
1 Conceitos Básicos
1.1 O que é Banco de Dados?
1.2 Banco de Dados versus Processamento de Arquivos
1.3 Modelo de Dados
1.4 O que é Sistema de Banco de Dados?
1.5 Projeto de Banco de Dados1.6 Pessoas em torno de um Sistema de Banco de Dados
1.7 Arquitetura de três-esquemas
1.8 Independência de Dados
1.9 Linguagens de Banco de Dados
1.10 Software Gerenciador de Banco de Dados
1.11 Exercícios complementares
1.12 Indicação de Leitura Complementar
2 Projeto Conceitual de Banco de Dados
2.1 Entidade e Conjunto (ou Tipo) de Entidades
2.2 Modelo de Dados Entidade-Relacionamento
2.3 Relacionamentos e Conjuntos de Relacionamentos
2.4 Atributos de Entidades ou Relacionamentos
2.5 Diagrama Entidade-Relacionamento (DER)
2.6 Exercício complementar2.7 Indicação de Leitura Complementar
2.8 Material Complementar
3 Modelo de Dados Relacional3.1 Conceitos do Modelo Relacional
3.2 Restrições do Modelo Relacional3.3 Restrições de Domínio
3.4 Restrições de Chave3.5 Restrição de Integridade de Entidade
3.6 Restrição de Integridade Referencial e Chave Estrangeira3.7 Indicação de Leitura Complementar3.8 Material Complementar
4 Projeto de Banco de Dados Relacional4.1 Esquema Conceitual do banco de dados Empresa
4.2 Mapeamento dos Conjuntos de Entidades Regulares (ou Fortes)4.3 Mapeamento dos Conjuntos de Entidades Fracas4.4 Mapear Conjuntos de Relacionamentos Binários 1:1
4.5 Mapear Conjuntos de Relacionamentos Binários 1:N4.6 Mapear Conjuntos de Relacionamentos Binários N:M
4.7 Mapear Conjuntos de Relacionamentos n-ários (grau > 2)4.8 Mapear atributos multivalorados
4.9 Esquema Lógico Relacional do banco de dados Empresa4.10 Material Complementar
4.11 Exercício complementar
5 Dependências Funcionais Dependências Multivaloradas e Normalização5.1 Processo de Normalização
5.2 Dependências Funcionais5.3 Dependências Funcionais Parciais
5.4 Dependências Funcionais Transitivas5.5 Primeira Forma Normal - 1FN
5.6 Segunda Forma Normal - 2FN5.7 Terceira Forma Normal - 3FN5.8 Terceira Forma Normal - 3FN (Alternativa)
5.9 Forma Normal de Boyce-Codd - FNBC5.10 Material Complementar - Slides
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 3/67
1 Conceitos Básicos
Bancos de dados tornaram-se essenciais em nosso dia a dia. São inúmeras as aplicações que utilizam sistemas de banco de dados:
1. bancos financeiros: armazenam todas as transações bancárias2. empresas aéreas: reservas de assentos em vôos, agendamentos de vôos
3. vendas: clientes, produtos, estoques, compras 4. revendedores online: registro de pedidos, recomendações personalizadas
5. industria: produção, estoque, pedidos, fornecedores6. recursos humanos: regoistro de empregados, salários, dedução de taxas7. universidades: registros de alunos, disciplinas, salas, notas
8. bibliotecas: registro de acervo, registro de usuário, registro de empréstimo
Muitas dessas aplicações são ditas aplicações tradicionais de banco de dados, pois envolvem essencialmente textos e números, porém tem crescido as aplicações que
envolvem dados ditos não convencionais como áudio, vídeo, mapas, imagens de satélites, etc.
O emprego de avanços tecnológicos tornaram possíveis aplicações inovadoras de sistemas de banco de dados, tais como:
1. banco de dados multimídia: armazenam e manipulam figuras, videoclipes, mensagens sonoras;2. sistemas de informações geográficas: armazenam e analisam mapas, dados do tempo e imagens de satélite;3. data warehouses: utilizados em conjunto com ferramentas de processamento analítico online (OLAP) possibilitam empresas extrair e analisar informações úteis de
grandes bancos de dados para tomada de decisão;4. tecnologia de bancos de dados ativos e de tempo real são utilizados no controle de processos industriais e de produção.
5. tecnologia de banco de dados aplicadas a WWW aprimora a recuperação de informações pelos usuários da internet.
Para que você possa compreender as aplicações mais avançadas começaremos explorando bancos de dados convencionais. Nas próximas seções conheceremos um
pouco mais sobre os conceitos que cercam os sistemas de banco de dados.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 4/67
1.1 O que é Banco de Dados?
Um banco de dados é uma coleção de dados relacionados, que possui algumas propriedades implícitas[ELMASRI 2005]:
representa aspectos do mundo real (chamado minimundo ou universo do discurso) e mudanças no minimundo devem ser refletidas no banco de dados;
é uma coleção lógica e coerente de dados com algum significado inerente;
é projetado, construído e povoado por dados que atendem a uma proposta específica dirigida a um grupo de usuários.
Um banco de dados pode ser gerado e mantido manualmente ou pode ser computadorizado. Obviamente, neste livro virtual abordaremos apenas sobre bancos de
dados computadorizados.
A coleção das informações armazenadas no banco de dados em um determinado momento é uma instância do banco de dados. O projeto geral do banco de dados é
o esquema do banco de dados. Os esquemas raramente - ou nunca - são modificados.
Os sistemas de banco de dados possuem vários esquemas, particionados de acordo com o nível de abstração, como você verá quando estudar a arquitetura de três-
esquemas para sistemas de banco de dados.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 5/67
1.2 Banco de Dados versus Processamento de Arquivos
No processamento de arquivos, cada usuário define e implementa os arquivos necessários para uma aplicação específica, como parte da programação da aplicação.
Mesmo que mais de uma aplicação necessite trabalhar com o mesmo conjunto de dados, cada aplicação mantém suas informações em arquivos separados e também asaplicações que os manipulam. Isso implica em redundâncias indesejadas, tanto em termos de definição e armazenamento de dados quanto de esforço para manter os
dados comuns atualizados.
Utilizando um banco de dados, um único repositório de dados é construído e mantido para ser acessado por vários usuários.
As principais características da abordagem de banco de dados são:
1. Natureza autodescritiva do sistema de banco de dados;
2. isolamento entre os programas e os dados, e a abstração dos dados;
3. suporte para as múltiplas visões dos dados;4. compartilhamento de dados e processamento de transações
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 6/67
1.3 Modelo de Dados
Modelo de dados é uma coleção de ferramentas conceituais para descrever dados, relações de dados, semântica de dados e restrições de consistência. Um modelo de
dados oferece uma maneira de descrever o projeto de um banco de dados no nível físico, lógico e de visão.
É usual encontrarmos a seguinte categorização dos modelos de dados:
Modelo Relacional que representa os dados como uma coleção de tabelas. Cada tabela possui diversas colunas e cada coluna possui um nome único. É o modelo de
dados mais usado. Esse modelo é um exemplo de um modelo de dados baseado em registros. Historicamente, o modelo de dados em rede e o modelo de dados
hierárquico precederam o modelo relacional. Esses modelos estavam intimamente relacionados com sua implementação subjacente.
Modelo Entidade/Relacionamento (MER) é baseado em uma percepção do mundo real que consiste em uma coleção de objetos básicos, chamados entidades e asrelações entre esses objetos. Uma entidade é uma "coisa" ou "objeto" no mundo real que é distinguivel dos outros objetos. O MER é muito usado no projeto de banco
de dados conceitual.
Modelo Baseado em Objeto pode ser visto como uma extensão ao modelo ER com noções de encapsulamento, métodos e identidade de objeto. O modelo relacional-
objeto combina os recursos do modelo orientado a objeto com o relacional.
Modelo Semi-estruturado permite a especificação dos dados em que itens de dados individuais do mesmo tipo possam ter distintos conjuntos de atributos. Isso é o
oposto dos modelos mencionados anteriormente. A Extensible Markup Language (XML) é amplamente utilizada para representar dados semi-estruturados.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 7/67
1.4 O que é Sistema de Banco de Dados?
Um sistema de banco de dados contém informação sobre algum extrato do mundo real do qual se pretende armazenar dados e recuperar informações. Na figura 1.1
está representada uma configuração simplificada de um sistema de banco de dados.
Figura 1.1 - Configuração simplificada de um sistema de banco de dados (extraida de [ELMASRI 2005] - figura cedida pela Editora Pearson).
Conforme apresentado na figura 1.1, um sistema de banco de dados é basicamente constituído por um conjunto de dados interrelacionados, que aparece na figura
como "banco de dados armazenado"; por metadados, ou seja, por um conjunto de dados sobre os dados e as restrições que se aplicam aos mesmos, que aparece na
figura como " Definição dos Dados Armazenados" - comumente chamado de Dicionário de Dados; o software gerenciador de banco de dados - que é um ambiente
conveniente e eficiente para acessar aos dados, e, finalmente um conjunto de programas de aplicações e/ou consultas que fazem a interface com o usuário e/ouprogramador do sistema.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 8/67
1.5 Projeto de Banco de Dados
O projeto de um sistema de banco de dados segue as seguintes etapas, apresentadas no diagrama da figura 1:
Figura 1 - Etapas de desenvolvimento de um projeto de sistema de banco de dados. (extraído de [ELMASRI 2005] - ilustração cedida pela editora Pearson)
Levantamento de requisitos (independe do SGBD) Na fase de levantamento de requisitos e análise de requisitos podem ser aplicadas técnicas de engenharia de software
que facilitam a comunicação entre especialistas de computação e especialistas de domínio. É uma fase essencial para o desenvolvimento do sistema, pois a qualidade dasolução está intrinsecamente relacionada a um documento de requisitos preciso.
Projeto Conceitual (independe do SGBD) a etapa de projeto conceitual é realizada a partir do documento de requisitos e é independente de implementação, ou
seja,independe de SGBD. O fruto desta etapa é a construção de um modelo conceitual, que em nossa disciplina será representado por um diagrama entidade
relacionamento. Nesta etapa podem ainda surgir questões sobre os requisitos, sendo recomendável questionar o especialista do domínio sobre tais dúvidas, nestesentido o modelo conceitual pode auxiliar no refinamento dos requisitos do sistema.
Projeto Lógico Esta etapa tem por objetivo transformar o modelo conceitual em um modelo lógico. O modelo lógico define como o banco de dados será implementado
em SGBD específico. Em nossa disciplina vamos obter um esquema relacional, pois o PostgreSQL é um SGBD baseado no modelo de dados relacional.
Projeto Físico nesta etapa o modelo do banco de dados é enriquecido com detalhes que influenciam no desempenho do banco de dados, mas não interferem em sua
funcionalidade. O modelo obtido nesta fase é o modelo físico do banco de dados.
Estas etapas, conforme [HEUSER 2008] salienta, são adequadas para a construção de um novo banco de dados. Caso já exista um banco de dados ou um conjunto de
arquivos convencionais, e se pretenda construir um novo banco de dados, o processo anterior é modificado e incorpora uma etapa de engenharia reversa.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 9/67
1.6 Pessoas em torno de um Sistema de Banco de Dados
Nesta seção vamos enfocar os profissionais que no cotidiano se envolvem na construção, manutenção e uso de um grande banco de dados.
Uma primeira figura que se destaca em ambientes que lidam com grandes quantidades de dados e que necessitam de adequada gestão desses dados por intermédio de
sistemas de banco de dados é o projetista de banco de dados. Os projetistas devem entrevistar todos os grupos de possíveis usuários para conhecer suas
necessidades de dados, ou seja, são os responsáveis pela identificação dos dados que serão armazenados no banco e também por escolher as estruturas adequadas
para representar e armazenar esses dados. Os projetistas começam a trabalhar antes mesmo do sistema ter sido implementado e alimentado com os dados.
Uma outra figura, não menos importante, em se tratando de grandes bancos de dados é o administrador de banco de dados (DBA) que é responsável pela
autorização para o acesso ao banco, pela coordenação e monitoração de seu uso e por adquirir recursos de software e hardware conforme necessário. É responsável
por problemas como brechas de segurança ou tempo de resposta ruim do sistema. Ou seja, o DBA é o responsável pelo sistema de banco de dados durante toda sua
vida útil.
Já foi dito que um sistema de banco de dados é desenvolvido para um grupo de usuários, então obviamente, este é um grupo de pessoas importante no contexto.
Usuários podem ser categorizados em usuários leigos - são aqueles que interagem com o sistema apenas por intermédio de programas de aplicação previamente
concebidos; programadores de aplicação - são profissionais de computação que interagem com o sistema com o intuito de escrever programas de aplicação;
usuários avançados interagem com o sistema sem escrever programas, formulam suas requisições em uma linguagem de consulta de banco de dados e usuários
especializados são usuários avançados que escrevem aplicações de banco de dados especializadas que não se encaixam na estrutura de processamento de dados
tradicional.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 10/67
1.7 Arquitetura de três-esquemas
A arquitetura de três-esquemas (também conhecida como arquitetura ANSI/SPARC) para sistemas de banco de dados foi proposta para auxiliar a realização e
visualização de importantes características do uso de banco de dados: independência entre dados e programas; suporte a múltiplas visões de usuários e uso de catálogo
(ou dicionário de dados) para armazenar a descrição do banco de dados.
O objetivo dessa arquitetura, ilustrada na figura 1, é a separação entre o usuário da aplicação e o banco de dados físico. Pode-se observar três níveis: o nível interno
(ou físico) que tem um esquema interno que descreve a estrutura de armazenamento físico do banco de dados. Esse esquema utiliza um modelo de dados físico e
descreve os detalhes completos do armazenamento de dados e caminhos de acesso aos mesmos. O nível conceitual (ou lógico) que possui um esquema conceitual
que descreve a estrutura de o todo o banco de dados para a comunidades usuária. Esse esquema oculta detalhes de armazenamento físico, concentrando-se em
descrição de entidades, tipos de dados, conexões, operações de usuários e restrições. O nível externo (ou de visão) abrange os esquemas externos ou visões dosusuários. Cada esquema externo descreve a parte do banco de dados que um dado grupo de usuários tem interesse e oculta o restante do banco de dados desse
grupo.
Figura 1 - Arquitetura Three-Schema (extraída de [ELMASRI 2006])
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 11/67
1.8 Independência de Dados
Independência de dados é a capacidade de mudar o esquema em um nível do sistema de banco de dados sem que ocorram alterações do esquema no próximo nível
mais alto. Existem dois tipos de independência de dados: lógica e física.
Independência de dados lógica: é a capacidade de alterar o esquema conceitual sem mudar o esquema externo ou os programas de aplicação.
Possíveis alterações no esquema externo: adicionar um tipo de registro ou item de dados, variar restrições ou remover um tipo de registro ou item de dados.
Independência de dados física: é a capacidade de mudar o esquema interno sem alterar o esquema conceitual. Consequentemente, o esquema externo também não
necessita alteração.
Possíveis mudanças em nível físico podem ser necessariás quando arquivos físicos precisam ser reorganizados para aperfeiçoar o desempenho da recuperação ou
atualização de dados.
Com um sistema gerenciador de banco de dados (SGBD) que implementa a arquitetura de três-esquemas, o catálogo é expandido para incluir informações de comomapear os dados entre níveis. Ou seja, o SGBD utiliza software adicional para realizar os mapeamentos e garantir a independência de dados o que acarreta uma
sobrecarga durante a compilação ou a execução de uma consulta ou de um programa, provocando ineficiências no SGBD. Porisso poucos SGBDs implementam a
arquitetura três-esquemas completa.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 12/67
1.9 Linguagens de Banco de Dados
Após termos obtido o esquema lógico e físico do banco de dados devemos escolher o Sistema Gerenciador de Banco de Dados (SGBD) que se deseja utilizar paraimplementá-lo.
A linguagem de definição de dados (data definition language) é usada pelo DBA e pelos projetistas do banco de dados para definir ambos os esquemas conceitual
e interno. O SGBD terá um compilador DDL cuja função é processar os comandos DDL a fim de identificar os construtores e para armazenar a descrição do esquemano catálogo do SGBD.
Quando os esquemas do banco de dados estiverem compilados e o banco de dados populado com os dados, os usuários devem ter alguns meios para manipular esse
banco. As manipulações típicas são a recuperação, inserção, remoção e modificação dos dados. A linguagem de manipulação de dados (DML) é fornecida peloSGBD para essa finalidade.
Basicamente, existem dois tipos de DMLs: procedurais e declarativas. As procedurais requerem que um usuário especifique que dados são necessários e como obtê-
los. As declarativas exigem apenas que os usuários especifiquem o que desejam sem especificar como obtê-los.
A parte de uma DML que que envolve recuperação de informações é chamada de linguagem de consulta.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 13/67
1.10 Software Gerenciador de Banco de Dados
Um Sistema Gerenciador de Banco de Dados (SGBD) é um complexo sistema de software. Os principais módulos componentes de um SGBD encontra-se ilustrado,de forma simplificada, na figura 1.
O banco de dados e o catálogo são normalmente armazenados no disco. O acesso ao disco é controlado principalmente pelo sistema operacional do ambiente onde
está instalado o SGBD. Um módulo de alto nível do SGBD, chamado de módulo de gerenciamento dos dados armazenados, controla o acesso à informação doSGBD que está armazenada em disco.
O compilador DDL processa as definições do esquema, especificadas na DDL, e armazena as descrições dos esquemas no catálogo do SGBD. O catálogo inclui
informações como nomes e tamanhos dos arquivos, nomes e tipos de itens de dados, detalhes de armazenamento de cada arquivo, informações de mapeamento entre osesquemas e restrições, além de muitas outras informações necessárias para os módulos do SGBD. Os módulos de software do SGBD acessam as informações do
catálogo conforme necessário.
O compilador de consulta manipula as consultas de alto nível que são feitas interativamente. Analisa sintaxe, compila ou interpreta a consulta criando um código deacesso ao BD e então gera as chamadas ao runtime.
O pré-compilador extrai os comandos DML dos programas escritos em uma linguagem de programação hospedeira. Esses comandos são enviados ao compiladorDML para compilação, gerando códigos para o acesso ao BD. O restante do programa é enviado para o compilador da linguagem de programação hospedeira. Oscódigos-objeto para os comandos DML e o restante do programa são acoplados, formando uma transação customizada cujo código executável inclui as chamadas para
o runtime.
O processador de consulta de banco de dados em tempo de execução (runtime) recebe os comandos para a recuperação ou atualização e os executa no bancode dados.
Figura 1 - Arquitetura simplicada dos componentes de SGBD. (extraída de [ELMASRI 2006])
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 14/67
1.11 Exercícios complementares
1. O que é um SGBD? Quais suas principais características?
2. O que é um modelo de dados estruturado? O que é um modelo de dados semi-estruturado? Dê exemplos de ambas abordagens.
3. Quais etapas do Projeto de Banco de Dados independe do SGBD? E quais delas depende do SGBD?
4. No contexto das pessoas envolvidas em um Sistema de Banco de Dados, relacione:
1. Usuário Leigo2. Programadores de aplicação
3. Usuários avançados4. Usuários especializados
5. DBA6. Projetista de BDa) Codificação de programas que atuam sobre o BD
b) Escrevem consultas usando uma determinada linguagem c) Interação com o BD é controlada por software
d) Interação com os possíveis usuários do BDe) Segurança e operação do BD
f) Desenvolvem aplicações especializadas
5. Discuta sobre a finalidade da Arquitetura de três-esquema.Ela determina privacidade sobre os dados? Por quê?Esta arquitetura é ideal? Por quê?
6. Devido a uma mudança em suas estratégias, uma empresa necessita alterar suas regras de negócio. Assim, o esquema conceitual de seu banco de dados deverá sofrer
alterações, bem como as aplicações que acessam o banco de dados. O que este fato representa no contexto de SBD?
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 15/67
1.12 Indicação de Leitura Complementar
Leia mais nos capítulos 1 e 2 de [ELMASRI 2005], no capítulo 1 de [SILBERCHATZ 2006] e no capítulo 1 de [HEUSER 2008].
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 16/67
2 Projeto Conceitual de Banco de Dados
Na seção 5 do capítulo 1, foram apresentadas as etapas que devem ser seguidas para o desenvolvimento de projeto de banco de dados. Na ocasião, foi apresentada a
figura 1 reproduzida aqui.
Figura 1 - Etapas de desenvolvimento de um projeto de sistema de banco de dados. (extraída de [ELMASRI 2005] - ilustração cedida pela editora Pearson)
Nesta disciplina vamos supor que teremos em mãos o documento de requisitos que é obtido após um processo, normalmente longo, de levantamento e análise de
requisitos. Várias metodologias e técnicas que podem auxiliar no processo de levantamento de requisitos são assuntos da disciplina Engenharia de Software. Maioresdetalhes sobre essas técnicas e metodologias podem se obtidos no livro do Pressman [PRESSMAN 2006].
Na etapa de projeto conceitual o desafio enfrentado é o de representar com o maior grau de fidelidade possível a complexidade existente na realidade que
pretendemos abstrair no banco de dados. Essa é uma etapa fundamental para o êxito da tarefa de implementar um bom banco de dados. O Modelo Entidade-
Relacionamento é um poderoso modelo de dados que nos auxilia a desenvolver a etapa de projeto conceitual do banco de dados.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 17/67
2.1 Entidade e Conjunto (ou Tipo) de Entidades
Uma entidade é um objeto que existe e é distinguível de outros objetos: uma determinada pessoa (Wes Montgomery, por exemplo), uma determinada empresa
(Polygram Records, por exemplo), um determinado disco (Tequila, por exemplo). Entidades possuem características que desejamos armazenar sobre elas, que sãochamadas de atributos das entidades, por exemplo, suponha que desejemos armazenar nomes e endereços de pessoas então diremos que esses são os atributos dasentidades pessoas que manteremos no banco de dados.
Um conjunto de entidades é um grupo de entidades do mesmo tipo que compartilham as mesmas propriedades, ou seja, representa um conjunto de elementos do mundoreal. Por exemplo, um conjunto Pessoa representando inúmeras pessoas, um conjunto Empresa representando inúmeras empresas, um conjunto Disco representando
inúmeros discos, etc. Na figura 3, estão representadas duas entidades do mundo real junto com as características que foram consideradas relevantes, p1 é uma entidadepessoa e para ela foram informados os valores dos atributos nome, endereço e idade; e d1 é uma entidade disco com os atributos nome , gravadora e mídia. Toda vezque são atribuídos valores para os atributos de um conjunto de entidades tem-se a instanciação (= exemplificação) de uma ocorrência de uma entidade da vida real.
Cada atributo deve ser definido como pertencente a um domínio, e os valores desses atributos devem pertencer a esses domínios.
Figura 3 – Exemplo de entidades pessoa e disco com seus respectivos atributos.
Um conjunto de entidades pode ser regular ou fraca. Um conjunto de entidades regulares possui um conjunto de atributos que identifica unicamente cada entidade
pertencente a ela, enquanto um conjunto de entidades fracas não possui um conjunto de atributos suficientes para garantir a unicidade de suas entidades.
Você verá mais sobre os identificadores e sua influência do conjunto de entidades na seção que trata sobre atributos.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 18/67
2.2 Modelo de Dados Entidade-Relacionamento
O Modelo Entidade-Relacionamento (MER) foi apresentado por Peter Chen em 1976. O modelo baseia-se em representar os dados do “mundo real” através da
definição de conjuntos de entidades e o relacionamento entre esses conjuntos de entidades.
A notação diagramática associada ao MER é conhecida como Diagrama Entidade-Relacionamento (DER). No DER a ênfase está na representação do esquema aoinvés das instâncias do banco de dados. Ou seja, privilegia-se a visão sobre as estruturas do banco e não dos valores armazenados neles.
Um exemplo de diagrama desenhado para representar o banco de dados de uma empresa é apresentado na Figura 2. Observando esta figura você pode perceber quetodo o banco de dados em questão está representado por seu esquema em um único diagrama. Não se aflija, você o entenderá melhor com a leitura dos próximoscapítulos.
Figura 2 - DER do banco de dados Empresa (extraída de [ELMASRI 2005])
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 19/67
2.3 Relacionamentos e Conjuntos de Relacionamentos
Para a modelagem de uma situação real, é necessário representar o relacionamento entre os Conjuntos de Entidades. Esses relacionamentos são denominados conjuntos
de relacionamentos e “possuem” rica semântica envolvida.
Essa semântica é expressa através dos conceitos de cardinalidade, participação total ou parcial, e grau de relacionamento.
Na figura 1, considere os conjuntos de entidades Empresa e Empregado, e o conjunto de relacionamentos entre eles Trabalha_em, representando o fato de empregados
trabalharem em empresa.
Estão ilustrados cinco empregados (e1, e2, e3, e4, e5), três empresas (c1, c2, c3) e cinco ocorrências de relacionamento entre eles (r1, r2, r3, r4, r5).
Pode-se inferir através da figura, que um empregado trabalha em uma única empresa, pois cada um participa de apenas uma ocorrência de relacionamento, enquantouma empresa emprega vários empregados, uma vez que uma empresa pode participar de mais de uma ocorrência de relacionamento.
Essa percepção da realidade pode ser representada através do conceito de Cardinalidade de Relacionamento.
Figura 1 - Diagrama representando o relacionamento Trabalha_em entre Empregado e Empresa.
A restrição de cardinalidade de relacionamento informa qual o número máximo de ocorrências de relacionamento pode haver de um conjunto de entidade com o
outro conjunto de entidade por um determinado conjunto de relacionamento.
No exemplo, a restrição de cardinalidade de Empregado no conjunto de relacionamento Trabalha_em com Empresa é 1, significando que um empregado pode serelacionar com apenas 1 entidade empresa. Por outro lado, a restrição de cardinalidade de Empresa no conjunto de relacionamento Trabalha_em com Empregado é N,
significando que uma empresa pode empregar vários (N) empregados. No caso dizemos que a restrição de cardinalidade neste relacionamento é N:1 (lê-se muitos para1 ou N para 1).
As cardinalidades entre os conjuntos de relacionamentos podem ser de 1 para 1, ou de 1 para N (ou N para 1), ou de N para N. A letra “N” representa vários e pode
ser substituída por qualquer outra letra, tal como, M, P, Q, etc.
A restrição de participação de um conjunto de entidade em um conjunto de relacionamentos indica a obrigatoriedade ou não de suas entidades participarem daqueleconjunto de relacionamentos com o outro conjunto de entidade.
A restrição de participação pode ser total ou parcial, se a restrição é total implica que todas as entidades pertencentes àquele conjunto de entidade obrigatoriamenteparticipará em alguma instância daquele conjunto de relacionamento, se a restrição é parcial implica que podem existir entidades que não participam do relacionamento.
O grau do relacionamento indica quantos conjuntos de entidades estão envolvidos naquele determinado relacionamento. No exemplo da Figura 1, temos que o grau do
relacionamento é 2, indicando um relacionamento binário. Um conjunto de relacionamentos pode associar vários conjuntos de entidades, caracterizando relacionamentosternários (grau 3), relacionamentos quaternários (grau 4), etc.
Um exemplo de relacionamento ternário, ou seja, com grau 3, está ilustrado na Figura 2. É importante observar que um relacionamento com grau N > 2 só se justifica se
não puder ser decomposto em relacionamentos com graus menores e ainda manter a semântica desejada.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 20/67
Figura 2 - Exemplo de Conjunto de Relacionamento Ternário (Grau 3)
Existem conjuntos de relacionamentos regulares que são aqueles que associam conjuntos de entidades regulares (ou fortes) e conjuntos de relacionamentos identidade
que associam um conjunto de entidade fraca ao conjunto de entidade proprietária.
Cabe ressaltar que devido ao fato de uma entidade fraca ser identificada sempre por sua entidade proprietária, a restrição de participação do conjunto de entidade fracaem seu conjunto de relacionamento identidade com a proprietária deve sempre ser total.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 21/67
2.4 Atributos de Entidades ou Relacionamentos
Atributos caracterizam as entidades e os relacionamentos.
Atributos, no MER, podem ser categorizados em:
simples e monovalorado,simples e multivalorado,
composto e monovalorado ecomposto e multivalorado.
Um atributo simples é aquele cujo significado está completamente informado no valor do atributo. No exemplo da Figura 3, reproduzida abaixo, se o atributo nome em
Pessoa é definido como sendo um atributo simples, espera-se que o valor atribuído a este atributo expresse completamente o significado que se pretende extrair dele.
Figura 3 – Exemplo de entidades pessoa e disco com seus respectivos atributos.
Porém, observe, o que é o nome de uma pessoa? Como você entende isso? Você pode julgar que informar apenas o primeiro nome é suficiente, outro pode achar que
são necessários o primeiro nome e o sobrenome e um terceiro pode julgar que são necessários: o primeiro nome, as iniciais dos nomes do meio e o sobrenome.
Quando é dito que um determinado atributo é simples, e os valores possíveis para esse atributo podem ser formados por partes como o exemplo citado, deve-se ter emmente que dependendo de quem for armazenar o valor, em um momento pode-se ter o valor completo (primeiro nome, nomes do meio e sobrenome) assim como em
outro momento pode-se encontrar apenas partes do valor completo (primeiro nome e sobrenome). Se não existe a necessidade de fazer a verificação se o valoresperado foi armazenado, então está tudo bem. Caso contrário, deve-se lançar mão de outra categoria de atributos, os atributos compostos.
Um atributo composto é definido por um conjunto de outros atributos componentes, ou seja, um atributo composto é aquele que para conhecer seu significado completo
faz-se necessário conhecer os valores de seus componentes.
Seguindo no mesmo exemplo, se é necessário garantir que todas as partes (ou pelo menos algumas delas) de um nome sejam conhecidas (obrigatório informar, porexemplo, o nome e sobrenome), então, deve-se representar o atributo nome como um atributo composto por prenome e sobrenome, para obrigar a pessoa que estiver
digitando os valores a fornecer esses dados (obviamente, esse “obrigar” deverá ser implementado mais tarde, por enquanto estamos sinalizando que seria interessanteimplementar dessa forma).
Figura 4 - Entidade Pessoa com Nome Composto
Na Figura 4, a entidade pessoa é representada com o atributo Nome composto por prenome e sobrenome. Desta forma, pode-se obrigar a entrada de dados com estasduas partes do nome. No exemplo o prenome é Wes e o sobrenome é Montgomery. Se quisermos conhecer o nome dessa pessoa, precisamos concatenar os dois
componentes: Wes Montgomery.
Um atributo ainda pode ser caracterizado como monovalorado ou multivalorado.
Um atributo definido como monovalorado implica que para uma entidade do mundo real, admite apenas um valor para aquele atributo. O que significa dizer isso?Continuemos com nosso exemplo anterior, uma pessoa, que é uma entidade do mundo real, pode ter apenas um nome associado a ela (esse nome pode ser composto
como vimos antes). Caso queiramos armazenar outros nomes pelos quais é conhecido, teremos que guardar seus apelidos ou codnomes, concorda? Pois bem, issosignifica que devemos definir o nome da pessoa como um atributo monovalorado, que vai admitir apenas um nome para cada pessoa.
E no caso dos apelidos ou codnomes? Bom, uma pessoa pode ter vários apelidos, não é? Pois bem, então se fossemos armazenar os apelidos de uma pessoa,
deveríamos definir esse atributo como multivalorado.
Um atributo multivalorado representa a possibilidade de para uma mesma entidade do mundo real registrarmos mais de um valor para aquele atributo.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 22/67
Figura 5 - Entidade Pessoa com vários apelidos.
Na figura 5, temos o exemplo da entidade pessoa com um atributo multivalorado Apelidos. No exemplo, vemos em contraposição ao Nome, que é um atributo simplese monovalorado, o atributo Apelidos que é simples e multivalorado.
Para entender a notação utilizada, observe que o valor de nome é definido pelos parenteses mais externos e é composto por dois outros atributos indicados nos
parenteses mais internos, enquanto o valor para o atributo Apelidos é definido entre chaves e o conjunto dos valores nos parenteses internos.
Além dessa categorização mais genérica de atributos no MER, existem outros conceitos associados a atributos:
atributo identificadoratributo identificador parcial ou discriminatórioatributo derivado
Ao definirmos um atributo como atributo identificador estamos impondo uma importante restrição aos valores possíveis para esse atributo - a restrição de ser únicodentro do universo de entidades do conjunto de entidades que o atributo caracteriza. Por exemplo, podem existir duas pessoas com o mesmo nome? Sim, pode, vocêvai responder. E está certo, podemos encontrar vários homônimos na vida real. Isso significa que o nome de uma pessoa não deve ser considerado um atributoidentificador para o conjunto de entidades pessoa. E que dado sobre uma pessoa a caracteriza de todas as outras? Simples, temos que encontrar dados que
indubitavelmente nos aponta uma única pessoa. Por exemplo, é possível ter mais de um cadastro de pessoa física (CPF)? Bom, se deixarmos as fraudes de lado,podemos afirmar que cada pessoa tem um, e somente um, número de CPF. Ou seja, se informo meu CPF, o único nome que deve ser encontrado é o meu! Sendoassim, esse é um possível atributo identificador de pessoa. Que tal procurar outros dados com as mesmas características? O registro geral (RG), caso reunamos asinformações de número e nome e estado do orgão emissor, pode identificar unicamente um indivíduo, assim como o título de eleitor, a CNH, etc. Em geral, podemosconsiderar os documentos de pessoas físicas e jurídicas como possíveis identificadores. Um conjunto de entidades que contém atributos suficientes para encontrarmos
um identificador é chamado de Conjunto de Entidades Regular (ou Forte).
Um atributo identificador parcial ou discriminatório só é encontrado no contexto de Conjunto de Entidades Fracas que é assim chamado por não possuir atributo
suficiente para que seja descoberto um identificador para suas entidades.
Nesse caso, o conjunto de entidades fracas precisará do auxílio do identificador de outro conjunto de entidades, dita sua proprietária, para identificar unicamente umaentidade dentro dela.
Se cada entidade da proprietária estiver relacionada a mais de uma entidade fraca, é necessário então definir um atributo identificador parcial que terá o importante papelde, junto com o identificador de sua proprietária, indicar uma e somente uma, entidade fraca dentre desse conjunto.
Por exemplo, podemos em um banco de dados de empresa, desejar armazenar dados sobre dependentes de seus funcionários para efeito de imposto de renda. Porémsobre esses dependentes, desejamos armazenar somente o nome e o parentesco com o funcionário.
Analisemos: podemos imaginar um conjunto de entidades Funcionário para o qual armazenamos, no mínimo, seu CPF e nome e temos um conjunto de entidadesDependente com os atributos nome e parentesco.
Para o conjunto de entidades Funcionário é fácil descobrir um identificador: CPF.
E para o conjunto de entidades Dependente? Vejamos: nome de pessoa não é um bom identificador, como já discutimos antes. Sobra-nos, então o parentesco? Nossa,quantos parentes "filho(a)" ou "mãe/pai" encontraríamos nesse banco de dados? Muitos, com certeza!
Ainda temos a possibilidade de reunirmos os dois dados: nome + parentesco para definirmos unicamente uma entidade nesse conjunto. Oras, se podemos encontrarhomonimos (e sabemos que sim) o que impede desses homonimos terem o mesmo grau de parentesco com seus responsáveis? Nada. Ou seja, se encontrarmos duaspessoas com o nome de "Sabrina Silva" no banco de dados de Dependente, não seria de estranhar que o grau de parentesco com seu responsável na empresa fosse "filho(a)"! Chegamos a um impasse! Não existem outros atributos para Dependentes, o que fazemos? Sentamos e choramos? Nem pensar!
A alternativa mais correta é considermos esse conjunto de entidades como Fraca. Sendo assim precisamos localizar uma proprietária para ela: Funcionário - pois édevido a existência de um responsável nos quadros da empresa é que leva ao cadastro do dependente. Certo. Então, se eu conheço o CPF do funcionário, conheçoseus dependentes. Não é bem assim, ainda precisamos saber se o funcionário pode ter atrelado a ele mais de um dependente. Se isso for verdade, precisamos além de
conhecer seu CPF, conhecer também o nome do dependente. Nesse caso o nome do dependente é o atributo identificador parcial do conjunto de entidades fracasDependente.
Veja o exemplo:
Funcionário Dependente
CPF NOME NOME PARENTESCO
05899356808 José Silva Sabrina Silva filho(a)
08085539926 Luiz Gonçalves Silva Sabrina Silva filho(a)
Consideremos que "José Silva" é pai de uma das "Sabrina Silva" e que "Luiz Gonçalves Silva" é pai da outra "Sabrina Silva". Se imaginarmos que cada funcionário temapenas um dependente, fica fácil encontrarmos um e só um dependente para cada um. Basta associarmos o identificador correto do responsável para cada dependente econsiderarmos esse também o identificador do tipo de entidade fraca Dependente.
Funcionário Dependente
CPF NOME CPF do Responsável NOME PARENTESCO
05899356808 José Silva 05899356808 Sabrina Silva filho(a)
08085539926 Luiz Gonçalves Silva 08085539926 Sabrina Silva filho(a)
08085539926 Gabriela Silva filho(a)
Mas, e se o funcionário puder ter mais de um dependente? Como fica? Se continuarmos considerando somente o CPF do responsável como identificador dessaidentidade, não iremos conseguir definir uma única entidade (olhe as duas últimas linhas). Como podemos diferenciá-las? A resposta é "Fazendo nome de dependente
ser um identificador parcial", pois se você souber o CPF do responsável e também o nome do dependente você localiza uma única linha em Dependente.
Para finalizar o assunto sobre diferentes atributos, vamos definir o atributo derivado. Um atributo derivado é aquele cujo valor pode ser obtido efetuando algum computosobre os dados já armazenados. Um exemplo típico é a idade de uma pessoa. Se você já tem a data de nascimento armazenada é possível saber a idade da pessoa,
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 23/67
para tanto basta conhecer a data atual e subtrair a data do nascimento armazenada. Essa é fácil, não é? Outros exemplos: número de funcionários de um departamento(se você já relacionou os funcionários aos seus respectivos departamentos basta contá-los!), número de dependentes por funcionário (similar ao anterior).
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 24/67
2.5 Diagrama Entidade-Relacionamento (DER)
O Diagrama Entidade-Relacionamento é a forma gráfica do modelo entidade-relacionamento.
Na Figura 1 você encontra um resumo da notação que deverá empregar em seu projeto conceitual do banco de dados. Observe que o termo atributo-chave foi citadono texto como Identificador (atributo grifado por linha contínua). O identificador parcial é anotado sublinhando com uma linha tracejada o atributo em questão.
Figura 1 - Resumo da Notação do DER
Um conjunto de entidades regular é representando por um retângulo, como ilustrado na Figura 2. Um elemento do conjunto de entidades é definido como uma Entidade,sendo identificado por características individuais definidas através do conceito de atributos (representados poe elipses). Assim, uma Pessoa pode ser caracterizadaatravés dos atributos Nome, CPF, Sexo, Idade, Altura, etc.
Figura 2 - Conjunto (ou Tipo) de Entidade Pessoa no DER
As distintas categorizações dos atributos: simples e monovalorado, simples e multivalorado, composto e monovalorado e composto e multivalorado são representadosna Figura 3.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 25/67
Figura 3 - Representação de Atributos no DER
Na Figura 4, o atributo nome é representado como um atributo composto e monovalorado. Prenome e Sobrenome são seus atributos componentes.
Figura 4 - Atributo Composto e Monovalorado
Na Figura 5 estão representados diversos conjuntos de entidades associados por conjuntos de relacionamentos. Em cada conjunto de relacionamento está ilustradauma restrição de cardinalidade 1:1, 1:N e M:N.
Figura 5 - Conjuntos de Relacionamentos de Restrição de Cardinalidade.
Na Figura 6 estão representados conjuntos de entidades interagindo em um conjunto de relacionamentos de grau 3 (ou ternário).
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 26/67
Figura 6 - Conjunto de Relacionamento de Grau 3.
A Figura 7 apresenta o conjunto de relacionamento Cursa entre Estudante e Disciplina, onde a restrição de participação de Estudante em Cursa é total (representado
pela linha dupla) e a restrição de participação de Disciplina em Cursa é parcial.
Figura 7 - Restrições de Participação Total e Parcial
A Figura 8 ilustra um conjunto de entidades fraca, Ementa, associada pelo conjunto de relacionamento identidade Possui ao seu conjunto de entidade proprietáriaDisciplina. Observe que a restrição de participação de Ementa em Possui é Total. Isso sempre é verdade quando se trata da relação entre a fraca e sua identidade. Deveser lembrado que, caso a cardinalidade em Possui fosse N:1, significando que uma disciplina pudesse ter várias ementas, seria necessário apontar um conjunto de
atributos identificador parcial para Ementa, conforme visto na seção sobre Atributos.
Figura 8 - Conjunto de Entidade Fraca
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 27/67
2.6 Exercício complementar
Você deve efetuar o projeto conceitual do banco de dados cujos requisitos estão listados abaixos. Você deve obter um esquema conceitual do banco de dadosexpresso segundo a notação do DER.
Procure relacionar todas as suposições que você precisou fazer para completar seu projeto.
Bom trabalho.
Marilde
Requisitos:
Uma gravadora de discos deseja manter informações sobre as bandas emúsicos que contrata, além da atuação deles em shows.
Sobre uma banda, deseja-se manter o seu nome e a data de sua criação.
Sobre um músico, interessam: o nome, o nome artístico, o CPF e a data de nascimento. Sabe-se que uma banda pode ser formada por diversos músicos, e que um
músico pode participar de uma ou mais bandas, sempre com um papel definido (vocalista, violonista, tecladista etc.).
Cada disco é gravado por uma banda específica. É comum bandas terem mais que um disco gravado. Todo disco tem um título, um produtor e um local de gravação
com logradouro, número, CEP, UF e país. Todo disco possui um código interno da gravadora para identificação. Além disso, os discos possuem uma ou mais canções.Todas as canções estão relacionadas a discos existentes, e cada canção pode estar presente em um ou mais discos.
As canções possuem um ou mais compositores, um título (que as identifica unicamente) e uma letra. É importante lembrar que os compositores não necessariamente sãomúsicos.
Os shows da banda também devem ser arquivados. Um show possui umcódigo identificador, ocorre em uma determinada cidade e exige acobrança de um determinado cachê. Num show, limita-se a capacidade de expectadores, bem como se registra a quantidade de pessoas que foram assisti-lo.
Uma banda realiza diversos shows, aproveitando para divulgar suasinúmeras canções. Um show é realizado exclusivamente por uma banda. Em um show, são executadas diversas canções. Em shows diferentes de uma mesma banda,podem existir canções repetidas. Não interessa saber se a banda A tocou a música da banda B, portanto uma canção é sempre executada pela mesma banda.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 28/67
2.7 Indicação de Leitura Complementar
Técnicas e metodologias para levantamento e análise de requisitos, que compõem as etapas iniciais de desenvolvimento de um projeto de banco de dados (e sistemasem geral) podem ser encontradas em [PRESSMAN 2006].
Explicações detalhadas sobre o emprego do modelo entidade-relacionamento (e sua extensão) no processo de projeto conceitual de banco de dados podem serencontradas em [ELMASRI 2005] E [SILBERCHATZ 2006].
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 29/67
2.8 Material Complementar
Slides utilizados na videoaula sobre modelo ER.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 30/67
3 Modelo de Dados Relacional
O Modelo Relacional foi proposto por Ted Codd, da IBM Researchs, em 1970 e tem sido largamente utilizado como base para Sistemas Gerenciadores de Banco deDados (SGBD).
Esse modelo usa o conceito de relações matemáticas como seu bloco de construção básica e tem sua base teórica na teoria de conjuntos.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 31/67
3.1 Conceitos do Modelo Relacional
O modelo relacional (MR) representa o banco de dados como uma coleção de relações.
Cada relação, ou tabela, assemelha-se a uma planilha eletrônica, com linhas, colunas e células onde se armazenam os dados. Cada linha em uma tabela representa umacoleção de valores de dados relacionados.No MR cada linha na tabela representa um fato que corresponde a uma entidade ou relacionamento do mundo real.Na terminologia formal do MR uma linha da tabela é chamada TUPLA, a coluna é chamada ATRIBUTO e a tabela é chamada RELAÇÃO.
Figura 1. Exemplo de uma relação com atributos e tuplas.
Na figura 1 pode ser observada a estrutura de uma relação, cujo nome é ALUNO. Essa relação possui os atributos Nome, SSN, FoneResidencia, Endereco,FoneEscritorio, Idade e MPG. Cada entidade aluno do mundo real é descrito por uma tupla, ou seja, pelos valores da entidade aluno relacionados a cada atributo darelação. Também podemos nos referir a uma tupla como uma instância da relação.
Cada valor em uma tupla é um valor atomico, ou seja, não divisivel. Pode ser observado que existem atributos que receberam o valor null. Qual o significado do valornull?
O valor null pode significar que para uma dada entidade do mundo real aquele atributo não se aplica, ou seja, a entidade em questão não pode ter um valor paraaquele atributo. Por exemplo, em uma relação Pessoa, podemos encontrar o atributo Certificado_Reservista, porém valores para esse atributo são esperadosapenas para pessoas do sexo masculino e maior de 18 anos. Então, se uma pessoa do sexo feminino ou uma pessoa do sexo masculino menor de 18 anos forcadastrada nessa relação Pessoa, o atributo Certificado_Reservista não vai fazer sentido para ela, nesse caso atribuimos o valor null com o sentido de não se
aplica.
Outro significado possível é o de desconhecermos o valor do atributo para determinada entidade do mundo real.
No exemplo da figura 1, existem valores null para os atributos FoneResidencia e FoneEscritorio, o que nos leva a interpretar essa informação como: os alunosBenjamin, Katherine e Barbara não possuem um telefone de escritório (existem 3 possibilidades para esse fato: ou não trabalham - então o atributo não se aplica; o localonde trabalham não possui telefone ou não quiseram informar o número - portanto o número é desconhecido). No caso do aluno Dick percebemos que ele não possuitelefone em casa, ou seja, não se aplica (ou não quis informar o número - valor desconhecido).
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 32/67
3.2 Restrições do Modelo Relacional
O mundo real, abstraido em um banco de dados, determina regras de negócio que devem ser respeitadas nos valores armazenados nesse banco de dados. Ou seja,
existe necessidade de explicitarmos restrições para os valores que entrarão no banco de dados conforme as regras de negócio impostas pelo minimundo representadonele.
Segundo Elmasri e Navathe [ELMASRI 2005], as restrições em banco de dados podem, geralmente, ser divididas em em 3 categorias principais:
1. restrições inerentes ao modelo de dado, por exemplo, no modelo relacional existe a restrição de não poder existir tuplas repetidas em uma relação.2. restrições baseadas em esquema, ou seja, que podem ser expressas diretamente nos esquemas do modelo de dado.3. restrições baseadas em aplicação, ou seja, que não podem ser expressas diretamente nos esquemas do modelo de dado e, portanto, devem ser expressas nos
programas de aplicação.
Outra categoria importante de restrições são as de dependência de dados, incluindo as dependencias funcionais e as multivaloradas, que são utilizadas para verificar aexcelencia do projeto de um banco de dados relacional.
Abordaremos a segunda categoria de restrições, que podem ser expressas no modelo relacional: domínio, chave, valores em null, integridade de entidade e integridadereferencial.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 33/67
3.3 Restrições de Domínio
As restrições de domínio estabelecem que dentro de cada tupla o valor atômico de um atributo deve pertencer a um domínio especificado.
Isso significa que essas restrições impõem um limite nos possíveis valores que podemos atribuir aos atributos de uma relação e, por consequência, quais os possíveisvalores dessa relação.
O domínio deverá ser especificado para informar se os valores possíveis são numéricos (inteiros, reais), caracteres ou cadeias de caracteres fixos ou variáveis,booleanos (verdadeiro ou falso), data, hora e, em alguns casos, existem até o tipo de dados de moeda. O domínio que poderá ser especificado para um esquema debanco de dados está diretamente associado ao sistema gerenciador de banco de dados (SGBD) adotado para controlar o banco de dados. Ou seja, antes deimplementar um sistema de banco de dados, existe a necessidade de verificar quais os tipos de dados pré-definidos no SGBD e verificar se existe a possibilidade de
definição de tipos do usuário, para que possamos definir tipos baseados naqueles pré-estabelecidos.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 34/67
3.4 Restrições de Chave
O modelo relacional é um modelo baseado na matemática. Seu principal conceito, o conceito de relação é definido como um conjunto de tuplas. Um conjunto, na
matemática, é definido como um conjunto de elementos distintos, portanto, todas as tuplas da relação também devem ser distintas [ELMASRI 2005].
Um subconjunto de atributos, menor ou igual ao conjunto de atributos da relação, com a propriedade de para quaisquer 2 tuplas da relação não terem as mesmascombinações de valores para esses atributos é chamado de superchave da relação.
Uma superchave especifica uma restrição de unicidade de tupla, na qual duas tuplas distintas, não podem ter o mesmo valor para o conjunto de atributos que forma asuperchave.
Exemplo, seja a relação:
Aluno(RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso)
Existem algumas superchaves nessa relação, ou seja, existem subconjuntos dos atributos da relação Aluno que garantem unicidade de tupla da relação ( você, leitor,sinta-se à vontade para verificar essa afirmação!):
1. (RA, titulo_eleitor)2. (RA, titulo_eleitor, #RG)3. (RA, titulo_eleitor, #RG, OrgaoEmissorRG)4. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome)
5. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo)6. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade)7. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso)8. (RA, #RG)
9. (RA, #RG, OrgaoEmissorRG)10. (RA, #RG, OrgaoEmissorRG, nome)11. (RA, #RG, OrgaoEmissorRG, nome, sexo)12. (RA, #RG, OrgaoEmissorRG, nome, sexo, idade)13. (RA, #RG, OrgaoEmissorRG, nome, sexo, idade, curso)
14. (RA, OrgaoEmissorRG)15. (RA, OrgaoEmissorRG, nome)16. (RA, OrgaoEmissorRG, nome, sexo)17. (RA, OrgaoEmissorRG, nome, sexo, idade)
18. (RA, OrgaoEmissorRG, nome, sexo, idade, curso)19. (RA, nome)20. (RA, nome, sexo)21. (RA, nome, sexo, idade)22. (RA, nome, sexo, idade, curso)
23. (RA, sexo)24. (RA, sexo, idade)25. (RA, sexo, idade, curso)26. (RA, idade)27. (RA, idade, curso)
28. (RA, curso)29. (titulo_eleitor, #RG)30. (titulo_eleitor, #RG, OrgaoEmissorRG)31. (titulo_eleitor, #RG, OrgaoEmissorRG, nome)
32. (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo)33. (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade)34. (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso)35. (titulo_eleitor, OrgaoEmissorRG)36. (titulo_eleitor, OrgaoEmissorRG, nome)
37. (titulo_eleitor, OrgaoEmissorRG, nome, sexo)38. (titulo_eleitor, OrgaoEmissorRG, nome, sexo, idade)39. (titulo_eleitor, OrgaoEmissorRG, nome, sexo, idade, curso)40. (titulo_eleitor, nome)41. (titulo_eleitor, nome, sexo)
42. (titulo_eleitor, nome, sexo, idade)43. (titulo_eleitor, nome, sexo, idade, curso)44. (titulo_eleitor, sexo)45. (titulo_eleitor, sexo, idade)
46. (titulo_eleitor, sexo, idade, curso)47. (titulo_eleitor, idade)48. (titulo_eleitor, idade, curso)49. (titulo_eleitor, curso)50. (#RG, OrgaoEmissorRG, nome)
51. ( #RG, OrgaoEmissorRG, nome, sexo)52. ( #RG, OrgaoEmissorRG, nome, sexo, idade)53. ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso)54. ( #RG, OrgaoEmissorRG, nome)55. ( #RG, OrgaoEmissorRG, nome, sexo)
56. ( #RG, OrgaoEmissorRG, nome, sexo, idade)57. ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso)58. ( #RG, OrgaoEmissorRG, sexo)59. ( #RG, OrgaoEmissorRG, sexo, idade)
60. ( #RG, OrgaoEmissorRG, sexo, idade, curso)
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 35/67
61. ( #RG, OrgaoEmissorRG, idade)62. ( #RG, OrgaoEmissorRG, curso)63. (RA)64. (titulo_eleitor)65. (#RG, OrgaoEmissorRG)
Na realidade, talvez tenha esquecido alguma combinação de atributos que garanta a unicidade também, portanto, talvez ainda não estejam listadas todas as superchavesda relação Aluno.
Se você localizar alguma outra superchave favor informar!
Um outro conceito importante é o de Chave Candidata. Uma chave candidata é definida como sendo uma superchave mínima, ou seja, uma superchave da qual não
poderemos retirar sequer um atributo sob pena de não garantir mais unicidade de tupla.
Seguindo no exemplo anterior, podemos observar que, na maioria dos casos, se retirarmos algum(ns) atributo(s) da superchave ainda mantemos a propriedade degarantir a unicidade de tupla.
Vejamos, vou verificar as duas primeiras superchaves, siga o mesmo raciocínio para as demais superchaves:
1. (RA, titulo_eleitor)(RA) retirando titulo_eleitor ----- Existe alguma superchave que é formada apenas por RA? Sim existe, a superchave 63, então a superchave 1 não ésuperchave mínima, pois mesmo retirando algum atributo permanece com a propriedade de garantir unicidade de tupla.(titulo_eleitor) retirando RA ------Existe alguma superchave que é formada apenas por titulo_eleitor? Sim existe, a superchave 64, então a superchave 1
não é superchave mínima, pois mesmo retirando algum atributo permanece com a propriedade de garantir unicidade de tupla.2. (RA, titulo_eleitor, #RG)
(RA, titulo_eleitor)----- Existe alguma superchave que é formada apenas por RA e titulo_eleitor? Sim existe, a superchave 1, então a superchave 2 não ésuperchave mínima.(RA, #RG)----- Existe alguma superchave que é formada apenas por RA e #RG? Sim existe, a superchave 8,então a superchave 2 não é superchave
mínima.(RA)----- Existe alguma superchave que é formada apenas por RA? Sim existe, a superchave 63,então a superchave 2 não é superchave mínima.
3. (RA, titulo_eleitor, #RG, OrgaoEmissorRG)4. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome)5. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo)
6. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade)7. (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso)8. (RA, #RG)9. (RA, #RG, OrgaoEmissorRG)
10. (RA, #RG, OrgaoEmissorRG, nome)11. (RA, #RG, OrgaoEmissorRG, nome, sexo)12. (RA, #RG, OrgaoEmissorRG, nome, sexo, idade)13. (RA, #RG, OrgaoEmissorRG, nome, sexo, idade, curso)14. (RA, OrgaoEmissorRG)
15. (RA, OrgaoEmissorRG, nome)16. (RA, OrgaoEmissorRG, nome, sexo)17. (RA, OrgaoEmissorRG, nome, sexo, idade)18. (RA, OrgaoEmissorRG, nome, sexo, idade, curso)19. (RA, nome)
20. (RA, nome, sexo)21. (RA, nome, sexo, idade)22. (RA, nome, sexo, idade, curso)23. (RA, sexo)
24. (RA, sexo, idade)25. (RA, sexo, idade, curso)26. (RA, idade)27. (RA, idade, curso)28. (RA, curso)
29. (titulo_eleitor, #RG)30. (titulo_eleitor, #RG, OrgaoEmissorRG)31. (titulo_eleitor, #RG, OrgaoEmissorRG, nome)32. (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo)33. (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade)
34. (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso)35. (titulo_eleitor, OrgaoEmissorRG)36. (titulo_eleitor, OrgaoEmissorRG, nome)37. (titulo_eleitor, OrgaoEmissorRG, nome, sexo)
38. (titulo_eleitor, OrgaoEmissorRG, nome, sexo, idade)39. (titulo_eleitor, OrgaoEmissorRG, nome, sexo, idade, curso)40. (titulo_eleitor, nome)41. (titulo_eleitor, nome, sexo)42. (titulo_eleitor, nome, sexo, idade)
43. (titulo_eleitor, nome, sexo, idade, curso)44. (titulo_eleitor, sexo)45. (titulo_eleitor, sexo, idade)46. (titulo_eleitor, sexo, idade, curso)
47. (titulo_eleitor, idade)48. (titulo_eleitor, idade, curso)49. (titulo_eleitor, curso)50. (#RG, OrgaoEmissorRG, nome)51. ( #RG, OrgaoEmissorRG, nome, sexo)
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 36/67
52. ( #RG, OrgaoEmissorRG, nome, sexo, idade)53. ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso)54. ( #RG, OrgaoEmissorRG, nome)55. ( #RG, OrgaoEmissorRG, nome, sexo)
56. ( #RG, OrgaoEmissorRG, nome, sexo, idade)57. ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso)58. ( #RG, OrgaoEmissorRG, sexo)59. ( #RG, OrgaoEmissorRG, sexo, idade)60. ( #RG, OrgaoEmissorRG, sexo, idade, curso)
61. ( #RG, OrgaoEmissorRG, idade)62. ( #RG, OrgaoEmissorRG, curso)63. (RA) ----- Não existe outro atributo para ser retirado! Sendo assim, a superchave 63 é uma superchave mínima!64. (titulo_eleitor) ----- Não existe outro atributo para ser retirado! Sendo assim, a superchave 64 é uma superchave mínima!65. (#RG, OrgaoEmissorRG)
(#RG) ----- Existem números de RG iguais emitidos por órgãos emissores de estados diferentes, portanto se retirarmos OrgaoEmissorRG a propriedadede unicidade não é mantida. Sendo assim, a superchave 65 é uma superchave mínima!(OrgaoEmissorRG) ----- Os órgãos emissores emitem diversos números de RG, sendo assim existem distintos alunos com o mesmo órgão emissor,portanto se retirarmos #RG a propriedade de unicidade não é mantida. Sendo assim, a superchave 65 é uma superchave mínima!
Observe que apesar da relação aluno ter pelo menos 65 superchaves, possui apenas 3 chaves candidatas: {(RA), (titulo_eleitor), (#RG, OrgaoEmissorRG)}.
Finalmente, chegamos ao conceito de Chave Primária. O conceito de chave primária é bastante similar ao conceito de Identificador do modelo ER. A chave primária é oconjunto de atributos escolhidos para garantir a unicidade da relação. A chave primária deve pertencer, obrigatoriamente, ao conjunto das chaves candidatas da relação.
A rigor, podemos escolher qualquer uma das chaves candidatas para torná-la a chave primária da relação, mas podemos utilizar alguns critéiros para "desempatar", por
exemplo:
- escolher a chave candidata com menor número de atributos. No exemplo, teríamos ainda um empate entre RA e titulo_eleitor, ambas chaves candidatas simples(formadas por um único atributo).
- escolher a chave candidata mais representativa, semanticamente falando, para a relação. No exemplo apresentado, o RA significa Registro Academico e parece ser achave candidata mais representativa quando se fala em alunos.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 37/67
3.5 Restrição de Integridade de Entidade
Estabelece que nenhum valor de chave primária pode ser um valor nulo (null).
As restrições de chave primária e de integridade de entidade são especificadas na própria relação.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 38/67
3.6 Restrição de Integridade Referencial e Chave Estrangeira
A restrição de integridade referencial é classificada entre duas relações e é usada para manter a consistência entre as tuplas nas duas relações.
A definição de integridade referencial está intrinsecamente relacionada ao conceito de chave estrangeira (FK - foreign key).
Considere R1 e R2, duas relações. Um conjunto de atributos FK de R1 é uma chave estrangeira de R1, que faz referência ou se refere à relação R2, se satisfizer asduas regras:
1. os atributos de FK tem o(s) mesmo(s) domínio(s) que os atributos da chave primária (PK - primary key) de R2; diz-se que atributos de FK fazem referência ouse referem à relação R2.
2. um valor de FK em uma tupla t1 de R1 ou ocorre como valor de PK para alguma tupla t2 de R2 ou é null. Então t1[FK]=t2[PK], e dizemos que a tupla t1 fazreferência à tupla t2.
Se essas 2 condições forem asseguradas, então uma restrição de integridade referencial é garantida.
Figura 1. Restrições de Integridade Referencial no esquema de um BD relacional
Na figura 1 podemos identificar as chaves estrangeiras e as relações referenciadas no esquema do BD Empresa. Na tabela EMPREGADO podemos perceber oatributo SuperSSN, que mantém o SSN do funcionário que é supervisor, neste caso temos uma chave estrangeira (FK) definida dentro da relação que está sendoreferenciada. Ou seja, temos uma chave estrangeira recursiva representando um autorelacionamento do modelo entidade-relacionamento. Existe uma outra FK, DNO,que referencia a relação DEPARTAMENTO, representando onde o funcionário está alocado.
Em DEPARTAMENTO encontramos a FK GerSSN que referencia a relação EMPREGADO, para manter o gerente do departamento. Em PROJETO, encontramosDNUM que referencia a tabela DEPARTAMENTO para registrar qual o departamento que controla o projeto. Em DEPENDENTE temos a FK ESSN referenciandoa relação EMPREGADO, para informar quem é o responsável pelo dependente, e que auxilia o atributo Nome_Dependente a formar a chave primária da relação. Além
dessas, temos as relações que expressam relacionamentos (TRABALHA_EM) e atributos mulltivalorados (DEPTO_LOCALIZACOES). TRABALHA_EM tem suachave primária formada pelas FKs ESSN , referenciando EMPREGADO, e PNO, referenciando PROJETO, para identificar os projetos nos quais os funcionáriostrabalham. DEPTO_LOCALIZACOES também tem uma FK auxiliando na chave primária (DNumero, referenciando DEPARTAMENTO) para que possam serdefinidas várias localizações para um mesmo departamento.
Observe que através das chaves estrangeiras podemos relacionar as diversas relações e a garantia de integridade referencial irá assegurar que sempre que uma tupla forreferenciada, certamente ela existe.
Em outros termos, apenas podemos atribuir um valor para uma chave estrangeira se esse valor existir como valor do atributo chave primária em alguma tupla da relaçãoreferenciada por ela.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 39/67
3.7 Indicação de Leitura Complementar
Explicações detalhadas sobre o emprego do modelo relacional no processo de projeto lógico e físico de banco de dados podem ser encontradas em [ELMASRI 2005]E [SILBERCHATZ 2006].
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 40/67
3.8 Material Complementar
Slides utilizados na videoaula sobre Modelo Relacional.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 41/67
4 Projeto de Banco de Dados Relacional
No processo de desenvolvimento de um sistema de banco de dados, conforme apresentado na figura 1, desenvolvemos na disciplina a etapa de Projeto Conceitual(consideramos que o levantamento e análise de requisitos já estariam prontos, portanto partimos dos Requisitos de Dados). Como fruto da etapa de Projeto Conceitualobtivemos um esquema conceitual do banco de dados segundo o modelo de dados entidade-relacionamento e o expressamos através de um diagrama entidade-relacionamento (DER). A partir desse diagrama passaremos a desenvolver o projeto lógico do banco de dados. Nessa disciplina utilizaremos o modelo de dados
relacional para nos apoiar nessa etapa. Portanto, ao final da etapa de Projeto Lógico obteremos um esquema lógico relacional do banco de dados.
Nesse capítulo do livro virtual será apresentado o procedimento a ser utilizado para obter o esquema lógico relacional a partir de um esquema conceitual representado
pelo DER.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 42/67
4.1 Esquema Conceitual do banco de dados Empresa
Nesse capítulo utilizaremos o esquema conceitual de um banco de dados de empresa, apresentado na figura 1, como exemplo para obtenção do esquema lógico.
Figura 1. Esquema conceitual do banco de dados Empresa [extraida de ELMASRI 2005]
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 43/67
4.2 Mapeamento dos Conjuntos de Entidades Regulares (ou Fortes)
Lembrando: o que é um conjunto de entidades regulares? São aqueles conjuntos de entidades que possuem atributos suficientes para formar um identificador para o
conjunto de entidades.
No exemplo, quem são os conjuntos de entidades regulares? São aqueles representados por um retângulo com linha simples, ou seja: Empregado, Departamento eProjeto.
Como mapeá-los?
Para cada conjunto de entidades regulares criar uma relação com nome igual ou similar ao do conjunto de entidade incluindo todos os atributos simples e monovalorados
desse conjunto de entidades. Assinalar como chave primária o conjunto de atributos identificador do conjunto de entidades. Cabe aqui, efetuar um estudo das chaves doconjunto de entidades, efetuando um levantamento sobre as superchaves da relação e as chaves candidatas culminando na escolha consciente da chave primária da
relação. É possível que nesse momento você perceba a necessidade de revisar o projeto conceitual para assinalar um identificador mais apropriado.
O que fazer se o conjunto de entidades possuir algum atributo composto?
Você deve acrescentar à relação criada apenas os atributos componentes do atributo composto que sejam simples e monovalorados, recursivamente. Ou seja, busque
sempre os atributos simples.
E quanto aos atributos multivalorados?
Você os deixa, por enquanto, pois descreveremos uma etapa apenas para tratar de atributos dessa natureza.
No exemplo, seriam criadas as seguintes relações, apresentadas na figura 1:
Figura 1. Esquema lógico relacional após mapeamento dos conjuntos de entidades regulares.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 44/67
4.3 Mapeamento dos Conjuntos de Entidades Fracas
Lembrando: o que é um conjunto de entidades fracas? É um conjunto de entidades que não possui atributos suficientes para definir um identificador para o conjunto de
entidades. Todos os conjuntos de entidades fracas devem ter pelo menos o conjunto de relacionamento Identidade que o associa ao seu conjunto de entidadesproprietária. Caso a cardinalidade expressa no conjunto de relacionamento Identidade leve a múltiplas ocorrências de entidades fracas para cada entidade proprietária
(1:N ou N:M), então existe a necessidade de definição de um identificador parcial no conjunto de entidades fracas.
Como mapear esses conjuntos de entidades fracas?
O mapeamento é similar ao explicado no capítulo anterior, ou seja, devemos criar uma relação para cada conjunto de entidade fraca incluindo seus atributos simples e
monovalorados. Todos os comentários acerca dos atributos compostos e multivalorados também se aplicam aqui.
A diferença está na determinação do atributo chave primária, pois nesse caso, a chave primária da relação será uma chave estrangeira que referencia a relação que
representa o conjunto de entidades proprietária. Caso tenha sido definido algum identificador parcial, esse deve também fazer parte da chave primária da nova relação.
No exemplo temos o conjunto de entidades Dependente associado ao conjunto de entidades proprietárias Empregado pelo conjunto de relacionamento Identidade
Dependente_de, cuja cardinalidade é 1:N, portanto houve necessidade da definição de uma identificador parcial, o atributo Nome (em Dependente), conformeapresentado na figura 1.
Figura 1. Extrato do esquema conceitual do BD Empresa - Conjunto de Entidades Fracas com Identidade e Proprietária.
O mapeamento desse conjunto de entidades gerou mais uma relação em nosso esquema relacional, conforme apresentado na figura 2.
Figura 2. Esquema lógico do banco de dados Empresa após o mapeamento dos conjuntos de entidades fracas.
Observe, na figura 2, que ESSN e Nome_Dependente formam a chave primária composta da relação Dependente. O ESSN é uma chave estrangeira que referencia a
relação empregado. Essa chave estrangeira aparece em decorrência do mapeamento do conjunto de relacionamento Identidade Dependente_de.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 45/67
4.4 Mapear Conjuntos de Relacionamentos Binários 1:1
Lembrando: o que são conjuntos de relacionamentos binários ou de grau 2? São conjuntos de relacionamento que possuem apenas 2 conjuntos de entidades
participando do conjunto de relacionamento.
E quanto a dizer que é 1:1? Isto se refere à restrição de cardinalidade imposta às entidades participantes do relacionamento, no caso, se considerarmos a cardinalidade
1:1 no conjunto de relacionamento Gerencia entre os conjuntos de entidade Empregado e Departamento, apresentado na figura 1, dizemos que uma entidadede Empregado pode se relacionar a uma, e só uma, entidade de Departamento pelo conjunto de relacionamento Gerencia e vice-versa.
Segundo [ELMASRI 2005], existem 3 abordagens para o mapeamento de conjuntos de relacionamentos binários 1:1. Vamos discutí-las neste capítulo, porém
salientando que a abordagem 1 é a mais seguida e deve ser preferencialmente adotada, exceto se houver ocorrências específicas que justifiquem a adoção de outra
abordagem conforme será explicado a seguir.
Figura 1. Extrato do esquema conceitual do BD Empresa - Conjunto de relacionamento binário 1:1
Abordagem 1: Escolha da chave estrangeira
Você deve escolher um dos conjuntos de entidade participantes para receber a chave estrangeira que servirá como ligação entre as relações.
Mas, qual delas escolher? A rigor você pode escolher qualquer uma delas, porém é recomendado que verifique se um dos conjuntos de entidade possui restrição de
participação total pois nesse caso é melhor que esse conjunto de entidade receba a chave estrangeira.
Por que? Porque a chave estrangeira será um atributo a mais nessa relação e se a restrição de participação é total isso implica que esse valor sempre deverá ser
preenchido (restrição not null).
Caso ambas as restrições sejam parciais, a escolha pode ser arbitrária (uni, duni, tê, salamê, mingue...) , ou seja, escolha qualquer das relações e coloque a chave
estrangeira referenciando a outra relação. Caso existam atributos no conjunto do relacionamento esses atributos (simples e monovalorados) devem ser incluidos na
mesma relação que receberá a chave estrangeira.
Em nosso exemplo, como pode ser observado na figura 1, encontramos a restrição de participação total do lado de Departamento no conjunto de relacionamentoGerencia, isso nos auxilia na escolha da relação (DEPARTAMENTO) que irá receber o atributo chave estrangeira que indicará qual dos funcionários é o gerente do
departamento. Observe que o atributo DataInicio também deve ser inserido na relação DEPARTAMENTO acompanhando a decisão de onde colocar a chave
estrangeira.
Analisemos o impacto de introduzir a chave estrangeira na relação EMPREGADO, que possui restrição de participação parcial no conjunto de relacionamentos
Gerencia pois nem todo empregado é gerente de departamento. Isso poderia ser feito porém o custo disso seria a introdução de valores null para esse atributo em todasas tuplas de empregado que não fossem gerentes (o que, obviamente, deve ser em número muito maior do que aqueles que são gerentes!).
Outra possibilidade, que não é recomendada a menos que se justifique plenamente, seria o de introduzir a chave estrangeira em ambas as relações, porém, além de
grande número de valores null como explicado acima, poderíamos ter problemas de consistência na atualização dessas tabelas. A justificativa mais plausível para essa
solução é a necessidade (muito forte!) de facilitar a navegação entre as tabelas. Isso só se justificaria se fossem previstas consultas muito frequentes que exigissem talnavegação.
Podemos observar nossa nova versão do esquema lógico relacional do banco de dados Empresa na figura 2, onde estão salientados os atributos acrescentados narelação DEPARTAMENTO para refletir o conjunto de relacionamentos Gerencia. O atributo GerSSN é a chave estrangeira que referencia a relação EMPREGADO,
portanto, esse atributo deve pertencer ao mesmo domínio do atributo chave de EMPREGADO, o atributo SSN.
Figura 2. Esquema lógico relacional do banco de dados Empresa após etapa de mapeamento dos conjuntos de relacionamentos binários 1:1
Abordagem 2: Opção da relação unificada (ou relacionamento incorporado)
Essa abordagem prevê a incorporação dos conjuntos de entidade e do conjunto de relacionamento em uma só relação. Essa opção pode ser interessante quando ambas
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 46/67
as restrições de participação são totais.
Se fosse esse o caso em nosso exemplo, deveríamos criar uma relação EmpregadoGerenciaDepartamento com todos os atributos de Empregado, todos os atributos deDepartamento e o atributo do conjunto de relacionamento. Essa tabela substituiria as tabelas EMPREGADO e DEPARTAMENTO. É muito fácil perceber que essa é
uma abordagem que não deve ser adotada trivialmente.
Abordagem 3: Opção Referência Cruzada (ou relação de relacionamento)
Nessa abordagem deve ser gerada uma nova relação com as chaves estrangeiras para referenciar as relações envolvidas no conjunto de relacionamento e o atributopresente no relacionamento. Essa abordagem deve ser evitada pois provoca, na maioria das vezes sem justificativas plausíveis, um acréscimo de tempo na execução de
consultas pois envolve o uso da operação mais cara para o SGBD - a junção - como veremos nas unidades que tratam de linguagens de banco de dados.
Essa nova relação gerada é chamada de Relação de Relacionamento (ou tabela de busca) pois cada tupla representa uma instância do relacionamento. Essa é a
solução para os conjuntos de relacionamentos binários N:M e para os de grau >2 (n-ários), como veremos nos próximos capítulos.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 47/67
4.5 Mapear Conjuntos de Relacionamentos Binários 1:N
Retornando ao exemplo que estamos utilizando, temos os conjuntos de relacionamentos binários 1:N - Supervisão, Trabalha_Para e Controla - representados na figura
1.
Perceba que temos ainda o conjunto de relacionamento Identidade Dependente_De que também é 1:N, porém nós já o mapeamos quando mapeamos o conjunto de
entidades fracas, lembra? Você não deve mapeá-lo novamente!
Lembrando: o que são conjuntos de relacionamentos binários 1:N? Considere o conjunto de relacionamento binário Controla entre DEPARTAMENTO e PROJETO,representado na figura 1, qual a semântica da restrição de cardinalidade 1:N? A semântica é que 1 departamento pode controlar diversos projetos (N) enquanto 1
projeto pode ser controlado por apenas 1 departamento.
Figura 1. Extrato do esquema conceitual do BD Empresa com os conjuntos de relacionamentos 1:N ou N:1.
Como mapear esses conjuntos de relacionamentos?
O mapeamento desses conjuntos de relacionamentos se faz por chave estrangeira. Mas em que conjunto de entidade devemos introduzir a chave estrangeira? Vamos
raciocinar utilizando o conjunto de relacionamentos Controla, se colocarmos a chave estrangeira em DEPARTAMENTO o que irá acontecer? A restrição de
cardinalidade nos diz que 1 departamento pode se relacionar com várias entidades de PROJETO, correto? Então, vejamos a figura 2.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 48/67
Figura 2. Tentativa fracassada de mapeamento do conjunto de relacionamento 1:N - Controla
Ou seja, não devemos inserir a chave estrangeira em DEPARTAMENTO! Devemos inserir na relação PROJETO, então? A resposta é sim! Vejamos a figura 3 paracomprovar!
Figura 3. Mapeamento correto do conjunto de relacionamento 1:N - Controla
Pode observar, na figura 3, que todas as instâncias de PROJETO são únicas (não há valores de chave repetidos) e a informação de qual é o departamento controlador
também está toda representada!
Anote a regra:
Para mapear um conjunto de relacionamento 1:N, localizar a relação que representa o tipo de entidade do lado N do conjunto de relacionamento e inserir nessa relaçãoa chave estrangeira da relação do lado 1. Essa é a regra pois cada instância do lado N se relaciona a apenas uma instância do lado 1.
Como ficou nosso esquema lógico do banco de dados Empresa? Vejamos o esquema lógico atual na figura 4.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 49/67
Figura 4. Esquema lógico relacional do banco de dados EMPRESA após mapeamento de conjuntos de relacionamentos binários 1:N
Algumas observações importantes que você pode conferir na figura 4:
O conjunto de relacionamento Supervisão em EMPREGADO, é um autorelacionamento (ou relacionamento recursivo) porisso o mapeamento desse conjunto derelacionamento foi expressa na própia relação EMPREGADO através da chave estrangeira, SuperSSN, que referencia a tabela EMPREGADO. Esse atributo
mantém quem é o supervisor imediato de cada instância da relação. Mas como chegamos a conclusão que deveríamos manter o SSN do supervisor e não dosupervisionado? Fácil, observando os papéis que as entidades empregado fazem no relacionamento (anotadas em cada aresta) e as respectivas cardinalidades.
Perceba que foi mantida a regra geral para o mapeamento, inserimos a chave estrangeira no lado N do conjunto de relacionamentos, ou seja, trouxemos o SSN
do supervisor para o lado de quem é supervisionado!A relação EMPREGADO possui também o atributo chave estrangeira DNO que referncia o DEPARTAMENTO onde o funcionário trabalha.
Alternativa de mapeamento:
Podemos adotar a Tabela de Relacionamento (ou Tabela de Busca) como uma solução alternativa de mapeamento caso existam poucas tuplas da relação querecebe a chave estrangeira participando do conjunto de relacionamentos, pois nesse caso, adotando a alternativa padrão incluiríamos muitos nulos. Essa solução, como
já explicado anteriormente, aplica-se no caso de conjuntos de relacionamentos binários N:M e nos de grau maior que 2 (n-ários). No próximo capítulo será explicado
como gerar essas Tabelas de Relacionamento.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 50/67
4.6 Mapear Conjuntos de Relacionamentos Binários N:M
Em nosso exemplo encontramos um conjunto de relacionamentos N:M - Trabalha_Em - entre os conjuntos de entidades EMPREGADO e PROJETO para denotar que
um empregado pode trabalhar em vários projetos (M) e que um projeto pode ter trabalhando nele diversos empregados (N), confira na figura 1.
Figura 1. Extrato do esquema conceitual do BD Empresa com um conjunto de relacionamento binário M:N
Para conjuntos de relacionamentos M:N adotamos a criação de uma Tabela de Relacionamento (ou Tabela de Busca), como já foi mencionado em capítulos anteriores.
Como construimos essa Tabela de Relacionamento?
Devemos criar uma relação para representar o conjunto de relacionamento. Seguindo o exemplo, devemos criar uma relação Trabalha_Em, inserir duas chaves
estrangeiras - ESSN e PNO - que respectivamente irão referenciar as tabelas EMPREGADO e PROJETO. Devemos acrescentar o atributo presente no conjunto de
relacionamentos - horas.
Como podemos definir uma chave primária para essa nova relação?
A chave primária da relação deve ser composta pelos atributos que são chaves estrangeiras - ESSN e PNO.
Observações Importantes:
Essa é a única situação de mapeamento de conjuntos de relacionamentos binários em que as chaves estrangeiras passam a fazer parte da chave primária darelação que a recebe.
A utilização da Tabela de Relacionamento para conjuntos de relacionamentos binários 1:1 e 1:N não são incentivados mas podem ser particularmente úteis
quando a relação que recebe a chave estrangeira tem poucas entidades que participam efetivamente do relacionamento para evitar o excesso de valores null natabela. Nesses casos, a chave primária da Tabela de Relacionamentos será apenas uma das chaves estrangeiras (e não as 2 como nos conjuntos de
relacionamentos M:N).
Nosso esquema lógico relacional após o mapeamento do conjunto de relacionamentos Trabalha_Em é apresentado na Figura 2.
Figura 2. Esquema lógico relacional do BD Empresa após o mapeamento dos conjuntos de relacionamentos N:M.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 51/67
4.7 Mapear Conjuntos de Relacionamentos n-ários (grau > 2)
Os conjuntos de relacionamentos de grau maior que 2 se caracterizam por ter mais do que dois conjuntos de entidades participando nele.
A complexidade do conjunto de relacionamentos aumenta de acordo com o número de conjuntos de entidades participantes, por exemplo, a determinação das
restrições de cardinalidades em um conjunto de relacionamentos ternários (com 3 conjuntos de entidades participantes) devem ser obtidas efetuando a análise de dois
conjuntos de entidades contra o terceiro conjunto de entidade.
Nosso exemplo não possui ternários, portanto vamos considerar a seguinte situação: queremos representar a situação de fornecimento de lotes de peças para projetos.
Suponha que tenhamos obtido o esquema conceitual mostrado na figura 1 para representar essa situação.
Figura 1. O conjunto de relacionamento ternário FORNECE sem as restrições de cardinalidade
Como podemos descobrir as restrições de cardinalidade desse conjunto de relacionamentos ternários? Devemos fazer as seguintes questões:
Dados 1 projeto e 1 lote quantos fornecedores podem fornecer o lote de peças para aquele projeto?
Dados 1 lote e 1 fornecedor quantos projetos podem receber o fornecimento do lote de peças daquele fornecedor?Dados 1 fornecedor e 1 projeto quantos lotes de peças podem ser fornecidos por aquele fornecedor para aquele projeto?
Dependendo dessas respostas atribuimos os valores 1 ou N ou M em cada aresta. Consideramos que N e M podem assumir quaisquer valores maiores do que 1.
Em função do aumento de complexidade envolvida em n-ários, recomenda-se bastante firmemente que sejam buscadas alternativas de modelagem se você se depararcom um conjunto de relacionamentos com grau maior do que 3. Procure ter em mente que o maior grau recomendado é o grau 3.
Dependendo das restrições de cardinalidade indicadas no conjunto de relacionamentos n-ários você deverá optar por uma forma de mapeá-lo:
Caso todas as restrições de cardinalidade sejam múltiplas (N:N:N) você deve utilizar uma Tabela de Relacionamento onde a chave primária é composta por
todas as chaves estrangeiras inseridas na nova relação e inserir nela também os atributos simples e monovalorados presentes no conjunto de relacionamento.Supondo que a resposta a cada uma das questões anteriores tenham sido: vários (N), a restrição de cardinalidade em Fornece é N:N:N conforme apresentada na
figura 2.
Figura 2. O conjunto de relacionamento ternário FORNECE com as restrições de cardinalidade N:N:N
O mapeamento do conjunto de relacionamentos Fornece seria a criação da relação FORNECE com as chaves estrangeiras: Fornecedor, Projeto, Lote referindo-serespectivamente às relações FORNECEDOR, PROJETO e LOTE. Além delas incluiríamos o atributo Quantidade presente no relacionamento Fornece. A chave
primária da relação seria composta pelas três chaves estrangeiras.
Caso alguma das restrições de cardinalidade seja 1 (1:N:N) ou (1:1:N) ou (1:1:1) então a chave estrangeira referente àquele conjunto de entidades que possui
restrição de cardinalidade 1 não deve entrar na chave primária. No último caso citado (1:1:1) apenas uma delas seria chave primária.
No exemplo acima vamos supor que dado um projeto e um lote podemos encontrar apenas um fornecedor, ou seja, a restrição de cardinalidade desse conjunto de
relacionamento seria 1:N:N, conforme apresentado na figura 3.
Figura 3. O conjunto de relacionamento ternário FORNECE com as restrições de cardinalidade 1:N:N
Nesse caso, o mapeamento levaria à construção de uma relação FORNECE com as chaves estrangeiras referentes a cada relação participante e o atributo dorelacionamento, porém a chave primária seria composta apenas pelas chaves estrangeiras Projeto e Lote.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 52/67
Observação Importante: um conjunto de relacionamento Identidade (que associa um conjunto de entidades fracas à sua proprietária) pode ser de grau maior que 2,porém o mapeamento segue o mesmo procedimento adotado em casos de conjuntos de relacionamento Identidade de grau 2.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 53/67
4.8 Mapear atributos multivalorados
Em nosso exemplo encontramos o atributo Localizações em DEPARTAMENTO que é definido como multivalorado.
O que significa mesmo ser multivalorado? Significa que uma entidade do mundo real pode receber diversos valores para aquele atributo. Em nosso exemplo significa que
um único departamento pode estar fisicamente distribuido em diversas localizações.
Existem algumas alternativas para o mapeamento de atributos multivalorados:
gerar uma nova tabela para receber os valores multivalorados
Alternativa mais bem aceita e utilizada. É a alternativa recomendada quando desejamos poder armazenar quantos valores forem necessários para o atributo
multivalorado. Consiste em gerar uma nova relação, essa relação deve conter o atributo multivalorado (ou os componentes simples e monovalorados dele casoseja um atributo composto) mais uma chave estrangeira que referencia a tabela que representa o conjunto de entidades que originalmente continha o atributo
multivalorado. A chave primária dessa nova relação é composta pelos atributos descritores do multivalorado e pela chaves estrangeira.
incluir o atributo na chave primária da relação que o contém
Solução bastante adotada quando o atributo multivalorado está presente em um conjunto de relacionamentos ou quando se encontra em conjuntos de entidades
com bem poucos atributos. Consiste em tornar o atributo multivalorado um componente da chave primária da relação que representa o conjunto de entidades que
originalmente o continha.
incluir, na relação que o contém, um conjunto de atributos equivalente ao número de valores que podemos associar a uma única entidade
Essa solução só se aplica caso conheçamos qual o número de possíveis valores esperados para aquele atributo multivalorado. Esse número deve ser conhecido e
pequeno (até 3 ocorrências se o atributo multivalorado for simples). O mapeamento consiste em acrescentar um conjunto de atributos equivalente ao número deocorrências esperadas na relação que representa o conjunto de entidades que originalmente continha o atributo multivalorado.
Em nosso exemplo adotamos a primeira alternativa, ou seja, geramos uma nova relação DEPTO_LOCALIZACOES com o atributo chave estrangeira DNumero quereferencia a relação DEPARTAMENTO e o atributo DLocalizacao que é o descritor do atributo multivalorado. Ambos os atributos fazem parte da chave primária
dessa nova relação, conforme apresentado na figura 1.
Figura 1. Esquema lógico relacional do BD Empresa após o mapeamento do atributo multivalorado
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 54/67
4.9 Esquema Lógico Relacional do banco de dados Empresa
Ao final das etapas descritas nos capítulos anteriores, com exceção daquele que tratou de conjuntos de relacionamentos n-ários, o projeto lógico relacional de nosso
exemplo chega ao fim e podemos então gerar o esquema lógico relacional completo para o banco de dados Empresa, assinalando as chaves estrangeiras e a quem elasreferenciam. O esquema lógico relacional completo é apresentado na figura 1. As setas partem das chaves estrangeiras e apontam para as relações referenciadas por
elas.
Figura 1. Esquema lógico relacional para o banco de dados Empresa
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 55/67
4.10 Material Complementar
Slides da videoaula sobre mapeamento DER para relacional.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 56/67
4.11 Exercício complementar
Obter o esquema lógico relacional a partir do esquema conceitual gerado no exercício do capítulo 2.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 57/67
5 Dependências Funcionais Dependências Multivaloradas e Normalização
Neste capítulo, vamos explorar os conceitos sobre dependências funcionais, dependências multivaloradas e o impacto desses conceitos sobre o processo de
normalização do esquema relacional que obtivemos.
Mas, para que serve a Normalização?
A Normalização, na etapa em que nos encontramos de desenvolvimento de um sistema de banco de dados, serve para validar o nosso esquema lógico relacional.
Ou seja, precisamos ter algum instrumento que nos auxilie a verificar se o esquema obtido não possui algum problema que possa impactar negativamente na segurançado banco de dados. Esse instrumento é a normalização.
Existem abordagens, alternativas àquela que estamos empregando em nosso curso, que utilizam a normalização como ferramenta para obtenção do esquema lógico
relacional. Ou seja, essas abordagens partem do conjunto de dados obtidos nos requisitos do sistema e os organizam por intermédio do processo de normalização.
Não se assustem com o formalismo empregado para a definição das formas normais, pois passado o primeiro susto vocês perceberão que não é tão difícil como
imaginaram!
Preparados para mais uma etapa a ser vencida? Então avancemos!
Boa leitura!
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 58/67
5.1 Processo de Normalização
O processo de normalização pode envolver diversas formas normais, no entanto, nesta disciplina serão apresentadas apenas a Primeira Forma Normal (1FN), Segunda Forma Normal (2FN), Terceira Forma Normal (3FN), Forma Normal de Boyce-Codd (FNBC) e Quarta Forma Normal (4FN). Outras formas normais, para quem quiser se aprofundar, podem ser estudadas nos livros que constituem a bibliografia básica desta disciplina.
Um projeto de sistema de banco de dados, que parte de um conjunto de requisitos, com um bom projeto conceitual e um projeto lógico relacional adequado possui, normalmente, um esquema relacional na terceira forma normal.
O que isso significa?
Diz-se que um "bom" sistema de banco de dados relacional contém esquemas relação que atendem a, no mínimo, a terceira forma normal!
Então, pode-se deduzir que projetos de sistemas de banco de dados quando executados com cuidado encaminham a bons esquemas lógicos relacionais!
Porém, se for necessário efetuar uma re-engenharia de um sistema de banco de dados em atividade, modelado conforme qualquer modelo de dados, desejando-se obter ao final do processo um esquema relacional otimizado, no sentido de garantir questões de segurança dos dados, então um bom processo de normalização faz-se necessário!
O livro do Heuser traz uma boa idéia de como a normalização pode auxiliar esse processo de re-engenharia.
Nos próximos capítulos serão apresentadas as formas normais acima citadas e os conceitos de dependências funcionais e multivaloradas necessárias para o bom entendimento das mesmas.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 59/67
5.2 Dependências Funcionais
Alguns conceitos são necessários para o estudo adequado das formas normais. O primeiro dos conceitos é o de dependência funcional.
A aplicação desse conceito permite ao projetista do banco de dados retratar algumas regras de negócio que relacionam atributos de uma mesma relação.
Definição:
Se o valor de um conjunto de atributos A permite descobrir o valor de um outro conjunto B, dizemos que A determina funcionalmente B, ou que B depende de A.
Notação: A à B
Por exemplo, as pessoas que moram no Brasil sabem que para o envio de uma correspondência devem incluir o Código de Endereçamento Postal (CEP) da localidadedestino, assim como devem incluir o CEP da localidade origem (para o caso de não localizar o destinatário). Sabe-se mais: uma cidade pode conter diversos códigos de
endereçamentos, porém um CEP identifica uma, e somente uma, localidade no Brasil.
Essa informação é capturada utilizando o conceito de dependência funcional entre os atributos CEP e Cidade, por exemplo. Denota-se: CEP à cidade
Como garantir que em um sistema de banco de dados não possam ser incluidas duas localidades distintas com o mesmo CEP? O primeiro passo é descobrir que existetal interdependência! Nos próximos capítulos serão discutidas as soluções para garantia da integridade na base de dados.
Em resumo: Faz-se necessário identificar essas interdependências entre os atributos, identificando as dependências funcionais, para que se possa, na medida dopossível, garantir a integridade dos mesmos.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 60/67
5.3 Dependências Funcionais Parciais
Pode-se determinar as formas normais de um esquema relacional, tomando-se por referência apenas a chave primária da relação, porém, nesta disciplina será adotada a
abordagem de determinar a forma normal tomando por referência todas as chaves candidatas presentes na relação.
Ma o que é uma chave candidata mesmo? É uma superchave mínima!
Os atributos pertencentes a chaves candidatas são chamados de atributos primos.
Podem ser encontradas ambas as abordagens no livro de Elmasri e Navathe.
Sendo assim, a definição de uma dependência funcional parcial é a seguinte:
Se A for chave da relação e o valor de um subconjunto de atributos de A permite descobrir o valor de um outro conjunto B, dizemos que B possui dependência
funcional parcial em relação a A.
Ou seja, a dependência funcional parcial só tem sentido ser avaliada se existir alguma chave candidata composta. Nesse caso deve-se avaliar se algum subconjunto de
atributos pertencente à chave composta consegue determinar algum outro atributo na relação.
Por exemplo, considere a relação:
Matricula(RA, SiglaDisc, nome_aluno, descr_disciplina, média)
Considerando que a única chave candidata presente nessa relação é a chave composta por RA e SiglaDisc, faz-se a seguinte análise:
Para que se determine o nome do estudante, faz-se necessário conhecer ambos os valores dos atributos da chave? A resposta é NÃO!
Basta que se conheça o valor do RA, para que se conheça o nome do estudante. Isso significa que está presente, nesta relação, a dependência funcional:
RA à nome_aluno
Isto implica que existe uma dependência funcional parcial em relação à chave candidata da relação (RA, SiglaDisc), pois apenas parte da chave já determina o atributo
nome_aluno.
Continuando a análise percebe-se ainda que existem as seguintes dependências funcionais:
RA, SiglaDisc à média ok, depende da chave candidata completa;
SiglaDisc à descr_disciplina indica dependência funcional parcial.
Em resumo:
Caso decida-se manter a tabela matrícula como:
Matricula(RA, SiglaDisc, nome_aluno, descr_disciplina, média)
Como será possível garantir que não existam dois nomes de estudantes distintos associados ao mesmo registro acadêmico (RA), conforme a dependência funcionalidentificada (RA à nome_aluno)?
Ou ainda, como poderá ser garantido que não serão registradas mais de uma disciplina associadas à mesma Sigla, conforme a dependência funcional (SiglaDiscàdescr_disciplina)?
Nos capítulos seguintes serão apresentadas as soluções para que possam ser garantidas essas restrições de integridade identificadas nas regras de negócio.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 61/67
5.4 Dependências Funcionais Transitivas
Considere uma relação R, com os atributos X, Y, A, e as seguintes dependências funcionais válidas sobre R:
DF1: X à Y
DF2: Y à A
e não existe a DF3: Y à X (ou seja, Y não é primo)
Diz-se que A é transitivamente dependente de X, pois é possível obter seu valor a partir de Y e este, por sua vez, é determinado por X.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 62/67
5.5 Primeira Forma Normal - 1FN
Uma tabela está na 1FN se não contém tabelas aninhadas, ou seja, ela não deve conter atributos multivalorados e nem atributos compostos.
Um exemplo de uma tabela não-normalizada (ñn): Aluno(RA, nome, {(e-mail: login, domínio)}), onde {(e-mail: login, domínio)} implica que o atributo e-mail é multivalorado e composto por login e domínio.
Para transformar uma tabela ñn em uma tabela normalizada deve-se extrair os atributos multivalorados e os atributos compostos, para tanto, lembre-se como seria a representação da entidade Aluno, segundo notação do DER vista em aula:
DER_Aluno
Observe que se fossem seguidos os passos para o mapeamento do DER para o esquema relacional, seriam obtidas as seguintes relações:
Aluno(RA, nome)
EmailAluno(RA, login, domínio) *
*Adotando a construção de uma nova tabela para representar o atributo multivalorado e-mail, como esse atributo é também composto, então foram acrescidos os atributos login e domínio (atributos componentes de email).
Ou seja, conforme já mencionado, efetuando-se o mapeamento adequado obtém-se as relações já normalizadas.
Em resumo:
ñn: Aluno(RA, nome, {(e-mail: login, domínio)})
Na primeira forma normal (pelo menos):
Aluno(RA, nome)
EmailAluno(RA, login, domínio)
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 63/67
5.6 Segunda Forma Normal - 2FN
Uma relação é dita estar na segunda forma normal, quando atende aos seguintes requisitos:
estar na 1FNnão existem atributos não primos dependentes parcialmente de alguma chave candidata da relação
Ou seja, caso ocorram dependências funcionais parciais, estas devem estar associadas a algum atributo primo (atributo que faz parte de alguma chave candidata), casocontrário, a relação não atende à 2FN.
Seja o exemplo da relação Alocação, considerando como única chave candidata da relação a chave composta (Sigla, Turma):
Alocação(Sigla, Turma, sala, créditos)
Sabe-se que existem as seguintes dependências funcionais (DF)presentes:
DF1: Sigla, Turma à sala
DF2: Sigla à créditos
A DF1, indica que faz-se necessário conhecer os valores de todos os atributos pertencentes à chave para que se possa determinar a sala onde haverá a aula.
Porém a DF2, indica que se for conhecido o valor de Sigla, pode-se determinar o número de créditos da disciplina.
Por exemplo, a disciplina de Banco de Dados, cuja sigla é BD possui 4 créditos. Esse fato independe de qual é a turma de alunos que participa das aulasdessa disciplina.
Portanto, a DF2 representa uma dependência funcional parcial de créditos em relação à chave candidata da relação (Sigla, Turma).
Deve-se, então, verificar se o atributo créditos é um atributo primo. Como a resposta é NÃO, pois o atributo créditos não faz parte de qualquer chave candidata darelação, então pode-se afirmar que a relação Alocação não atende à segunda forma normal!
O que fazer para normalizar essa relação para que atenda à 2FN?
Deve-se particionar a relação original de forma a extrair a dependência funcional parcial que a está inviabilizando atender à 2FN.
Sendo assim, obtém-se as seguintes relações:
Alocação(Sigla, Turma, Sala), onde (Sigla, Turma) é a chave candidata da relação e está mantida a dependência funcional DF1.
Disciplina(Sigla, Créditos), onde (Sigla) é a chave candidata da relação e está mantida a dependência funcional DF2.
Assim, ambas as relações obtidas atendem à segunda forma normal.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 64/67
5.7 Terceira Forma Normal - 3FN
Uma relação é dita estar na terceira forma normal se atende aos seguintes requisitos:
está na 2FNtodos os seus atributos não primos são dependentes não-transitivos de uma chave candidata.
Seja o seguinte exemplo:
Alocação(Sigla, Turma, Sala, Prédio) onde sabe-se que são válidas as seguintes dependências funcionais:
DF1: Sigla, Turma à Sala, Prédio
DF2: Sala à Prédio
Observa-se que, conforme é explicitado na DF1, a chave candidata da relação é composta por Sigla e Turma.
Percebe-se, ainda, que o atributo Prédio não depende diretamente da chave candidata, basta que se conheça o valor do atributo sala para que se determine qual é o
prédio onde se encontra tal sala.
Dessa forma, a DF2 remete a uma dependência funcional transitiva do atributo Prédio em relação à chave candidata da relação.
Sendo assim, resta verificar se o atributo Prédio é um atributo primo, o que não se confirma, pois o mesmo não pertence a qualquer chave candidata da relação.
Desta forma, pode-se afirmar que a tabela Alocação não atende à terceira forma normal!
O que fazer para normalizar essa tabela?
Basta extrair a DF que impede que a tabela atenda à 3FN, gerando outra tabela derivada da original:
Alocação(Sigla, Turma, Sala)
onde mantém-se a DF: Sigla, Turma à Sala
Local(Sala, Prédio)
onde mantém-se a DF: Sala à Prédio
Desta forma, as relações obtidas atendem à Terceira Forma Normal!
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 65/67
5.8 Terceira Forma Normal - 3FN (Alternativa)
Uma forma alternativa de verificar se uma relação se encontra na 3FN é a que se segue:
Liste as dependências funcionais (DF) válidas (ou que devem ser verificadas na relação)Para cada DF na forma X à Y
ou X é uma superchave da relação
ou Y é um atributo primo
Ou seja, devem ser analisadas cada DF, caso o antecedente da dependência funcional (lado X) seja uma superchave, então já pode ser assumido que a relação
encontra-se na Terceira Forma Normal.
Caso contrário, se X não for superchave, pode-se ainda verificar o consequente (lado Y) e verificar se esse é um atributo primo. Caso Y faça parte de alguma chavecandidata, então pode-se afirmar que a relação atende à Terceira Forma Normal.
No exemplo visto no capítulo anterior:
Alocação(Sigla, Turma, Sala, Prédio) onde sabe-se que são válidas as seguintes dependências funcionais:
DF1: Sigla, Turma à Sala, Prédio
DF2: Sala à Prédio
Analisando a DF1, verifica-se que Sigla, Turma é uma superchave da relação pois determina todos os demais atributos da relação. Então, por essa DF, a tabela atendeà 3FN.
Porém, analisando a DF2, percebe-se que Sala não é uma superchave. Verifica-se então se o atributo Prédio é um atributo primo.
Sabe-se que Prédio não é atributo primo, portanto, a tabela não atende à 3FN.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 66/67
5.9 Forma Normal de Boyce-Codd - FNBC
Uma relação é dita estar na forma normal de Boyce-Codd se atende aos seguintes requisitos:
está na 2FNtodos os seus atributos são dependentes não-transitivos de uma chave candidata.
Ou seja, esta é uma forma normal mais restritiva do que a terceira forma normal, pois impede que qualquer atributo seja dependente transitivo de alguma chavecandidata da relação! Mesmo atributos primos devem atender a essa exigência!
Um jeito prático de descobrir se a a tabela está na FNBC é listando todas as DFs válidas, na forma X à Y, e verificando se todas possuem o antecedente (lado X)como superchave. Essa é a única condição que deve ser avaliada.
Desta forma, é fácil perceber que podem ser encontradas relações que atendem à 3FN mas não atendem à FNBC. Por outro lado, percebe-se também que todarelação que atende à FNBC atende também a 3FN.
Observe o seguinte exemplo:
Propriedade(IDProp, NomeRegião, Lote, Area) com as seguintes DFs válidas sobre ela:
DF1: IDProp àNomeRegião, Lote, Area
DF2: NomeRegião, Lote à IDProp,Area
DF3: Area à NomeRegião
Pode ser observado que DF1 e DF2, tem superchaves como seus antecedentes pois ambos definem chaves candidatas da relação.
Porém na DF3, Area não é superchave, portanto a relação não encontra na FNBC.
Seguindo o mesmo procedimento visto nos capítulos anteriores, deve-se normalizar a tabela extraindo a DF que está ferindo a FNBC:
Propriedade(IDProp, Lote, Area), onde são atendidas as dependências funcionais:
DF1: IDProp à Lote, Area
DF2: Lote à IDProp,Area
Divisao(Area, NomeRegião), onde é atendida a dependência funcional:
DF3: Area à NomeRegião
Portanto, ambas as relações derivadas encontram-se na FNBC.
18/04/13 name
ead.sead.ufscar.br/mod/book/print.php?id=232593 67/67
5.10 Material Complementar - Slides
Slides utilizados na videoaula sobre dependencias funcionais e normalização.