Livro banco de_dados_volume_03

13,125 views

Published on

Livro banco de_dados_volume_03

  1. 1. UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE) COORDENAÇÃO GERAL DE EDUCAÇÃO A DISTÂNCIA (EAD/UFRPE) Banco de Dados Sandra de Albuquerque Siebra Volume 3 Recife, 2010
  2. 2. Universidade Federal Rural de PernambucoReitor: Prof. Valmar Corrêa de AndradeVice-Reitor: Prof. Reginaldo BarrosPró-Reitor de Administração: Prof. Francisco Fernando Ramos CarvalhoPró-Reitor de Extensão: Prof. Paulo Donizeti SiepierskiPró-Reitor de Pesquisa e Pós-Graduação: Prof. Fernando José FreirePró-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo FerreiraPró-Reitora de Ensino de Graduação: Profª. Maria José de SenaCoordenação Geral de Ensino a Distância: Profª Marizete Silva SantosProdução Gráfica e EditorialCapa e Editoração: Rafael Lira, Italo Amorim e Arlinda TorresRevisão Ortográfica: Elias VieiraIlustrações: Noé AprígioCoordenação de Produção: Marizete Silva Santos
  3. 3. Sumário Apresentação................................................................................................................. 4 Conhecendo o Volume 3 ................................................................................................ 5 Capítulo 7 – O Modelo Relacional .................................................................................. 7 O Modelo Relacional (MR) ..............................................................................................7 Conceitos do Modelo Relacional .....................................................................................8 Regras de Integridade Fundamentais ............................................................................14 As 12 Regras de Codd ....................................................................................................18 Capítulo 8 – Derivando o MR a partir do MER .............................................................. 25 Algumas Informações Iniciais ........................................................................................25 Regras para Derivar o Modelo Relacional a partir do MER............................................26 Capítulo 9 – Normalização de Dados ............................................................................ 41 Dependências Funcionais ..............................................................................................41 Anomalias de Atualização ..............................................................................................43 O que é Normalização?..................................................................................................45 Primeira Forma Normal (1FN) .......................................................................................47 Segunda Forma Normal .................................................................................................49 Terceira Forma Normal ..................................................................................................52 Forma Normal de Boyce-Codd ......................................................................................55 Quarta Forma Normal ...................................................................................................56 Quinta Forma Normal ....................................................................................................58 Um Roteiro para a Normalização ...................................................................................60 Algumas Informações Adicionais ...................................................................................60 Considerações Finais .................................................................................................... 67 Conheça a Autora ........................................................................................................ 69
  4. 4. Apresentação Caro(a) cursista, Seja bem-vindo(a) ao terceiro módulo do curso Banco de Dados! Neste terceiro módulo, vamos estudar o modelo relacional e todas as suas nuances. O modelo relacional éo resultado da modelagem lógica do Banco de Dados e é a etapa seguinte a modelagem conceitual. Dentro deste contexto, estudaremos como tranformar a modelagem conceitual em modelagem lógica,como otimizar o modelo criado através das regras de normalização e como fazer as checagens de integridadereferencial. Bons estudos! Sandra de Albuquerque Siebra Autora4
  5. 5. Banco de DadosConhecendo o Volume 3 Neste terceiro volume, você irá encontrar o Módulo 3 da disciplina de Banco deDados. Para facilitar seus estudos, veja a organização deste segundo módulo. Módulo 3 – Modelagem Lógica e Projeto de Banco de Dados Carga horária do Módulo 3: 15 h/aula Objetivo do Módulo 3: » Introduzir os principais conceitos e definições relacionados à modelagem lógica de dados. » Examinar os principais conceitos envolvidos no modelo relacional. » Estudar como derivar a modelagem lógica a partir da modelagem conceitual. » Estudar como otimizar a modelagem de dados através da normalização. Conteúdo Programático do Módulo 3: » O Modelo Relacional. » As 12 Regras de Codd. » Transformação do Modelo E-R para o Modelo Relacional. » Restrições de Integridade. » Dependências Funcionais. » Normalização de Dados. 5
  6. 6. Banco de Dados Capítulo 7 O que vamos estudar neste capítulo? Neste capítulo, vamos estudar os seguintes temas: » O Modelo Relacional. » Restrições de Integridade. » As 12 Regras de Codd. Metas Após o estudo deste capítulo, esperamos que você consiga: » Identificar as particularidades e os componentes do Modelo Relacional. » Fazer a checagem de integridade do modelo. » Reconhecer as 12 regras de Codd.6
  7. 7. Banco de DadosCapítulo 7 – O Modelo Relacional Vamos conversar sobre o assunto? No projeto de Banco de Dados, a modelagem lógica ou projeto lógico é a terceiraetapa (vide Figura 1), antecedida pela análise de requisitos e pela modelagem conceitual.O produto dessa etapa é o modelo relacional ou esquema relacional e este é justamente oassunto desse capítulo! Esse modelo já é dependente do SGBD que for ser escolhido paraa implementação do banco de dados. Logo, atente para o fato de que esse é o momentodessa decisão ser tomada. Neste capítulo, vamos falar sobre o modelo relacional, que é um exemplo demodelo lógico de dados, e sobre os conceitos a ele relacionados. Figura 1 - Etapas do Projeto de Banco de DadosO Modelo Relacional (MR) Vamos relembrar... o que é o modelo lógico? É um modelo que vai especificar arepresentação/declaração dos dados de acordo com o SGBD escolhido, definindo assim aestrutura de registros do BD (onde cada registro define número fixo de campos (atributos)e cada campo possui tamanho fixo). Um exemplo de modelo lógico é o modelo relacional(MR). Os SGBDs que utilizam o MR são denominados SGBDs Relacionais e, nesta disciplina,trataremos do projeto lógico apenas desse tipo de SGBD. 7
  8. 8. Banco de Dados O Modelo Relacional foi introduzido por Ted Codd, da IBM Research, em 1970, em um artigo clássico (Codd, 1970) que imediatamente atraiu a atenção em virtude de sua simplicidade e base matemática. O modelo usa o conceito de uma relação matemática – algo como uma tabela de valores – como seu bloco de construção básica e tem sua base teórica na teoria dos conjuntos. As primeiras implementações comerciais do modelo relacional tornaram-se disponíveis no início da década de 80, antes disso, eram utilizados os modelos de redes e hierárquico (sobre os quais estudamos no Volume 1, capítulo 1). O modelo relacional tem como objetivos: prover esquemas de fácil utilização; melhorar a independência lógica e física de dados; prover os usuários com linguagens de manipulação de BD de alto nível, permitindo o seu uso por usuários não experientes; otimizar o acesso aos BDs e melhorar a integridade e segurança dos dados. Comentário O MR representa os dados do BD como relações1 (tabelas) de nomes únicos. O conceito de tabelas está intimamente ligado ao conceito de uma relação matemática – de1 A palavra relação éutilizada no sentido onde se origina o nome deste modelo. Vamos apresentar, na seção a seguir, cada um dosde lista ou rol de conceitos relevantes dentro do contexto do modelo relacional.informações e não nosentido de associaçãoou relacionamento. Conceitos do Modelo Relacional Em um ambiente de banco de dados relacional utilizamos alguns conceitos muito importantes para a correta implantação e operação de qualquer sistema de banco de dados. Por exemplo, na terminologia do modelo relacional, cada tabela é chamada relação e vai possuir um nome único que a identifica, cada linha da tabela é chamada tupla, cada cabeçalho de coluna é conhecido como atributo (vide Figura 2). Figura 2 - Exemplos de Terminologias do Modelo Relacional Alguns desses novos termos originam-se diretamente da Teoria de Conjuntos, outros são decorrentes da utilização de elos lógicos para implementar os relacionamentos entre os dados armazenados no banco de dados. A seguir, cada um dos conceitos fundamentais do modelo relacional será descrito. Tabela ou Relação No modelo relacional, a estrutura que armazena os dados referentes a cada uma das ocorrências de uma entidade ou relacionamento com atributos do MER é chamada de tabela ou relação. Uma tabela é uma representação bi-dimensional de dados composta de linhas e colunas. Por exemplo, a tabela de empregados de uma empresa (vide Tabela 1) onde 8
  9. 9. Banco de Dadospoderiam ser armazenados dados como o CPF, o nome e o telefone de cada empregado. Atabela como um todo representaria os empregados da empresa. Cada coluna representariaum atributo (ex: a primeira coluna da Tabela 1 é o CPF ). E cada linha da tabela representa osdados de um empregado. Por exemplo, a primeira linha da Tabela 1 se refere à empregadade CPF número 987675456-98, de nome Ana Marques e cujo telefone é 3245-8976. Tabela 1 - Tabela ou Relação Empregado CPF Nome Telefone 987675456-98 Ana Marques 3245-8976 765456243-45 João Pontes 3124-5645 213415467-89 Marcos Alves 3456-8923 567324980-03 Tânia Gomes 3455-9098 Comentário Matematicamente, define-se uma relação como um subconjunto de um produtocartesiano de uma lista de domínios2. Assim, suponha que D1 denote o domínio do atributo 2 Um domínio contémA1, D2 denote o domínio do atributo A2 e Dn denote o domínio do atributo N da tabela T1. os valores possíveisQualquer linha da tabela que possui estes atributos é denotada pela tupla3 (d1,d2,...,dn) em para um determinadoque d1, d2 e dn têm como valores possíveis (domínios), respectivamente D1, D2 e Dn. Em atributo da relação.geral, uma instância de T1 é um subconjunto de D1 X D2 X ... X Dn. O conjunto de atributos de uma relação é chamado de esquema da relação. Oesquema de uma relação é denotado por : R[A1 D1, ..., An Dn] onde: Comentário R é o nome da relação; 3 Uma tupla é uma A1, ..., An é a lista de atributos da relação R e ocorrência particular de um elemento da D1, ..., Dn são os domínios de cada um dos atributos da relação R. tabela. Falaremos sobre esse conceito, Frequentemente, é utilizada uma notação simplificada em que é omitida a definição em detalheas, mais ado domínio de cada atributo da relação: R[A1, ..., An]. Por exemplo, o esquema da relação frente.representada na Tabela 1 seria: Empregado[CPF char4(11), Nome char(50), Telefonechar(9)] ou, na notação simplificada, teríamos Empregado[CPF, Nome, Telefone]. Na criação dos esquemas das relações o nome das relações ou tabelas devem ser Comentárioúnicos no banco de dados, devem ser escritos no singular e, de preferência, devem sernomes curtos. Se for usado um nome composto, este deve ser separado por um underline 4 O tipo char equivale(_), por exemplo Pessoa_Fisica ou Pessoa_Juridica. ao tipo string das linguagens de O atributo identificador da relação é apresentado sublinhado (esse atributo programação, onde você pode digitaridentificador dará origem à chave primária da relação, como veremos mais a frente). Assim, letras, números ese CPF fosse o atributo identificador teríamos: Empregado[CPF, Nome, Telefone]. símbolos. Quando você define um tipo O grau de uma relação é o número de atributos que a compõe. Por exemplo, o grau char, você tem deda relação Empregado[CPF, Nome, Telefone] é três, porque essa relação possui 3 atributos. especificar o tamanho do que preencherá Uma particularidade referente à definição de relação é que, nesta definição, não o mesmo. Esse tipoexiste qualquer tipo de ordenação ou de definição de ordenação. Assim, por exemplo, as pode variar de nomeduas relações representadas pelas Tabelas 1 e 2 são consideradas idênticas. Afinal, o que de SGBD para SGBD mas sempre vai ter ummudou de uma tabela para outra foi apenas a ordem em que os valores de preenchimento correspondente.da tabela aparecem. 9
  10. 10. Banco de Dados Tabela 2 - Tabela ou Relação Empregado CPF Nome Telefone 213415467-89 Marcos Alves 3456-8923 567324980-03 Tânia Gomes 3455-9098 765456243-45 João Pontes 3124-5645 987675456-98 Ana Marques 3245-8976 Linha (Tupla) Uma ocorrência em particular de dados em uma tabela ocupa uma linha dessa tabela. Por exemplo, na Tabela 3, os dados de cada um dos empregados que a compõe ocupam uma linha diferente da tabela. Como existem 4 empregados, a Tabela 3 possui 4 linhas (ou tuplas ou registros). O número de linhas ou tuplas de uma relação é chamado de cardinalidade da relação. Logo, a cardinalidade da relação expressa na Tabela 3 é quatro. Cada linha da tabela deve ser única e deve possuir um atributo identificador. No caso da Tabela 3, esse identificador é o CPF do empregado. O atributo identificador, no modelo relacional, passa a ser chamado de chave primária (PK) - detalharemos melhor esse ponto mais a frente. Tabela 3 - Exemplos de Atributos e Tuplas Outra definição que pode ser dada para linha ou tupla é: um conjunto de pares (<atributo>,<valor>), em que cada par fornece o valor do mapeamento de um atributo Ai para um valor Vi, tal que cada valor Vi seja um elemento do domínio Di ou um valor nulo. Algumas regras para tuplas são: em uma tabela ou relação não devem existir tuplas ou linhas duplicadas. As linhas de uma tabela não seguem uma ordem específica. Dessa forma, as tuplas ou linhas abaixo seriam idênticas: T = <(CPF, 987675456-98), (Nome, Ana Marques), (Telefone, 3245-8976)> e T = <(Telefone, 3245-8976), (CPF, 987675456-98), (Nome, Ana Marques)> Coluna (Atributo) Cada tipo de informação armazenada em uma tabela é uma coluna. Ou seja, cada10
  11. 11. Banco de Dadosatributo que caracteriza a relação é expresso em uma coluna. Toda coluna de uma tabeladeve possuir um nome pelo qual será referenciada sempre que necessário. Na verdade,ao criarmos uma tabela definimos, para cada uma de suas colunas, o seu nome (nome doatributo) e também o seu tipo (numérico, alfabético, data, etc). Por exemplo, CPF, Nome eTelefone são atributos (colunas ou campos) da Tabela Empregado, expressos na Tabela 3. Um nome de atributo deve ser único em uma tabela e deve expressar o tipo deinformação que ele representa. E o valor de um atributo não deve poder ser decompostoem mais de uma coluna.Domínio do Atributo Domínio de um atributo é a faixa de valores que esse atributo pode conter. Emoutras palavras, é o conjunto de valores que um determinado atributo pode assumir. Porexemplo, para o atributo CPF da Tabela 3, o domínio seria o conjunto dos números naturais.Em outras tabelas quaisquer, por exemplo, o domíno do atributo “dia do mês”seria oconjunto dos números entre 1 e 31. O atributo “sexo” teria como domínio os mnemônicosM (para masculino) ou F (para feminino) e assim por diante. Sempre que identificamos um atributo de uma tabela, temos também uma ideia dequal o tipo de informação que ele poderá vir a conter.Chaves Comentário Uma chave5 é um atributo (ou conjunto de atributos) que identifica univocamentecada entrada de uma relação. Ou seja, por meio de chaves podemos diferenciar as diversas 5 O conceito de chave estátuplas pertencentes a uma relação. Como consequência dessa definição, temos que os diretamente ligadoatributos chaves não podem apresentar valores duplicados, nem podem ser nulos. ao de identificador da entidade ou relacionamento que foi NULO - Não devemos confundir o conceito de nulo com espaços em branco ou o número zero, por estudado no volume exemplo, que são valores conhecidos. Nulo é a ausência de informação. anterior, quando foram detalhados os Uma coluna de preenchimento obrigatório numa tabela deve possuir todos os seus valores não- componentes do MER. nulos. Se, por exemplo, uma linha da tabela Empregado contiver um nulo na coluna Telefone, significa que o telefone do empregado correspondente àquela linha é desconhecido. Assim, ou o telefone não foi informado por algum motivo ou o empregado não possui telefone, de qualquer forma, a informação está ausente na tabela. Comentário Uma definição mais formal para chave seria: seja R um esquema de relação. Sedissermos que um subconjunto K de atributos de R é uma superchave6 para R, estaremos 6 Superchave é o conjunto de um ouconsiderando restrições para as relações r(R), nas quais não existem duas tuplas distintas mais atributos que noscom mesmos valores em todos os atributos de K. Isto é, se as tuplas t1 e t2 fazem parte da permitem identificarrelação r e t1 <> t2, então t1[K] <> t2[K]. de maneira unívoca uma tupla de uma Quando há a possibilidade de mais de um atributo (isoladamente) poder ser chave relação.em uma relação, dizemos que esses atributos são chaves candidatas. Por exemplo, na Tabela4, CPF e Nome poderiam ser chaves candidatas, porque poderiam ser atributos usados paralocalizar uma entrada na tabela. 11
  12. 12. Banco de Dados Tabela 4 - Tabela ou Relação Empregado CPF (PK) Nome Telefone 213415467-89 Marcos Alves 3456-8923 567324980-03 Tânia Gomes 3455-9098 765456243-45 João Pontes 3124-5645 987675456-98 Ana Marques 3245-8976 Um dos princípios do modelo relacional diz que uma linha de uma tabela deve sempre poder ser referenciada de forma única. Por isso, entre as chaves candidatas, uma delas deve ser eleita para ser a principal, a chave primária da tabela (Primary Key ou PK), aquela que realmente identifica univocamente cada tupla da tabela. No caso, para a Tabela 4, a melhor escolha para chave primária seria o atributo CPF, já que essa informação não se repetiria, de forma alguma, em dois empregados distintos da tabela. A escolha da chave primária (PK) da tabela é influenciada pelas necessidades do domíno do mundo real que está sendo modelado. Chaves primárias são geralmente indicadas na tabela pela sigla PK (Primary Key) e podem também ser sublinhadas (vide Tabela 4). As outras chaves candidatas que não forem escolhidas para chave primária, são chamadas de chaves secundárias. Por exemplo, na Tabela 4, o atributo Nome seria uma chave secundária. Muitas vezes, uma tabela não possui, entre seus atributos, um que por si só seja suficiente para identificar univocamente uma ocorrência. Nesses casos deve sempre ser possível que a combinação de dois ou mais atributos tenha a capacidade de se constituir numa chave primária. Chamamos a essas chaves primárias formadas pela combinação de vários atributos de chaves primárias compostas. Ou seja, uma chave primária composta é uma chave primária que é formada por mais de um atributo ou coluna. Geralmente, uma tabela que represente um relacionamento entre outras duas tabelas (originada de um relacionamento do MER) irá possuir chaves primárias compostas. Por exemplo, a tabela Alocação (vide Tabela 5), terá como chaves primárias os atributos CPF e Cod_Projeto. Isso, porque para descobrir qual a função de um empregado em um projeto, precisamos dessas duas informações. Nenhum dos atributos isoladamente poderia fornecer essa informação. Tabela 5 - Tabela ou Relação Alocação CPF (PK) Cod_projeto (PK) Função 213415467-89 002 Analista 567324980-03 001 Consultor 765456243-45 003 Suporte 987675456-98 002 Programador12
  13. 13. Banco de Dados Tabela 6 - Tabela ou Relação Empregado CPF (PK) Nome Telefone 213415467-89 Marcos Alves 3456-8923 567324980-03 Tânia Gomes 3455-9098 765456243-45 João Pontes 3124-5645 987675456-98 Ana Marques 3245-8976 Tabela 7 - Tabela ou Relação Projeto Cod_projeto (PK) Nome Projeto 001 SOFTHOUSE 002 GEOPROC 003 LINUX WORLD Uma tabela pode incluir entre seus atributos a chave primária de outra tabela.Essa chave é chamada chave estrangeira. Ou seja, uma chave estrangeira é uma coluna(ou combinação de colunas) que indica um valor que deve existir como chave primária emuma outra tabela (chamada de Tabela Pai). Por exemplo, na tabela Alocação (vide Tabela5), as colunas CPF e Cod_Projeto são chaves estrangeiras, porque elas são chave primária,respectivamente, das tabelas Empregado (vide Tabela 6) e Projeto (vide Tabela 7). Vamos definir novamente com outras palavras: uma chave estrangeira de umarelação R1 é um atributo (ou conjunto de atributos) que referencia a chave primária de umaoutra relação R2. Dessa forma, para qualquer tupla de R1, o valor da chave estrangeira deveser igual ao valor da chave primária de alguma tupla da relação R2 referenciada, ou deve sero valor nulo (se a chave estrangeira não fizer parte da chave primária da relação R1). Comisso queremos dizer que o atributo que é chave estrangeira em uma relação R1, pode ou nãofazer parte da chave primária de R1. No exemplo de chave estrangeira dado anteriormente,as chaves estrangeiras CPF e Cod_Projeto fazem parte da chave primária da tabela Alocação(vide Tabela 5). Porém, a chave estrangeira pode não fazer parte da chave primária. Observea tabela Funcionário (vide Tabela 8). Ela possui um campo Cod_Depto que é chave primáriada tabela Departamento (vide Tabela 9). Logo, na tabela Funcionário, o atributo Cod_Deptoé uma chave estrangeira. Chaves estrangeiras são indicadas pela sigla FK (Foreign Key). Tabela 8 - Tabela ou Relação Funcionário CPF (PK) Nome Cod_Depto (FK) 213415467-89 Marcos Alves 11 567324980-03 Tânia Gomes 22 765456243-45 João Pontes 11 987675456-98 Ana Marques 22 13
  14. 14. Banco de Dados Tabela 9 - Tabela ou Relação Departamento Cod_Depto (PK) Nome 11 Vendas 22 Financeiro Uma chave estrangeira formada por mais de uma coluna é chamada de chave estrangeira composta. No modelo relacional os relacionamentos representados no MER passam a ser representados através de chaves estrangeiras. Ou seja, as chaves estrangeiras tornam possível a associação lógica entre tabelas distintas. Isso ficará mais claro no próximo capítulo quando forem apresentadas as regras de derivação do MR a partir do MER. Regras de Integridade Fundamentais O modelo relacional, ao definir conceitos como Tabela, Tupla, Atributo, Nulo, Domínio, Chave Primária e Chave Estrangeira deixa implícitas algumas regras fundamentais para a manutenção da consistência do banco de dados. Elas são chamadas de Regras de Integridade e tratam dos cuidados que analistas, projetistas e programadores devem observar ao implementar as rotinas de Inclusão, Alteração e Exclusão de dados nas bases de dados. Na prática, as restrições de integridade fornecem meios para assegurar que mudanças feitas no banco de dados não resultem na perda da consistência sobre estes dados. Vamos ver agora dois dos principais tipos de integridade a serem mantidas em um banco de dados adequadamente projetado: a Integridade de Entidade e a Integridade Referencial. Posteriormente, discutiremos regras de integridade complementares e regras de integridade semântica. Integridade de Entidade (ou de Identidade ou Existencial) Refere-se às chaves primárias e procura garantir que toda e qualquer linha de uma tabela deve poder ser acessada com base apenas no conteúdo de sua chave primária. Para isso, algumas regras devem ser observadas: » Toda tupla tem um conjunto de atributos que a identifica de maneira única na relação (Integridade de Chave). » Nenhum atributo que faça parte de uma chave primária pode ter valor nulo (eles devem ser NN = not null). » Não se deve permitir que em uma mesma tabela existam duas ocorrências (tuplas) com chaves primárias iguais. Ou seja, os atributos que são chave primária devem ser únicos (ND = No Duplicate ou Unique). Isso significa que os conteúdos de todos os atributos que constituem uma chave primária devem ser conhecidos e únicos. Um conteúdo nulo representa uma informação desconhecida ou, em outras palavras, a ausência da informação, o que não pode ser permitido em qualquer elemento de uma chave primária. Algumas recomendações para se alcançar a integridade de entidade são:14
  15. 15. Banco de Dados » Selecione chaves primárias que realmente tenham preenchimento único no domínio do problema. » Se possível, prefira chaves primárias simples e numéricas. » Se não houver nenhuma coluna que possa ser uma chave candidata, utilize chaves primárias sequenciais, geralmente, atribuídas pelo sistema.Integridade Referencial Diz respeito às chaves estrangeiras e visa manter a integridade dos relacionamentosprevistos no banco de dados. Ou seja, a integridade referencial cuida para que umarelação possa ter um conjunto de atributos que contém valores com mesmo domínio deum conjunto de atributos que forma a chave primária de outra relação. Este conjunto échamado chave estrangeira. Na definição dos cuidados referentes a esse tipo de integridade, utilizaremos doisconceitos: » Tabela-Pai (Parent Table): é aquela onde o atributo de relacionamento desempenha o papel de chave primária. » Tabela-Filho (Dependent Table): tabela onde o atributo de relacionamento desempenha o papel de chave estrangeira. Para manter a integridade referencial, a regra básica é: o conteúdo de uma chaveestrangeira deve, necessariamente, ser igual ao de uma ocorrência da Tabela-Pai ou entãoser nulo. Vale ressaltar que o valor da chave estrangeira só poderá ser nulo na Tabela-Filho,se o atributo que for chave estrangeira não fizer parte da chave primária da Tabela-Filho. Por exemplo, na última tupla da tabela Funcionário (vide Tabela 10), temos que oCod_Depto é NULL. Isso é possível apenas porque o atributo Cod_Depto não faz parte dachave primária da tabela Funcionário. E deve significar que, por enquanto, a funcionáriaAna Marques não foi alocada em nenhum departamento (vamos supor que ela acaboude ser contratada). Já todas as outras tuplas da tabela Funcionário possuem o Cod_Deptopreenchido e, para que a integridade referencial seja mantida, como esse atributo é chaveestrangeira, ele deve existir como chave primária em alguma outra tabela. No caso, natabela Departamento (vide Tabela 9). Nesse exemplo fornecido, a tabela Funcionário é aTabela-Filho e a tabela Departamento é a Tabela-Pai. Tabela 10 - Tabela ou Relação Funcionário CPF (PK) Nome Cod_Depto (FK) 213415467-89 Marcos Alves 11 567324980-03 Tânia Gomes 22 765456243-45 João Pontes 11 987675456-98 Ana Marques NULL 15
  16. 16. Banco de Dados Observação Uma chave estrangeira pode referenciar-se a um atributo da sua própria tabela (caso que ocorrerá com os auto-relacionamentos do MER). Por exemplo, a tabela Funcionário (vide Tabela 11) poderia ter, para cada funcionário, quem é o seu supervisor direto. Assim, o campo CPF_Supervisor, que é considerado chave estrangeira, é a chave primária da própria tabela Funcionário e não de outra tabela qualquer. Tabela 11 - Tabela ou Relação Funcionário CPF (PK) Nome CPF_Supervisor (FK) 213415467-89 Marcos Alves 765456243-45 567324980-03 Tânia Gomes 765456243-45 765456243-45 João Pontes NULL As consequências da Integridade Referencial refletem-se nas consistências necessárias ao se proceder às operações de Inclusão, Alteração e Exclusão de dados nas Tabelas Pai e Filho. Veja as regras no Quadro 1.16
  17. 17. Banco de Dados Quadro 1 - Regras de Inclusão, Alteração e Exclusão para manter a Integridade Referencial Operação Tabela_Pai Tabela-Filho A inclusão de dados na Tabela- Filho deve atentar para o fato de A inclusão de dados na tabela-pai não tem que não será possível incluir uma Inclusão nenhuma implicação ou problema. nova tupla se o valor do campo que for chave estrangeira já não estiver cadastrado na Tabela-Pai. Se a alteração envolver o valor da chave primária, deve-se utilizar um dos seguintes critérios: » A chave não deve ser alterada se estiver Se a alteração envolver o sendo utilizada em alguma tabela-filho. atributo que é chave estrangeira, a alteração só deve ser realizada » A chave deve ser alterada e deve-se colocar usando valores que existam na Alteração NULL nas chaves estrangeiras presentes na(s) tabela pai (podendo também Tabela(s)-Filho (contanto que o valor em usar o valor NULL, se essa chave questão não faça parte da chave primária da(s) estrangeira não fizer parte da Tabela(s)-Filho correspondente(s)). chave primária da Tabela-Filho). » A chave deve ser alterada e o novo valor deve ser colocado no campo que é chave estrangeira em todas as tabelas-filho relacionadas. Para excluir uma tupla dessa tabela, deve-se utilizar um dos seguintes critérios: » Não deletar, se a tupla estiver sendo utilizada em uma Tabela-Filho. A exclusão de Dados na Tabela- » Deletar a tupla e colocar NULL nas chaves Exclusão Filho não tem nenhuma estrangeiras das Tabelas-Filhos afetadas (isso se implicação ou problema. o atributo envolvido não fizer parte da chave- primária da Tabela-Filho). » Deletar e, também, eliminar todas as tuplas das Tabelas-Filho que façam uso do valor da tupla sendo eliminada. As restrições de integridade devem ser implementadas pelo SGBD. Muitos SGBD’s implementam integridade de entidade, mas não implementam integridade referencial.Regras de Integridade Complementares Além das regras de integridade de entidade e referencial, um banco de dadosrelacional pode suportar um conjunto adicional de regras (ou restrições) cuja finalidade 17
  18. 18. Banco de Dados é especificar aspectos próprios de cada coluna e respectivo domínio, complementando com isso a definição de suas características lógicas. As principais restrições de integridade complementares tratam da obrigatoriedade e unicidade de valores e sobre conjuntos de valores permitidos. Vamos às regras: » Obrigatoriedade - Indica se deve ou não ser permitida a existência de nulos em uma coluna (ou seja, se um atributo pode ou não ser nulo). Colunas que não aceitam nulos são de preenchimento obrigatório como, por exemplo, o nome de um funcionário na tabela de funcionários. Campos que não possuam obrigatoriedade de preenchimento são considerados campos opcionais. Por exemplo, o número do telefone poderia ser um campo opcional, dependendo do domínio, visto que ainda podem haver pessoas que não possuem número de telefone. A definição de se um campo será de preenchimento obrigatório ou não, vai depender muito do domínio do mundo real sendo modelado. » Unicidade - Indica se deve ser permitido ou não que uma coluna possua valores idênticos em duas ou mais linhas. Uma coluna que não pode possuir valores repetidos é uma coluna de valores únicos. » Verificação de Valores Específicos - Indica explicitamente qual o conjunto de valores permitidos para uma determinada coluna. Por exemplo, para a coluna Sexo de uma tabela Empregado só poderiam ser aceitos os valores ‘M’ ou ‘F’. Qualquer outro valor deveria ser recusado. Restrições de Integridade Semântica São restrições especificadas e mantidas num banco de dados relacional pelo programa de aplicação e que são inerentes a aplicação sendo desenvolvida. Ou seja, são as regras de negócio do domínio do mundo real sendo implementado. Por exemplo, em um determinado sistema pode-se querer implementar a restrição que “o salário de um empregado não pode ser maior do que o salário do seu supervisor direto” ou que “o número máximo de horas por semana que um empregado pode trabalhar em projetos é de 40 horas” (suponha que a empresa não permite horas extras) ou, ainda, “a data de entrega de um pedido não pode ser inferior à data em que o pedido foi realizado”. Tais restrições, como dito, são específicas do domínio sendo implementado e necessitam ser programadas em cada aplicação que vá fazer uso do banco de dados. As 12 Regras de Codd Edgard F. Codd, em 1985, estabeleceu as 12 regras de Codd que determinam o quanto um banco de dados é relacional. Algumas vezes as regras se tornam uma barreira e nem todos os SGBDs relacionais fornecem suporte a elas. De qualquer forma, a título de conhecimento, vamos apresentá-las a seguir. Lembramos que nem todas as regras serão completamente compreendidas nesse momento, mas o serão até o final da disciplina. Regra 1 - Regra das informações em tabelas: As informações a serem armazenadas no banco de dados devem ser apresentadas como relações (tabelas formadas por linhas e colunas) e o vínculo de dados entre as tabelas deve ser estabelecido por meio de valores de campos comuns (chaves estrangeiras). Regra 2 - Regra de acesso garantido: Todo e qualquer valor atômico em um BD relacional possui a garantia de ser logicamente acessado pela combinação do nome da tabela, do valor da chave primária e do nome do campo/coluna que deseja acessar. Isso18
  19. 19. Banco de Dadosporque, com o nome da tabela, se localiza a tabela desejada. Com o valor da chave primáriaa tupla desejada dentro da tabela é localizada. E com o nome do campo/coluna se acessa aparte desejada da tupla. Regra 3 - Regra de tratamento sistemático de valores nulos: Valores nulos devemser suportados de forma sistemática e independente do tipo de dado para representarinformações inexistentes e informações inaplicáveis. Deve-se sempre lembrar que valoresnulos devem ter um tratamento diferente de “valores em branco”. Comentário Regra 4 - Regra do catálogo relacional ativo: Toda a estrutura do banco de dados(domínios, campos, tabelas, regras de integridade, índices, etc) deve estar disponível em 7 Veremos como fazertabelas (também referenciadas como catálogo). Sua manipulação é possível por meio de isso no último volumelinguagens específicas (por exemplo, SQL). Essas tabelas são, geralmente, manipuladas pelo desta disicplina, quando estivermospróprio sistema no momento em que o usuário efetua alterações na estrutura do banco de estudando a linguagemdados (por exemplo, a inclusão de um novo atributo em uma tabela). SQL. Regra 5 - Regras de atualização de alto-nível: Essa regra diz que o usuário deveter capacidade de manipular as informações do banco de dados em grupos de registros, ouseja, ser capaz de inserir, alterar e excluir vários registros ao mesmo tempo7. Comentário Regra 6 - Regra de sub-linguagem de dados abrangente: Pelo menos umalinguagem, com sintaxe bem definida, deve ser suportada, para que o usuário possa 8 Commit servemanipular a estrutura do banco de dados (como criação e alteração de tabelas), assim para confirmar as operações realizadascomo extrair, inserir, atualizar ou excluir dados, definir restrições de integridade e de acesso no banco de dados.e controle de transações (commit e rollback8, por exemplo). Deve ser possível ainda a Rollback serve paramanipulação dos dados por meio de programas aplicativos. desfazer uma operação que ainda não tenha Regra 7 - Regra de independência física: Quando for necessária alguma sido confirmada.modificação na forma como os dados estão armazenados fisicamente, nenhuma alteraçãodeve ser necessária nas aplicações que fazem uso do banco de dados (isolamento), assimcomo devem permanecer inalterados os mecanismos de consulta e manipulação de dadosutilizados pelos usuários finais. Regra 8 - Regra de independência lógica: Qualquer alteração efetuada na estrutura Comentáriodo banco de dados como inclusão ou exclusão de campos de uma tabela ou alteração norelacionamento entre tabelas não deve afetar o aplicativo utilizado ou ter um baixo impacto 9 Visão: é uma relaçãosobre o mesmo. Da mesma forma, o aplicativo somente deve manipular visões9 dessas virtual que não faztabelas. parte do esquema conceitual do BD, mas Regra 9 - Regra de atualização de visões: Uma vez que as visões dos dados de uma que é visível a um grupo de usuários. Emou mais tabelas são, teoricamente, suscetíveis a atualizações, então um aplicativo que faz outras palavras, umauso desses dados deve ser capaz de efetuar alterações, exclusões e inclusões neles. Essas visão é uma tabelaatualizações, no entanto, devem ser repassadas automaticamente às tabelas originais. Ou virtual que é definidaseja, a atualização em uma visão deve refletir na atualização das tabelas representadas por a partir de outras tabelas, contendoessa visão. sempre os dados atualizados. Regra 10 - Regra de independência de integridade: As várias formas de integridadede banco de dados (integridade de entidade, integridade referencial e restrições deintegridade complementares) precisam ser estabelecidas dentro do catálogo do sistema oudicionário de dados e serem totalmente independentes da lógica dos aplicativos. Assim, osaplicativos não devem ser afetados quando ocorrerem mudanças nas regras de restriçõesde integridade. Regra 11 - Regra de independência de distribuição: Alguns SGBDs, notadamente osque seguem o padrão SQL, podem ser distribuídos em diversas plataformas/equipamentosque se encontrem interligados em rede. Essa capacidade de distribuição não pode afetar afuncionalidade do sistema e dos aplicativos que fazem uso do banco de dados. Em resumo, 19
  20. 20. Banco de Dados as aplicações não são logicamente afetadas quando ocorrem mudanças geográficas dos dados (caso dos BDs distribuídos). Regra 12 - Regra não-subversiva: O sistema deve ser capaz de impedir qualquer usuário ou programador de transgredir os mecanismos de segurança, regras de integridade do banco de dados e restrições, utilizando algum recurso de linguagem de baixo nível que eventualmente possam ser oferecidos pelo próprio sistema. Conheça Mais Neste capítulo foram vistos conceitos básicos do modelo relacional. Para obter mais informações ou materiais diversificados para o que foi visto aqui, você pode proceder a uma pesquisa usando o Google (www.google.com.br) com as palavras chaves “Modelagem Lógica” + “Banco de Dados” ou “Modelo Relacional” ou ainda “Esquema Relacional”. Você vai ver que virá muito material. Entre eles: apostilas, notas de aula, reportagens, etc. Adicionalmente, você pode consultar qualquer livro sobre banco de dados, pois qualquer um deles terá um ou mais capítulos voltados para a explicação do modelo relacional. Entre os livros que podemos indicar estão: HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados – Série Livros Didáticos, V.4. Bookman Companhia Ed., 6ª Edição - 2009 SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São Paulo: Pearson Education do Brasil, 2005. DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, 2000. ALVES, W.P. Fundamentos de Bancos de Dados. Editora Érica, 2004. Você Sabia? A linguagem padrão dos Bancos de Dados Relacionais é a Structured Query Language, ou simplesmente SQL, como é mais conhecida. Ela será assunto do próximo volume (Volume 4) da disciplina. Aprenda Praticando Vamos dar uma olhada novamente em questões de concurso? NCE-UFRJ - 2001 - TRE-RJ - Analista Judiciário - Especialidade - Análise de Sistemas - Desenvolvimento 1) Sobre os conceitos de domínio, atributo e relacionamento, é correto afirmar que: a) um domínio é definido pelo conjunto dos atributos pertencentes a um relacionamento;20
  21. 21. Banco de Dados b) domínio e atributo representam um único conceito semântico; c) um atributo é considerado identificador se pertencer ao domínio que define um relacionamento; d) todos os atributos de uma relação devem pertencer a um mesmo domínio; e) domínio são os valores possíveis que um atributo pode assumir.2) A cardinalidade de uma relação é caracterizada por: a) Número de atributos dessa relação; b) Número de campos dessa relação; c) Quantidade de chaves estrangeiras da relação; d) Número de tuplas de uma relação; e) Nenhuma das respostas anteriores.3) Uma chave estrangeira: a) Pode conter valores que não existem na Tabela-Pai (tabela referenciada); b) Pode não pertencer à chave primária; c) Tem de pertencer, obrigatoriamente, à chave primária; d) Podem sempre assumir o valor nulo; e) Nenhuma das respostas anteriores. Fundação Getúlio Vargas – 20084) No contexto de Banco de Dados, um conceito assegura que um valor que aparece em uma tabela para um determinado conjunto de atributos apareça em outro conjunto de atributos de outra tabela. Por exemplo, se cristalina é o nome de uma agência que aparece em uma tupla da tabela conta, então deve existir uma tupla cristalina na tabela agencia. Esse conceito é definido como um sistema de regras, utilizado para garantir que os relacionamentos entre tuplas de tabelas relacionadas sejam válidas e que não exclui ou altera, acidentalmente, dados relacionados. Trata- se do seguinte conceito: a) Integridade Funcional; b) Dependência Funcional; c) Integridade Relacional; d) Dependência Referencial; e) Integridade Referencial. (Técnico de Tecnologia da Informação/UFT/FCC/2005)5) Os dois principais tipos de integridade a serem mantidos em um banco de dados relacional adequadamente projetado são: a) Integridade Existencial e Integridade Permanente; b) Integridade de Entidade e Integridade de Relacionamento; c) Integridade de Entidade e Integridade Referencial; d) Integridade Permanente e Integridade Referencial; e) Integridade Existencial e Integridade de Entidade. (Administrador/PM SANTOS/FCC/2005) 21
  22. 22. Banco de Dados 6) Um tipo de dado específico, como por exemplo Nome do Funcionário, é armazenado numa localização da estrutura do banco de dados denominada. a) Tabela; b) Linha; c) Planilha; d) Coluna; e) Registro. Respostas: 1) E – O domínio de um atributo são os valores que ele pode assumir. Ou seja, é o tipo deste atributo. Por exemplo, o atributo dia do mês tem como domínio os valores naturais entre 1 e 31. 2) C – A cardinalidade de uma relação é o número de linhas ou tuplas dessa relação. Assim, uma relação com quatro tuplas, tem cardinalidade 4. 3) B – Uma chave estrangeira pode não pertencer à chave primária, não pode conter valores que não existam na tabela-pai e só podem assumir valor nulo se não pertencer à chave primária da tabela onde é chave estrangeira. 4) E – Integridade Referencial. Ela checa todas as validações necessárias referentes ao uso de chaves estrangeiras. 5) C – os dois principais tipos de integridade que podem ser verificados em um BD relacional são a integridade de entidade (que se referem às checagens da chave primária) e a integriadade referencial (que se refere às checagens da chave estrangeira). 6) D – Nome do funcionário é tipicamente um atributo e um atributo é representado no BD relacional por uma coluna. Atividades e Orientações de Estudo Agora vamos exercitar o que foi estudado neste capítulo. Assim sendo, faça as atividades sugeridas a seguir. Lembre que exercitar vai ajudá-lo(a) a fixar melhor o conteúdo estudado. E o conteúdo desse capítulo é fundamental para o capítulo seguinte, onde vamos aprender a construir o Modelo Relacional. Mãos à obra! Atividades Práticas: Responda as questões a seguir em um documento de texto (doc) e poste as respostas no ambiente virtual, no local indicado. Esse trabalho deve ser feito individualmente. (Exercícios adaptados do livro de Carlos Heuser (1998) - capítulo 4). Exercício 1: Abaixo aparecem diversos esquemas de relação que compõem um banco de dados relacional. Identifique nestes esquemas, da maneira apropriada, as chaves primárias e chaves estrangeiras: Aluno (CodigoAluno,Nome,CodigoCurso) Curso(CodigoCurso,Nome)22
  23. 23. Banco de Dados Disciplina(CodigoDisciplina,Nome,Creditos,CodigoDepartamento) Curriculo(CodigoCurso,CodigoDisciplina,Obrigatória-Opcional) Conceito(CodigoAluno,CodigoDisciplina,Ano-Semestre,Conceito) Departamento(CodigoDepartamento,Nome) Exercício 2: Considere o esquema das relações de um BD relacional a seguir: Paciente(CodigoConvenio (FK), NumeroPaciente, Nome) Convenio(CodigoConvenio, Nome) Medico(CRM, Nome, Especialização) Consulta(CodigoConvenio (FK), NumeroPaciente (FK), CRM(FK), Data-Hora) A partir desse esquema, explique que verificações/checagens deveriam ser feitaspelo SGBD para garantir integridade referencial nas seguintes situações: a) Uma linha é incluída na tabela Consulta. b) Uma linha é excluída da tabela Paciente. Vamos Revisar? Você estudou, neste capítulo, os conceitos básicos referentes ao modelo relacional.Entre eles, os conceitos de tabela ou relação, tuplas ou linhas, atributos ou colunas e chaves(chave candidata, primária, secundária e estrangeira). Esses conceitos serão todos utilizadosno próximo capítulo onde você aprenderá a derivar o modelo relacional a partir do modeloentidade-relacionamento. Adicionalmente, foram vistos também neste capítulo os principaistipos de integridade (de entidade e referencial), além de integridades complementares eintegridade semântica. 23
  24. 24. Banco de Dados Capítulo 8 O que vamos estudar neste capítulo? Neste capítulo, vamos estudar os seguintes temas: » Como derivar o MR a partir do MER. Metas Após o estudo deste capítulo, esperamos que você consiga: » Derivar o MR a partir do MER. » Verificar a corretude do modelo derivado.24
  25. 25. Banco de DadosCapítulo 8 – Derivando o MR a partirdo MER Vamos conversar sobre o assunto? “Vimos no capítulo anterior os conceitos básicos do modelo relacional. Porém,ainda não vimos como gerar o modelo relacional, que faz parte da modelagem lógica dobanco de dados, que é a terceira etapa do projeto de banco de dados como um todo. Amelhor maneira de produzir o modelo relacional é derivá-lo a partir do modelo entidade-relacionamento. Para fazer isso, existem algumas regras. São justamente essas regras quediscutiremos neste capítulo.” Neste capítulo, você vai aprender como derivar o MR a partir do MER, para isso,todas as instruções de como fazer isso serão dadas. Vamos lá?Algumas Informações Iniciais A terceira fase do projeto de banco de dados é o projeto lógico que objetiva mapearo modelo de dados conceitual para o modelo de dados relacional. Essa fase dá origem aoesquema lógico representado pelo modelo relacional que já é um modelo que depende doSGBD e será usado para implementar o banco de dados. É comum, em projetos de banco de dados, se realizar a modelagem dos dadosatravés de um modelo de dados de alto-nível. O modelo de dados de alto-nível normalmenteadotado é o Modelo Entidade-Relacionamento (MER) e o esquema das visões e de todaa base de dados são especificados em diagramas entidade-relacionamento (DER). O passoseguinte à modelagem dos dados conceitual é o mapeamento do diagrama da base dedados global para um modelo de dados de implementação. Existem três tipos de modelosde dados de implementação: hierárquico, rede e relacional. Para cada um desses modelos,podem-se definir estratégias de tradução a partir do DER. A estratégia de tradução, ou demapeamento, que trataremos neste capítulo e nesta disciplina será apenas para o modelode dados relacional. O Modelo Relacional é a representação do modelo lógico do projeto de bancode dados, sendo que a forma de representação dos conceitos necessários ao projetodeve passar a ser mais detalhada e se aproximar um pouco mais da representação física.Dessa forma, várias mudanças devem ser realizadas no DER gerado na fase de modelagemconceitual, como, por exemplo: entidades passam a ser representadas por relações outabelas. Atributos passam a ser representados em colunas. O atributo identificador passaa ser a chave primária (PK) da tabela. Os relacionamentos e as dependências passam aser representados por chaves estrangeiras (FK) e assim por diante. Na Figura 3, pode servisto um exemplo do resultado da transformação de um MER em MR. Cada etapa dessemapeamento será estudada na seção a seguir. 25
  26. 26. Banco de Dados Figura 3 - Passagem do MER para o MR Regras para Derivar o Modelo Relacional a partir do MER Agora, iremos estudar cada uma das etapas de derivação do MR a partir do MER. » Mapeamento de Entidades Fortes – Cada conjunto de entidades fortes é mapeado como uma relação que envolve todos os atributos da entidade correspondente do DER. Assim, para cada entidade regular E no DER, criar uma relação R que inclua todos os atributos simples de E. Se houver atributos compostos, inclua apenas os atributos simples que compõem o atributo composto (ou seja, decomponha o atributo composto). O(s) atributo(s) identificador(es) da entidade E deve(m) ser marcado(s) como chave primária da relação R. Por exemplo, suponha a entidade Aluno que possui dois atributos CPF e Nome, sendo o CPF o atributo identificador da entidade (vide Figura 4). No MR, seria criada uma relação ou tabela de nome Aluno, com duas colunas (atributos) CPF, que deveria ser marcado como chave primária (PK) e Nome. Como, anteriormente explicado, se houvesse atributos compostos, esses deveriam ser substituídos pelos atributos simples que o compõem (vide Figura 5). Assim, o atributo Endereço, que é composto pelos atributos Rua, Numero e Bairro, seria representado na relação apenas por estes últimos. Figura 4 - Exemplo de Mapeamento de Entidade Forte26
  27. 27. Banco de Dados Figura 5 - Exemplo de mapeamento de atributo composto» Mapeamento de Atributos Multivalorados – Os atributos multivalorados vão se tornar relações cujas chaves primárias serão compostas pela chave da entidade possuidora do atributo mais o atributo multivalorado. Ou seja, para cada atributo A multivalorado, deve-se criar uma nova relação R que inclua o atributo multivalorado A e a chave-primária K da relação que representa o tipo de entidade ou o tipo de relacionamento que tem A como atributo. O detalhe é que a chave-primária da relação R será composta por K e pelo atributo A. Se o atributo multivalorado for composto, você deve seguir a instrução anteriormente dada de decompô-lo (usar os atributos simples que o compõem). Por exemplo, suponha a entidade Empregado (vide Figura 6). Ela possui os atributos CPF e Nome simples e o atributo Telefone que é multivalorado. Essa entidade seria mapeada para a relação Empregado (pela regra já descrita anteriormente) e o atributo mutivalorado Telefone daria origem a outra relação, que chamamos de Telefone_Empregado, contendo a chave primária da relação Empregado (que originou-se da entidade possuidora do atributo) e o atributo valorado, também fazendo parte da chave primária dessa nova relação. Figura 6 - Exemplo mapeamento de atributo multivalorado» Mapeamento de Entidades Fracas – São mapeadas em uma relação formada por todos os atributos da entidade fraca mais os atributos que formam a chave primária da relação da qual a entidade fraca depende. O relacionamento não é mapeado. Assim, para cada tipo de entidade fraca EF do DER, criar uma relação R e incluir todos os atributos simples (ou os componentes simples de atributos compostos) de EF como atributos de R. Além disso, incluir como a chave-estrangeira de R a 27
  28. 28. Banco de Dados chave-primária da relação que corresponde à entidade forte, da qual a entidade fraca depende. Logo, a chave primária da entidade fraca deverá ser formada pela chave primária da relação que representa a entidade forte da qual a entidade fraca depende e pelo atributo identificador da entidade fraca. Por exemplo, vide a Figura 7. A entidade forte Empregado foi mapeada para a relação Empregado, como explicado anteriormente. A entidade fraca Dependente deu origem a uma relação cuja chave primária é formada pela chave primária de empregado (CPF) e pelo identificador da própria entidade fraca (RG), além do atributo adicional Nome. Figura 7 - Exemplo de mapeamento de entidade fraca » Mapeamento de Relacionamentos Binários 1:1 – Esse tipo de relacionamento não é mapeado em uma nova relação. Seus atributos são colocados em qualquer uma das relações que mapeiem as entidades envolvidas. A entidade escolhida para receber os atributos do relacionamento receberá, também, a chave primária da outra entidade envolvida. Assim, temos que, para cada tipo de relacionamento binário 1:1 R do DER, devem-se criar as relações E1 e E2 que correspondem aos tipos de entidade participantes do relacionamento R. Depois, deve-se escolher uma das relações, por exemplo, E1, para incluir nela, como chave-estrangeira, a chave-primária de E2. Devem-se incluir também em E1 todos os atributos simples (ou os componentes simples de atributos compostos) do tipo de relacionamento R. Por exemplo, suponha que “Um empregado trabalha em uma empresa e uma empresa possui um único empregado” (vide Figura 8). Esse é um relacionamento binário 1:1. Para mapeá-lo para o MR, devem-se criar duas relações Empregado e Empresa, conforme a maneira anteriormente explicada (mapeamento de entidade forte). Depois, seria escolhida uma das relações (suponha que escolhemos a relação Empregado) para receber os atributos do relacionamento (no caso, Dt_admissao) e a chave primária da relação que não for a escolhida (no caso, o atributo Codigo, que pertence à relação Empresa). Se a entidade escolhida fosse a relação Empresa (a escolha é sua) seria necessário colocar a chave primária da entidade Empregado na relação Empresa, assim como o atributo do relacionamento. Todas as duas abordagens seriam possíveis.28
  29. 29. Banco de Dados Figura 8 - Exemplo de mapeamento de relacionamento binário 1:1» Mapeamento de Relacionamentos Binários 1:N – Esse tipo de relacionamento não é mapeado em uma nova relação. Seus atributos são colocados na relação que mapeia a entidade com cardinalidade N. Os atributos-chaves da entidade com cardinalidade 1 são mapeados (passam a fazer parte) na entidade com cardinalidade N. Ou seja, para cada tipo de relacionamento binário 1:N (que não envolva entidades fracas) R, você deve identificar a relação S que representa o tipo de entidade que participa do lado N do tipo de relacionamento. Depois, deve incluir em S, como chave-estrangeira, a chave-primária da relação T que representa o outro tipo de entidade que participa em R. Por fim, devem-se incluir, também, quaisquer atributos simples (ou componentes simples de atributos compostos) do tipo de relacionamento 1:N como atributos de S. Por exemplo, suponha que “Uma empresa tem zero ou mais empregados e um empregado trabalha para uma e apenas uma empresa” (vide Figura 9). Esse é um relacionamento binário 1:N. Para mapeá-lo para o MR, devem-se criar duas relações Empregado e Empresa, conforme a maneira anteriormente explicada (mapeamento de entidade forte). Depois, deve- se incluir na relação que representa a entidade do lado N do relacionamento (no caso, Empregado), a chave primária da relação que representa a entidade do lado 1 (no caso, Empresa). Por fim, os atributos do relacionamento devem também ser incluídos na relação do lado N. Neste caso, obrigatoriamente o lado escolhido deveria ser o lado N do relacionamento. 29
  30. 30. Banco de Dados Figura 9 - Exemplo de mapeamento de relacionamento binário 1:N Comentário » Mapeamento de Relacionamentos Binários M:N – O relacionamento é mapeado em uma nova relação que recebe os atributos do relacionamento mais os atributos- chaves das entidades envolvidas no relacionamento. Assim, a chave da relação10 Isso ocorrerá quandofor necessário que seria a concatenação das chaves das entidades envolvidas (e, em alguns casos,o relacionamento também o atributo identificador do próprio relacionamento10). Então teríamos que,reflita algum aspecto para cada tipo de relacionamento binário M:N R, criar uma nova relação S paratemporal ou mantenhaalgum tipo de representar este relacionamento R. Nesta nova relação seriam incluídas, comohistórico. Consulte o chave-estrangeira, as chaves-primárias das relações que representam os tipos decapítulo 5 do Volume entidade participantes do relacionamento. A combinação dessas chaves-primárias2 da disciplina para irá formar a chave primária da nova relação S. Também seriam incluídos na relaçãomais informações arespeito. S qualquer atributo simples do tipo de relacionamento M:N (ou componentes simples dos atributos compostos). Relacionamentos M:N sempre derivam uma nova relação, para o tipo relacionamento. Por exemplo, temos que “Um projeto aloca zero ou mais empregados e um empregado pode trabalhar em zero ou mais projetos.” (vide Figura 10). Como o relacionamento é binário e M:N, seriam criadas três relações: Projeto, Empregado e Alocação (melhor passar o verbo para um substantivo, assim o relacionamento aloca passa a ser a relação alocação). As duas primeiras relações seriam criadas pela regra já vista de mapeamento de entidades fortes. Quanto ao relacionamento, seria criado para ele uma relação Alocação que teria como chave primária as chaves das duas relações que representam as entidades envolvidas no relacionamento (no caso, CPF e Código), além do atributo do próprio relacionamento (no caso, Dt_alocação). 30
  31. 31. Banco de Dados Figura 10 - Exemplo de mapeamento de relacionamento binário M:N Se, como mencionado anteriormente, fosse necessário armazenar algum aspecto temporal do relacionamento (no caso, guardar o histórico das alocações feitas), o atributo Dt_alocação do relacionamento viria no DER como identificador do relacionamento. Isso faria com que ele no mapeamento também passasse a fazer parte da chave primária da relação que representa esse relacionamento (no caso, a relação Alocação), conforme pode ser visto na Figura 11. Consegue perceber o que muda? (Observe as figuras 10 e 11).Figura 11 - Exemplo de mapeamento de relacionamento binário M:N (guardando aspecto temporal) 31
  32. 32. Banco de Dados » Mapeamento de Relacionamentos Ternários, Quaternários, etc – Usualmente, mapeamos tais relacionamentos como se todos fossem de cardinalidade M:N. A relação será formada pelos atributos do relacionamento e as chaves primárias das entidades envolvidas neste relacionamento. Por exemplo, suponha o relacionamento ternário da Figura 12. Cada entidade forte seria mapeada em uma relação, conforme regra já vista. E o relacionamento matricula, seria mapeado na relação Matricula que seria composta pelas chaves primárias de cada uma das relações que representam as entidades envolvidas no relacionamento (no caso, Sigla, CPF e Código), mais a o atributo existente no próprio relacionamento (no caso, Dt_matricula). Sendo que as chaves primárias comporiam as chaves primárias da própria relação. Figura 12 - Exemplo de mapeamento de relacionamento ternário » Mapeamento de Especialização/Generalização – Há dois casos. Primeiro, se a especialização for mutuamente exclusiva e total. Ou seja, nenhum elemento é membro de mais de uma entidade e se todas as entidades do nível superior forem membros dos níveis inferiores (por exemplo, todo cliente ou é pessoa física ou é pessoa jurídica, nunca será apenas um cliente). Neste caso são criadas relações apenas para as especializações (entidades filhas, no nível inferior) e elas usarão como chave primária o atributo identificador da entidade de nível superior. Por exemplo, atente para a Figura 13. Temos que o Cliente foi especializado em Pessoa_ Fisica e Pessoa_Juridica e essa é uma especialização mutuamente exclusiva e total. Dessa forma, esse diagrama dará origem a duas relações. Ambas terão os atributos da entidade de nível superior (e a chave primária será o identificador da mesma – o código), além de seus próprios atributos.32
  33. 33. Banco de Dados Figura 13 - Exemplo de mapeamento de especialização/generalização total e mutuamente exclusiva Se a especialização não for mutuamente exclusiva, deve ser criada uma tabelapara cada entidade, todas tendo como chave primária o atributo identificador da entidadeprincipal (de nível superior). Por exemplo, vide a Figura 14. Uma conta pode ser apenasuma conta normal, pode ser uma poupança ou uma conta de investimento. Assim, aespecialização não é mutuamente exclusiva, como consequência, cada entidade daráorigem a uma tabela e todas terão como chave primária a chave da entidade principal. 33
  34. 34. Banco de Dados Figura 14 - Exemplo de mapeamento de especialização/generalização não exclusiva » Agregação e Entidade Associativa – Envolvem um relacionamento entre relacionamentos. Para fazer o mapeamento, primeiro, criamos relações para todas as entidades envolvidas. Segundo, criamos uma relação para o primeiro relacionamento (a entidade associativa) que terá como chave primária as chaves primárias das entidades diretamente envolvidas. Terceiro, criamos uma relação para o relacionamento externo, contendo as chaves primárias de todas as entidades. Por exemplo, vide a Figura 15. Nela temos um exemplo de uso de entidade associativa para poder especificar que em uma consulta feita por um médico a um paciente, medicamentos podem ser prescritos. Cada entidade forte dará origem a uma relação. Depois, a entidade associativa Consulta também dará origem a uma relação que terá como chave primária as chaves das duas entidades diretamente envolvidas (no caso, Medico e Paciente) no relacionamento da entidade associativa. Por último, o relacionamento externo, que se liga com a entidade associativa (no caso, o relacionamento prescreve que passamos a chamar de prescrição no MR) também dará origem a uma relação que terá como chave primária a chave da entidade associativa e a chave da entidade que a ela se liga.34
  35. 35. Banco de Dados Figura 15 - Exemplo de mapeamento de diagrama envolvendo entidade associativa» Mapeando Auto-Relacionamentos –. Existem duas maneiras de transformar um auto-relacionamento (vide Figura 16) em relações: Figura 16 - Exemplo de auto-relacionamento › A primeira é usar para representar a entidade e seu auto-relacionamento apenas uma relação com duas ocorrências da chave primária. Por exemplo, o auto-relacionamento da Figura 16 que representa que um empregado é gerenciado por zero ou um empregado e esse empregado-gerente pode gerenciar zero ou mais empregados, daria origem a uma única relação chamada Empregado, onde haveria duas ocorrências da chave primária CPF: uma para o próprio empregado e outra para o seu gerente, como apresentado a seguir: 35
  36. 36. Banco de Dados › A outra opção é criar duas relações, uma para representar a entidade e outra para representar o auto-relacionamento. Dessa forma, o DER da Figura 16 daria origem a duas relações: Empregado e Gerência. A relação Empregado seria mapeada da forma já explicada para entidades fortes. E o auto- relacionamento seria mapeado em uma relação que conteria duas entradas da chave primária da entidade: uma para o empregado e outra para o seu gerente, como apresentado a seguir. Considerações Finais O principal ponto que deve ser considerado em um esquema relacional, quando comparado ao esquema do MER, é que os tipos de relacionamento não são representados explicitamente; eles são representados por dois atributos A e B, um para a chave-primária e outra para a chave-estrangeira – sobre o mesmo domínio – incluídos em duas relações S e T. Duas tuplas em S e T estão relacionadas quando elas tiverem o mesmo valor para A e B, ou seja, os relacionamentos são definidos pelos valores dos atributos A e B. Uma vez que o modelo relacional esteja pronto, ele deve ser normalizado (otimizado). O como fazer isso é assunto do próximo capítulo. Depois, com o MR Normalizado, o projeto do banco de dados estará pronto para passar da sua fase lógica (Projeto Lógico), para a fase física, o Projeto Físico ou de Implementação. Conheça Mais Alguns livros que podem ser usados para aprofundar o estudo nesse capítulo são: HEUSER, CARLOS ALBERTO. Projeto de Banco De Dados – Série Livros Didáticos, V.4. Bookman Companhia Ed., 6ª Edição - 2009 SILBERSCHATZ, Abraham; KORTH, Henry F; SUDARSHAN, S. Sistema de banco de dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier;Campus, 2006. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 4a. ed. São Paulo: Pearson Education do Brasil, 2005. DATE, C. J. Introdução a sistemas de bancos de dados. Rio de Janeiro: Campus, 2000. ALVES, W.P. Fundamentos de Bancos de Dados. Editora Érica, 2004.36
  37. 37. Banco de Dados Aprenda Praticando A partir das regras de mapeamento estudadas neste capítulo, mapeie o MER aseguir para o MR, apresentando o esquema das relações que são originadas. Vamos começar o mapeamento pela especialização/generalização do lado esquerdodo diagrama. Se observar, a especialização do diagrama é mutuamente exclusiva e total. Umcliente não pode ser pessoa física e jurídica. Ele ou é pessoa física ou é pessoa jurídica.Também, ele não pode ser simplesmente um cliente. Dessa forma, precisamos criar relaçõesapenas para as especializações (entidades filhas, no nível inferior), no caso Pessoa_Fisica ePessoa_Juridica. E, essas relações usarão como chave primária o atributo identificador daentidade de nível superior (no caso Cliente). Uma vez mapeada a especialização, vamos tratar agora de mapear o relacionamento 37
  38. 38. Banco de Dados superior (circulado no diagrama acima). Se observar, esse é um relacionamento 1:N. E, como vimos, em relacionamento binário 1:N, os atributos chaves da entidade com cardinalidade 1 são mapeados (passam a fazer parte) da entidade com cardinalidade N, bem como qualquer atributo que o relacionamento tivesse (o que não é o caso, pois o relacionamento possui não tem nenhum atributo). Logo, ficaríamos com: Não é tão complicado! Quanto mais você exercitar, mais vai memorizar as regras e conseguir aplicá-las com mais facilidade. Porém, para isso, você realmente precisa praticar! Atividades e Orientações de Estudo Agora é a sua vez de fazer as atividades! Lembre, praticar é muito importante para fixar o conteúdo estudado! Atividades Práticas Resolva as atividades a seguir em um documento texto e poste o mesmo no ambiente virtual, no local indicado. Essa atividade é para ser realizada em DUPLA (escolha seu companheiro de trabalho!) e fará parte da avaliação somativa de vocês. A partir das regras de mapeamento estudadas neste capítulo, mapeie os MER, a seguir, para o MR, apresentando o esquema das relações que são originadas. a) Controle Acadêmico38
  39. 39. Banco de Dados b) Controle Farmácia Vamos Revisar? A modelagem lógica que vem em seguida a modelagem conceitual é caracterizadapela criação do modelo relacional (MR). Uma das formas de criar esse modelo é derivandoo mesmo a partir do modelo entidade-relacionamento, criado na etapa anterior demodelagem conceitual. Para derivar o modelo, existem diversas regras que seguidas,produzem os esquemas relacionais. Foram justamente essas regras que foram apresentadasnesse capítulo, bem como alguns exemplos de mapeamento do MER para o MR. No próximocapítulo veremos como otimizar os esquemas relacionais através da normalização de dados.Até lá! 39
  40. 40. Banco de Dados Capítulo 9 O que vamos estudar neste capítulo? Neste capítulo, vamos estudar os seguintes temas: » Dependências Funcionais. » Normalização de Dados. Metas Após o estudo deste capítulo, esperamos que você: » Saiba o que são dependências funcionais. » Saiba normalizar o seu modelo relacional, pelo menos, até a 3ª Forma Normal. » Conheça todas as formais normais (1FN, 2FN, 3FN, 4FN e 5FN), além da forma normal de Boyce-Codd.40
  41. 41. Banco de DadosCapítulo 9 – Normalização de Dados Vamos conversar sobre o assunto? Projetar um banco de dados relacional significa agrupar atributos para formar bonsesquemas de relações. Mas o que seria um bom esquema? Em nível geral, poderíamos dizerque seria um esquema fácil de entender e em que as tuplas da relação fossem armazenadase acessadas de forma eficiente. Para isso, é preciso que sejam minimizadas, ao máximo,a redundância nos dados e as anomalias de inserção, atualização e exclusão. Além disso,é preciso garantir a integridade dos dados, evitando que informações sem sentido sejaminseridas e é preciso organizar e dividir as tabelas da forma mais eficiente possível. Umaforma de colaborar com essas necessidades é fazer a normalização dos dados. Esse éjustamente o assunto deste capítulo. Neste capítulo estudaremos o que são dependências funcionais, seu impacto sobreos dados e como realizar a otimização do MR através da normalização dos dados. Vamos lá?Dependências Funcionais Sempre que um atributo X identifica um atributo Y dizemos que entre eles há uma Você Sabia?dependência funcional11. Temos, portanto, que X é o determinante e que Y é o dependente.A representação é: X → Y. Em outras palavras, se o valor de um atributo X permite descobrir 11 O Modelo Relacionalo valor de um outro atributo Y, dizemos que X determina funcionalmente Y. Por exemplo, pegou emprestado dadada uma determinada cidade (não considerando cidades homônimas) sabemos o seu teoria de funções daestado e com o estado temos o país. Isso é representado da seguinte forma: matemática o conceito de dependência Cidade → estado funcional. Estado → país Em outras palavras, estado é funcionalmente dependente de cidade e país éfuncionalmente dependente de estado. Ou ainda, cidade determina estado e estadodetermina país. Logo, a dependência funcional é caracterizada pela existência de campos em umadeterminada tabela relacional cuja ocorrência de valores está associada a valores quesão preenchidos em outros campos na mesma tabela. Por exemplo, suponha uma tabelaEMPREGADO que possui dois atributos CPF e NOME. O atributo NOME é funcionalmentedependente do atributo CPF. Assim, CPF → Nome. Com isso, queremos dizer que nome éfunção do CPF, ou seja, se eu tiver um número de CPF, poderei encontrar o nome da pessoacorrespondente. Em outras palavras, CPF determina o Nome (vide Figura 17). 41

×