Livro de Banco de Dados - Ufscar

18/04/13
name
Livro Virtual de Sistemas de Banco de Dados

Neste livro virtual voc encontra notas de aula, slides utilizados nas videoaulas e webconferencias, exerccios complementares e sugestes de leituras. Espero que faa bom proveito! Profa. Marilde
Site: Curso:
EaD - SEaD 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
ead.sead.ufscar.br/mod/book/print.php?id=232593
1/67
18/04/13
name
Sumrio
1 Conceitos Bsicos 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 Dados 1.6 Pessoas em torno de um Sistema de Banco de Dados 1.7 Arquitetura de trs-esquemas 1.8 Independncia de Dados 1.9 Linguagens de Banco de Dados 1.10 Software Gerenciador de Banco de Dados 1.11 Exerccios complementares 1.12 Indicao 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 Exerccio complementar 2.7 Indicao de Leitura Complementar 2.8 Material Complementar 3 Modelo de Dados Relacional 3.1 Conceitos do Modelo Relacional 3.2 Restries do Modelo Relacional 3.3 Restries de Domnio 3.4 Restries de Chave 3.5 Restrio de Integridade de Entidade 3.6 Restrio de Integridade Referencial e Chave Estrangeira 3.7 Indicao de Leitura Complementar 3.8 Material Complementar 4 Projeto de Banco de Dados Relacional 4.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 Fracas 4.4 Mapear Conjuntos de Relacionamentos Binrios 1:1 4.5 Mapear Conjuntos de Relacionamentos Binrios 1:N 4.6 Mapear Conjuntos de Relacionamentos Binrios N:M 4.7 Mapear Conjuntos de Relacionamentos n-rios (grau > 2) 4.8 Mapear atributos multivalorados 4.9 Esquema Lgico Relacional do banco de dados Empresa 4.10 Material Complementar 4.11 Exerccio complementar 5 Dependncias Funcionais Dependncias Multivaloradas e Normalizao 5.1 Processo de Normalizao 5.2 Dependncias Funcionais 5.3 Dependncias Funcionais Parciais 5.4 Dependncias Funcionais Transitivas 5.5 Primeira Forma Normal - 1FN 5.6 Segunda Forma Normal - 2FN 5.7 Terceira Forma Normal - 3FN 5.8 Terceira Forma Normal - 3FN (Alternativa) 5.9 Forma Normal de Boyce-Codd - FNBC 5.10 Material Complementar - Slides
2/67
18/04/13
name
1 Conceitos Bsicos
Bancos de dados tornaram-se essenciais em nosso dia a dia. So inmeras as aplicaes que utilizam sistemas de banco de dados: 1. 2. 3. 4. 5. 6. 7. 8. bancos financeiros: armazenam todas as transaes bancrias empresas areas: reservas de assentos em vos, agendamentos de vos vendas: clientes, produtos, estoques, compras revendedores online: registro de pedidos, recomendaes personalizadas industria: produo, estoque, pedidos, fornecedores recursos humanos: regoistro de empregados, salrios, deduo de taxas universidades: registros de alunos, disciplinas, salas, notas bibliotecas: registro de acervo, registro de usurio, registro de emprstimo
Muitas dessas aplicaes so ditas aplicaes tradicionais de banco de dados, pois envolvem essencialmente textos e nmeros, porm tem crescido as aplicaes que envolvem dados ditos no convencionais como udio, vdeo, mapas, imagens de satlites, etc. O emprego de avanos tecnolgicos tornaram possveis aplicaes inovadoras de sistemas de banco de dados, tais como: 1. banco de dados multimdia: armazenam e manipulam figuras, videoclipes, mensagens sonoras; 2. sistemas de informaes geogrficas: armazenam e analisam mapas, dados do tempo e imagens de satlite; 3. data warehouses: utilizados em conjunto com ferramentas de processamento analtico online (OLAP) possibilitam empresas extrair e analisar informaes teis de grandes bancos de dados para tomada de deciso; 4. tecnologia de bancos de dados ativos e de tempo real so utilizados no controle de processos industriais e de produo. 5. tecnologia de banco de dados aplicadas a WWW aprimora a recuperao de informaes pelos usurios da internet. Para que voc possa compreender as aplicaes mais avanadas comearemos explorando bancos de dados convencionais. Nas prximas sees conheceremos um pouco mais sobre os conceitos que cercam os sistemas de banco de dados.
3/67
18/04/13
name
1.1 O que Banco de Dados?

Um banco de dados uma coleo de dados relacionados, que possui algumas propriedades implcitas[ELMASRI 2005]: representa aspectos do mundo real (chamado minimundo ou universo do discurso) e mudanas no minimundo devem ser refletidas no banco de dados; uma coleo lgica e coerente de dados com algum significado inerente; projetado, construdo e povoado por dados que atendem a uma proposta especfica dirigida a um grupo de usurios. 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 coleo das informaes armazenadas no banco de dados em um determinado momento uma instncia do banco de dados. O projeto geral do banco de dados o esquema do banco de dados. Os esquemas raramente - ou nunca - so modificados. Os sistemas de banco de dados possuem vrios esquemas, particionados de acordo com o nvel de abstrao, como voc ver quando estudar a arquitetura de trsesquemas para sistemas de banco de dados.
4/67
18/04/13
name
1.2 Banco de Dados versus Processamento de Arquivos

No processamento de arquivos, cada usurio define e implementa os arquivos necessrios para uma aplicao especfica, como parte da programao da aplicao. Mesmo que mais de uma aplicao necessite trabalhar com o mesmo conjunto de dados, cada aplicao mantm suas informaes em arquivos separados e tambm as aplicaes que os manipulam. Isso implica em redundncias indesejadas, tanto em termos de definio e armazenamento de dados quanto de esforo para manter os dados comuns atualizados. Utilizando um banco de dados, um nico repositrio de dados construdo e mantido para ser acessado por vrios usurios. As principais caractersticas da abordagem de banco de dados so: 1. 2. 3. 4. Natureza autodescritiva do sistema de banco de dados; isolamento entre os programas e os dados, e a abstrao dos dados; suporte para as mltiplas vises dos dados; compartilhamento de dados e processamento de transaes
5/67
18/04/13
name
1.3 Modelo de Dados

Modelo de dados uma coleo de ferramentas conceituais para descrever dados, relaes de dados, semntica de dados e restries de consistncia. Um modelo de dados oferece uma maneira de descrever o projeto de um banco de dados no nvel fsico, lgico e de viso. usual encontrarmos a seguinte categorizao dos modelos de dados: Modelo Relacional que representa os dados como uma coleo 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 hierrquico precederam o modelo relacional. Esses modelos estavam intimamente relacionados com sua implementao subjacente. Modelo Entidade/Relacionamento (MER) baseado em uma percepo do mundo real que consiste em uma coleo de objetos bsicos, chamados entidades e as relaes 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 extenso ao modelo ER com noes de encapsulamento, mtodos e identidade de objeto. O modelo relacionalobjeto combina os recursos do modelo orientado a objeto com o relacional. Modelo Semi-estruturado permite a especificao 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.
6/67
18/04/13
name
1.4 O que Sistema de Banco de Dados?

Um sistema de banco de dados contm informao sobre algum extrato do mundo real do qual se pretende armazenar dados e recuperar informaes. Na figura 1.1 est representada uma configurao simplificada de um sistema de banco de dados.
Figura 1.1 - Configurao 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 constitudo 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 restries que se aplicam aos mesmos, que aparece na figura como " Definio dos Dados Armazenados" - comumente chamado de Dicionrio 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 aplicaes e/ou consultas que fazem a interface com o usurio e/ou programador do sistema.
7/67
18/04/13
name
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. (extrado de [ELMASRI 2005] - ilustrao cedida pela editora Pearson) Levantamento de requisitos (independe do SGBD) Na fase de levantamento de requisitos e anlise de requisitos podem ser aplicadas tcnicas de engenharia de software que facilitam a comunicao entre especialistas de computao e especialistas de domnio. uma fase essencial para o desenvolvimento do sistema, pois a qualidade da soluo 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 implementao, ou seja,independe de SGBD. O fruto desta etapa a construo de um modelo conceitual, que em nossa disciplina ser representado por um diagrama entidade relacionamento. Nesta etapa podem ainda surgir questes sobre os requisitos, sendo recomendvel questionar o especialista do domnio sobre tais dvidas, neste sentido o modelo conceitual pode auxiliar no refinamento dos requisitos do sistema. Projeto Lgico Esta etapa tem por objetivo transformar o modelo conceitual em um modelo lgico. O modelo lgico define como o banco de dados ser implementado em SGBD especfico. Em nossa disciplina vamos obter um esquema relacional, pois o PostgreSQL um SGBD baseado no modelo de dados relacional. Projeto Fsico nesta etapa o modelo do banco de dados enriquecido com detalhes que influenciam no desempenho do banco de dados, mas no interferem em sua funcionalidade. O modelo obtido nesta fase o modelo fsico do banco de dados. Estas etapas, conforme [HEUSER 2008] salienta, so adequadas para a construo 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.
8/67
18/04/13
name
1.6 Pessoas em torno de um Sistema de Banco de Dados

Nesta seo vamos enfocar os profissionais que no cotidiano se envolvem na construo, manuteno 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 gesto desses dados por intermdio de sistemas de banco de dados o projetista de banco de dados. Os projetistas devem entrevistar todos os grupos de possveis usurios para conhecer suas necessidades de dados, ou seja, so os responsveis pela identificao dos dados que sero armazenados no banco e tambm por escolher as estruturas adequadas para representar e armazenar esses dados. Os projetistas comeam a trabalhar antes mesmo do sistema ter sido implementado e alimentado com os dados. Uma outra figura, no menos importante, em se tratando de grandes bancos de dados o administrador de banco de dados (DBA) que responsvel pela autorizao para o acesso ao banco, pela coordenao e monitorao de seu uso e por adquirir recursos de software e hardware conforme necessrio. responsvel por problemas como brechas de segurana ou tempo de resposta ruim do sistema. Ou seja, o DBA o responsvel 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 usurios, ento obviamente, este um grupo de pessoas importante no contexto. Usurios podem ser categorizados em usurios leigos - so aqueles que interagem com o sistema apenas por intermdio de programas de aplicao previamente concebidos; programadores de aplicao - so profissionais de computao que interagem com o sistema com o intuito de escrever programas de aplicao; usurios avanados interagem com o sistema sem escrever programas, formulam suas requisies em uma linguagem de consulta de banco de dados e usurios especializados so usurios avanados que escrevem aplicaes de banco de dados especializadas que no se encaixam na estrutura de processamento de dados tradicional.
9/67
18/04/13
name
1.7 Arquitetura de trs-esquemas

A arquitetura de trs-esquemas (tambm conhecida como arquitetura ANSI/SPARC) para sistemas de banco de dados foi proposta para auxiliar a realizao e visualizao de importantes caractersticas do uso de banco de dados: independncia entre dados e programas; suporte a mltiplas vises de usurios e uso de catlogo (ou dicionrio de dados) para armazenar a descrio do banco de dados. O objetivo dessa arquitetura, ilustrada na figura 1, a separao entre o usurio da aplicao e o banco de dados fsico. Pode-se observar trs nveis: o nvel interno (ou fsico) que tem um esquema interno que descreve a estrutura de armazenamento fsico do banco de dados. Esse esquema utiliza um modelo de dados fsico e descreve os detalhes completos do armazenamento de dados e caminhos de acesso aos mesmos. O nvel conceitual (ou lgico) que possui um esquema conceitual que descreve a estrutura de o todo o banco de dados para a comunidades usuria. Esse esquema oculta detalhes de armazenamento fsico, concentrando-se em descrio de entidades, tipos de dados, conexes, operaes de usurios e restries. O nvel externo (ou de viso) abrange os esquemas externos ou vises dos usurios . Cada esquema externo descreve a parte do banco de dados que um dado grupo de usurios tem interesse e oculta o restante do banco de dados desse grupo.
Figura 1 - Arquitetura Three-Schema (extrada de [ELMASRI 2006])
10/67
18/04/13
name
1.8 Independncia de Dados

Independncia de dados a capacidade de mudar o esquema em um nvel do sistema de banco de dados sem que ocorram alteraes do esquema no prximo nvel mais alto. Existem dois tipos de independncia de dados: lgica e fsica. Independncia de dados lgica: a capacidade de alterar o esquema conceitual sem mudar o esquema externo ou os programas de aplicao. Possveis alteraes no esquema externo: adicionar um tipo de registro ou item de dados, variar restries ou remover um tipo de registro ou item de dados. Independncia de dados fsica: a capacidade de mudar o esquema interno sem alterar o esquema conceitual. Consequentemente, o esquema externo tambm no necessita alterao. Possveis mudanas em nvel fsico podem ser necessaris quando arquivos fsicos precisam ser reorganizados para aperfeioar o desempenho da recuperao ou atualizao de dados. Com um sistema gerenciador de banco de dados (SGBD) que implementa a arquitetura de trs-esquemas, o catlogo expandido para incluir informaes de como mapear os dados entre nveis. Ou seja, o SGBD utiliza software adicional para realizar os mapeamentos e garantir a independncia de dados o que acarreta uma sobrecarga durante a compilao ou a execuo de uma consulta ou de um programa, provocando ineficincias no SGBD. Porisso poucos SGBDs implementam a arquitetura trs-esquemas completa.
11/67
18/04/13
name
1.9 Linguagens de Banco de Dados

Aps termos obtido o esquema lgico e fsico do banco de dados devemos escolher o Sistema Gerenciador de Banco de Dados (SGBD) que se deseja utilizar para implement-lo. A linguagem de definio 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 funo processar os comandos DDL a fim de identificar os construtores e para armazenar a descrio do esquema no catlogo do SGBD. Quando os esquemas do banco de dados estiverem compilados e o banco de dados populado com os dados, os usurios devem ter alguns meios para manipular esse banco. As manipulaes tpicas so a recuperao, insero, remoo e modificao dos dados. A linguagem de manipulao de dados (DML) fornecida pelo SGBD para essa finalidade. Basicamente, existem dois tipos de DMLs: procedurais e declarativas. As procedurais requerem que um usurio especifique que dados so necessrios e como obtlos. As declarativas exigem apenas que os usurios especifiquem o que desejam sem especificar como obt-los. A parte de uma DML que que envolve recuperao de informaes chamada de linguagem de consulta.
12/67
18/04/13
name
1.10 Software Gerenciador de Banco de Dados

Um Sistema Gerenciador de Banco de Dados (SGBD) um complexo sistema de software. Os principais mdulos componentes de um SGBD encontra-se ilustrado, de forma simplificada, na figura 1. O banco de dados e o catlogo so normalmente armazenados no disco. O acesso ao disco controlado principalmente pelo sistema operacional do ambiente onde est instalado o SGBD. Um mdulo de alto nvel do SGBD, chamado de mdulo de gerenciamento dos dados armazenados, controla o acesso informao do SGBD que est armazenada em disco. O compilador DDL processa as definies do esquema, especificadas na DDL, e armazena as descries dos esquemas no catlogo do SGBD. O catlogo inclui informaes como nomes e tamanhos dos arquivos, nomes e tipos de itens de dados, detalhes de armazenamento de cada arquivo, informaes de mapeamento entre os esquemas e restries, alm de muitas outras informaes necessrias para os mdulos do SGBD. Os mdulos de software do SGBD acessam as informaes do catlogo conforme necessrio. O compilador de consulta manipula as consultas de alto nvel que so feitas interativamente. Analisa sintaxe, compila ou interpreta a consulta criando um cdigo de acesso ao BD e ento gera as chamadas ao runtime. O pr-compilador extrai os comandos DML dos programas escritos em uma linguagem de programao hospedeira. Esses comandos so enviados ao compilador DML para compilao, gerando cdigos para o acesso ao BD. O restante do programa enviado para o compilador da linguagem de programao hospedeira. Os cdigos-objeto para os comandos DML e o restante do programa so acoplados, formando uma transao customizada cujo cdigo executvel inclui as chamadas para o runtime. O processador de consulta de banco de dados em tempo de execuo (runtime) recebe os comandos para a recuperao ou atualizao e os executa no banco de dados.
Figura 1 - Arquitetura simplicada dos componentes de SGBD. (extrada de [ELMASRI 2006])
13/67
18/04/13
name
1.11 Exerccios complementares

1. O que um SGBD? Quais suas principais caractersticas? 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. Usurio Leigo 2. Programadores de aplicao 3. Usurios avanados 4. Usurios especializados 5. DBA 6. Projetista de BD a) Codificao de programas que atuam sobre o BD b) Escrevem consultas usando uma determinada linguagem c) Interao com o BD controlada por software d) Interao com os possveis usurios do BD e) Segurana e operao do BD f) Desenvolvem aplicaes especializadas 5. Discuta sobre a finalidade da Arquitetura de trs-esquema. Ela determina privacidade sobre os dados? Por qu? Esta arquitetura ideal? Por qu? 6. Devido a uma mudana em suas estratgias, uma empresa necessita alterar suas regras de negcio. Assim, o esquema conceitual de seu banco de dados dever sofrer alteraes, bem como as aplicaes que acessam o banco de dados. O que este fato representa no contexto de SBD?
14/67
18/04/13
name
1.12 Indicao de Leitura Complementar

Leia mais nos captulos 1 e 2 de [ELMASRI 2005], no captulo 1 de [SILBERCHATZ 2006] e no captulo 1 de [HEUSER 2008].
15/67
18/04/13
name
2 Projeto Conceitual de Banco de Dados

Na seo 5 do captulo 1, foram apresentadas as etapas que devem ser seguidas para o desenvolvimento de projeto de banco de dados. Na ocasio, foi apresentada a figura 1 reproduzida aqui.
Figura 1 - Etapas de desenvolvimento de um projeto de sistema de banco de dados. (extrada de [ELMASRI 2005] - ilustrao cedida pela editora Pearson) Nesta disciplina vamos supor que teremos em mos o documento de requisitos que obtido aps um processo, normalmente longo, de levantamento e anlise de requisitos. Vrias metodologias e tcnicas que podem auxiliar no processo de levantamento de requisitos so assuntos da disciplina Engenharia de Software. Maiores detalhes sobre essas tcnicas 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 possvel 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 EntidadeRelacionamento um poderoso modelo de dados que nos auxilia a desenvolver a etapa de projeto conceitual do banco de dados.
16/67
18/04/13
name
2.1 Entidade e Conjunto (ou Tipo) de Entidades

Uma entidade um objeto que existe e distinguvel 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 caractersticas que desejamos armazenar sobre elas, que so chamadas de atributos das entidades, por exemplo, suponha que desejemos armazenar nomes e endereos de pessoas ento diremos que esses so os atributos das entidades 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 mundo real. Por exemplo, um conjunto Pessoa representando inmeras pessoas, um conjunto Empresa representando inmeras empresas, um conjunto Disco representando inmeros discos, etc. Na figura 3, esto representadas duas entidades do mundo real junto com as caractersticas que foram consideradas relevantes, p1 uma entidade pessoa e para ela foram informados os valores dos atributos nome, endereo e idade; e d1 uma entidade disco com os atributos nome , gravadora e mdia. Toda vez que so atribudos valores para os atributos de um conjunto de entidades tem-se a instanciao (= exemplificao) de uma ocorrncia de uma entidade da vida real. Cada atributo deve ser definido como pertencente a um domnio, e os valores desses atributos devem pertencer a esses domnios.
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 no possui um conjunto de atributos suficientes para garantir a unicidade de suas entidades. Voc ver mais sobre os identificadores e sua influncia do conjunto de entidades na seo que trata sobre atributos.
17/67
18/04/13
name
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 atravs da definio de conjuntos de entidades e o relacionamento entre esses conjuntos de entidades. A notao diagramtica associada ao MER conhecida como Diagrama Entidade-Relacionamento (DER). No DER a nfase est na representao do esquema ao invs das instncias do banco de dados. Ou seja, privilegia-se a viso sobre as estruturas do banco e no 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 que todo o banco de dados em questo est representado por seu esquema em um nico diagrama. No se aflija, voc o entender melhor com a leitura dos prximos captulos.
Figura 2 - DER do banco de dados Empresa (extrada de [ELMASRI 2005])
18/67
18/04/13
name
2.3 Relacionamentos e Conjuntos de Relacionamentos

Para a modelagem de uma situao real, necessrio representar o relacionamento entre os Conjuntos de Entidades. Esses relacionamentos so denominados conjuntos de relacionamentos e possuem rica semntica envolvida. Essa semntica expressa atravs dos conceitos de cardinalidade, participao 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. Esto ilustrados cinco empregados (e1, e2, e3, e4, e5), trs empresas (c1, c2, c3) e cinco ocorrncias de relacionamento entre eles (r1, r2, r3, r4, r5). Pode-se inferir atravs da figura, que um empregado trabalha em uma nica empresa, pois cada um participa de apenas uma ocorrncia de relacionamento, enquanto uma empresa emprega vrios empregados, uma vez que uma empresa pode participar de mais de uma ocorrncia de relacionamento. Essa percepo da realidade pode ser representada atravs do conceito de Cardinalidade de Relacionamento.
Figura 1 - Diagrama representando o relacionamento Trabalha_em entre Empregado e Empresa. A restrio de cardinalidade de relacionamento informa qual o nmero mximo de ocorrncias de relacionamento pode haver de um conjunto de entidade com o outro conjunto de entidade por um determinado conjunto de relacionamento. No exemplo, a restrio de cardinalidade de Empregado no conjunto de relacionamento Trabalha_em com Empresa 1, significando que um empregado pode se relacionar com apenas 1 entidade empresa. Por outro lado, a restrio de cardinalidade de Empresa no conjunto de relacionamento Trabalha_em com Empregado N, significando que uma empresa pode empregar vrios (N) empregados. No caso dizemos que a restrio de cardinalidade neste relacionamento N:1 (l-se muitos para 1 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 vrios e pode ser substituda por qualquer outra letra, tal como, M, P, Q, etc. A restrio de participao de um conjunto de entidade em um conjunto de relacionamentos indica a obrigatoriedade ou no de suas entidades participarem daquele conjunto de relacionamentos com o outro conjunto de entidade. A restrio de participao pode ser total ou parcial, se a restrio total implica que todas as entidades pertencentes quele conjunto de entidade obrigatoriamente participar em alguma instncia daquele conjunto de relacionamento, se a restrio parcial implica que podem existir entidades que no participam do relacionamento. O grau do relacionamento indica quantos conjuntos de entidades esto envolvidos naquele determinado relacionamento. No exemplo da Figura 1, temos que o grau do relacionamento 2, indicando um relacionamento binrio. Um conjunto de relacionamentos pode associar vrios conjuntos de entidades, caracterizando relacionamentos ternrios (grau 3), relacionamentos quaternrios (grau 4), etc. Um exemplo de relacionamento ternrio, ou seja, com grau 3, est ilustrado na Figura 2. importante observar que um relacionamento com grau N > 2 s se justifica se no puder ser decomposto em relacionamentos com graus menores e ainda manter a semntica desejada.
19/67
18/04/13
name
Figura 2 - Exemplo de Conjunto de Relacionamento Ternrio (Grau 3) Existem conjuntos de relacionamentos regulares que so 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 proprietria. Cabe ressaltar que devido ao fato de uma entidade fraca ser identificada sempre por sua entidade proprietria, a restrio de participao do conjunto de entidade fraca em seu conjunto de relacionamento identidade com a proprietria deve sempre ser total.
20/67
18/04/13
name
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 e composto 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 atribudo a este atributo expresse completamente o significado que se pretende extrair dele.
Figura 3 Exemplo de entidades pessoa e disco com seus respectivos atributos. Porm, 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 so necessrios o primeiro nome e o sobrenome e um terceiro pode julgar que so necessrios: o primeiro nome, as iniciais dos nomes do meio e o sobrenome. Quando dito que um determinado atributo simples, e os valores possveis para esse atributo podem ser formados por partes como o exemplo citado, deve-se ter em mente 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 no existe a necessidade de fazer a verificao se o valor esperado foi armazenado, ento est tudo bem. Caso contrrio, deve-se lanar mo 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 necessrio conhecer os valores de seus componentes. Seguindo no mesmo exemplo, se necessrio garantir que todas as partes (ou pelo menos algumas delas) de um nome sejam conhecidas (obrigatrio informar, por exemplo, o nome e sobrenome), ento, 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 interessante implementar 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 estas duas 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, isso significa 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 vrios apelidos, no ? Pois bem, ento se fossemos armazenar os apelidos de uma pessoa, deveramos 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.
21/67
18/04/13
name
Figura 5 - Entidade Pessoa com vrios apelidos. Na figura 5, temos o exemplo da entidade pessoa com um atributo multivalorado Apelidos. No exemplo, vemos em contraposio ao Nome, que um atributo simples e monovalorado, o atributo Apelidos que simples e multivalorado. Para entender a notao 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. Alm dessa categorizao mais genrica de atributos no MER, existem outros conceitos associados a atributos: atributo identificador atributo identificador parcial ou discriminatrio atributo derivado Ao definirmos um atributo como atributo identificador estamos impondo uma importante restrio aos valores possveis para esse atributo - a restrio de ser nico dentro 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 vrios homnimos na vida real. Isso significa que o nome de uma pessoa no deve ser considerado um atributo identificador 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, possvel ter mais de um cadastro de pessoa fsica (CPF)? Bom, se deixarmos as fraudes de lado, podemos afirmar que cada pessoa tem um, e somente um, nmero de CPF. Ou seja, se informo meu CPF, o nico nome que deve ser encontrado o meu! Sendo assim, esse um possvel atributo identificador de pessoa. Que tal procurar outros dados com as mesmas caractersticas? O registro geral (RG), caso reunamos as informaes de nmero e nome e estado do orgo emissor, pode identificar unicamente um indivduo, assim como o ttulo de eleitor, a CNH, etc. Em geral, podemos considerar os documentos de pessoas fsicas e jurdicas como possveis identificadores. Um conjunto de entidades que contm atributos suficientes para encontrarmos um identificador chamado de Conjunto de Entidades Regular (ou Forte). Um atributo identificador parcial ou discriminatrio s encontrado no contexto de Conjunto de Entidades Fracas que assim chamado por no possuir atributo suficiente para que seja descoberto um identificador para suas entidades. Nesse caso, o conjunto de entidades fracas precisar do auxlio do identificador de outro conjunto de entidades, dita sua proprietria, para identificar unicamente uma entidade dentro dela. Se cada entidade da proprietria estiver relacionada a mais de uma entidade fraca, necessrio ento definir um atributo identificador parcial que ter o importante papel de, junto com o identificador de sua proprietria, 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 funcionrios para efeito de imposto de renda. Porm sobre esses dependentes, desejamos armazenar somente o nome e o parentesco com o funcionrio. Analisemos: podemos imaginar um conjunto de entidades Funcionrio para o qual armazenamos, no mnimo, seu CPF e nome e temos um conjunto de entidades Dependente com os atributos nome e parentesco. Para o conjunto de entidades Funcionrio fcil descobrir um identificador: CPF. E para o conjunto de entidades Dependente? Vejamos: nome de pessoa no um bom identificador, como j discutimos antes. Sobra-nos, ento o parentesco? Nossa, quantos parentes "filho(a)" ou "me/pai" encontraramos 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 encontrar homonimos (e sabemos que sim) o que impede desses homonimos terem o mesmo grau de parentesco com seus responsveis? Nada. Ou seja, se encontrarmos duas pessoas com o nome de "Sabrina Silva" no banco de dados de Dependente, no seria de estranhar que o grau de parentesco com seu responsvel na empresa fosse "filho(a)"! Chegamos a um impasse! No 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 proprietria para ela: Funcionrio - pois devido a existncia de um responsvel nos quadros da empresa que leva ao cadastro do dependente. Certo. Ento, se eu conheo o CPF do funcionrio, conheo seus dependentes. No bem assim, ainda precisamos saber se o funcionrio pode ter atrelado a ele mais de um dependente. Se isso for verdade, precisamos alm de conhecer seu CPF, conhecer tambm o nome do dependente. Nesse caso o nome do dependente o atributo identificador parcial do conjunto de entidades fracas Dependente. Veja o exemplo: Funcionrio CPF 05899356808 08085539926 NOME Jos Silva Luiz Gonalves Silva Dependente NOME Sabrina Silva Sabrina Silva PARENTESCO filho(a) filho(a)
Consideremos que "Jos Silva" pai de uma das "Sabrina Silva" e que "Luiz Gonalves Silva" pai da outra "Sabrina Silva". Se imaginarmos que cada funcionrio tem apenas um dependente, fica fcil encontrarmos um e s um dependente para cada um. Basta associarmos o identificador correto do responsvel para cada dependente e considerarmos esse tambm o identificador do tipo de entidade fraca Dependente. Funcionrio CPF 05899356808 08085539926 NOME Jos Silva Luiz Gonalves Silva Dependente CPF do Responsvel 05899356808 08085539926 08085539926 NOME Sabrina Silva Sabrina Silva Gabriela Silva PARENTESCO filho(a) filho(a) filho(a)
Mas, e se o funcionrio puder ter mais de um dependente? Como fica? Se continuarmos considerando somente o CPF do responsvel como identificador dessa identidade, no 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 responsvel e tambm 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 computo sobre os dados j armazenados. Um exemplo tpico a idade de uma pessoa. Se voc j tem a data de nascimento armazenada possvel saber a idade da pessoa,
ead.sead.ufscar.br/mod/book/print.php?id=232593 22/67
18/04/13
name
para tanto basta conhecer a data atual e subtrair a data do nascimento armazenada. Essa fcil, no ? Outros exemplos: nmero de funcionrios de um departamento (se voc j relacionou os funcionrios aos seus respectivos departamentos basta cont-los!), nmero de dependentes por funcionrio (similar ao anterior).
23/67
18/04/13
name
2.5 Diagrama Entidade-Relacionamento (DER)

O Diagrama Entidade-Relacionamento a forma grfica do modelo entidade-relacionamento. Na Figura 1 voc encontra um resumo da notao que dever empregar em seu projeto conceitual do banco de dados. Observe que o termo atributo-chave foi citado no texto como Identificador (atributo grifado por linha contnua). O identificador parcial anotado sublinhando com uma linha tracejada o atributo em questo.
Figura 1 - Resumo da Notao do DER
Um conjunto de entidades regular representando por um retngulo, como ilustrado na Figura 2. Um elemento do conjunto de entidades definido como uma Entidade, sendo identificado por caractersticas individuais definidas atravs do conceito de atributos (representados poe elipses). Assim, uma Pessoa pode ser caracterizada atravs dos atributos Nome, CPF, Sexo, Idade, Altura, etc.
Figura 2 - Conjunto (ou Tipo) de Entidade Pessoa no DER As distintas categorizaes dos atributos: simples e monovalorado, simples e multivalorado, composto e monovalorado e composto e multivalorado so representados na Figura 3.
24/67
18/04/13
name
Figura 3 - Representao de Atributos no DER Na Figura 4, o atributo nome representado como um atributo composto e monovalorado. Prenome e Sobrenome so seus atributos componentes.
Figura 4 - Atributo Composto e Monovalorado Na Figura 5 esto representados diversos conjuntos de entidades associados por conjuntos de relacionamentos. Em cada conjunto de relacionamento est ilustrada uma restrio de cardinalidade 1:1, 1:N e M:N.
Figura 5 - Conjuntos de Relacionamentos de Restrio de Cardinalidade.
Na Figura 6 esto representados conjuntos de entidades interagindo em um conjunto de relacionamentos de grau 3 (ou ternrio).
25/67
18/04/13
name
Figura 6 - Conjunto de Relacionamento de Grau 3.
A Figura 7 apresenta o conjunto de relacionamento Cursa entre Estudante e Disciplina, onde a restrio de participao de Estudante em Cursa total (representado pela linha dupla) e a restrio de participao de Disciplina em Cursa parcial.
Figura 7 - Restries de Participao 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 proprietria Disciplina. Observe que a restrio de participao de Ementa em Possui Total. Isso sempre verdade quando se trata da relao entre a fraca e sua identidade. Deve ser lembrado que, caso a cardinalidade em Possui fosse N:1, significando que uma disciplina pudesse ter vrias ementas, seria necessrio apontar um conjunto de atributos identificador parcial para Ementa, conforme visto na seo sobre Atributos.
Figura 8 - Conjunto de Entidade Fraca
26/67
18/04/13
name
2.6 Exerccio complementar

Voc deve efetuar o projeto conceitual do banco de dados cujos requisitos esto listados abaixos. Voc deve obter um esquema conceitual do banco de dados expresso segundo a notao do DER. Procure relacionar todas as suposies que voc precisou fazer para completar seu projeto. Bom trabalho. Marilde Requisitos: Uma gravadora de discos deseja manter informaes sobre as bandas e msicos que contrata, alm da atuao deles em shows. Sobre uma banda, deseja-se manter o seu nome e a data de sua criao. Sobre um msico, interessam: o nome, o nome artstico, o CPF e a data de nascimento. Sabe-se que uma banda pode ser formada por diversos msicos, e que um msico pode participar de uma ou mais bandas, sempre com um papel definido (vocalista, violonista, tecladista etc.). Cada disco gravado por uma banda especfica. comum bandas terem mais que um disco gravado. Todo disco tem um ttulo, um produtor e um local de gravao com logradouro, nmero, CEP, UF e pas. Todo disco possui um cdigo interno da gravadora para identificao. Alm disso, os discos possuem uma ou mais canes. Todas as canes esto relacionadas a discos existentes, e cada cano pode estar presente em um ou mais discos. As canes possuem um ou mais compositores, um ttulo (que as identifica unicamente) e uma letra. importante lembrar que os compositores no necessariamente so msicos. Os shows da banda tambm devem ser arquivados. Um show possui um cdigo identificador, ocorre em uma determinada cidade e exige a cobrana 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 suas inmeras canes. Um show realizado exclusivamente por uma banda. Em um show, so executadas diversas canes. Em shows diferentes de uma mesma banda, podem existir canes repetidas. No interessa saber se a banda A tocou a msica da banda B, portanto uma cano sempre executada pela mesma banda.
27/67
18/04/13
name

Tcnicas e metodologias para levantamento e anlise de requisitos, que compem as etapas iniciais de desenvolvimento de um projeto de banco de dados (e sistemas em geral) podem ser encontradas em [PRESSMAN 2006]. Explicaes detalhadas sobre o emprego do modelo entidade-relacionamento (e sua extenso) no processo de projeto conceitual de banco de dados podem ser encontradas em [ELMASRI 2005] E [SILBERCHATZ 2006].
28/67
18/04/13
name
2.8 Material Complementar

Slides utilizados na videoaula sobre modelo ER.
29/67
18/04/13
name
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 de Dados (SGBD). Esse modelo usa o conceito de relaes matemticas como seu bloco de construo bsica e tem sua base terica na teoria de conjuntos.
30/67
18/04/13
name
3.1 Conceitos do Modelo Relacional

O modelo relacional (MR) representa o banco de dados como uma coleo de relaes. Cada relao, ou tabela, assemelha-se a uma planilha eletrnica, com linhas, colunas e clulas onde se armazenam os dados. Cada linha em uma tabela representa uma coleo 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 RELAO.
Figura 1. Exemplo de uma relao com atributos e tuplas.
Na figura 1 pode ser observada a estrutura de uma relao, cujo nome ALUNO. Essa relao 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 da relao. Tambm podemos nos referir a uma tupla como uma instncia da relao. Cada valor em uma tupla um valor atomico, ou seja, no divisivel. Pode ser observado que existem atributos que receberam o valor null. Qual o significado do valor null? O valor null pode significar que para uma dada entidade do mundo real aquele atributo no se aplica, ou seja, a entidade em questo no pode ter um valor para aquele atributo. Por exemplo, em uma relao Pessoa, podemos encontrar o atributo Certificado_Reservista, porm valores para esse atributo so esperados apenas para pessoas do sexo masculino e maior de 18 anos. Ento, se uma pessoa do sexo feminino ou uma pessoa do sexo masculino menor de 18 anos for cadastrada nessa relao Pessoa, o atributo Certificado_Reservista no vai fazer sentido para ela, nesse caso atribuimos o valor null com o sentido de no se aplica. Outro significado possvel 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 informao como: os alunos Benjamin, Katherine e Barbara no possuem um telefone de escritrio (existem 3 possibilidades para esse fato: ou no trabalham - ento o atributo no se aplica; o local onde trabalham no possui telefone ou no quiseram informar o nmero - portanto o nmero desconhecido). No caso do aluno Dick percebemos que ele no possui telefone em casa, ou seja, no se aplica (ou no quis informar o nmero - valor desconhecido).
31/67
18/04/13
name
3.2 Restries do Modelo Relacional

O mundo real, abstraido em um banco de dados, determina regras de negcio que devem ser respeitadas nos valores armazenados nesse banco de dados. Ou seja, existe necessidade de explicitarmos restries para os valores que entraro no banco de dados conforme as regras de negcio impostas pelo minimundo representado nele. Segundo Elmasri e Navathe [ELMASRI 2005], as restries em banco de dados podem, geralmente, ser divididas em em 3 categorias principais: 1. restries inerentes ao modelo de dado, por exemplo, no modelo relacional existe a restrio de no poder existir tuplas repetidas em uma relao. 2. restries baseadas em esquema, ou seja, que podem ser expressas diretamente nos esquemas do modelo de dado. 3. restries baseadas em aplicao, ou seja, que no podem ser expressas diretamente nos esquemas do modelo de dado e, portanto, devem ser expressas nos programas de aplicao. Outra categoria importante de restries so as de dependncia de dados, incluindo as dependencias funcionais e as multivaloradas, que so utilizadas para verificar a excelencia do projeto de um banco de dados relacional. Abordaremos a segunda categoria de restries, que podem ser expressas no modelo relacional: domnio, chave, valores em null, integridade de entidade e integridade referencial.
32/67
18/04/13
name
3.3 Restries de Domnio

As restries de domnio estabelecem que dentro de cada tupla o valor atmico de um atributo deve pertencer a um domnio especificado. Isso significa que essas restries impem um limite nos possveis valores que podemos atribuir aos atributos de uma relao e, por consequncia, quais os possveis valores dessa relao. O domnio dever ser especificado para informar se os valores possveis so numricos (inteiros, reais), caracteres ou cadeias de caracteres fixos ou variveis, booleanos (verdadeiro ou falso), data, hora e, em alguns casos, existem at o tipo de dados de moeda. O domnio que poder ser especificado para um esquema de banco de dados est diretamente associado ao sistema gerenciador de banco de dados (SGBD) adotado para controlar o banco de dados. Ou seja, antes de implementar 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 definio de tipos do usurio, para que possamos definir tipos baseados naqueles pr-estabelecidos.
33/67
18/04/13
name
3.4 Restries de Chave

O modelo relacional um modelo baseado na matemtica. Seu principal conceito, o conceito de relao definido como um conjunto de tuplas. Um conjunto, na matemtica, definido como um conjunto de elementos distintos, portanto, todas as tuplas da relao tambm devem ser distintas [ELMASRI 2005]. Um subconjunto de atributos, menor ou igual ao conjunto de atributos da relao, com a propriedade de para quaisquer 2 tuplas da relao no terem as mesmas combinaes de valores para esses atributos chamado de superchave da relao. Uma superchave especifica uma restrio de unicidade de tupla, na qual duas tuplas distintas, no podem ter o mesmo valor para o conjunto de atributos que forma a superchave. Exemplo, seja a relao: Aluno(RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso) Existem algumas superchaves nessa relao, ou seja, existem subconjuntos dos atributos da relao Aluno que garantem unicidade de tupla da relao ( voc, leitor, sinta-se vontade para verificar essa afirmao!): 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. (RA, titulo_eleitor) (RA, titulo_eleitor, #RG) (RA, titulo_eleitor, #RG, OrgaoEmissorRG) (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome) (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo) (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade) (RA, titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso) (RA, #RG) (RA, #RG, OrgaoEmissorRG) (RA, #RG, OrgaoEmissorRG, nome) (RA, #RG, OrgaoEmissorRG, nome, sexo) (RA, #RG, OrgaoEmissorRG, nome, sexo, idade) (RA, #RG, OrgaoEmissorRG, nome, sexo, idade, curso) (RA, OrgaoEmissorRG) (RA, OrgaoEmissorRG, nome) (RA, OrgaoEmissorRG, nome, sexo) (RA, OrgaoEmissorRG, nome, sexo, idade) (RA, OrgaoEmissorRG, nome, sexo, idade, curso) (RA, nome) (RA, nome, sexo) (RA, nome, sexo, idade) (RA, nome, sexo, idade, curso) (RA, sexo) (RA, sexo, idade) (RA, sexo, idade, curso) (RA, idade) (RA, idade, curso) (RA, curso) (titulo_eleitor, #RG) (titulo_eleitor, #RG, OrgaoEmissorRG) (titulo_eleitor, #RG, OrgaoEmissorRG, nome) (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo) (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade) (titulo_eleitor, #RG, OrgaoEmissorRG, nome, sexo, idade, curso) (titulo_eleitor, OrgaoEmissorRG) (titulo_eleitor, OrgaoEmissorRG, nome) (titulo_eleitor, OrgaoEmissorRG, nome, sexo) (titulo_eleitor, OrgaoEmissorRG, nome, sexo, idade) (titulo_eleitor, OrgaoEmissorRG, nome, sexo, idade, curso) (titulo_eleitor, nome) (titulo_eleitor, nome, sexo) (titulo_eleitor, nome, sexo, idade) (titulo_eleitor, nome, sexo, idade, curso) (titulo_eleitor, sexo) (titulo_eleitor, sexo, idade) (titulo_eleitor, sexo, idade, curso) (titulo_eleitor, idade) (titulo_eleitor, idade, curso) (titulo_eleitor, curso) (#RG, OrgaoEmissorRG, nome) ( #RG, OrgaoEmissorRG, nome, sexo) ( #RG, OrgaoEmissorRG, nome, sexo, idade) ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso) ( #RG, OrgaoEmissorRG, nome) ( #RG, OrgaoEmissorRG, nome, sexo) ( #RG, OrgaoEmissorRG, nome, sexo, idade) ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso) ( #RG, OrgaoEmissorRG, sexo) ( #RG, OrgaoEmissorRG, sexo, idade) ( #RG, OrgaoEmissorRG, sexo, idade, curso)
34/67
18/04/13
name
61. 62. 63. 64. 65.
( #RG, OrgaoEmissorRG, idade) ( #RG, OrgaoEmissorRG, curso) (RA) (titulo_eleitor) (#RG, OrgaoEmissorRG)
Na realidade, talvez tenha esquecido alguma combinao de atributos que garanta a unicidade tambm, portanto, talvez ainda no estejam listadas todas as superchaves da relao 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 mnima, ou seja, uma superchave da qual no poderemos retirar sequer um atributo sob pena de no 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 de garantir a unicidade de tupla. Vejamos, vou verificar as duas primeiras superchaves, siga o mesmo raciocnio 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, ento a superchave 1 no superchave mnima, 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, ento a superchave 1 no superchave mnima, 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, ento a superchave 2 no superchave mnima. (RA, #RG)----- Existe alguma superchave que formada apenas por RA e #RG? Sim existe, a superchave 8,ento a superchave 2 no superchave mnima. (RA)----- Existe alguma superchave que formada apenas por RA? Sim existe, a superchave 63,ento a superchave 2 no superchave mnima. 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
52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65.
( #RG, OrgaoEmissorRG, nome, sexo, idade) ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso) ( #RG, OrgaoEmissorRG, nome) ( #RG, OrgaoEmissorRG, nome, sexo) ( #RG, OrgaoEmissorRG, nome, sexo, idade) ( #RG, OrgaoEmissorRG, nome, sexo, idade, curso) ( #RG, OrgaoEmissorRG, sexo) ( #RG, OrgaoEmissorRG, sexo, idade) ( #RG, OrgaoEmissorRG, sexo, idade, curso) ( #RG, OrgaoEmissorRG, idade) ( #RG, OrgaoEmissorRG, curso) (RA) ----- No existe outro atributo para ser retirado! Sendo assim, a superchave 63 uma superchave mnima! (titulo_eleitor) ----- No existe outro atributo para ser retirado! Sendo assim, a superchave 64 uma superchave mnima! (#RG, OrgaoEmissorRG) (#RG) ----- Existem nmeros de RG iguais emitidos por rgos emissores de estados diferentes, portanto se retirarmos OrgaoEmissorRG a propriedade de unicidade no mantida. Sendo assim, a superchave 65 uma superchave mnima! (OrgaoEmissorRG) ----- Os rgos emissores emitem diversos nmeros de RG, sendo assim existem distintos alunos com o mesmo rgo emissor, portanto se retirarmos #RG a propriedade de unicidade no mantida. Sendo assim, a superchave 65 uma superchave mnima!
Observe que apesar da relao aluno ter pelo menos 65 superchaves, possui apenas 3 chaves candidatas: {(RA), (titulo_eleitor), (#RG, OrgaoEmissorRG)}. Finalmente, chegamos ao conceito de Chave Primria. O conceito de chave primria bastante similar ao conceito de Identificador do modelo ER. A chave primria o conjunto de atributos escolhidos para garantir a unicidade da relao. A chave primria deve pertencer, obrigatoriamente, ao conjunto das chaves candidatas da relao. A rigor, podemos escolher qualquer uma das chaves candidatas para torn-la a chave primria da relao, mas podemos utilizar alguns critiros para "desempatar", por exemplo: - escolher a chave candidata com menor nmero de atributos. No exemplo, teramos 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 relao. No exemplo apresentado, o RA significa Registro Academico e parece ser a chave candidata mais representativa quando se fala em alunos.
36/67
18/04/13
name
3.5 Restrio de Integridade de Entidade

Estabelece que nenhum valor de chave primria pode ser um valor nulo (null). As restries de chave primria e de integridade de entidade so especificadas na prpria relao.
37/67
18/04/13
name
3.6 Restrio de Integridade Referencial e Chave Estrangeira

A restrio de integridade referencial classificada entre duas relaes e usada para manter a consistncia entre as tuplas nas duas relaes. A definio de integridade referencial est intrinsecamente relacionada ao conceito de chave estrangeira (FK - foreign key). Considere R1 e R2, duas relaes. Um conjunto de atributos FK de R1 uma chave estrangeira de R1, que faz referncia ou se refere relao R2, se satisfizer as duas regras: 1. os atributos de FK tem o(s) mesmo(s) domnio(s) que os atributos da chave primria (PK - primary key) de R2; diz-se que atributos de FK fazem referncia ou se referem relao 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. Ento t1[FK]=t2[PK], e dizemos que a tupla t1 faz referncia tupla t2. Se essas 2 condies forem asseguradas, ento uma restrio de integridade referencial garantida.
Figura 1. Restries de Integridade Referencial no esquema de um BD relacional Na figura 1 podemos identificar as chaves estrangeiras e as relaes referenciadas no esquema do BD Empresa. Na tabela EMPREGADO podemos perceber o atributo SuperSSN, que mantm o SSN do funcionrio que supervisor, neste caso temos uma chave estrangeira (FK) definida dentro da relao que est sendo referenciada. Ou seja, temos uma chave estrangeira recursiva representando um autorelacionamento do modelo entidade-relacionamento. Existe uma outra FK, DNO, que referencia a relao DEPARTAMENTO, representando onde o funcionrio est alocado. Em DEPARTAMENTO encontramos a FK GerSSN que referencia a relao EMPREGADO, para manter o gerente do departamento. Em PROJETO, encontramos DNUM que referencia a tabela DEPARTAMENTO para registrar qual o departamento que controla o projeto. Em DEPENDENTE temos a FK ESSN referenciando a relao EMPREGADO, para informar quem o responsvel pelo dependente, e que auxilia o atributo Nome_Dependente a formar a chave primria da relao. Alm dessas, temos as relaes que expressam relacionamentos (TRABALHA_EM) e atributos mulltivalorados (DEPTO_LOCALIZACOES). TRABALHA_EM tem sua chave primria formada pelas FKs ESSN , referenciando EMPREGADO, e PNO, referenciando PROJETO, para identificar os projetos nos quais os funcionrios trabalham. DEPTO_LOCALIZACOES tambm tem uma FK auxiliando na chave primria (DNumero, referenciando DEPARTAMENTO) para que possam ser definidas vrias localizaes para um mesmo departamento. Observe que atravs das chaves estrangeiras podemos relacionar as diversas relaes e a garantia de integridade referencial ir assegurar que sempre que uma tupla for referenciada, certamente ela existe. Em outros termos, apenas podemos atribuir um valor para uma chave estrangeira se esse valor existir como valor do atributo chave primria em alguma tupla da relao referenciada por ela.
38/67
18/04/13
name

Explicaes detalhadas sobre o emprego do modelo relacional no processo de projeto lgico e fsico de banco de dados podem ser encontradas em [ELMASRI 2005] E [SILBERCHATZ 2006].
39/67
18/04/13
name

Slides utilizados na videoaula sobre Modelo Relacional.
40/67
18/04/13
name
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 anlise de requisitos j estariam prontos, portanto partimos dos Requisitos de Dados). Como fruto da etapa de Projeto Conceitual obtivemos um esquema conceitual do banco de dados segundo o modelo de dados entidade-relacionamento e o expressamos atravs de um diagrama entidaderelacionamento (DER). A partir desse diagrama passaremos a desenvolver o projeto lgico do banco de dados. Nessa disciplina utilizaremos o modelo de dados relacional para nos apoiar nessa etapa. Portanto, ao final da etapa de Projeto Lgico obteremos um esquema lgico relacional do banco de dados.
Nesse captulo do livro virtual ser apresentado o procedimento a ser utilizado para obter o esquema lgico relacional a partir de um esquema conceitual representado pelo DER.
41/67
18/04/13
name
4.1 Esquema Conceitual do banco de dados Empresa

Nesse captulo utilizaremos o esquema conceitual de um banco de dados de empresa, apresentado na figura 1, como exemplo para obteno do esquema lgico.
Figura 1. Esquema conceitual do banco de dados Empresa [extraida de ELMASRI 2005]
42/67
18/04/13
name
4.2 Mapeamento dos Conjuntos de Entidades Regulares (ou Fortes)

Lembrando: o que um conjunto de entidades regulares? So aqueles conjuntos de entidades que possuem atributos suficientes para formar um identificador para o conjunto de entidades. No exemplo, quem so os conjuntos de entidades regulares? So aqueles representados por um retngulo com linha simples, ou seja: Empregado, Departamento e Projeto. Como mape-los? Para cada conjunto de entidades regulares criar uma relao com nome igual ou similar ao do conjunto de entidade incluindo todos os atributos simples e monovalorados desse conjunto de entidades. Assinalar como chave primria o conjunto de atributos identificador do conjunto de entidades. Cabe aqui, efetuar um estudo das chaves do conjunto de entidades, efetuando um levantamento sobre as superchaves da relao e as chaves candidatas culminando na escolha consciente da chave primria da relao. possvel 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 relao 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 relaes, apresentadas na figura 1:
Figura 1. Esquema lgico relacional aps mapeamento dos conjuntos de entidades regulares.
43/67
18/04/13
name
4.3 Mapeamento dos Conjuntos de Entidades Fracas

Lembrando: o que um conjunto de entidades fracas? um conjunto de entidades que no 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 entidades proprietria. Caso a cardinalidade expressa no conjunto de relacionamento Identidade leve a mltiplas ocorrncias de entidades fracas para cada entidade proprietria (1:N ou N:M), ento existe a necessidade de definio de um identificador parcial no conjunto de entidades fracas. Como mapear esses conjuntos de entidades fracas? O mapeamento similar ao explicado no captulo anterior, ou seja, devemos criar uma relao para cada conjunto de entidade fraca incluindo seus atributos simples e monovalorados. Todos os comentrios acerca dos atributos compostos e multivalorados tambm se aplicam aqui. A diferena est na determinao do atributo chave primria, pois nesse caso, a chave primria da relao ser uma chave estrangeira que referencia a relao que representa o conjunto de entidades proprietria. Caso tenha sido definido algum identificador parcial, esse deve tambm fazer parte da chave primria da nova relao. No exemplo temos o conjunto de entidades Dependente associado ao conjunto de entidades proprietrias Empregado pelo conjunto de relacionamento Identidade Dependente_de, cuja cardinalidade 1:N, portanto houve necessidade da definio de uma identificador parcial, o atributo Nome (em Dependente), conforme apresentado na figura 1.
Figura 1. Extrato do esquema conceitual do BD Empresa - Conjunto de Entidades Fracas com Identidade e Proprietria. O mapeamento desse conjunto de entidades gerou mais uma relao em nosso esquema relacional, conforme apresentado na figura 2.
Figura 2. Esquema lgico do banco de dados Empresa aps o mapeamento dos conjuntos de entidades fracas. Observe, na figura 2, que ESSN e Nome_Dependente formam a chave primria composta da relao Dependente. O ESSN uma chave estrangeira que referencia a relao empregado. Essa chave estrangeira aparece em decorrncia do mapeamento do conjunto de relacionamento Identidade Dependente_de.
44/67
18/04/13
name
4.4 Mapear Conjuntos de Relacionamentos Binrios 1:1

Lembrando: o que so conjuntos de relacionamentos binrios ou de grau 2? So 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 restrio 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 entidade de 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 binrios 1:1. Vamos discut-las neste captulo, porm salientando que a abordagem 1 a mais seguida e deve ser preferencialmente adotada, exceto se houver ocorrncias especficas que justifiquem a adoo de outra abordagem conforme ser explicado a seguir.
Figura 1. Extrato do esquema conceitual do BD Empresa - Conjunto de relacionamento binrio 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 ligao entre as relaes. Mas, qual delas escolher? A rigor voc pode escolher qualquer uma delas, porm recomendado que verifique se um dos conjuntos de entidade possui restrio de participao 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 relao e se a restrio de participao total isso implica que esse valor sempre dever ser preenchido (restrio not null). Caso ambas as restries sejam parciais, a escolha pode ser arbitrria (uni, duni, t, salam, mingue...) , ou seja, escolha qualquer das relaes e coloque a chave estrangeira referenciando a outra relao. Caso existam atributos no conjunto do relacionamento esses atributos (simples e monovalorados) devem ser incluidos na mesma relao que receber a chave estrangeira. Em nosso exemplo, como pode ser observado na figura 1, encontramos a restrio de participao total do lado de Departamento no conjunto de relacionamento Gerencia, isso nos auxilia na escolha da relao (DEPARTAMENTO) que ir receber o atributo chave estrangeira que indicar qual dos funcionrios o gerente do departamento. Observe que o atributo DataInicio tambm deve ser inserido na relao DEPARTAMENTO acompanhando a deciso de onde colocar a chave estrangeira. Analisemos o impacto de introduzir a chave estrangeira na relao EMPREGADO, que possui restrio de participao parcial no conjunto de relacionamentos Gerencia pois nem todo empregado gerente de departamento. Isso poderia ser feito porm o custo disso seria a introduo de valores null para esse atributo em todas as tuplas de empregado que no fossem gerentes (o que, obviamente, deve ser em nmero muito maior do que aqueles que so gerentes!). Outra possibilidade, que no recomendada a menos que se justifique plenamente, seria o de introduzir a chave estrangeira em ambas as relaes, porm, alm de grande nmero de valores null como explicado acima, poderamos ter problemas de consistncia na atualizao dessas tabelas. A justificativa mais plausvel para essa soluo a necessidade (muito forte!) de facilitar a navegao entre as tabelas. Isso s se justificaria se fossem previstas consultas muito frequentes que exigissem tal navegao. Podemos observar nossa nova verso do esquema lgico relacional do banco de dados Empresa na figura 2, onde esto salientados os atributos acrescentados na relao DEPARTAMENTO para refletir o conjunto de relacionamentos Gerencia. O atributo GerSSN a chave estrangeira que referencia a relao EMPREGADO, portanto, esse atributo deve pertencer ao mesmo domnio do atributo chave de EMPREGADO, o atributo SSN.
Figura 2. Esquema lgico relacional do banco de dados Empresa aps etapa de mapeamento dos conjuntos de relacionamentos binrios 1:1 Abordagem 2: Opo da relao unificada (ou relacionamento incorporado) Essa abordagem prev a incorporao dos conjuntos de entidade e do conjunto de relacionamento em uma s relao. Essa opo pode ser interessante quando ambas
18/04/13
name
as restries de participao so totais. Se fosse esse o caso em nosso exemplo, deveramos criar uma relao EmpregadoGerenciaDepartamento com todos os atributos de Empregado, todos os atributos de Departamento e o atributo do conjunto de relacionamento. Essa tabela substituiria as tabelas EMPREGADO e DEPARTAMENTO. muito fcil perceber que essa uma abordagem que no deve ser adotada trivialmente. Abordagem 3: Opo Referncia Cruzada (ou relao de relacionamento) Nessa abordagem deve ser gerada uma nova relao com as chaves estrangeiras para referenciar as relaes envolvidas no conjunto de relacionamento e o atributo presente no relacionamento. Essa abordagem deve ser evitada pois provoca, na maioria das vezes sem justificativas plausveis, um acrscimo de tempo na execuo de consultas pois envolve o uso da operao mais cara para o SGBD - a juno - como veremos nas unidades que tratam de linguagens de banco de dados. Essa nova relao gerada chamada de Relao de Relacionamento (ou tabela de busca) pois cada tupla representa uma instncia do relacionamento. Essa a soluo para os conjuntos de relacionamentos binrios N:M e para os de grau >2 (n-rios), como veremos nos prximos captulos.
46/67
18/04/13
name
4.5 Mapear Conjuntos de Relacionamentos Binrios 1:N

Retornando ao exemplo que estamos utilizando, temos os conjuntos de relacionamentos binrios 1:N - Superviso, Trabalha_Para e Controla - representados na figura 1. Perceba que temos ainda o conjunto de relacionamento Identidade Dependente_De que tambm 1:N, porm ns j o mapeamos quando mapeamos o conjunto de entidades fracas, lembra? Voc no deve mape-lo novamente! Lembrando: o que so conjuntos de relacionamentos binrios 1:N? Considere o conjunto de relacionamento binrio Controla entre DEPARTAMENTO e PROJETO, representado na figura 1, qual a semntica da restrio de cardinalidade 1:N? A semntica 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 restrio de cardinalidade nos diz que 1 departamento pode se relacionar com vrias entidades de PROJETO, correto? Ento, vejamos a figura 2.
47/67
18/04/13
name
Figura 2. Tentativa fracassada de mapeamento do conjunto de relacionamento 1:N - Controla Ou seja, no devemos inserir a chave estrangeira em DEPARTAMENTO! Devemos inserir na relao PROJETO, ento? A resposta sim! Vejamos a figura 3 para comprovar!
Figura 3. Mapeamento correto do conjunto de relacionamento 1:N - Controla Pode observar, na figura 3, que todas as instncias de PROJETO so nicas (no h valores de chave repetidos) e a informao de qual o departamento controlador tambm est toda representada! Anote a regra: Para mapear um conjunto de relacionamento 1:N, localizar a relao que representa o tipo de entidade do lado N do conjunto de relacionamento e inserir nessa relao a chave estrangeira da relao do lado 1. Essa a regra pois cada instncia do lado N se relaciona a apenas uma instncia do lado 1. Como ficou nosso esquema lgico do banco de dados Empresa? Vejamos o esquema lgico atual na figura 4.
48/67
18/04/13
name
Figura 4. Esquema lgico relacional do banco de dados EMPRESA aps mapeamento de conjuntos de relacionamentos binrios 1:N Algumas observaes importantes que voc pode conferir na figura 4: O conjunto de relacionamento Superviso em EMPREGADO, um autorelacionamento (ou relacionamento recursivo) porisso o mapeamento desse conjunto de relacionamento foi expressa na prpia relao EMPREGADO atravs da chave estrangeira, SuperSSN, que referencia a tabela EMPREGADO. Esse atributo mantm quem o supervisor imediato de cada instncia da relao. Mas como chegamos a concluso que deveramos manter o SSN do supervisor e no do supervisionado? Fcil, observando os papis 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 relao EMPREGADO possui tambm o atributo chave estrangeira DNO que referncia o DEPARTAMENTO onde o funcionrio trabalha. Alternativa de mapeamento: Podemos adotar a Tabela de Relacionamento (ou Tabela de Busca) como uma soluo alternativa de mapeamento caso existam poucas tuplas da relao que recebe a chave estrangeira participando do conjunto de relacionamentos, pois nesse caso, adotando a alternativa padro incluiramos muitos nulos. Essa soluo, como j explicado anteriormente, aplica-se no caso de conjuntos de relacionamentos binrios N:M e nos de grau maior que 2 (n-rios). No prximo captulo ser explicado como gerar essas Tabelas de Relacionamento.
49/67
18/04/13
name
4.6 Mapear Conjuntos de Relacionamentos Binrios 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 vrios 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 binrio M:N Para conjuntos de relacionamentos M:N adotamos a criao de uma Tabela de Relacionamento (ou Tabela de Busca), como j foi mencionado em captulos anteriores. Como construimos essa Tabela de Relacionamento? Devemos criar uma relao para representar o conjunto de relacionamento. Seguindo o exemplo, devemos criar uma relao Trabalha_Em, inserir duas chaves estrangeiras - ESSN e PNO - que respectivamente iro referenciar as tabelas EMPREGADO e PROJETO. Devemos acrescentar o atributo presente no conjunto de relacionamentos - horas. Como podemos definir uma chave primria para essa nova relao? A chave primria da relao deve ser composta pelos atributos que so chaves estrangeiras - ESSN e PNO. Observaes Importantes: Essa a nica situao de mapeamento de conjuntos de relacionamentos binrios em que as chaves estrangeiras passam a fazer parte da chave primria da relao que a recebe. A utilizao da Tabela de Relacionamento para conjuntos de relacionamentos binrios 1:1 e 1:N no so incentivados mas podem ser particularmente teis quando a relao que recebe a chave estrangeira tem poucas entidades que participam efetivamente do relacionamento para evitar o excesso de valores null na tabela. Nesses casos, a chave primria da Tabela de Relacionamentos ser apenas uma das chaves estrangeiras (e no as 2 como nos conjuntos de relacionamentos M:N). Nosso esquema lgico relacional aps o mapeamento do conjunto de relacionamentos Trabalha_Em apresentado na Figura 2.
Figura 2. Esquema lgico relacional do BD Empresa aps o mapeamento dos conjuntos de relacionamentos N:M.
50/67
18/04/13
name
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 nmero de conjuntos de entidades participantes, por exemplo, a determinao das restries de cardinalidades em um conjunto de relacionamentos ternrios (com 3 conjuntos de entidades participantes) devem ser obtidas efetuando a anlise de dois conjuntos de entidades contra o terceiro conjunto de entidade. Nosso exemplo no possui ternrios, portanto vamos considerar a seguinte situao: queremos representar a situao de fornecimento de lotes de peas para projetos. Suponha que tenhamos obtido o esquema conceitual mostrado na figura 1 para representar essa situao.
Figura 1. O conjunto de relacionamento ternrio FORNECE sem as restries de cardinalidade Como podemos descobrir as restries de cardinalidade desse conjunto de relacionamentos ternrios? Devemos fazer as seguintes questes: Dados 1 projeto e 1 lote quantos fornecedores podem fornecer o lote de peas para aquele projeto? Dados 1 lote e 1 fornecedor quantos projetos podem receber o fornecimento do lote de peas daquele fornecedor? Dados 1 fornecedor e 1 projeto quantos lotes de peas 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 funo do aumento de complexidade envolvida em n-rios, recomenda-se bastante firmemente que sejam buscadas alternativas de modelagem se voc se deparar com um conjunto de relacionamentos com grau maior do que 3. Procure ter em mente que o maior grau recomendado o grau 3. Dependendo das restries de cardinalidade indicadas no conjunto de relacionamentos n-rios voc dever optar por uma forma de mape-lo: Caso todas as restries de cardinalidade sejam mltiplas (N:N:N) voc deve utilizar uma Tabela de Relacionamento onde a chave primria composta por todas as chaves estrangeiras inseridas na nova relao e inserir nela tambm os atributos simples e monovalorados presentes no conjunto de relacionamento. Supondo que a resposta a cada uma das questes anteriores tenham sido: vrios (N), a restrio de cardinalidade em Fornece N:N:N conforme apresentada na figura 2.
Figura 2. O conjunto de relacionamento ternrio FORNECE com as restries de cardinalidade N:N:N O mapeamento do conjunto de relacionamentos Fornece seria a criao da relao FORNECE com as chaves estrangeiras: Fornecedor, Projeto, Lote referindo-se respectivamente s relaes FORNECEDOR, PROJETO e LOTE. Alm delas incluiramos o atributo Quantidade presente no relacionamento Fornece. A chave primria da relao seria composta pelas trs chaves estrangeiras. Caso alguma das restries de cardinalidade seja 1 (1:N:N) ou (1:1:N) ou (1:1:1) ento a chave estrangeira referente quele conjunto de entidades que possui restrio de cardinalidade 1 no deve entrar na chave primria. No ltimo caso citado (1:1:1) apenas uma delas seria chave primria. No exemplo acima vamos supor que dado um projeto e um lote podemos encontrar apenas um fornecedor, ou seja, a restrio de cardinalidade desse conjunto de relacionamento seria 1:N:N, conforme apresentado na figura 3.
Figura 3. O conjunto de relacionamento ternrio FORNECE com as restries de cardinalidade 1:N:N Nesse caso, o mapeamento levaria construo de uma relao FORNECE com as chaves estrangeiras referentes a cada relao participante e o atributo do relacionamento, porm a chave primria seria composta apenas pelas chaves estrangeiras Projeto e Lote.
18/04/13
name
Observao Importante: um conjunto de relacionamento Identidade (que associa um conjunto de entidades fracas sua proprietria) pode ser de grau maior que 2, porm o mapeamento segue o mesmo procedimento adotado em casos de conjuntos de relacionamento Identidade de grau 2.
52/67
18/04/13
name
4.8 Mapear atributos multivalorados

Em nosso exemplo encontramos o atributo Localizaes 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 localizaes. 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 necessrios para o atributo multivalorado. Consiste em gerar uma nova relao, essa relao deve conter o atributo multivalorado (ou os componentes simples e monovalorados dele caso seja 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 primria dessa nova relao composta pelos atributos descritores do multivalorado e pela chaves estrangeira. incluir o atributo na chave primria da relao que o contm Soluo 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 primria da relao que representa o conjunto de entidades que originalmente o continha. incluir, na relao que o contm, um conjunto de atributos equivalente ao nmero de valores que podemos associar a uma nica entidade Essa soluo s se aplica caso conheamos qual o nmero de possveis valores esperados para aquele atributo multivalorado. Esse nmero deve ser conhecido e pequeno (at 3 ocorrncias se o atributo multivalorado for simples). O mapeamento consiste em acrescentar um conjunto de atributos equivalente ao nmero de ocorrncias esperadas na relao que representa o conjunto de entidades que originalmente continha o atributo multivalorado. Em nosso exemplo adotamos a primeira alternativa, ou seja, geramos uma nova relao DEPTO_LOCALIZACOES com o atributo chave estrangeira DNumero que referencia a relao DEPARTAMENTO e o atributo DLocalizacao que o descritor do atributo multivalorado. Ambos os atributos fazem parte da chave primria dessa nova relao, conforme apresentado na figura 1.
Figura 1. Esquema lgico relacional do BD Empresa aps o mapeamento do atributo multivalorado
53/67
18/04/13
name
4.9 Esquema Lgico Relacional do banco de dados Empresa

Ao final das etapas descritas nos captulos anteriores, com exceo daquele que tratou de conjuntos de relacionamentos n-rios, o projeto lgico relacional de nosso exemplo chega ao fim e podemos ento gerar o esquema lgico relacional completo para o banco de dados Empresa, assinalando as chaves estrangeiras e a quem elas referenciam. O esquema lgico relacional completo apresentado na figura 1. As setas partem das chaves estrangeiras e apontam para as relaes referenciadas por elas.
Figura 1. Esquema lgico relacional para o banco de dados Empresa
54/67
18/04/13
name

Slides da videoaula sobre mapeamento DER para relacional.
55/67
18/04/13
name
4.11 Exerccio complementar

Obter o esquema lgico relacional a partir do esquema conceitual gerado no exerccio do captulo 2.
56/67
18/04/13
name
5 Dependncias Funcionais Dependncias Multivaloradas e Normalizao

Neste captulo, vamos explorar os conceitos sobre dependncias funcionais, dependncias multivaloradas e o impacto desses conceitos sobre o processo de normalizao do esquema relacional que obtivemos. Mas, para que serve a Normalizao? A Normalizao, na etapa em que nos encontramos de desenvolvimento de um sistema de banco de dados, serve para validar o nosso esquema lgico relacional. Ou seja, precisamos ter algum instrumento que nos auxilie a verificar se o esquema obtido no possui algum problema que possa impactar negativamente na segurana do banco de dados. Esse instrumento a normalizao. Existem abordagens, alternativas quela que estamos empregando em nosso curso, que utilizam a normalizao como ferramenta para obteno do esquema lgico relacional. Ou seja, essas abordagens partem do conjunto de dados obtidos nos requisitos do sistema e os organizam por intermdio do processo de normalizao. No se assustem com o formalismo empregado para a definio das formas normais, pois passado o primeiro susto vocs percebero que no to difcil como imaginaram! Preparados para mais uma etapa a ser vencida? Ento avancemos! Boa leitura!
57/67
18/04/13
name
5.1 Processo de Normalizao
O processo de normalizao pode envolver diversas formas normais, no entanto, nesta disciplina sero apresentadas apenas a Primeira Forma Normal (1FN), Segunda Forma Nor
Um projeto de sistema de banco de dados, que parte de um conjunto de requisitos, com um bom projeto conceitual e um projeto lgico relacional adequado possui, normalmente, u O que isso significa? Diz-se que um "bom" sistema de banco de dados relacional contm esquemas relao que atendem a, no mnimo, a terceira forma normal! Ento, pode-se deduzir que projetos de sistemas de banco de dados quando executados com cuidado encaminham a bons esquemas lgicos relacionais!
Porm, se for necessrio 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 O livro do Heuser traz uma boa idia de como a normalizao pode auxiliar esse processo de re-engenharia.
Nos prximos captulos sero apresentadas as formas normais acima citadas e os conceitos de dependncias funcionais e multivaloradas necessrias para o bom entendimento das m
58/67
18/04/13
name
5.2 Dependncias Funcionais

Alguns conceitos so necessrios para o estudo adequado das formas normais. O primeiro dos conceitos o de dependncia funcional. A aplicao desse conceito permite ao projetista do banco de dados retratar algumas regras de negcio que relacionam atributos de uma mesma relao. Definio: 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. Notao: A B Por exemplo, as pessoas que moram no Brasil sabem que para o envio de uma correspondncia devem incluir o Cdigo de Endereamento Postal (CEP) da localidade destino, assim como devem incluir o CEP da localidade origem (para o caso de no localizar o destinatrio). Sabe-se mais: uma cidade pode conter diversos cdigos de endereamentos, porm um CEP identifica uma, e somente uma, localidade no Brasil. Essa informao capturada utilizando o conceito de dependncia funcional entre os atributos CEP e Cidade, por exemplo. Denota-se: CEP cidade Como garantir que em um sistema de banco de dados no possam ser incluidas duas localidades distintas com o mesmo CEP? O primeiro passo descobrir que existe tal interdependncia! Nos prximos captulos sero discutidas as solues para garantia da integridade na base de dados. Em resumo: Faz-se necessrio identificar essas interdependncias entre os atributos, identificando as dependncias funcionais, para que se possa, na medida do possvel, garantir a integridade dos mesmos.
59/67
18/04/13
name
5.3 Dependncias Funcionais Parciais

Pode-se determinar as formas normais de um esquema relacional, tomando-se por referncia apenas a chave primria da relao, porm, nesta disciplina ser adotada a abordagem de determinar a forma normal tomando por referncia todas as chaves candidatas presentes na relao. Ma o que uma chave candidata mesmo? uma superchave mnima! Os atributos pertencentes a chaves candidatas so chamados de atributos primos. Podem ser encontradas ambas as abordagens no livro de Elmasri e Navathe. Sendo assim, a definio de uma dependncia funcional parcial a seguinte: Se A for chave da relao e o valor de um subconjunto de atributos de A permite descobrir o valor de um outro conjunto B, dizemos que B possui dependncia funcional parcial em relao a A. Ou seja, a dependncia 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 relao. Por exemplo, considere a relao: Matricula(RA, SiglaDisc, nome_aluno, descr_disciplina, mdia) Considerando que a nica chave candidata presente nessa relao a chave composta por RA e SiglaDisc, faz-se a seguinte anlise: Para que se determine o nome do estudante, faz-se necessrio conhecer ambos os valores dos atributos da chave? A resposta NO! Basta que se conhea o valor do RA, para que se conhea o nome do estudante. Isso significa que est presente, nesta relao, a dependncia funcional: RA nome_aluno Isto implica que existe uma dependncia funcional parcial em relao chave candidata da relao (RA, SiglaDisc), pois apenas parte da chave j determina o atributo nome_aluno. Continuando a anlise percebe-se ainda que existem as seguintes dependncias funcionais: RA, SiglaDisc mdia ok, depende da chave candidata completa; SiglaDisc descr_disciplina indica dependncia funcional parcial. Em resumo: Caso decida-se manter a tabela matrcula como: Matricula(RA, SiglaDisc, nome_aluno, descr_disciplina, mdia) Como ser possvel garantir que no existam dois nomes de estudantes distintos associados ao mesmo registro acadmico (RA), conforme a dependncia funcional identificada (RA nome_aluno)? Ou ainda, como poder ser garantido que no sero registradas mais de uma disciplina associadas mesma Sigla, conforme a dependncia funcional (SiglaDisc descr_disciplina)? Nos captulos seguintes sero apresentadas as solues para que possam ser garantidas essas restries de integridade identificadas nas regras de negcio.
60/67
18/04/13
name
5.4 Dependncias Funcionais Transitivas

Considere uma relao R, com os atributos X, Y, A, e as seguintes dependncias funcionais vlidas sobre R: DF1: X Y DF2: Y A e no existe a DF3: Y X (ou seja, Y no primo) Diz-se que A transitivamente dependente de X, pois possvel obter seu valor a partir de Y e este, por sua vez, determinado por X.
61/67
18/04/13
name
5.5 Primeira Forma Normal - 1FN

Uma tabela est na 1FN se no contm tabelas aninhadas, ou seja, ela no deve conter atributos multivalorados e nem atributos compostos.
Um exemplo de uma tabela no-normalizada (n): Aluno(RA, nome, {(e-mail: login, domnio)}), onde {(e-mail: login, domnio)} implica que o atributo e-mail multivalorado e com
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 representao d
DER_Aluno
Observe que se fossem seguidos os passos para o mapeamento do DER para o esquema relacional, seriam obtidas as seguintes relaes: Aluno(RA, nome) EmailAluno(RA, login, domnio) *
*Adotando a construo de uma nova tabela para representar o atributo multivalorado e-mail, como esse atributo tambm composto, ento foram acrescidos os atributos login e d Ou seja, conforme j mencionado, efetuando-se o mapeamento adequado obtm-se as relaes j normalizadas. Em resumo: n: Aluno(RA, nome, {(e-mail: login, domnio)}) Na primeira forma normal (pelo menos): Aluno(RA, nome)
EmailAluno(RA, login, domnio)
62/67
18/04/13
name
5.6 Segunda Forma Normal - 2FN

Uma relao dita estar na segunda forma normal, quando atende aos seguintes requisitos: estar na 1FN no existem atributos no primos dependentes parcialmente de alguma chave candidata da relao Ou seja, caso ocorram dependncias funcionais parciais, estas devem estar associadas a algum atributo primo (atributo que faz parte de alguma chave candidata), caso contrrio, a relao no atende 2FN. Seja o exemplo da relao Alocao, considerando como nica chave candidata da relao a chave composta (Sigla, Turma): Alocao(Sigla, Turma, sala, crditos) Sabe-se que existem as seguintes dependncias funcionais (DF)presentes: DF1: Sigla, Turma sala DF2: Sigla crditos A DF1, indica que faz-se necessrio conhecer os valores de todos os atributos pertencentes chave para que se possa determinar a sala onde haver a aula. Porm a DF2, indica que se for conhecido o valor de Sigla, pode-se determinar o nmero de crditos da disciplina. Por exemplo, a disciplina de Banco de Dados, cuja sigla BD possui 4 crditos. Esse fato independe de qual a turma de alunos que participa das aulas dessa disciplina. Portanto, a DF2 representa uma dependncia funcional parcial de crditos em relao chave candidata da relao (Sigla, Turma). Deve-se, ento, verificar se o atributo crditos um atributo primo. Como a resposta NO, pois o atributo crditos no faz parte de qualquer chave candidata da relao, ento pode-se afirmar que a relao Alocao no atende segunda forma normal! O que fazer para normalizar essa relao para que atenda 2FN? Deve-se particionar a relao original de forma a extrair a dependncia funcional parcial que a est inviabilizando atender 2FN. Sendo assim, obtm-se as seguintes relaes: Alocao(Sigla, Turma, Sala), onde (Sigla, Turma) a chave candidata da relao e est mantida a dependncia funcional DF1. Disciplina(Sigla, Crditos), onde (Sigla) a chave candidata da relao e est mantida a dependncia funcional DF2. Assim, ambas as relaes obtidas atendem segunda forma normal.
63/67
18/04/13
name
5.7 Terceira Forma Normal - 3FN

Uma relao dita estar na terceira forma normal se atende aos seguintes requisitos: est na 2FN todos os seus atributos no primos so dependentes no-transitivos de uma chave candidata. Seja o seguinte exemplo: Alocao(Sigla, Turma, Sala, Prdio) onde sabe-se que so vlidas as seguintes dependncias funcionais: DF1: Sigla, Turma Sala, Prdio DF2: Sala Prdio Observa-se que, conforme explicitado na DF1, a chave candidata da relao composta por Sigla e Turma. Percebe-se, ainda, que o atributo Prdio no depende diretamente da chave candidata, basta que se conhea o valor do atributo sala para que se determine qual o prdio onde se encontra tal sala. Dessa forma, a DF2 remete a uma dependncia funcional transitiva do atributo Prdio em relao chave candidata da relao. Sendo assim, resta verificar se o atributo Prdio um atributo primo, o que no se confirma, pois o mesmo no pertence a qualquer chave candidata da relao. Desta forma, pode-se afirmar que a tabela Alocao no 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: Alocao(Sigla, Turma, Sala) onde mantm-se a DF: Sigla, Turma Sala Local(Sala, Prdio) onde mantm-se a DF: Sala Prdio Desta forma, as relaes obtidas atendem Terceira Forma Normal!
64/67
18/04/13
name
5.8 Terceira Forma Normal - 3FN (Alternativa)

Uma forma alternativa de verificar se uma relao se encontra na 3FN a que se segue: Liste as dependncias funcionais (DF) vlidas (ou que devem ser verificadas na relao) Para cada DF na forma X Y ou X uma superchave da relao ou Y um atributo primo Ou seja, devem ser analisadas cada DF, caso o antecedente da dependncia funcional (lado X) seja uma superchave, ento j pode ser assumido que a relao encontra-se na Terceira Forma Normal. Caso contrrio, se X no for superchave, pode-se ainda verificar o consequente (lado Y) e verificar se esse um atributo primo. Caso Y faa parte de alguma chave candidata, ento pode-se afirmar que a relao atende Terceira Forma Normal. No exemplo visto no captulo anterior: Alocao(Sigla, Turma, Sala, Prdio) onde sabe-se que so vlidas as seguintes dependncias funcionais: DF1: Sigla, Turma Sala, Prdio DF2: Sala Prdio Analisando a DF1, verifica-se que Sigla, Turma uma superchave da relao pois determina todos os demais atributos da relao. Ento, por essa DF, a tabela atende 3FN. Porm, analisando a DF2, percebe-se que Sala no uma superchave. Verifica-se ento se o atributo Prdio um atributo primo. Sabe-se que Prdio no atributo primo, portanto, a tabela no atende 3FN.
65/67
18/04/13
name
5.9 Forma Normal de Boyce-Codd - FNBC

Uma relao dita estar na forma normal de Boyce-Codd se atende aos seguintes requisitos: est na 2FN todos os seus atributos so dependentes no-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 chave candidata da relao! Mesmo atributos primos devem atender a essa exigncia! Um jeito prtico de descobrir se a a tabela est na FNBC listando todas as DFs vlidas, na forma X Y, e verificando se todas possuem o antecedente (lado X) como superchave. Essa a nica condio que deve ser avaliada. Desta forma, fcil perceber que podem ser encontradas relaes que atendem 3FN mas no atendem FNBC. Por outro lado, percebe-se tambm que toda relao que atende FNBC atende tambm a 3FN. Observe o seguinte exemplo: Propriedade(IDProp, NomeRegio, Lote, Area) com as seguintes DFs vlidas sobre ela: DF1: IDProp NomeRegio, Lote, Area DF2: NomeRegio, Lote IDProp,Area DF3: Area NomeRegio Pode ser observado que DF1 e DF2, tem superchaves como seus antecedentes pois ambos definem chaves candidatas da relao. Porm na DF3, Area no superchave, portanto a relao no encontra na FNBC. Seguindo o mesmo procedimento visto nos captulos anteriores, deve-se normalizar a tabela extraindo a DF que est ferindo a FNBC: Propriedade(IDProp, Lote, Area), onde so atendidas as dependncias funcionais: DF1: IDProp Lote, Area DF2: Lote IDProp,Area Divisao(Area, NomeRegio), onde atendida a dependncia funcional: DF3: Area NomeRegio Portanto, ambas as relaes derivadas encontram-se na FNBC.
66/67
18/04/13
name
5.10 Material Complementar - Slides

Slides utilizados na videoaula sobre dependencias funcionais e normalizao.
67/67

Livro de Banco de Dados - Ufscar

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Livro de Banco de Dados - Ufscar

Diunggah oleh

Hak Cipta:

Format Tersedia

18/04/13

Livro Virtual de Sistemas de Banco de Dados

EaD - SEaD Sistemas de Banco de Dados (G4)

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 Dados

1.6 Pessoas em torno de um Sistema de Banco de Dados

1.7 Arquitetura de trs-esquemas

Figura 1 - Arquitetura Three-Schema (extrada de [ELMASRI 2006])

1.8 Independncia de Dados

1.9 Linguagens de Banco de Dados

1.10 Software Gerenciador de Banco de Dados

Figura 1 - Arquitetura simplicada dos componentes de SGBD. (extrada de [ELMASRI 2006])

1.11 Exerccios complementares

1.12 Indicao 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

Figura 2 - DER do banco de dados Empresa (extrada de [ELMASRI 2005])

2.3 Relacionamentos e Conjuntos de Relacionamentos

2.4 Atributos de Entidades ou Relacionamentos

2.5 Diagrama Entidade-Relacionamento (DER)

Figura 1 - Resumo da Notao do DER

Figura 5 - Conjuntos de Relacionamentos de Restrio de Cardinalidade.

Figura 6 - Conjunto de Relacionamento de Grau 3.

Figura 7 - Restries de Participao Total e Parcial

Figura 8 - Conjunto de Entidade Fraca

2.6 Exerccio complementar

2.7 Indicao de Leitura Complementar

2.8 Material Complementar

3 Modelo de Dados Relacional

3.1 Conceitos do Modelo Relacional

Figura 1. Exemplo de uma relao com atributos e tuplas.

3.2 Restries do Modelo Relacional

3.3 Restries de Domnio

3.4 Restries de Chave

61. 62. 63. 64. 65.

3.5 Restrio de Integridade de Entidade

3.6 Restrio de Integridade Referencial e Chave Estrangeira

3.7 Indicao de Leitura Complementar

3.8 Material Complementar

4 Projeto de Banco de Dados Relacional

4.1 Esquema Conceitual do banco de dados Empresa

Figura 1. Esquema conceitual do banco de dados Empresa [extraida de ELMASRI 2005]

4.2 Mapeamento dos Conjuntos de Entidades Regulares (ou Fortes)

4.3 Mapeamento dos Conjuntos de Entidades Fracas

4.4 Mapear Conjuntos de Relacionamentos Binrios 1:1

4.5 Mapear Conjuntos de Relacionamentos Binrios 1:N

4.6 Mapear Conjuntos de Relacionamentos Binrios N:M

4.7 Mapear Conjuntos de Relacionamentos n-rios (grau > 2)

4.8 Mapear atributos multivalorados

Figura 1. Esquema lgico relacional do BD Empresa aps o mapeamento do atributo multivalorado

4.9 Esquema Lgico Relacional do banco de dados Empresa

Figura 1. Esquema lgico relacional para o banco de dados Empresa

4.10 Material Complementar

4.11 Exerccio complementar

5 Dependncias Funcionais Dependncias Multivaloradas e Normalizao

5.1 Processo de Normalizao

5.2 Dependncias Funcionais

5.3 Dependncias Funcionais Parciais

5.4 Dependncias Funcionais Transitivas

5.5 Primeira Forma Normal - 1FN