UNIVERSIDADE FEDERAL RURAL DE PERNAMBUCO (UFRPE)

COORDENAO GERAL DE EDUCAO A DISTNCIA (EAD/UFRPE)

Banco de Dados

Sandra de Albuquerque Siebra

Volume 3

Recife, 2010

Universidade Federal Rural de Pernambuco Reitor: Prof. Valmar Corra de Andrade Vice-Reitor: Prof. Reginaldo Barros Pr-Reitor de Administrao: Prof. Francisco Fernando Ramos Carvalho Pr-Reitor de Extenso: Prof. Paulo Donizeti Siepierski Pr-Reitor de Pesquisa e Ps-Graduao: Prof. Fernando Jos Freire Pr-Reitor de Planejamento: Prof. Rinaldo Luiz Caraciolo Ferreira Pr-Reitora de Ensino de Graduao: Prof. Maria Jos de Sena Coordenao Geral de Ensino a Distncia: Prof Marizete Silva Santos

Produo Grfica e Editorial Capa e Editorao: Rafael Lira, Italo Amorim e Arlinda Torres Reviso Ortogrfica: Elias Vieira Ilustraes: No Aprgio Coordenao de Produo: Marizete Silva Santos

Sumrio
Apresentao................................................................................................................. 4 Conhecendo o Volume 3 ................................................................................................ 5 Captulo 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 Captulo 8 Derivando o MR a partir do MER .............................................................. 25 Algumas Informaes Iniciais ........................................................................................25 Regras para Derivar o Modelo Relacional a partir do MER............................................26 Captulo 9 Normalizao de Dados ............................................................................ 41 Dependncias Funcionais ..............................................................................................41 Anomalias de Atualizao ..............................................................................................43 O que Normalizao?..................................................................................................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 Normalizao ...................................................................................60 Algumas Informaes Adicionais ...................................................................................60 Consideraes Finais .................................................................................................... 67 Conhea a Autora ........................................................................................................ 69

Apresentao
Caro(a) cursista, Seja bem-vindo(a) ao terceiro mdulo do curso Banco de Dados! Neste terceiro mdulo, vamos estudar o modelo relacional e todas as suas nuances. O modelo relacional o resultado da modelagem lgica do Banco de Dados e a etapa seguinte a modelagem conceitual. Dentro deste contexto, estudaremos como tranformar a modelagem conceitual em modelagem lgica, como otimizar o modelo criado atravs das regras de normalizao e como fazer as checagens de integridade referencial. Bons estudos! Sandra de Albuquerque Siebra Autora

Banco de Dados

Conhecendo o Volume 3
Neste terceiro volume, voc ir encontrar o Mdulo 3 da disciplina de Banco de Dados. Para facilitar seus estudos, veja a organizao deste segundo mdulo.

Mdulo 3 Modelagem Lgica e Projeto de Banco de Dados

Carga horria do Mdulo 3: 15 h/aula Objetivo do Mdulo 3: Introduzir os principais conceitos e definies relacionados modelagem lgica de dados. Examinar os principais conceitos envolvidos no modelo relacional. Estudar como derivar a modelagem lgica a partir da modelagem conceitual. Estudar como otimizar a modelagem de dados atravs da normalizao. Contedo Programtico do Mdulo 3: O Modelo Relacional. As 12 Regras de Codd. Transformao do Modelo E-R para o Modelo Relacional. Restries de Integridade. Dependncias Funcionais. Normalizao de Dados.

Banco de Dados

Captulo 7
O que vamos estudar neste captulo?
Neste captulo, vamos estudar os seguintes temas: O Modelo Relacional. Restries de Integridade. As 12 Regras de Codd.

Metas
Aps o estudo deste captulo, 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.

Banco de Dados

Captulo 7 O Modelo Relacional

Vamos conversar sobre o assunto?
No projeto de Banco de Dados, a modelagem lgica ou projeto lgico a terceira etapa (vide Figura 1), antecedida pela anlise de requisitos e pela modelagem conceitual. O produto dessa etapa o modelo relacional ou esquema relacional e este justamente o assunto desse captulo! Esse modelo j dependente do SGBD que for ser escolhido para a implementao do banco de dados. Logo, atente para o fato de que esse o momento dessa deciso ser tomada.

Neste captulo, vamos falar sobre o modelo relacional, que um exemplo de modelo lgico de dados, e sobre os conceitos a ele relacionados.

Figura 1 - Etapas do Projeto de Banco de Dados

O Modelo Relacional (MR)

Vamos relembrar... o que o modelo lgico? um modelo que vai especificar a representao/declarao dos dados de acordo com o SGBD escolhido, definindo assim a estrutura de registros do BD (onde cada registro define nmero fixo de campos (atributos) e cada campo possui tamanho fixo). Um exemplo de modelo lgico o modelo relacional (MR). Os SGBDs que utilizam o MR so denominados SGBDs Relacionais e, nesta disciplina, trataremos do projeto lgico apenas desse tipo de SGBD.

Banco de Dados

O Modelo Relacional foi introduzido por Ted Codd, da IBM Research, em 1970, em um artigo clssico (Codd, 1970) que imediatamente atraiu a ateno em virtude de sua simplicidade e base matemtica. O modelo usa o conceito de uma relao matemtica algo como uma tabela de valores como seu bloco de construo bsica e tem sua base terica na teoria dos conjuntos. As primeiras implementaes comerciais do modelo relacional tornaram-se disponveis no incio da dcada de 80, antes disso, eram utilizados os modelos de redes e hierrquico (sobre os quais estudamos no Volume 1, captulo 1). O modelo relacional tem como objetivos: prover esquemas de fcil utilizao; melhorar a independncia lgica e fsica de dados; prover os usurios com linguagens de manipulao de BD de alto nvel, permitindo o seu uso por usurios no experientes; otimizar o acesso aos BDs e melhorar a integridade e segurana dos dados. O MR representa os dados do BD como relaes1 (tabelas) de nomes nicos. O conceito de tabelas est intimamente ligado ao conceito de uma relao matemtica de onde se origina o nome deste modelo. Vamos apresentar, na seo a seguir, cada um dos conceitos relevantes dentro do contexto do modelo relacional.

Comentrio
1

A palavra relao utilizada no sentido de lista ou rol de informaes e no no sentido de associao ou relacionamento.

Conceitos do Modelo Relacional

Em um ambiente de banco de dados relacional utilizamos alguns conceitos muito importantes para a correta implantao e operao de qualquer sistema de banco de dados. Por exemplo, na terminologia do modelo relacional, cada tabela chamada relao e vai possuir um nome nico que a identifica, cada linha da tabela chamada tupla, cada cabealho 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 so decorrentes da utilizao de elos lgicos 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 Relao
No modelo relacional, a estrutura que armazena os dados referentes a cada uma das ocorrncias de uma entidade ou relacionamento com atributos do MER chamada de tabela ou relao. Uma tabela uma representao bi-dimensional de dados composta de linhas e colunas. Por exemplo, a tabela de empregados de uma empresa (vide Tabela 1) onde

Banco de Dados

poderiam ser armazenados dados como o CPF, o nome e o telefone de cada empregado. A tabela como um todo representaria os empregados da empresa. Cada coluna representaria um atributo (ex: a primeira coluna da Tabela 1 o CPF ). E cada linha da tabela representa os dados de um empregado. Por exemplo, a primeira linha da Tabela 1 se refere empregada de CPF nmero 987675456-98, de nome Ana Marques e cujo telefone 3245-8976.
Tabela 1 - Tabela ou Relao Empregado CPF 987675456-98 765456243-45 213415467-89 567324980-03 Nome Ana Marques Joo Pontes Marcos Alves Tnia Gomes Telefone 3245-8976 3124-5645 3456-8923 3455-9098

Matematicamente, define-se uma relao como um subconjunto de um produto cartesiano de uma lista de domnios2. Assim, suponha que D1 denote o domnio do atributo A1, D2 denote o domnio do atributo A2 e Dn denote o domnio do atributo N da tabela T1. Qualquer linha da tabela que possui estes atributos denotada pela tupla3 (d1,d2,...,dn) em que d1, d2 e dn tm como valores possveis (domnios), respectivamente D1, D2 e Dn. Em geral, uma instncia de T1 um subconjunto de D1 X D2 X ... X Dn. O conjunto de atributos de uma relao chamado de esquema da relao. O esquema de uma relao denotado por : R[A1 D1, ..., An Dn] onde: R o nome da relao; A1, ..., An a lista de atributos da relao R e D1, ..., Dn so os domnios de cada um dos atributos da relao R. Frequentemente, utilizada uma notao simplificada em que omitida a definio do domnio de cada atributo da relao: R[A1, ..., An]. Por exemplo, o esquema da relao representada na Tabela 1 seria: Empregado[CPF char4(11), Nome char(50), Telefone char(9)] ou, na notao simplificada, teramos Empregado[CPF, Nome, Telefone]. Na criao dos esquemas das relaes o nome das relaes ou tabelas devem ser nicos no banco de dados, devem ser escritos no singular e, de preferncia, devem ser nomes curtos. Se for usado um nome composto, este deve ser separado por um underline (_), por exemplo Pessoa_Fisica ou Pessoa_Juridica. O atributo identificador da relao apresentado sublinhado (esse atributo identificador dar origem chave primria da relao, como veremos mais a frente). Assim, se CPF fosse o atributo identificador teramos: Empregado[CPF, Nome, Telefone]. O grau de uma relao o nmero de atributos que a compe. Por exemplo, o grau da relao Empregado[CPF, Nome, Telefone] trs, porque essa relao possui 3 atributos. Uma particularidade referente definio de relao que, nesta definio, no existe qualquer tipo de ordenao ou de definio de ordenao. Assim, por exemplo, as duas relaes representadas pelas Tabelas 1 e 2 so consideradas idnticas. Afinal, o que mudou de uma tabela para outra foi apenas a ordem em que os valores de preenchimento da tabela aparecem.

Comentrio
2

Um domnio contm os valores possveis para um determinado atributo da relao.

Comentrio
3 Uma tupla uma ocorrncia particular de um elemento da tabela. Falaremos sobre esse conceito, em detalheas, mais a frente.

Comentrio
O tipo char equivale ao tipo string das linguagens de programao, onde voc pode digitar letras, nmeros e smbolos. Quando voc define um tipo char, voc tem de especificar o tamanho do que preencher o mesmo. Esse tipo pode variar de nome de SGBD para SGBD mas sempre vai ter um correspondente.
4

Banco de Dados

Tabela 2 - Tabela ou Relao Empregado CPF 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Telefone 3456-8923 3455-9098 3124-5645 3245-8976

Linha (Tupla)
Uma ocorrncia 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 compe ocupam uma linha diferente da tabela. Como existem 4 empregados, a Tabela 3 possui 4 linhas (ou tuplas ou registros). O nmero de linhas ou tuplas de uma relao chamado de cardinalidade da relao. Logo, a cardinalidade da relao 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 primria (PK) - detalharemos melhor esse ponto mais a frente.
Tabela 3 - Exemplos de Atributos e Tuplas

Outra definio 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 domnio Di ou um valor nulo. Algumas regras para tuplas so: em uma tabela ou relao no devem existir tuplas ou linhas duplicadas. As linhas de uma tabela no seguem uma ordem especfica. Dessa forma, as tuplas ou linhas abaixo seriam idnticas: 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 informao armazenada em uma tabela uma coluna. Ou seja, cada

10

Banco de Dados

atributo que caracteriza a relao expresso em uma coluna. Toda coluna de uma tabela deve possuir um nome pelo qual ser referenciada sempre que necessrio. Na verdade, ao criarmos uma tabela definimos, para cada uma de suas colunas, o seu nome (nome do atributo) e tambm o seu tipo (numrico, alfabtico, data, etc). Por exemplo, CPF, Nome e Telefone so 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 de informao que ele representa. E o valor de um atributo no deve poder ser decomposto em mais de uma coluna.

Domnio do Atributo
Domnio de um atributo a faixa de valores que esse atributo pode conter. Em outras palavras, o conjunto de valores que um determinado atributo pode assumir. Por exemplo, para o atributo CPF da Tabela 3, o domnio seria o conjunto dos nmeros naturais. Em outras tabelas quaisquer, por exemplo, o domno do atributo dia do msseria o conjunto dos nmeros entre 1 e 31. O atributo sexo teria como domnio os mnemnicos M (para masculino) ou F (para feminino) e assim por diante. Sempre que identificamos um atributo de uma tabela, temos tambm uma ideia de qual o tipo de informao que ele poder vir a conter.

Chaves
Uma chave5 um atributo (ou conjunto de atributos) que identifica univocamente cada entrada de uma relao. Ou seja, por meio de chaves podemos diferenciar as diversas tuplas pertencentes a uma relao. Como consequncia dessa definio, temos que os atributos chaves no podem apresentar valores duplicados, nem podem ser nulos.
NULO - No devemos confundir o conceito de nulo com espaos em branco ou o nmero zero, por exemplo, que so valores conhecidos. Nulo a ausncia de informao. Uma coluna de preenchimento obrigatrio numa tabela deve possuir todos os seus valores nonulos. 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 no foi informado por algum motivo ou o empregado no possui telefone, de qualquer forma, a informao est ausente na tabela.
5

Comentrio
O conceito de chave est diretamente ligado ao de identificador da entidade ou relacionamento que foi estudado no volume anterior, quando foram detalhados os componentes do MER.

Comentrio
6

Uma definio mais formal para chave seria: seja R um esquema de relao. Se dissermos que um subconjunto K de atributos de R uma superchave6 para R, estaremos considerando restries para as relaes r(R), nas quais no existem duas tuplas distintas com mesmos valores em todos os atributos de K. Isto , se as tuplas t1 e t2 fazem parte da relao r e t1 <> t2, ento t1[K] <> t2[K]. Quando h a possibilidade de mais de um atributo (isoladamente) poder ser chave em uma relao, dizemos que esses atributos so chaves candidatas. Por exemplo, na Tabela 4, CPF e Nome poderiam ser chaves candidatas, porque poderiam ser atributos usados para localizar uma entrada na tabela.

Superchave o conjunto de um ou mais atributos que nos permitem identificar de maneira unvoca uma tupla de uma relao.

11

Banco de Dados

Tabela 4 - Tabela ou Relao Empregado CPF (PK) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Telefone 3456-8923 3455-9098 3124-5645 3245-8976

Um dos princpios 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 primria 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 primria seria o atributo CPF, j que essa informao no se repetiria, de forma alguma, em dois empregados distintos da tabela.
A escolha da chave primria (PK) da tabela influenciada pelas necessidades do domno do mundo real que est sendo modelado.

Chaves primrias so geralmente indicadas na tabela pela sigla PK (Primary Key) e podem tambm ser sublinhadas (vide Tabela 4). As outras chaves candidatas que no forem escolhidas para chave primria, so chamadas de chaves secundrias. Por exemplo, na Tabela 4, o atributo Nome seria uma chave secundria. Muitas vezes, uma tabela no possui, entre seus atributos, um que por si s seja suficiente para identificar univocamente uma ocorrncia. Nesses casos deve sempre ser possvel que a combinao de dois ou mais atributos tenha a capacidade de se constituir numa chave primria. Chamamos a essas chaves primrias formadas pela combinao de vrios atributos de chaves primrias compostas. Ou seja, uma chave primria composta uma chave primria 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 primrias compostas. Por exemplo, a tabela Alocao (vide Tabela 5), ter como chaves primrias os atributos CPF e Cod_Projeto. Isso, porque para descobrir qual a funo de um empregado em um projeto, precisamos dessas duas informaes. Nenhum dos atributos isoladamente poderia fornecer essa informao.
Tabela 5 - Tabela ou Relao Alocao CPF (PK) 213415467-89 567324980-03 765456243-45 987675456-98 Cod_projeto (PK) 002 001 003 002 Funo Analista Consultor Suporte Programador

12

Banco de Dados

Tabela 6 - Tabela ou Relao Empregado CPF (PK) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Telefone 3456-8923 3455-9098 3124-5645 3245-8976

Tabela 7 - Tabela ou Relao Projeto Cod_projeto (PK) 001 002 003 Nome Projeto SOFTHOUSE GEOPROC LINUX WORLD

Uma tabela pode incluir entre seus atributos a chave primria de outra tabela. Essa chave chamada chave estrangeira. Ou seja, uma chave estrangeira uma coluna (ou combinao de colunas) que indica um valor que deve existir como chave primria em uma outra tabela (chamada de Tabela Pai). Por exemplo, na tabela Alocao (vide Tabela 5), as colunas CPF e Cod_Projeto so chaves estrangeiras, porque elas so chave primria, respectivamente, das tabelas Empregado (vide Tabela 6) e Projeto (vide Tabela 7). Vamos definir novamente com outras palavras: uma chave estrangeira de uma relao R1 um atributo (ou conjunto de atributos) que referencia a chave primria de uma outra relao R2. Dessa forma, para qualquer tupla de R1, o valor da chave estrangeira deve ser igual ao valor da chave primria de alguma tupla da relao R2 referenciada, ou deve ser o valor nulo (se a chave estrangeira no fizer parte da chave primria da relao R1). Com isso queremos dizer que o atributo que chave estrangeira em uma relao R1, pode ou no fazer parte da chave primria de R1. No exemplo de chave estrangeira dado anteriormente, as chaves estrangeiras CPF e Cod_Projeto fazem parte da chave primria da tabela Alocao (vide Tabela 5). Porm, a chave estrangeira pode no fazer parte da chave primria. Observe a tabela Funcionrio (vide Tabela 8). Ela possui um campo Cod_Depto que chave primria da tabela Departamento (vide Tabela 9). Logo, na tabela Funcionrio, o atributo Cod_Depto uma chave estrangeira. Chaves estrangeiras so indicadas pela sigla FK (Foreign Key).
Tabela 8 - Tabela ou Relao Funcionrio CPF (PK) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Cod_Depto (FK) 11 22 11 22

13

Banco de Dados

Tabela 9 - Tabela ou Relao Departamento Cod_Depto (PK) 11 22 Nome

Vendas 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 atravs de chaves estrangeiras. Ou seja, as chaves estrangeiras tornam possvel a associao lgica entre tabelas distintas. Isso ficar mais claro no prximo captulo quando forem apresentadas as regras de derivao do MR a partir do MER.

Regras de Integridade Fundamentais

O modelo relacional, ao definir conceitos como Tabela, Tupla, Atributo, Nulo, Domnio, Chave Primria e Chave Estrangeira deixa implcitas algumas regras fundamentais para a manuteno da consistncia do banco de dados. Elas so chamadas de Regras de Integridade e tratam dos cuidados que analistas, projetistas e programadores devem observar ao implementar as rotinas de Incluso, Alterao e Excluso de dados nas bases de dados. Na prtica, as restries de integridade fornecem meios para assegurar que mudanas feitas no banco de dados no resultem na perda da consistncia 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 semntica.

Integridade de Entidade (ou de Identidade ou Existencial)

Refere-se s chaves primrias e procura garantir que toda e qualquer linha de uma tabela deve poder ser acessada com base apenas no contedo de sua chave primria. Para isso, algumas regras devem ser observadas: Toda tupla tem um conjunto de atributos que a identifica de maneira nica na relao (Integridade de Chave). Nenhum atributo que faa parte de uma chave primria pode ter valor nulo (eles devem ser NN = not null). No se deve permitir que em uma mesma tabela existam duas ocorrncias (tuplas) com chaves primrias iguais. Ou seja, os atributos que so chave primria devem ser nicos (ND = No Duplicate ou Unique).

Isso significa que os contedos de todos os atributos que constituem uma chave primria devem ser conhecidos e nicos. Um contedo nulo representa uma informao desconhecida ou, em outras palavras, a ausncia da informao, o que no pode ser permitido em qualquer elemento de uma chave primria. Algumas recomendaes para se alcanar a integridade de entidade so:

14

Banco de Dados

Selecione chaves primrias que realmente tenham preenchimento nico no domnio do problema. Se possvel, prefira chaves primrias simples e numricas. Se no houver nenhuma coluna que possa ser uma chave candidata, utilize chaves primrias sequenciais, geralmente, atribudas pelo sistema.

Integridade Referencial
Diz respeito s chaves estrangeiras e visa manter a integridade dos relacionamentos previstos no banco de dados. Ou seja, a integridade referencial cuida para que uma relao possa ter um conjunto de atributos que contm valores com mesmo domnio de um conjunto de atributos que forma a chave primria de outra relao. Este conjunto chamado chave estrangeira. Na definio dos cuidados referentes a esse tipo de integridade, utilizaremos dois conceitos: Tabela-Pai (Parent Table): aquela onde o atributo de relacionamento desempenha o papel de chave primria. Tabela-Filho (Dependent Table): tabela onde o atributo de relacionamento desempenha o papel de chave estrangeira.

Para manter a integridade referencial, a regra bsica : o contedo de uma chave estrangeira deve, necessariamente, ser igual ao de uma ocorrncia da Tabela-Pai ou ento ser nulo. Vale ressaltar que o valor da chave estrangeira s poder ser nulo na Tabela-Filho, se o atributo que for chave estrangeira no fizer parte da chave primria da Tabela-Filho. Por exemplo, na ltima tupla da tabela Funcionrio (vide Tabela 10), temos que o Cod_Depto NULL. Isso possvel apenas porque o atributo Cod_Depto no faz parte da chave primria da tabela Funcionrio. E deve significar que, por enquanto, a funcionria Ana Marques no foi alocada em nenhum departamento (vamos supor que ela acabou de ser contratada). J todas as outras tuplas da tabela Funcionrio possuem o Cod_Depto preenchido e, para que a integridade referencial seja mantida, como esse atributo chave estrangeira, ele deve existir como chave primria em alguma outra tabela. No caso, na tabela Departamento (vide Tabela 9). Nesse exemplo fornecido, a tabela Funcionrio a Tabela-Filho e a tabela Departamento a Tabela-Pai.
Tabela 10 - Tabela ou Relao Funcionrio CPF (PK) 213415467-89 567324980-03 765456243-45 987675456-98 Nome Marcos Alves Tnia Gomes Joo Pontes Ana Marques Cod_Depto (FK) 11 22 11 NULL

15

Banco de Dados

Observao
Uma chave estrangeira pode referenciar-se a um atributo da sua prpria tabela (caso que ocorrer com os auto-relacionamentos do MER). Por exemplo, a tabela Funcionrio (vide Tabela 11) poderia ter, para cada funcionrio, quem o seu supervisor direto. Assim, o campo CPF_Supervisor, que considerado chave estrangeira, a chave primria da prpria tabela Funcionrio e no de outra tabela qualquer.

Tabela 11 - Tabela ou Relao Funcionrio CPF (PK) 213415467-89 567324980-03 765456243-45 Nome Marcos Alves Tnia Gomes Joo Pontes CPF_Supervisor (FK) 765456243-45 765456243-45 NULL

As consequncias da Integridade Referencial refletem-se nas consistncias necessrias ao se proceder s operaes de Incluso, Alterao e Excluso de dados nas Tabelas Pai e Filho. Veja as regras no Quadro 1.

16

Banco de Dados

Quadro 1 - Regras de Incluso, Alterao e Excluso para manter a Integridade Referencial Operao Tabela_Pai Tabela-Filho A incluso de dados na TabelaFilho deve atentar para o fato de Incluso A incluso de dados na tabela-pai no tem nenhuma implicao ou problema. que no ser possvel incluir uma nova tupla se o valor do campo que for chave estrangeira j no estiver cadastrado na Tabela-Pai. Se a alterao envolver o valor da chave primria, deve-se utilizar um dos seguintes critrios: A chave no deve ser alterada se estiver sendo utilizada em alguma tabela-filho. A chave deve ser alterada e deve-se colocar NULL nas chaves estrangeiras presentes na(s) Tabela(s)-Filho (contanto que o valor em questo no faa parte da chave primria da(s) Tabela(s)-Filho correspondente(s)). 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 critrios: No deletar, se a tupla estiver sendo utilizada em uma Tabela-Filho. Deletar a tupla e colocar NULL nas chaves estrangeiras das Tabelas-Filhos afetadas (isso se o atributo envolvido no fizer parte da chaveprimria da Tabela-Filho). Deletar e, tambm, eliminar todas as tuplas das Tabelas-Filho que faam uso do valor da tupla sendo eliminada. A excluso de Dados na TabelaFilho no tem nenhuma implicao ou problema. Se a alterao envolver o atributo que chave estrangeira, a alterao s deve ser realizada Alterao usando valores que existam na tabela pai (podendo tambm usar o valor NULL, se essa chave estrangeira no fizer parte da chave primria da Tabela-Filho).

Excluso

As restries de integridade devem ser implementadas pelo SGBD. Muitos SGBDs implementam integridade de entidade, mas no implementam integridade referencial.

Regras de Integridade Complementares

Alm das regras de integridade de entidade e referencial, um banco de dados relacional pode suportar um conjunto adicional de regras (ou restries) cuja finalidade

17

Banco de Dados

especificar aspectos prprios de cada coluna e respectivo domnio, complementando com isso a definio de suas caractersticas lgicas. As principais restries de integridade complementares tratam da obrigatoriedade e unicidade de valores e sobre conjuntos de valores permitidos. Vamos s regras: Obrigatoriedade - Indica se deve ou no ser permitida a existncia de nulos em uma coluna (ou seja, se um atributo pode ou no ser nulo). Colunas que no aceitam nulos so de preenchimento obrigatrio como, por exemplo, o nome de um funcionrio na tabela de funcionrios. Campos que no possuam obrigatoriedade de preenchimento so considerados campos opcionais. Por exemplo, o nmero do telefone poderia ser um campo opcional, dependendo do domnio, visto que ainda podem haver pessoas que no possuem nmero de telefone. A definio de se um campo ser de preenchimento obrigatrio ou no, vai depender muito do domnio do mundo real sendo modelado. Unicidade - Indica se deve ser permitido ou no que uma coluna possua valores idnticos em duas ou mais linhas. Uma coluna que no pode possuir valores repetidos uma coluna de valores nicos. Verificao de Valores Especficos - 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.

Restries de Integridade Semntica

So restries especificadas e mantidas num banco de dados relacional pelo programa de aplicao e que so inerentes a aplicao sendo desenvolvida. Ou seja, so as regras de negcio do domnio do mundo real sendo implementado. Por exemplo, em um determinado sistema pode-se querer implementar a restrio que o salrio de um empregado no pode ser maior do que o salrio do seu supervisor direto ou que o nmero mximo de horas por semana que um empregado pode trabalhar em projetos de 40 horas (suponha que a empresa no permite horas extras) ou, ainda, a data de entrega de um pedido no pode ser inferior data em que o pedido foi realizado. Tais restries, como dito, so especficas do domnio sendo implementado e necessitam ser programadas em cada aplicao 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 ttulo de conhecimento, vamos apresent-las a seguir. Lembramos que nem todas as regras sero completamente compreendidas nesse momento, mas o sero at o final da disciplina. Regra 1 - Regra das informaes em tabelas: As informaes a serem armazenadas no banco de dados devem ser apresentadas como relaes (tabelas formadas por linhas e colunas) e o vnculo 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 atmico em um BD relacional possui a garantia de ser logicamente acessado pela combinao do nome da tabela, do valor da chave primria e do nome do campo/coluna que deseja acessar. Isso

18

Banco de Dados

porque, com o nome da tabela, se localiza a tabela desejada. Com o valor da chave primria a tupla desejada dentro da tabela localizada. E com o nome do campo/coluna se acessa a parte desejada da tupla. Regra 3 - Regra de tratamento sistemtico de valores nulos: Valores nulos devem ser suportados de forma sistemtica e independente do tipo de dado para representar informaes inexistentes e informaes inaplicveis. Deve-se sempre lembrar que valores nulos devem ter um tratamento diferente de valores em branco. Regra 4 - Regra do catlogo relacional ativo: Toda a estrutura do banco de dados (domnios, campos, tabelas, regras de integridade, ndices, etc) deve estar disponvel em tabelas (tambm referenciadas como catlogo). Sua manipulao possvel por meio de linguagens especficas (por exemplo, SQL). Essas tabelas so, geralmente, manipuladas pelo prprio sistema no momento em que o usurio efetua alteraes na estrutura do banco de dados (por exemplo, a incluso de um novo atributo em uma tabela). Regra 5 - Regras de atualizao de alto-nvel: Essa regra diz que o usurio deve ter capacidade de manipular as informaes do banco de dados em grupos de registros, ou seja, ser capaz de inserir, alterar e excluir vrios registros ao mesmo tempo7. Regra 6 - Regra de sub-linguagem de dados abrangente: Pelo menos uma linguagem, com sintaxe bem definida, deve ser suportada, para que o usurio possa manipular a estrutura do banco de dados (como criao e alterao de tabelas), assim como extrair, inserir, atualizar ou excluir dados, definir restries de integridade e de acesso e controle de transaes (commit e rollback8, por exemplo). Deve ser possvel ainda a manipulao dos dados por meio de programas aplicativos. Regra 7 - Regra de independncia fsica: Quando for necessria alguma modificao na forma como os dados esto armazenados fisicamente, nenhuma alterao deve ser necessria nas aplicaes que fazem uso do banco de dados (isolamento), assim como devem permanecer inalterados os mecanismos de consulta e manipulao de dados utilizados pelos usurios finais. Regra 8 - Regra de independncia lgica: Qualquer alterao efetuada na estrutura do banco de dados como incluso ou excluso de campos de uma tabela ou alterao no relacionamento entre tabelas no deve afetar o aplicativo utilizado ou ter um baixo impacto sobre o mesmo. Da mesma forma, o aplicativo somente deve manipular vises9 dessas tabelas. Regra 9 - Regra de atualizao de vises: Uma vez que as vises dos dados de uma ou mais tabelas so, teoricamente, suscetveis a atualizaes, ento um aplicativo que faz uso desses dados deve ser capaz de efetuar alteraes, excluses e incluses neles. Essas atualizaes, no entanto, devem ser repassadas automaticamente s tabelas originais. Ou seja, a atualizao em uma viso deve refletir na atualizao das tabelas representadas por essa viso. Regra 10 - Regra de independncia de integridade: As vrias formas de integridade de banco de dados (integridade de entidade, integridade referencial e restries de integridade complementares) precisam ser estabelecidas dentro do catlogo do sistema ou dicionrio de dados e serem totalmente independentes da lgica dos aplicativos. Assim, os aplicativos no devem ser afetados quando ocorrerem mudanas nas regras de restries de integridade. Regra 11 - Regra de independncia de distribuio: Alguns SGBDs, notadamente os que seguem o padro SQL, podem ser distribudos em diversas plataformas/equipamentos que se encontrem interligados em rede. Essa capacidade de distribuio no pode afetar a funcionalidade do sistema e dos aplicativos que fazem uso do banco de dados. Em resumo,
8

Comentrio
7

Veremos como fazer isso no ltimo volume desta disicplina, quando estivermos estudando a linguagem SQL.

Comentrio
Commit serve para confirmar as operaes realizadas no banco de dados. Rollback serve para desfazer uma operao que ainda no tenha sido confirmada.

Comentrio
Viso: uma relao virtual que no faz parte do esquema conceitual do BD, mas que visvel a um grupo de usurios. Em outras palavras, uma viso uma tabela virtual que definida a partir de outras tabelas, contendo sempre os dados atualizados.
9

19

Banco de Dados

as aplicaes no so logicamente afetadas quando ocorrem mudanas geogrficas dos dados (caso dos BDs distribudos). Regra 12 - Regra no-subversiva: O sistema deve ser capaz de impedir qualquer usurio ou programador de transgredir os mecanismos de segurana, regras de integridade do banco de dados e restries, utilizando algum recurso de linguagem de baixo nvel que eventualmente possam ser oferecidos pelo prprio sistema.

Conhea Mais
Neste captulo foram vistos conceitos bsicos do modelo relacional. Para obter mais informaes 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 Lgica + 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 captulos voltados para a explicao do modelo relacional. Entre os livros que podemos indicar esto: HEUSER, CARLOS ALBERTO. Projeto De Banco De Dados Srie Livros Didticos, V.4. Bookman Companhia Ed., 6 Edio - 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. So Paulo: Pearson Education do Brasil, 2005. DATE, C. J. Introduo 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 padro dos Bancos de Dados Relacionais a Structured Query Language, ou simplesmente SQL, como mais conhecida. Ela ser assunto do prximo volume (Volume 4) da disciplina.

Aprenda Praticando
Vamos dar uma olhada novamente em questes de concurso? NCE-UFRJ - 2001 - TRE-RJ - Analista Judicirio - Especialidade - Anlise de Sistemas - Desenvolvimento 1) Sobre os conceitos de domnio, atributo e relacionamento, correto afirmar que: a) um domnio definido pelo conjunto dos atributos pertencentes a um relacionamento;

20

Banco de Dados

b) domnio e atributo representam um nico conceito semntico; c) um atributo considerado identificador se pertencer ao domnio que define um relacionamento; d) todos os atributos de uma relao devem pertencer a um mesmo domnio; e) domnio so os valores possveis que um atributo pode assumir. 2) A cardinalidade de uma relao caracterizada por: a) Nmero de atributos dessa relao; b) Nmero de campos dessa relao; c) Quantidade de chaves estrangeiras da relao; d) Nmero de tuplas de uma relao; e) Nenhuma das respostas anteriores. 3) Uma chave estrangeira: a) Pode conter valores que no existem na Tabela-Pai (tabela referenciada); b) Pode no pertencer chave primria; c) Tem de pertencer, obrigatoriamente, chave primria; d) Podem sempre assumir o valor nulo; e) Nenhuma das respostas anteriores. Fundao Getlio Vargas 2008 4) No contexto de Banco de Dados, um conceito assegura que um valor que aparece em uma tabela para um determinado conjunto de atributos aparea em outro conjunto de atributos de outra tabela. Por exemplo, se cristalina o nome de uma agncia que aparece em uma tupla da tabela conta, ento 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 vlidas e que no exclui ou altera, acidentalmente, dados relacionados. Tratase do seguinte conceito: a) Integridade Funcional; b) Dependncia Funcional; c) Integridade Relacional; d) Dependncia Referencial; e) Integridade Referencial. (Tcnico de Tecnologia da Informao/UFT/FCC/2005) 5) Os dois principais tipos de integridade a serem mantidos em um banco de dados relacional adequadamente projetado so: 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

Banco de Dados

6) Um tipo de dado especfico, como por exemplo Nome do Funcionrio, armazenado numa localizao da estrutura do banco de dados denominada. a) Tabela; b) Linha; c) Planilha; d) Coluna; e) Registro.

Respostas:
1) E O domnio de um atributo so os valores que ele pode assumir. Ou seja, o tipo deste atributo. Por exemplo, o atributo dia do ms tem como domnio os valores naturais entre 1 e 31. 2) C A cardinalidade de uma relao o nmero de linhas ou tuplas dessa relao. Assim, uma relao com quatro tuplas, tem cardinalidade 4. 3) B Uma chave estrangeira pode no pertencer chave primria, no pode conter valores que no existam na tabela-pai e s podem assumir valor nulo se no pertencer chave primria da tabela onde chave estrangeira. 4) E Integridade Referencial. Ela checa todas as validaes necessrias referentes ao uso de chaves estrangeiras. 5) C os dois principais tipos de integridade que podem ser verificados em um BD relacional so a integridade de entidade (que se referem s checagens da chave primria) e a integriadade referencial (que se refere s checagens da chave estrangeira). 6) D Nome do funcionrio tipicamente um atributo e um atributo representado no BD relacional por uma coluna.

Atividades e Orientaes de Estudo

Agora vamos exercitar o que foi estudado neste captulo. Assim sendo, faa as atividades sugeridas a seguir. Lembre que exercitar vai ajud-lo(a) a fixar melhor o contedo estudado. E o contedo desse captulo fundamental para o captulo seguinte, onde vamos aprender a construir o Modelo Relacional. Mos obra!

Atividades Prticas:
Responda as questes a seguir em um documento de texto (doc) e poste as respostas no ambiente virtual, no local indicado. Esse trabalho deve ser feito individualmente. (Exerccios adaptados do livro de Carlos Heuser (1998) - captulo 4). Exerccio 1: Abaixo aparecem diversos esquemas de relao que compem um banco de dados relacional. Identifique nestes esquemas, da maneira apropriada, as chaves primrias e chaves estrangeiras: Aluno (CodigoAluno,Nome,CodigoCurso) Curso(CodigoCurso,Nome)

22

Banco de Dados

Disciplina(CodigoDisciplina,Nome,Creditos,CodigoDepartamento) Curriculo(CodigoCurso,CodigoDisciplina,Obrigatria-Opcional) Conceito(CodigoAluno,CodigoDisciplina,Ano-Semestre,Conceito) Departamento(CodigoDepartamento,Nome) Exerccio 2: Considere o esquema das relaes de um BD relacional a seguir: Paciente(CodigoConvenio (FK), NumeroPaciente, Nome) Convenio(CodigoConvenio, Nome) Medico(CRM, Nome, Especializao) Consulta(CodigoConvenio (FK), NumeroPaciente (FK), CRM(FK), Data-Hora) A partir desse esquema, explique que verificaes/checagens deveriam ser feitas pelo SGBD para garantir integridade referencial nas seguintes situaes: a) Uma linha includa na tabela Consulta. b) Uma linha excluda da tabela Paciente.

Vamos Revisar?
Voc estudou, neste captulo, os conceitos bsicos referentes ao modelo relacional. Entre eles, os conceitos de tabela ou relao, tuplas ou linhas, atributos ou colunas e chaves (chave candidata, primria, secundria e estrangeira). Esses conceitos sero todos utilizados no prximo captulo onde voc aprender a derivar o modelo relacional a partir do modelo entidade-relacionamento. Adicionalmente, foram vistos tambm neste captulo os principais tipos de integridade (de entidade e referencial), alm de integridades complementares e integridade semntica.

23

Banco de Dados

Captulo 8
O que vamos estudar neste captulo?
Neste captulo, vamos estudar os seguintes temas: Como derivar o MR a partir do MER.

Metas
Aps o estudo deste captulo, esperamos que voc consiga: Derivar o MR a partir do MER. Verificar a corretude do modelo derivado.

24

Banco de Dados

Captulo 8 Derivando o MR a partir

do MER
Vamos conversar sobre o assunto?
Vimos no captulo anterior os conceitos bsicos do modelo relacional. Porm, ainda no vimos como gerar o modelo relacional, que faz parte da modelagem lgica do banco de dados, que a terceira etapa do projeto de banco de dados como um todo. A melhor maneira de produzir o modelo relacional deriv-lo a partir do modelo entidaderelacionamento. Para fazer isso, existem algumas regras. So justamente essas regras que discutiremos neste captulo.

Neste captulo, voc vai aprender como derivar o MR a partir do MER, para isso, todas as instrues de como fazer isso sero dadas. Vamos l?

Algumas Informaes Iniciais

A terceira fase do projeto de banco de dados o projeto lgico que objetiva mapear o modelo de dados conceitual para o modelo de dados relacional. Essa fase d origem ao esquema lgico representado pelo modelo relacional que j um modelo que depende do SGBD e ser usado para implementar o banco de dados. comum, em projetos de banco de dados, se realizar a modelagem dos dados atravs de um modelo de dados de alto-nvel. O modelo de dados de alto-nvel normalmente adotado o Modelo Entidade-Relacionamento (MER) e o esquema das vises e de toda a base de dados so especificados em diagramas entidade-relacionamento (DER). O passo seguinte modelagem dos dados conceitual o mapeamento do diagrama da base de dados global para um modelo de dados de implementao. Existem trs tipos de modelos de dados de implementao: hierrquico, rede e relacional. Para cada um desses modelos, podem-se definir estratgias de traduo a partir do DER. A estratgia de traduo, ou de mapeamento, que trataremos neste captulo e nesta disciplina ser apenas para o modelo de dados relacional. O Modelo Relacional a representao do modelo lgico do projeto de banco de dados, sendo que a forma de representao dos conceitos necessrios ao projeto deve passar a ser mais detalhada e se aproximar um pouco mais da representao fsica. Dessa forma, vrias mudanas devem ser realizadas no DER gerado na fase de modelagem conceitual, como, por exemplo: entidades passam a ser representadas por relaes ou tabelas. Atributos passam a ser representados em colunas. O atributo identificador passa a ser a chave primria (PK) da tabela. Os relacionamentos e as dependncias passam a ser representados por chaves estrangeiras (FK) e assim por diante. Na Figura 3, pode ser visto um exemplo do resultado da transformao de um MER em MR. Cada etapa desse mapeamento ser estudada na seo a seguir.

25

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 derivao do MR a partir do MER. Mapeamento de Entidades Fortes Cada conjunto de entidades fortes mapeado como uma relao que envolve todos os atributos da entidade correspondente do DER. Assim, para cada entidade regular E no DER, criar uma relao R que inclua todos os atributos simples de E. Se houver atributos compostos, inclua apenas os atributos simples que compem 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 primria da relao 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 relao ou tabela de nome Aluno, com duas colunas (atributos) CPF, que deveria ser marcado como chave primria (PK) e Nome. Como, anteriormente explicado, se houvesse atributos compostos, esses deveriam ser substitudos pelos atributos simples que o compem (vide Figura 5). Assim, o atributo Endereo, que composto pelos atributos Rua, Numero e Bairro, seria representado na relao apenas por estes ltimos.

Figura 4 - Exemplo de Mapeamento de Entidade Forte

26

Banco de Dados

Figura 5 - Exemplo de mapeamento de atributo composto

Mapeamento de Atributos Multivalorados Os atributos multivalorados vo se tornar relaes cujas chaves primrias sero compostas pela chave da entidade possuidora do atributo mais o atributo multivalorado. Ou seja, para cada atributo A multivalorado, deve-se criar uma nova relao R que inclua o atributo multivalorado A e a chave-primria K da relao que representa o tipo de entidade ou o tipo de relacionamento que tem A como atributo. O detalhe que a chave-primria da relao R ser composta por K e pelo atributo A. Se o atributo multivalorado for composto, voc deve seguir a instruo anteriormente dada de decomp-lo (usar os atributos simples que o compem). 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 relao Empregado (pela regra j descrita anteriormente) e o atributo mutivalorado Telefone daria origem a outra relao, que chamamos de Telefone_Empregado, contendo a chave primria da relao Empregado (que originou-se da entidade possuidora do atributo) e o atributo valorado, tambm fazendo parte da chave primria dessa nova relao.

Figura 6 - Exemplo mapeamento de atributo multivalorado

Mapeamento de Entidades Fracas So mapeadas em uma relao formada por todos os atributos da entidade fraca mais os atributos que formam a chave primria da relao da qual a entidade fraca depende. O relacionamento no mapeado. Assim, para cada tipo de entidade fraca EF do DER, criar uma relao R e incluir todos os atributos simples (ou os componentes simples de atributos compostos) de EF como atributos de R. Alm disso, incluir como a chave-estrangeira de R a

27

Banco de Dados

chave-primria da relao que corresponde entidade forte, da qual a entidade fraca depende. Logo, a chave primria da entidade fraca dever ser formada pela chave primria da relao 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 relao Empregado, como explicado anteriormente. A entidade fraca Dependente deu origem a uma relao cuja chave primria formada pela chave primria de empregado (CPF) e pelo identificador da prpria entidade fraca (RG), alm do atributo adicional Nome.

Figura 7 - Exemplo de mapeamento de entidade fraca

Mapeamento de Relacionamentos Binrios 1:1 Esse tipo de relacionamento no mapeado em uma nova relao. Seus atributos so colocados em qualquer uma das relaes que mapeiem as entidades envolvidas. A entidade escolhida para receber os atributos do relacionamento receber, tambm, a chave primria da outra entidade envolvida. Assim, temos que, para cada tipo de relacionamento binrio 1:1 R do DER, devem-se criar as relaes E1 e E2 que correspondem aos tipos de entidade participantes do relacionamento R. Depois, deve-se escolher uma das relaes, por exemplo, E1, para incluir nela, como chave-estrangeira, a chave-primria de E2. Devem-se incluir tambm 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 binrio 1:1. Para mape-lo para o MR, devem-se criar duas relaes Empregado e Empresa, conforme a maneira anteriormente explicada (mapeamento de entidade forte). Depois, seria escolhida uma das relaes (suponha que escolhemos a relao Empregado) para receber os atributos do relacionamento (no caso, Dt_admissao) e a chave primria da relao que no for a escolhida (no caso, o atributo Codigo, que pertence relao Empresa). Se a entidade escolhida fosse a relao Empresa (a escolha sua) seria necessrio colocar a chave primria da entidade Empregado na relao Empresa, assim como o atributo do relacionamento. Todas as duas abordagens seriam possveis.

28

Banco de Dados

Figura 8 - Exemplo de mapeamento de relacionamento binrio 1:1

Mapeamento de Relacionamentos Binrios 1:N Esse tipo de relacionamento no mapeado em uma nova relao. Seus atributos so colocados na relao que mapeia a entidade com cardinalidade N. Os atributos-chaves da entidade com cardinalidade 1 so mapeados (passam a fazer parte) na entidade com cardinalidade N. Ou seja, para cada tipo de relacionamento binrio 1:N (que no envolva entidades fracas) R, voc deve identificar a relao 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-primria da relao T que representa o outro tipo de entidade que participa em R. Por fim, devem-se incluir, tambm, 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 binrio 1:N. Para mape-lo para o MR, devem-se criar duas relaes Empregado e Empresa, conforme a maneira anteriormente explicada (mapeamento de entidade forte). Depois, devese incluir na relao que representa a entidade do lado N do relacionamento (no caso, Empregado), a chave primria da relao que representa a entidade do lado 1 (no caso, Empresa). Por fim, os atributos do relacionamento devem tambm ser includos na relao do lado N. Neste caso, obrigatoriamente o lado escolhido deveria ser o lado N do relacionamento.

29

Banco de Dados

Figura 9 - Exemplo de mapeamento de relacionamento binrio 1:N

Comentrio
10

Isso ocorrer quando for necessrio que o relacionamento reflita algum aspecto temporal ou mantenha algum tipo de histrico. Consulte o captulo 5 do Volume 2 da disciplina para mais informaes a respeito.

Mapeamento de Relacionamentos Binrios M:N O relacionamento mapeado em uma nova relao que recebe os atributos do relacionamento mais os atributoschaves das entidades envolvidas no relacionamento. Assim, a chave da relao seria a concatenao das chaves das entidades envolvidas (e, em alguns casos, tambm o atributo identificador do prprio relacionamento10). Ento teramos que, para cada tipo de relacionamento binrio M:N R, criar uma nova relao S para representar este relacionamento R. Nesta nova relao seriam includas, como chave-estrangeira, as chaves-primrias das relaes que representam os tipos de entidade participantes do relacionamento. A combinao dessas chaves-primrias ir formar a chave primria da nova relao S. Tambm seriam includos na relao S qualquer atributo simples do tipo de relacionamento M:N (ou componentes simples dos atributos compostos). Relacionamentos M:N sempre derivam uma nova relao, 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 binrio e M:N, seriam criadas trs relaes: Projeto, Empregado e Alocao (melhor passar o verbo para um substantivo, assim o relacionamento aloca passa a ser a relao alocao). As duas primeiras relaes seriam criadas pela regra j vista de mapeamento de entidades fortes. Quanto ao relacionamento, seria criado para ele uma relao Alocao que teria como chave primria as chaves das duas relaes que representam as entidades envolvidas no relacionamento (no caso, CPF e Cdigo), alm do atributo do prprio relacionamento (no caso, Dt_alocao).

30

Banco de Dados

Figura 10 - Exemplo de mapeamento de relacionamento binrio M:N

Se, como mencionado anteriormente, fosse necessrio armazenar algum aspecto temporal do relacionamento (no caso, guardar o histrico das alocaes feitas), o atributo Dt_alocao do relacionamento viria no DER como identificador do relacionamento. Isso faria com que ele no mapeamento tambm passasse a fazer parte da chave primria da relao que representa esse relacionamento (no caso, a relao Alocao), 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 binrio M:N (guardando aspecto temporal)

31

Banco de Dados

Mapeamento de Relacionamentos Ternrios, Quaternrios, etc Usualmente, mapeamos tais relacionamentos como se todos fossem de cardinalidade M:N. A relao ser formada pelos atributos do relacionamento e as chaves primrias das entidades envolvidas neste relacionamento. Por exemplo, suponha o relacionamento ternrio da Figura 12. Cada entidade forte seria mapeada em uma relao, conforme regra j vista. E o relacionamento matricula, seria mapeado na relao Matricula que seria composta pelas chaves primrias de cada uma das relaes que representam as entidades envolvidas no relacionamento (no caso, Sigla, CPF e Cdigo), mais a o atributo existente no prprio relacionamento (no caso, Dt_matricula). Sendo que as chaves primrias comporiam as chaves primrias da prpria relao.

Figura 12 - Exemplo de mapeamento de relacionamento ternrio

Mapeamento de Especializao/Generalizao H dois casos. Primeiro, se a especializao for mutuamente exclusiva e total. Ou seja, nenhum elemento membro de mais de uma entidade e se todas as entidades do nvel superior forem membros dos nveis inferiores (por exemplo, todo cliente ou pessoa fsica ou pessoa jurdica, nunca ser apenas um cliente). Neste caso so criadas relaes apenas para as especializaes (entidades filhas, no nvel inferior) e elas usaro como chave primria o atributo identificador da entidade de nvel superior. Por exemplo, atente para a Figura 13. Temos que o Cliente foi especializado em Pessoa_ Fisica e Pessoa_Juridica e essa uma especializao mutuamente exclusiva e total. Dessa forma, esse diagrama dar origem a duas relaes. Ambas tero os atributos da entidade de nvel superior (e a chave primria ser o identificador da mesma o cdigo), alm de seus prprios atributos.

32

Banco de Dados

Figura 13 - Exemplo de mapeamento de especializao/generalizao total e mutuamente exclusiva

Se a especializao no for mutuamente exclusiva, deve ser criada uma tabela para cada entidade, todas tendo como chave primria o atributo identificador da entidade principal (de nvel superior). Por exemplo, vide a Figura 14. Uma conta pode ser apenas uma conta normal, pode ser uma poupana ou uma conta de investimento. Assim, a especializao no mutuamente exclusiva, como consequncia, cada entidade dar origem a uma tabela e todas tero como chave primria a chave da entidade principal.

33

Banco de Dados

Figura 14 - Exemplo de mapeamento de especializao/generalizao no exclusiva

Agregao e Entidade Associativa Envolvem um relacionamento entre relacionamentos. Para fazer o mapeamento, primeiro, criamos relaes para todas as entidades envolvidas. Segundo, criamos uma relao para o primeiro relacionamento (a entidade associativa) que ter como chave primria as chaves primrias das entidades diretamente envolvidas. Terceiro, criamos uma relao para o relacionamento externo, contendo as chaves primrias 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 mdico a um paciente, medicamentos podem ser prescritos. Cada entidade forte dar origem a uma relao. Depois, a entidade associativa Consulta tambm dar origem a uma relao que ter como chave primria 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 prescrio no MR) tambm dar origem a uma relao que ter como chave primria a chave da entidade associativa e a chave da entidade que a ela se liga.

34

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 relaes:

Figura 16 - Exemplo de auto-relacionamento

A primeira usar para representar a entidade e seu auto-relacionamento apenas uma relao com duas ocorrncias da chave primria. 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 relao chamada Empregado, onde haveria duas ocorrncias da chave primria CPF: uma para o prprio empregado e outra para o seu gerente, como apresentado a seguir:

35

Banco de Dados

A outra opo criar duas relaes, uma para representar a entidade e outra para representar o auto-relacionamento. Dessa forma, o DER da Figura 16 daria origem a duas relaes: Empregado e Gerncia. A relao Empregado seria mapeada da forma j explicada para entidades fortes. E o autorelacionamento seria mapeado em uma relao que conteria duas entradas da chave primria da entidade: uma para o empregado e outra para o seu gerente, como apresentado a seguir.

Consideraes Finais
O principal ponto que deve ser considerado em um esquema relacional, quando comparado ao esquema do MER, que os tipos de relacionamento no so representados explicitamente; eles so representados por dois atributos A e B, um para a chave-primria e outra para a chave-estrangeira sobre o mesmo domnio includos em duas relaes S e T. Duas tuplas em S e T esto relacionadas quando elas tiverem o mesmo valor para A e B, ou seja, os relacionamentos so 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 prximo captulo. Depois, com o MR Normalizado, o projeto do banco de dados estar pronto para passar da sua fase lgica (Projeto Lgico), para a fase fsica, o Projeto Fsico ou de Implementao.

Conhea Mais
Alguns livros que podem ser usados para aprofundar o estudo nesse captulo so: HEUSER, CARLOS ALBERTO. Projeto de Banco De Dados Srie Livros Didticos, V.4. Bookman Companhia Ed., 6 Edio - 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. So Paulo: Pearson Education do Brasil, 2005. DATE, C. J. Introduo a sistemas de bancos de dados. Rio de Janeiro: Campus, 2000. ALVES, W.P. Fundamentos de Bancos de Dados. Editora rica, 2004.

36

Banco de Dados

Aprenda Praticando
A partir das regras de mapeamento estudadas neste captulo, mapeie o MER a seguir para o MR, apresentando o esquema das relaes que so originadas.

Vamos comear o mapeamento pela especializao/generalizao do lado esquerdo do diagrama. Se observar, a especializao do diagrama mutuamente exclusiva e total. Um cliente no pode ser pessoa fsica e jurdica. Ele ou pessoa fsica ou pessoa jurdica. Tambm, ele no pode ser simplesmente um cliente. Dessa forma, precisamos criar relaes apenas para as especializaes (entidades filhas, no nvel inferior), no caso Pessoa_Fisica e Pessoa_Juridica. E, essas relaes usaro como chave primria o atributo identificador da entidade de nvel superior (no caso Cliente).

Uma vez mapeada a especializao, vamos tratar agora de mapear o relacionamento

37

Banco de Dados

superior (circulado no diagrama acima). Se observar, esse um relacionamento 1:N. E, como vimos, em relacionamento binrio 1:N, os atributos chaves da entidade com cardinalidade 1 so mapeados (passam a fazer parte) da entidade com cardinalidade N, bem como qualquer atributo que o relacionamento tivesse (o que no o caso, pois o relacionamento possui no tem nenhum atributo). Logo, ficaramos com:

No to complicado! Quanto mais voc exercitar, mais vai memorizar as regras e conseguir aplic-las com mais facilidade. Porm, para isso, voc realmente precisa praticar!

Atividades e Orientaes de Estudo

Agora a sua vez de fazer as atividades! Lembre, praticar muito importante para fixar o contedo estudado!

Atividades Prticas
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 avaliao somativa de vocs. A partir das regras de mapeamento estudadas neste captulo, mapeie os MER, a seguir, para o MR, apresentando o esquema das relaes que so originadas. a) Controle Acadmico

38

Banco de Dados

b) Controle Farmcia

Vamos Revisar?
A modelagem lgica que vem em seguida a modelagem conceitual caracterizada pela criao do modelo relacional (MR). Uma das formas de criar esse modelo derivando o mesmo a partir do modelo entidade-relacionamento, criado na etapa anterior de modelagem conceitual. Para derivar o modelo, existem diversas regras que seguidas, produzem os esquemas relacionais. Foram justamente essas regras que foram apresentadas nesse captulo, bem como alguns exemplos de mapeamento do MER para o MR. No prximo captulo veremos como otimizar os esquemas relacionais atravs da normalizao de dados. At l!

39

Banco de Dados

Captulo 9
O que vamos estudar neste captulo?
Neste captulo, vamos estudar os seguintes temas: Dependncias Funcionais. Normalizao de Dados.

Metas
Aps o estudo deste captulo, esperamos que voc: Saiba o que so dependncias funcionais. Saiba normalizar o seu modelo relacional, pelo menos, at a 3 Forma Normal. Conhea todas as formais normais (1FN, 2FN, 3FN, 4FN e 5FN), alm da forma normal de Boyce-Codd.

40

Banco de Dados

Captulo 9 Normalizao de Dados

Vamos conversar sobre o assunto?
Projetar um banco de dados relacional significa agrupar atributos para formar bons esquemas de relaes. Mas o que seria um bom esquema? Em nvel geral, poderamos dizer que seria um esquema fcil de entender e em que as tuplas da relao fossem armazenadas e acessadas de forma eficiente. Para isso, preciso que sejam minimizadas, ao mximo, a redundncia nos dados e as anomalias de insero, atualizao e excluso. Alm disso, preciso garantir a integridade dos dados, evitando que informaes sem sentido sejam inseridas e preciso organizar e dividir as tabelas da forma mais eficiente possvel. Uma forma de colaborar com essas necessidades fazer a normalizao dos dados. Esse justamente o assunto deste captulo.

Neste captulo estudaremos o que so dependncias funcionais, seu impacto sobre os dados e como realizar a otimizao do MR atravs da normalizao dos dados. Vamos l?

Dependncias Funcionais
Sempre que um atributo X identifica um atributo Y dizemos que entre eles h uma dependncia funcional11. Temos, portanto, que X o determinante e que Y o dependente. A representao : X Y. Em outras palavras, se o valor de um atributo X permite descobrir o valor de um outro atributo Y, dizemos que X determina funcionalmente Y. Por exemplo, dada uma determinada cidade (no considerando cidades homnimas) sabemos o seu estado e com o estado temos o pas. Isso representado da seguinte forma: Cidade estado Estado pas Em outras palavras, estado funcionalmente dependente de cidade e pas funcionalmente dependente de estado. Ou ainda, cidade determina estado e estado determina pas. Logo, a dependncia funcional caracterizada pela existncia de campos em uma determinada tabela relacional cuja ocorrncia de valores est associada a valores que so preenchidos em outros campos na mesma tabela. Por exemplo, suponha uma tabela EMPREGADO que possui dois atributos CPF e NOME. O atributo NOME funcionalmente dependente do atributo CPF. Assim, CPF Nome. Com isso, queremos dizer que nome funo do CPF, ou seja, se eu tiver um nmero de CPF, poderei encontrar o nome da pessoa correspondente. Em outras palavras, CPF determina o Nome (vide Figura 17).

Voc Sabia?
11

O Modelo Relacional pegou emprestado da teoria de funes da matemtica o conceito de dependncia funcional.

41

Banco de Dados

Figura 17 CPF determina o Nome

Para efetuar a normalizao de um modelo de dados relacional, como veremos daqui a pouco, alguns tipos de dependncias funcionais so de extrema relevncia: Dependncia Parcial Ocorre quando a chave primria composta e existe um campo da relao que depende somente de parte desta chave primria composta. Por exemplo, veja a Relao Alocao (vide Tabela 12). Ela possui a chave composta CPF_Empregdo e Cod_Projeto. O ideal seria que todos os campos (atributos) da relao dependessem (fossem funcionalmente dependentes) da chave primria total, completa. Porm, o campo Nome_Empregado depende apenas de parte da chave primria (no caso, do CPF_Empregado). O mesmo ocorre com o atributo Nome_Projeto que s depende do atributo Cod_Projeto. Apenas o atributo Horas_ Trabalhadas funcionalmente dependente da chave primria completa (porque para determinar as horas trabalhadas, precisamos saber o CPF do empregado e para qual projeto ele est trabalhando atravs do cdigo do projeto).
Tabela 12 - Relao Alocao CPF_Empregado (PK) Cod_ Projeto (PK) Nome_Empregado Nome_Projeto Horas_Trabalhadas

123456 654321 789654

11 22 33

Ana Maria Gomes Jos da Silva Cludio Alencar

SoftHouse HardCore LinuxP

40 20 40

Dependncia Transitiva Ocorre quando uma coluna depende no somente da chave primria da tabela, mas tambm de uma segunda coluna (ou conjunto de colunas) da tabela, que no fazem parte da chave primria. Em outras palavras, a dependncia funcional transitiva a dependncia funcional indireta existente entre dois ou mais atributos. Assim, se um atributo C depende funcionalmente de um atributo B e o atributo B depende funcionalmente de um atributo A, ento dizse que o atributo C depende indiretamente (transitivamente) do atributo A (vide Figura 18).

42

Banco de Dados

Figura 18 - Exemplo de dependncia transitiva

Por exemplo, a relao Pedido_Venda (vide Tabela 13) tem como chave primria o atributo Cod_Pedido. Os atributos Data_Pedido, Situao_Pedido e CPF_Cliente dependem funcionalmente dessa chave primria. Porm, o atributo Nome_Cliente depende funcionalmente do CPF_Cliente (que no a chave primria) e, apenas, indiretamente do Cod_Pedido, o que uma anomalia, visto que, todos os atributos de uma relao deveriam depender funcionalmente apenas da sua chave primria.
Tabela 13 - Relao Pedido_Venda Cod_Pedido (PK) 1 2 3 Data_Pedido 18/03/2010 22/02/2010 10/01/2010 Situao_Pedido Pendente Entregue Entregue CPF_Cliente 123456 654211 987654 Nome_Cliente Pedro Alves Carolina Dantas Olvia Duncan

Dependncia Multivalorada Ocorre quando o valor de um atributo determina um conjunto de valores de um outro atributo. Por exemplo, at agora vimos que um atributo (que deve ser a chave primria da relao) determina outro atributo: CPF Nome (ou seja, o CPF determina o nome, sendo um nome para cada CPF). Porm, se considerarmos: CPF Dependente teremos um problema para expressar a realidade, porque atravs de um CPF poderia ocorrer de mais de um dependente ser determinado e no apenas um. Isso caracteriza uma dependncia multivalorada. Uma dependncia multivalorada representada por X Y (que quer dizer, X multidetermina Y ou Y multidependente de X).

Uma dependncia funcional (DF) uma propriedade do esquema da relao e no de uma instncia particular da relao (tupla). Assim, uma DF no pode ser automaticamente inferida a partir de algumas tuplas da relao, mas deve ser definida por algum que conhea a semntica dos atributos da relao. Isso, porque a DF deve ser vlida para todas as tuplas de uma relao, ou seja, para a definio do esquema da relao como um todo.

Anomalias de Atualizao
A mistura de atributos de vrias entidades pode gerar problemas conhecidos como anomalias de atualizao e essas anomalias podem, por sua vez, causar problemas tais como a ocorrncia de:

43

Banco de Dados

Grupos repetitivos de dados; Dependncias parciais de chave; Redundncias desnecessrias de dados; Perdas acidentais de informaes; Dificuldade de representao de fatos da realidade (modelos); e Dependncias transitivas entre atributos. As anomalias de atualizao podem ser de 3 tipos:

Anomalias de insero Causam a repetio desnecessria de dados (redundncia); Anomalias de alterao Levam as inconsistncias e aumentam o esforo para a atualizao dos dados; Anomalias de excluso - Causam a perda de informaes associadas a um dado registro. Para ficar mais claro, vamos demonstrar essas anomalias atravs de exemplos.

Exemplo 1 - Considere uma nica relao VENDAS para representar as informaes sobre os negcios de uma loja de CDs (vide Tabela 14)
Tabela 14 - Relao Vendas Nome_Cliente (PK) Carlos Veneza Juliano Morais Joana Pena Cod_CD (PK) 22 10 45 Dt_Compra (PK) 20/05/2009 13/02/2010 10/10/2009 Nome_CD Tribalistas Siderado Amarantine Cantor Tribalistas Skank Enya Preo 22,00 10,00 18,00

Agora imagine a seguinte situao: o cliente Joo Pontes deseja comprar 5 CDs iguais (por exemplo, Perfil de Ivete Sangalo, que custa 15 reais). Como essa operao refletiria na Relao Vendas? Seria possvel realiz-la? O primeiro problema seria: como no podemos ter mais de uma tupla com a mesma chave primria, o cliente no poderia comprar os 5 cds no mesmo dia. Isso, porque, se comprasse, haveria 5 tuplas com a mesma chave primria (Nome_Cliente, Cod_CD e Dt_ Compra), o que no seria possvel. Se o cliente comprasse em dias diferentes, mesmo assim, poderiam ser observadas as seguintes anomalias: Anomalia de insero Redundncia em quase todas as colunas (5 linhas praticamente iguais mudando s o campo Dt_Compra - na tabela), afinal, o mesmo CD e o mesmo cliente. Anomalia de alterao se houvesse um aumento de preo do CD, a atualizao do preo deveria ser feita em todas as linhas referentes quele CD na tabela. Anomalia de excluso A tabela s guarda registro dos CDs que foram comprados. Dessa forma, se s ocorreu uma nica venda de um CD e ela fosse apagada, no haveria na loja mais nenhuma informao sobre aquele CD.

Exemplo 2 Suponha que voc criou uma relao Empregado para armazenar as informaes sobre os empregados de uma empresa X qualquer (vide Tabela 15).

44

Banco de Dados

Tabela 15 - Relao Empregado CPF (PK) 123456 987654 007654 Nome_Emp Carlos Veneza Juliano Morais Joana Pena Endereco_Emp R. das Flores, 10 R. ABC, 230 Av. Joo XX, 11 Cod_Depto 12 55 43 Nome_Depto Vendas Suporte Financeiro

Na relao criada dessa forma, possvel observar as seguintes anomalias de atualizao: Anomalia de insero - Para inserir uma nova tupla Empregado na relao Empregado, deve-se incluir, tambm, valores para os atributos do departamento em que o empregado trabalha ou colocar null em qualquer campo referente ao departamento. Alm disso, deve-se tomar cuidado ao inserir dados de um departamento que j conste na tabela. Por exemplo, para inserir uma nova tupla para um empregado que trabalhe no departamento 55, preciso tomar cuidado para poder assegurar que os valores dos atributos sejam inseridos corretamente, tal que fiquem consistentes com os valores do departamento 55 que j existe na relao (segunda linha da Tabela 15), seno, seriam inseridos dados inconsistentes na relao. Adicionalmente, seria difcil inserir um novo departamento que ainda no tivesse empregados na relao Empregado. A nica maneira de fazer isso seria colocar valores null nos atributos relativos aos empregados. Porm, isso provocaria um problema, pois o CPF do empregado faz parte da chave primria da relao Empregado, e supe-se que cada tupla deva representar um empregado e no um departamento. Anomalia de alterao - Se for mudado o valor de um dos atributos de um departamento qualquer, por exemplo, o nome do departamento 43 passar a ser Administrao, esse valor precisaria ser mudado em todas as tuplas referentes a todos os empregados que trabalhassem neste departamento ou a base de dados se tornaria inconsistente. Anomalia de remoo - Se for removida uma tupla da relao Empregado e esta for a ltima ocorrncia de um departamento em particular (por exemplo, remover o empregado Carlos Veneza), a informao correspondente ao departamento seria perdida (no caso, as informaes sobre o departamento Vendas).

De acordo com as anomalias exemplificadas acima, pode-se verificar a importncia de projetar esquemas de relaes de maneira que nenhuma anomalia de atualizao ocorra. Neste contexto, podem ser usadas as tcnicas de normalizao, pois um dos objetivos das mesmas justamente evitar anomalias de atualizao no banco de dados. Veremos essas tcnicas ainda neste captulo.

O que Normalizao?
Em 1970, o Professor Dr. Edgar F. Codd12, analista da IBM, desenvolveu uma srie de estudos sobre como tratar os dados, a fim de eliminar as anomalias de atualizao e as suas consequncias desagradveis para as organizaes. Deste esforo surgiram duas inovaes que revolucionaram a maneira de tratar os dados. A primeira destas inovaes foi o Modelo Relacional, no qual se basearam os Sistemas Gerenciadores de Base de Dados

Comentrio
J falamos sobre ele, lembra?
12

45

Banco de Dados

(SGBD) da metade da dcada de 1980 e incio de 1990. A segunda inovao foi o processo de Normalizao, sendo que ambas esto intimamente relacionadas. O processo de normalizao como foi proposto por Codd sujeita um esquema de relao a uma srie de testes para certificar-se de que ele satisfaa certa forma normal. Na verdade, a normalizao de dados pode ser vista como o processo de anlise de determinados esquemas de relaes com base em suas dependncias funcionais e chaves primrias para alcanar as propriedades desejveis de: (1) minimizao de redundncias e (2) minimizao de anomalias de insero, excluso e alterao. Nesse processo, os esquemas de relaes insatisfatrios, que no alcanam certas condies (no caso, os testes de forma normal) so decompostos em esquemas de relaes menores que passam nos testes e, consequentemente, possuem as propriedades desejadas. Em outras palavras, quando uma tabela no atende ao critrio de uma forma normal, sua estrutura redesenhada atravs da projeo (jogar para fora) de alguns atributos, levando a construo de novas tabelas contendo algum atributo que possa refazer o contedo da tabela original atravs da juno (reunir) das tabelas resultantes. Assim, podemos dizer que o processo de normalizao tem as seguintes funes: Analisar tabelas e organiz-las de forma que a sua estrutura seja simples, relacional e estvel, para que o gerenciamento delas possa ser tambm simples, eficiente e seguro; Evitar a perda e a repetio da informao; Conseguir uma forma de representao adequada para o que se deseja armazenar; Oferecer mecanismos para analisar o projeto do BD (identificao de erros e possibilidades de melhorias) e oferecer mtodos para corrigir problemas que, por ventura, sejam encontrados. E, com essas funes, pretende-se alcanar os seguintes objetivos: Garantir a integridade dos dados, evitando que informaes sem sentido sejam inseridas no banco de dados; Organizar e dividir as tabelas da forma mais eficiente possvel, diminuindo a redundncia e permitindo a evoluo do banco de dados com o mnimo de efeito colateral.

Inicialmente Codd props trs formas normais que ele chamou de primeira (1FN), segunda (2FN) e terceira (3FN) forma normal. Uma definio mais forte da 3FN (chamada forma normal BOYCE-CODD - FNBC ou BCNF) foi depois proposta por Boyce e Codd. Todas essas formas normais so baseadas nas dependncias funcionais entre os atributos de uma relao. Posteriormente, uma quarta (4FN) e quinta (5FN) forma normal foram propostas. As formas normais so aplicadas para evitar redundncia de dados, inconsistncias e anomalias de atualizao. Isso porque, redundncia de dados um fato gerador de inconsistncias. J as anomalias de atualizao criam dificuldades operacionais para manuteno do banco de dados, quebrando a confiabilidade no dado ou ferindo a integridade dos dados. Uma forma normal engloba todas as outras anteriores, ou seja, a hierarquia entre as formas normais indica que uma tabela s pode estar numa forma mais avanada se, alm de atender as condies necessrias, j estiver na forma normal imediatamente anterior. Por exemplo, para que uma tabela esteja na 2FN, ela obrigatoriamente deve estar na 1FN e assim por diante. Na prtica, o mais comum normalizar relaes apenas at a 3FN. Isso porque as trs primeiras formas normais (1FN, 2FN e 3FN) atendem maioria dos casos de

46

Banco de Dados

normalizao e j so suficientes para organizar as tabelas de um BD. Apresentaremos cada uma das formas normais nas sees a seguir, ilustrando cada uma delas com exemplos.

Primeira Forma Normal (1FN)

Para o Modelo Relacional a Forma Normal mais importante consiste da Primeira Forma Normal, pois considerada parte da prpria definio de uma relao. Uma relao se encontra na Primeira Forma Normal (1FN) se todos os domnios de atributos possuem apenas valores atmicos (indivisveis), e que o valor de cada atributo na tupla seja um valor simples. Ou seja, a 1FN no permite a construo de relaes que apresentem atributos compostos (vide o atributo Graus das Lentes na Tabela 16) e nem possibilita a existncia de atributos multivalorados (vide o atributo Cursos na Tabela 17) em suas tuplas. Os nicos valores de atributos permitidos devem ser simples e atmicos.
Tabela 16 - Relao Paciente (fora da 1FN) CPF (PK) 123456 987659 007543 Nome Jonas Borges Cssia Lima Tlio Gomes Tipo_Sanguineo AB+ OA+ Graus_Lentes 0.25, 0.50 1.0,0.5 0.0,0.25

Tabela 17 - Relao Matricula_Aluno (fora da 1FN) CPF (PK) 123456 987659 007543 Nome Jonas Borges Cssia Lima Tlio Gomes Cursos Programador, Arquiteto Analista Operador, Programador, Analista

Para normalizar para a Primeira Forma Normal deve-se: I) Atributos Compostos - cada um dos atributos compostos (ou no atmicos) devem ser divididos em seus atributos componentes. Por exemplo, na Tabela 16, o atributo Graus_Lentes poderia ser subdivido em Grau_LenteEsq e Grau_LenteDir, visto que temos de armazenar o grau de cada olho separadamente, quebrando assim o atributo composto nos dois outros que o compe. Com essa quebra, ficaramos com a relao apresentada na Tabela 18. Observe que, agora, todos os atributos so indivisveis (atmicos).

47

Banco de Dados

Tabela 18 - Relao Paciente (na 1FN) CPF (PK) 123456 987659 007543 Nome Jonas Borges Cssia Lima Tlio Gomes Tipo_Sanguineo AB+ OA+ Grau_LenteEsq 0.25 1.0 0.0 Grau_LenteDir 0.50 0.5 0.25

II) Atributos Multi-valorados temos dois tratamentos possveis: a) Quando a quantidade de valores a serem preenchidos no atributo multivalorado for pequena e conhecida a priori, substitui-se o atributo multivalorado por um conjunto de atributos de mesmo domnio, cada um monovalorado representando uma ocorrncia do valor. Por exemplo, na relao Matricula_ Aluno representada na Tabela 17, suponha que a pessoa possa se matricular, no mximo, em trs cursos. Dessa forma, poderamos decompor o atributo Cursos em trs colunas (vide Tabela 19). Essa opo menos utilizada do que a opo que explicaremos a seguir, porque ela pode gerar colunas de valor Null e, com isso, desperdiar espao de armazenamento.
Tabela 19 - Relao Matricula (na 1FN, considerando quantidade pequena e conhecida de valores) CPF (PK) 123456 987659 007543 Nome Jonas Borges Cssia Lima Tlio Gomes Curso1 Programador Analista Operador Curso2 Arquiteto Null Programador Curso3 Null Null Analista

b) Quando a quantidade de valores for muito varivel, desconhecida ou grande, retira-se da relao o atributo multivalorado, e cria-se uma nova relao que tem o mesmo conjunto de atributos chave, mais o atributo multivalorado tambm como chave, mas tomado como monovalorado. Em outras palavras, projetam-se os atributos com domnio multivalorado para fora da tabela, levando um atributo (geralmente a chave da tabela original) como elo para refazer a ligao e recuperar o contedo da tabela original. Por exemplo, na relao Matricula_Aluno representada, na Tabela 17, se no soubssemos a quantidade de cursos nos quais um aluno pode se matricular, deveramos tirar o atributo Cursos da relao Matricula_Aluno (vide Tabela 20). Depois, criar uma nova relao, que chamamos Aluno_Curso (vide Tabela 21), onde seria colocada a chave primria da relao Matricula_Aluno (no caso, o atributo CPF) e o atributo multivalorado (agora, como monovalorado), tambm como chave primria (no caso, o atributo Curso). Dessa forma, cada curso cursado pelo aluno, daria origem a uma tupla dessa nova relao (videTabela 21). Essa opo a mais utilizada por no dar origem a campos de preenchimento null. S seria usado o espao de armazenamento necessrio.

48

Banco de Dados

Tabela 20 - Relao Matricula_Aluno (na 1FN), considerando quantidade varivel ou desconhecida de valores CPF (PK) 123456 987659 007543 Nome Jonas Borges Cssia Lima Tlio Gomes

Tabela 21 - Relao Aluno_Curso criada para atender a 1FN CPF (PK) 123456 123456 987659 007543 007543 007543 Curso (PK) Programador Arquiteto Analista Operador Programador Analista

Mesmo que uma relao esteja na 1FN, ela pode apresentar redundncias e anomalias de atualizao. Para eliminar ou minimizar estes problemas, devemos prosseguir no processo de normalizao, aplicando as outras formas normais.

Segunda Forma Normal

Uma relao est na segunda forma normal quando duas condies so satisfeitas: A relao est na primeira forma normal; Todos os atributos que no fazem parte da chave-primria dependem funcionalmente de toda a chave primria, ou seja, nenhum dos atributos da relao possui dependncia parcial. Em outras palavras, todo atributo A da relao R no parcialmente dependente da chave-primria de R.

Dica
Relaes na 1FN e que possuam chave primria simples esto, automaticamente, na 2FN.

Por exemplo, veja a Relao Alocao (vide Tabela 22). Ela possui a chave composta CPF_Empregdo e Cod_Projeto. Essa relao se encontra na 1FN porque no possui atributos multivalorados ou compostos. Porm, no est na 2FN porque o campo Nome_Empregado depende apenas de parte da chave primria (no caso, do CPF_Empregado) e o atributo

49

Banco de Dados

Nome_Projeto s depende do atributo Cod_Projeto. Apenas o atributo Horas_Trabalhadas funcionalmente dependente da chave primria completa (porque para determinar as horas trabalhadas, precisamos saber o CPF do empregado e para qual projeto ele est trabalhando atravs do cdigo do projeto). Dessa forma, como existe dependncia parcial, a relao no est na 2FN.
Tabela 22 - Relao Alocao CPF_Empregado (PK) 123456 654321 789654 Cod_Projeto (PK) 11 22 33 Nome_Empregado Ana Maria Gomes Jos da Silva Cludio Alencar Nome_Projeto SoftHouse HardCore LinuxP Horas_Trabalhadas 40 20 40

E como faramos para passar uma relao para a 2FN? Para passarmos uma entidade da 1FN para a 2FN, devemos eliminar as dependncias parciais. E como fazer isso? 1) Para cada atributo que no faa parte da chave primria da relao, analisar se existe dependncia parcial da chave primria. Para identificar a dependncia parcial de uma coluna em relao chave primria, deve-se indagar: Para que o valor do atributo seja determinado, quais as partes da chave primria que devem ser conhecidas? 2) Para cada grupo de atributos que tenham a mesma dependncia parcial da chave primria, devem-se criar novas relaes (tabelas) que tero como chave primria a chave parcial que estava na relao original e todo o grupo de atributos que depende da mesma chave parcial; 3) Excluir da relao original o grupo de atributos para o qual foi criada uma nova relao; 4) Repetir esses procedimentos para cada grupo de atributos que tenha dependncia parcial da chave primria da relao original, at que todas as relaes somente contenham atributos que dependam de toda a chave primria.

Dica
13

O nome das novas relaes deve ser escolhido de acordo com suas chaves primrias.

Por exemplo, a relao Alocao (Tabela 22) daria origem a duas novas relaes13 13(vide Tabelas 23 e 24), uma vez que h dois grupos e dependncias parciais nesta relao: Cod_Projeto a NomeProjeto e CPF_Empregado a Nome_Empregado. Veja que em cada nova relao criada, foi colocada a parte da chave primria da tabela original da qual o atributo depende. E, posteriormente, os atributos que tinham dependncia parcial foram retirados da relao original (vide Tabela 25), s ficando nela o atributo (no caso Horas_Trabalhadas) que dependia da chave primria completa.
Tabela 23 - Relao Empregado CPF_Empregado (PK) 123456 654321 789654 Nome_Empregado Ana Maria Gomes Jos da Silva Cludio Alencar

50

Banco de Dados

Tabela 24 - Relao Projeto Cod_Projeto (PK) 11 22 33 Nome_Projeto SoftHouse HardCore LinuxP

Tabela 25 - Relao Alocao CPF_Empregado (PK) Cod_Projeto (PK) 11 22 33 Horas_Trabalhadas 40 20 40

123456 654321 789654

Relaes que no esto na 2FN podem apresentar problemas de inconsistncia devido duplicidade dos dados e perda de dados em operaes de remoo/alterao (anomalias de atualizao). Por exemplo, veja a relao Turma na Tabela 26. Se a disciplina BD no for oferecida para nenhuma turma, isso levar remoo da terceira tupla da relao Turma, o que ocasionaria a perda do nmero de horas da disciplina BD, pois esta informao no se encontra em outra relao ou tupla. Adicionalmente, outra anomalia a duplicidade do nmero de horas das disciplinas, que pode levar inconsistncia (por exemplo, caso o nmero de horas da disciplina IP fosse atualizado na primeira tupla e no na segunda). Observe que esses problemas so causados porque o atributo Num_horas depende apenas de parte da chave primria (no caso, depende da Sigla_Disciplina).
Tabela 26 - Relao Turma (fora da 2FN) Cod_Turma (PK) 11 22 11 22 22 Sigla_Disciplina (PK) IP IP BD SO SO Num_SalaAula S15 S16 S02 S10 S12 Num_Horas 6 6 4 4 4

E, ento, como ficaria essa relao Turma (Tabela 26) na 2FN? Observe as Tabelas 27 e 28 e reflita sobre como elas foram obtidas.

51

Banco de Dados

Tabela 27 - Relao Disciplina Sigla_Disciplina (PK) IP BD SO Num_Horas 6 4 4

Tabela 28 - Relao Turma (na 2FN) Cod_Turma (PK) 11 22 11 11 22 Sigla_Disciplina (PK) IP IP BD SO SO Num_SalaAula S15 S16 S02 S10 S12

Terceira Forma Normal

Uma relao est na terceira forma normal quando duas condies so satisfeitas: A relao est na segunda forma normal; No existir dependncia transitiva na relao, ou seja, nenhum dos atributos no chave depende de outro atributo que tambm no chave. Ou seja, se todos os atributos dependerem completa e exclusivamente da chave primria. Ou ainda, se no houver relao de identificao entre os atributos que no faam parte da chave primria (dependncia transitiva).

Dica
Relaes que estejam na 2FN e que no tenham nenhum ou apenas um atributo alm da chave esto automaticamente na 3FN.

Por exemplo, observe a relao Funcionrio (Tabela 29). Ela est na 2FN porque no contm chave composta. Porm, h uma dependncia transitiva na mesma. O atributo Salrio depende do atributo Cargo (que no faz parte da chave primria). J o atributo Cargo, por sua vez, depende da chave primria Cod_Empregado. Assim, temos: Cod_Empregado Cargo Salrio.

52

Banco de Dados

Tabela 29 - Relao Funcionrio (fora da 3FN) Cod_Empregado (PK) 100 101 102 Nome_Empregado Carlos Alves Jos Souza Maria Ramos Cargo Programador Analista Programador Salrio 2000 3500 2000

E como faramos para passar uma relao para a 3FN? Para passarmos uma entidade da 2FN para a 3FN, devemos eliminar as dependncias transitivas. E como fazer isso? 1) Para cada atributo que no participe da chave primria da relao, analisar se existe dependncia transitiva da chave primria. Para identificar a dependncia transitiva de um atributo deve-se indagar: Qual outro atributo no pertencente chave e poderia determinar o valor do atributo em anlise? Ou seja, voc vai analisar se o valor de um atributo no-chave pode ser determinado por algum outro atributo que tambm no pertena chave primria da relao; 2) Para cada grupo de atributos no-chaves dependentes funcionalmente de outros atributos no-chaves, cria-se uma nova relao. Essa nova relao vai ter os atributos dependentes como no-chaves e os atributos que causam a dependncia (determinantes) como chave primria. Ou seja, vai ser chave primria da nova relao os atributos dos quais os atributos no-chave da relao original dependem. O nome das novas relaes deve ser escolhido de acordo com a chave primria das mesmas; 3) Repetir os passos anteriores at que todos os atributos restantes na relao original dependam diretamente de toda a chave primria. Em outras palavras, repete-se at que todas as relaes no contenham atributos dependentes de atributos nochaves; 4) Excluir da tabela original todos os atributos com dependncia transitiva, mantendo o atributo determinante da transitividade. Deve-se excluir, tambm, os atributos derivados a partir de outros (atributos calculados), como por exemplo, se houver um atributo data de nascimento e outro atributo idade, o atributo idade deve ser excludo, uma vez que, a qualquer momento, ele poder ser calculado a partir do atributo data de nascimento. Vamos exemplificar. Para passar a Tabela 29 para a 3FN, iramos criar uma nova relao (que chamamos de Salario_Cargo, vide Tabela 30) que ter como chave primria o atributo no-chave determinante da dependncia transitiva (no caso, o Cargo) e o atributo no-chave dependente (no caso Salrio), uma vez que Cargo a Salrio na relao Funcionrio original (vide Tabela 29). Depois, o atributo em dependncia transitiva deve ser retirado da relao original (no caso, Salrio retirado da relao Funcionrio vide Tabela 31). Assim, a relao original fica apenas com atributos que dependem funcionalmente apenas da chave primria (no caso, Cod_Empregado).
Tabela 30 - Relao Salario_Cargo Cargo (PK) Salrio

Programador Analista

2000 3500

53

Banco de Dados

Tabela 31 - Relao Funcionrio (na 3FN) Cod_Empregado (PK) 100 101 102 Nome_Empregado Carlos Alves Jos Souza Maria Ramos Cargo Programador Analista Programador

Relaes que no esto na 3FN podem apresentar problemas de inconsistncia devido duplicidade dos dados e perda de dados em operaes de remoo/alterao (anomalias de atualizao). Por exemplo, a relao Turma (vide Tabela 32) est na 2FN, mas no est na 3FN, pois o atributo Capacidade depende do atributo Sala e no da chave primria da relao que Cod_Turma. Considerando que a sala S23 tivesse sua capacidade atualizada de 50 para 60 apenas na segunda tupla, teramos um caso de anomalia de alterao, com consequente inconsistncia nos dados armazenados (a segunda tupla marcaria que a sala S23 tem capacidade para 60 pessoas e a terceira tupla marcaria que essa mesma sala teria capacidade para 50 pessoas).
Tabela 32 - Relao Turma (fora da 3FN) Cod_Turma (PK) IP501 BD210 PR900 Professor Carlos Alves Jos Souza Maria Ramos Sala S09 S23 S23 Capacidade 40 50 50

E, ento, como ficaria essa relao Turma (Tabela 32) na 3FN? Observe as Tabelas 33 e 34 e reflita sobre como elas foram obtidas.
Tabela 33 - Relao Sala Sala (PK) Capacidade

S09 S23

40 50

Tabela 34 - Relao Turma (na 3FN) Cod_Turma (PK) Professor Sala S09 S23 S23

IP501 BD210 PR900

Carlos Alves Jos Souza Maria Ramos

54

Banco de Dados

Forma Normal de Boyce-Codd

Uma relao considerada pertencente FNBC quando estiver na Primeira Forma Normal (1FN) e para cada chave candidata, todos os atributos que no participam da chave candidata forem dependentes no transitivos de toda a chave candidata. Em outras palavras, quando todo determinante14, existente na tabela, fizer parte da chave. A FNBC uma forma mais restritiva de 3FN, isto , toda relao em FNBC est tambm em 3FN; entretanto, uma relao em 3FN no est necessariamente em FNBC. Por exemplo, na relao Turma (vide Tabela 35) cada tupla informa que um aluno A estuda em uma disciplina D com um professor P. Para esta relao, considere as seguintes regras: Para cada disciplina, um aluno tem um nico professor; Cada disciplina pode ser ensinada por mais de um professor; e Cada professor s pode ensinar uma disciplina.
14

Comentrio
Chamamos de determinante um atributo do qual algum outro atributo funcionalmente dependente.

Tendo em mente estas regras, quais so os determinantes dessa relao? Temos que (Aluno, Disciplina) Professor (sabendo o aluno e a disciplina, podemos determinar o professor) que Professor Disciplina (ou seja, atravs do professor, podemos descobrir/ determinar a disciplina). Como no h dependncia transitiva, ou seja, nenhum atributo no-chave determinado por outro atributo no-chave, a relao est na 3FN. Porm, ela no est na FNBC, porque temos que Professor um atributo determinante e ele no faz parte da chave primria. Isso acaba ocasionando anomalia de remoo. Vamos exemplificar: Observando a relao Turma na Tabela 35 temos que, se removermos a informao de que o aluno Carlos Alves est matriculado na disciplina de BD, no haveria mais no banco de dados nenhum registro de que Paulo Bennet leciona a disciplina de BD. A informao seria perdida.
Tabela 35 - Relao Turma Aluno (PK) Carlos Alves Carlos Alves Jos Souza Jos Souza Maria Ramos Disciplina (PK) IP BD IP PRG PRG Professor Joana Mendes Paulo Bennet Joana Mendes Garcia Lopes Rui Carneiro

Observao

Na prtica, quando um esquema relacional est na 3NF, normalmente, tambm est na BCNF. A exceo quando existe uma dependncia X A onde X no uma superchave e A um atributo da chave (vide Figura 19).

55

Banco de Dados

Figura 19 Ocorrncia da BCNF

Para Normalizar para a Forma Normal de Boyce-Codd seguem-se os mesmos passos da Terceira Forma Normal. Deve-se verificar se h algum determinante que no chave primria e, em caso afirmativo, deve-se criar uma nova relao com os que dependem funcionalmente deste determinante e com o prprio determinante como chave primria da nova relao. Por exemplo, a relao Turma (Tabela 35) seria decomposta nas seguintes relaes apresentadas nas tabelas 36 e 37, de acordo com os determinantes identificados.
Tabela 36 - Relao Aluno-Professor Aluno (PK) Professor

Carlos Alves
Carlos Alves Jos Souza Jos Souza Maria Ramos

Joana Mendes Paulo Bennet Joana Mendes Garcia Lopes Rui Carneiro

Tabela 37 - Relao Professor-Disciplina Professor (PK) Disciplina

Joana Mendes Paulo Bennet Garcia Lopes Rui Carneiro

IP BD PRG PRG

Quarta Forma Normal

Uma relao est na Quarta Forma Normal (4FN) se no possuir dois ou mais atributos multi-valorados independentes. Em outras palavras, se no possuir casos de multidependncia funcional. Mas o que mesmo multi-dependncia funcional? Se cada valor de um Atributo A permite descobrir um conjunto de possveis valores de um outro Atributo B, dizemos que A determina multi-funcionalmente B (A B). Por exemplo, geralmente, em uma universidade um professor ministra mais de uma disciplina. Logo, Nome_Prof Disciplina (Nome_Prof determina multi-funcionalmente disciplina) e, assim, sempre que o nome do professor for pesquisado ser possvel obter os nomes de suas disciplinas.

56

Banco de Dados

Observao

Para se verificar a 4FN a relao deve ter, no mnimo, trs atributos.

Por exemplo, analise a relao Alocao_Professor (vide Tabela 35). Nela temos as seguintes multi-dependncias funcionais: Nome_Prof Sigla_Disciplina (ou seja, a partir do nome do professor podemos saber as disciplina que ele ministra) e Nome_Prof Orientando (ou seja, a partir do nome do professor possvel saber os alunos que ele orienta).
Tabela 35 - Relao Alocao_Professor (fora da 4FN) Nome_Prof (PK) Andr Fernandes Andr Fernandes Jorge Macedo Jorge Macedo Mrcia Gadelha Sigla_Disciplina (PK) BD ES IP IP SO Orientando (PK) Tadeu Batista Tadeu Batista Otto Melo Paulo Gouveia Jonas Bastos

Observe que as disciplinas que o professor leciona devem ser independentes dos alunos que ele orienta. Se a relao acima significasse que o professor orienta determinado aluno em uma determinada disciplina, a relao estaria correta e no necessitaria ser normalizada. Porm, estamos considerando multi-dependncias funcionais entre atributos independentes. Relaes que no esto na 4FN podem apresentar problemas de inconsistncias devido duplicidade dos dados. Por exemplo, na Tabela 35, o professor Andr Fernandes s tem um orientando Tadeu Batista, mas ministra duas disciplinas. Devido a esse fato, o nome do orientando precisou ser duplicado sem necessidade. O mesmo ocorreu com o professor Jorge Macedo que s ministra uma disciplina IP e possui dois orientandos (houve duplicao da sigla da disciplina). Adicionalmente, relaes desse tipo podem apresentar anomalias de atualizao, por exemplo: Anomalia de insero um orientando s pode ser inserido se o professor estiver ministrando alguma disicplina (veja que todos os atributos so chaves, nenhum deles pode ficar com valor null); Anomalia de remoo deletar uma disciplina ou um orientando levaria a perda de informao; Anomalia de alterao se necessitssemos alterar o nome de um orientando, precisaramos alterar o mesmo em todas as tuplas em que ele aparecesse.

Para Normalizar para a Quarta Forma Normal, voc deve retirar da relao o atributo multi-valorado e criar uma nova relao, tendo-o como parte da chave, a fim de separar as dependncias. Ou seja, deve-se usar o mesmo procedimento feito para passar uma relao para a 1FN, visto anteriormente. Uma observao importante que, para se normalizar em 4FN, a entidade tem que estar (obrigatoriamente) na 3FN. Por exemplo, a

57

Banco de Dados

relao Alocao_Professor daria origem nova relao Orientaes_Professor (vide Tabela 36) e provocaria mudanas na relao original Alocao_Professor (vide Tabela 37).
Tabela 36 - Relao Orientaes_Professor Nome_Prof (PK) Andr Fernandes Jorge Macedo Jorge Macedo Mrcia Gadelha Orientando (PK) Tadeu Batista Otto Melo Paulo Gouveia Jonas Bastos

Tabela 37 - Relao Alocao_Professor (na 4FN) Nome_Prof (PK) Andr Fernandes Andr Fernandes Jorge Macedo Mrcia Gadelha Sigla_Disciplina (PK) BD ES IP SO

Veja que, agora, assuntos diferentes so tratados em relaes diferentes, evitando duplicaes e anomalias. importante relembrar que a necessidade de aplicar a 4FN ocorre apenas quando se tem tabelas que mantm relacionamentos ternrios ou superiores e se detectam dependncias funcionais multivaloradas independentes.

Quinta Forma Normal

No vamos dar uma exposio abrangente sobre a quinta forma normal, vamos apenas apresentar uma noo da sua ideia central. A quinta forma normal (5FN) tambm chamada de Forma Normal de Projeo / Juno (FNPJ) e trata de casos bastante particulares que ocorrem na modelagem de dados: os relacionamentos mltiplos (ternrios, quaternrios e n-rios). Uma relao R est na quinta forma normal (5FN) se est na 4FN e no possui nenhuma dependncia de juno. Mas o que uma dependncia de juno?
Dependncia de Juno: Dada uma relao R e certas projees (subconjuntos da relao) R1,..., Rn diz-se que h uma dependncia de juno (de R em relao a R1,..., Rn) se R pode ser reconstituda com a juno de R1,..., Rn.

Em outras palavras, uma relao na 4FN estar na 5FN, quando seu contedo no puder ser reconstrudo (juno), porque h perda de informao, a partir das diversas relaes menores (subconjuntos extrados da relao principal). Ou seja, se ao particionar

58

Banco de Dados

uma relao, sua juno posterior no conseguir recuperar as informaes contidas na relao original, ento esta relao est na 5FN. Assim, se uma relao no est na 5FN, ento, existe uma decomposio de R em um conjunto de projees (subconjuntos) que esto na 5FN e cuja juno natural restabelece a relao original. Esta forma normal trata especificamente dos casos de perda de informao, quando da decomposio de relacionamentos mltiplos. Para exemplificar, pode acontecer de uma tabela representar um relacionamento triplo que no pode ser simplificado, pois se for quebrado em relacionamentos binrios poder gerar informaes incorretas. Neste caso, a tabela j est na 5FN. Para checar esse fato, pode-se utilizar a seguinte pergunta: possvel substituir o relacionamento ternrio por relacionamentos binrios? Vamos a outro exemplo. Se um vendedor vende certo tipo de veculo e ele representa o fabricante daquele tipo de veculo, ento ele vende aquele tipo de veculo para aquele fabricante (regra de simetria), tal como representado na relao Vendas (vide Tabela 41). Essa relao pode ser decomposta em trs outras relaes, portanto no est na 5NF (observe que h uma redundncia de informaes na relao, que ir requerer mais ateno na atualizao de dados).
Tabela 41 - Relao Vendas Vendedor (PK) Andr Fernandes Andr Fernandes Andr Fernandes Andr Fernandes Jorge Macedo Fabricante (PK) Ford Ford GM GM Ford Veculo (PK) Automvel Caminho Automvel Caminho Automvel

Assim, para transformar em 5FN podemos quebrar a relao Vendas em 3 relaes diferentes, representadas nas Tabelas 42, 43 e 44. Essas relaes no podem ser decompostas, estando assim na 5NF. Para conseguir recompor a relao Vendas originais seriam necessrias as trs relaes.
Tabela 42 - Relao Vendedor-Fabricante Vendedor (PK) Andr Fernandes Andr Fernandes Jorge Macedo Fabricante (PK) Ford GM Ford

59

Banco de Dados

Tabela 43 - Relao Vendedor-Veculo Vendedor (PK) Andr Fernandes Andr Fernandes Jorge Macedo Veculo (PK) Automvel Caminho Automvel

Tabela 44 - Relao Fabricante-Veculo Fabricante (PK) Ford Ford GM GM Veculo (PK) Automvel Caminho Automvel Caminho

Qualquer outra decomposio da relao original poderia ocasionar informaes incorretas (tuplas esprias). Como pde ser observado, a 4NF decompe uma relao aos pares (substitui uma relao por duas de suas projees em pares), enquanto que a 5NF utilizada quando uma decomposio aos pares no possvel, como no caso anterior (a relao foi decomposta em trs outras, sem perdas).

Um Roteiro para a Normalizao

A partir do modelo relacional gerado a partir do modelo entidade relacionamento, construdo na fase de modelagem conceitual, proceda os seguintes passos: Elimine os atributos repetidos (se houver), de modo a obter um modelo na 1FN; Elimine as dependncias parciais da chave primria em suas relaes (se houver) para obter o modelo na 2FN; Elimine as dependncias transitivas nas tabelas (se houverem), obtendo um esquema na 3FN; Avalie se vale a pena aplicar mais algum tipo adicional de normalizao 4FN, 5FN e FNBC.

Algumas Informaes Adicionais

Para finalizar esse captulo, vamos dar algumas informaes adicionais sobre cuidados que voc precisar ter no refinamento do seu modelo relacional. O que fazer se voc no conseguir definir uma chave primria? Realmente, poder haver algumas ocasies que, no momento da gerao da estrutura de tabelas, voc no consiga determinar um ou mais atributos que garantam a identificao nica de alguma relao, ou seja, no conseguir definir uma chave primria. Nestes casos,

60

Banco de Dados

ser necessrio criar um atributo artificial (por exemplo, um cdigo, geralmente, sequencial) para servir como chave primria. Atributos Irrelevantes devem ser desconsiderados Alguns atributos de um relatrio no necessitam estar armazenados em um BD, pois sero determinados em tempo de execuo. Por exemplo, nmero de pginas de um relatrio ou a sua data de emisso. Estes dados no devem ser considerados atributos da estrutura de tabelas aninhadas. Atributos derivados tambm podem ser desconsiderados Informaes que so deduzidas a partir de dados do BD, como clculos (somas, mdias, valor mximo) ou a idade, que pode ser deduzida a partir da data do nascimento podem ser eliminadas do conjunto de atributos da estrutura de tabelas aninhadas. Esta afirmao no uma exigncia. Isso porque, s vezes, um somatrio, por exemplo, solicitado com tanta frequncia em uma consulta, que se torna mais eficaz manter o seu resultado no BD, do que calcul-lo diversas vezes em pouco tempo. Valores Nulos em Tuplas as relaes devem ser projetadas de forma que suas tuplas tenham a menor quantidade possvel de valores nulos. Normalmente, os atributos que possuem valores nulos podem ser colocados em relaes separadas. E quais as razes para se usarem valores nulos? Quando o valor no aplicvel ou invlido, quando o valor desconhecido (embora possa existir) ou est, temporariamente, indisponvel (embora se saiba que ele exista). Tuplas Esprias - projetos incorretos de bancos de dados relacionais podem gerar resultados invlidos (tuplas esprias) em certas operaes de juno de relaes15 (Join). A propriedade de juno sem perdas usada para garantir resultados corretos em operaes de juno, de forma que nenhuma tupla espria seja gerada.

Comentrio
15

Consideraes Finais
O processo de Normalizao pode ser considerado como a aplicao de uma srie de regras, que constituem as Formas Normais, que iro provocar a decomposio de esquemas de dados insatisfatrios de algumas relaes, em novas relaes. O processo de normalizao aplicado em uma relao por vez. Durante o processo, a relao vai sendo quebrada, criando-se outras relaes. Geralmente, o processo de normalizao realizado em etapas, comeando atravs das formas normais menos rgidas e depois atravs de refinamentos sucessivos, at chegar a uma normalizao considerada satisfatria para a aplicao. A deciso de normalizar ou no uma relao um compromisso entre garantir a eliminao de inconsistncias no BD e alcanar a eficincia de acesso (pois normalizar demais pode diminuir a eficincia dos aplicativos). Por isso mesmo, deve ser realizada alguma ponderao antes de se tomar uma deciso.

Quando relaes so combinadas a partir de um atributo (geralmente a chave primria) em comum.

Saiba Mais
Existem diversos livros de Banco de Dados que possuem um captulo especfico sobre Normalizao e Dependncias Funcionais. Aqui vo o nome apenas de alguns: RAMAKRISHNNAN, R.; GEHRKE, J. Database Management Systems. McGraw-Hill, 2003.

61

Banco de Dados

DATE, C. J. Introduo a Sistemas de Banco de Dados. Elsevier Editora, 2004. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. Traduzido por: Marilia Guimares Pinheiro et al. 4a. ed. So Paulo: Pearson Education do Brasil, 2005. HEUSER, Carlos Alberto. Projeto de Banco de Dados. 3. Edio., Porto Alegre : Sagra-Luzzatto, 2004. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de Dados. Elsevier Editora, 2006. Adicionalmente, para elaborao desse captulo foram consultados os materiais e notas de aulas dos professores citados a seguir, a quem deixamos nossos agradecimentos: Prof. Roberto Schaefer (FACNET), Prof. Luiz Camolesi Jr. (UNIMEP Universidade Metodista de Piracicaba), Prof. Jefferson S. Silva (CEFET- PHB PI), Professores Osvaldo Kotaro Takai, Isabel Cristina Italiano e Joo Eduardo Ferreira (DCC-IME-USP), Prof. Cludio Mrcio (UNP), Prof. Clodis Boscarioli (Unioeste), Profa. Marilde Santos (Departamento de Computao UFSCar), Prof. Joo Arajo (FCT/UNL), Prof. Cludio Mrcio (Sistemas de Informao UNP), Prof. Mrcio Antnio Duarte (UFG Catalo/GO), Prof. Marcelo Nogueira (UNIP Universidade Paulista), Prof. Joo Murilo Azevedo (Faculdade Guararapes/PE) e Prof. Brenno E. Albert (UFRJ).

Aprenda Praticando
A tabela abaixo representa os pedidos de produtos de software para uma loja e no obedece nenhuma das formas normais vistas (1FN, 2FN e 3FN). Indique os passos para deix-la em cada uma dessas formas normais.
TABELA_PEDIDO Num_ Pedido (PK) Cod_ Prod (PK) 001 111 002 003 002 222 003 005 Photoshop Coreldraw Flash Coreldraw Flash ABC 23/03/2010 BRSofts Av. Itu, 33 10/02/2010 InfoSoft R. Flor, 25 Nm_Prod Data

Nm_ Fornecedor

Endereo_ Fornec

Qtd

Preo_ Total

02 03 02 03 05 10

500,00 350,00 100,00 350,00 100,00 200,00

Em uma primeira avaliao, j podemos verificar que a tabela Pedido no est na 1FN, pois h vrios atributos no atmicos, ou seja, atributos multi-valorados. Para deixar a tabela em 1FN preciso dividir esses atributos em linhas. Com isso, ficamos com a tabela a seguir.

62

Banco de Dados

TABELA_PEDIDO Num_ Pedido (PK) 111 111 111 222 222 222 Cod_ Prod (PK) 001 002 003 002 003 005 Photoshop Coreldraw Flash Coreldraw Flash ABC 10/02/2010 10/02/2010 10/02/2010 23/03/2010 23/03/2010 23/03/2010 Nm_Prod Data Nm_ Fornecedor InfoSoft InfoSoft InfoSoft BRSofts BRSofts BRSofts Endereo_ Fornec R. Flor, 25 R. Flor, 25 R. Flor, 25 Av. Itu, 33 Av. Itu, 33 Av. Itu, 33 Preo_ Total 500,00 350,00 100,00 350,00 100,00 200,00

Qtd

02 03 02 03 05

Reavaliando a tabela, podemos perceber que ela no se encontra na 2FN, pois h atributos que dependem apenas de parte da chave primria composta (dependncia parcial). Quais seriam? Temos que: Data, Nm_Fornecedor e Endereco dependem apenas de Num_Pedido. Nm_Prod depende apenas de Cod_Produto. Apenas Qtd e Preco dependem da chave composta. Assim redividimos as tabelas, segundo essas dependncias e ficamos com:
TABELA_PEDIDO Num_Pedido (PK) 111 222 Data 10/02/2010 23/03/2010 Nm_Fornecedor InfoSoft BRSofts Endereo_Fornec R. Flor, 25 Av. Itu, 33

TABELA_PRODUTO Cod_Prod (PK) 001 002 003 005 Nm_Prod Photoshop Coreldraw Flash ABC

63

Banco de Dados

TABELA_PRODUTOS_PEDIDO Num_Pedido (PK) 111 111 111 222 222 222 Cod_Prod (PK) 001 002 003 002 003 005 Qtd 02 03 02 03 05 10 Preo_Total 500,00 350,00 100,00 350,00 100,00 200,00

Agora, s falta avaliar se as tabelas j esto na 3FN, ou seja, se h alguma dependncia transitiva. Se avaliarmos a Tabela_Pedido, o atributo Endereo_Fornec depende de um atributo no-chave (dependncia transitiva), no caso, o Nm_Fornecedor. Dessa forma, preciso criar uma nova tabela (Tabela_Fornecedor) e ajustar a Tabela_ Pedido. As outras tabelas ficariam iguais, no haveria modificao nas mesmas.
TABELA_PEDIDO Num_Pedido (PK) 111 222 Data 10/02/2010 23/03/2010 Nm_Fornecedor InfoSoft BRSofts

TABELA_FORNECEDOR Nm_Fornecedor (PK) InfoSoft BRSofts Endereo_Fornec R. Flor, 25 Av. Itu, 33

Agora, se reavaliar as tabelas, vai verificar que as mesmas se encontram na 3FN.

Voc Sabia?
Voc sabia que, algumas vezes, precisaremos fazer uma desnormalizao do Banco de Dados? Mas o que isso? Desnormalizao uma tcnica usada para converter uma ou mais tabelas relacionadas em uma nica tabela com informaes possivelmente redundantes, a fim de melhorar o desempenho no acesso aos dados. Essa tcnica usada em casos particulares para evitar junes e proporcionar agilidade nas consultas aos dados, como no caso do projeto de data warehouses.

64

Banco de Dados

Atividades e Orientaes de Estudos

Agora a sua vez de fazer as atividades! Lembre que praticar muito importante para fixar o contedo estudado!

Atividades Prticas:
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 avaliao somativa de vocs. I) Faa a Normalizao, pelo menos at a 3FN, das relaes a seguir. Atributos entre chaves indicam atributos multivalorados. Atributos sublinhados indicam as chaves primrias. a) Tabela_Oficina (cod_cliente, nome, endereco, cod_carro, modelo, ano_ fabricacao, {cod_servico, descricao}, data_servico,valor_servico,{cod_produto, nome_produto}) b) Tabela_Hospital (cod_paciente, nome, tel, endereco, crm, nome_med, tel_med, endereco_med, cod_especialidade, nome_espec, data_consulta, diagnostico) c) Tabela_Locadora (cod_cliente, nome, tel, {cod_fita, nome_filme, duracao, cod_ genero, descricao}, data_locacao, data_devolucao, valor) d) Tabela_Estoque (cod_peca, descricao, quantidade_comprada, {cod_fornecedor, nome, telefone}) e) Tabela_Biblioteca (cod_aluno, nome, telefone, end, {cod_livro, titulo, editora, volume, cod_autor, nome, genero}, data_emprestimo, data_devolucao) f) Tabela_Matricula (cod_aluno, cod_turma, cod_disciplina, nome_disciplina, nome_aluno, cod_localnascaluno, nome_localnascaluno) g) Tabela_Consulta (cod_medico, nome_med, crm, fone, cod_paciente, nome_ pac, fone_pac, end_pac, dt_consulta, diagnostico) II) Considere a relao para livros publicados: LIVRO (ttulo_livro, nome_autor, tipo_livro, preo_tabela, afiliao_autor, editora) Suponha as que existam as seguintes dependncias: ttulo_livro editora, tipo_livro tipo_livro preo_tabela nome_autor afiliao_autor a) Em que forma normal est esta relao? Justifique sua resposta. b) Aplique a normalizao at que no possa mais decompor as relaes. Justifique as razes de cada decomposio.

65

Banco de Dados

Vamos Revisar?
O Modelo Relacional, devido sua natureza inerentemente formal, dispe de uma ferramenta conceitual que permite modelar diversas formas de controle de consistncia. O controle atravs da prpria estrutura do BD obtido no Modelo Relacional construindose as relaes, segundo regras que garantam a manuteno de certas propriedades. Essas regras so chamadas Formas Normais. As principais formas normais so a 1FN (que trata atributos compostos e multivalorados), a 2FN (que trata dependncias parciais) e a 3FN (que trata dependncias transitivas). E, geralmente, s normalizamos as relaes at essa 3FN. Adicionalmente, existem a BCNF, a 4FN e a 5FN que s so aplicadas em casos especiais. Qualquer um que projete um sistema a ser implementado em banco de dados relacional deve estar familiarizado com as tcnicas bsicas da normalizao, pois elas podem contribuir para melhorar a qualidade do projeto do banco de dados.

66

Banco de Dados

Consideraes Finais
Ol, cursista! Esperamos que voc tenha aproveitado este terceiro mdulo da disciplina Banco de Dados. Com os assuntos vistos at agora, voc j tem tudo para criar o seu banco de dados e comear a trabalhar com ele, armazenando, alterando, deletando e consultado os dados armazenados. justamente isto que estudaremos no prximo mdulo: a linguagem SQL que vai lhe ajudar a criar e manipular o seu banco de dados! Aguardamos sua participao no prximo mdulo. At l e bons estudos! Sandra de Albuquerque Siebra Autora

67

Banco de Dados

Referncias
BATINI, C.; CERI, S.; NAVATHE, S. B. Conceptual database design: an entityrelationship approach. San Francisco: Benjamim Cummings, 1992. COUGO, Paulo Srgio. Modelagem Conceitual e Projeto de Banco de Dados. Elsevier Editora, 1997. DATE, C. J. Banco de dados: tpicos avanados. Rio de Janeiro : Campus, 1988. DATE, C. J. Introduo a Sistemas de Banco de Dados. Elsevier Editora, 2004. ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. Traduzido por: Marilia Guimares Pinheiro et al. 4a. ed. So Paulo: Pearson Education do Brasil, 2005. HEUSER, Carlos Alberto. Projeto de Banco de Dados. 3. Edio., Porto Alegre: SagraLuzzatto, 2004. KORTH, H. F.; SILBERSCHATZ, A.; SUDARSHAN, S. Sistema de Banco de Dados: Elsevier Editora, 2006. KROENKE, David M. Banco de Dados: Fundamentos, Projeto e Implementao. 6 Edio: Editora LTC, 1999. LAENDER, A. H. F. ; CASANOVA, M. A. ; TUCHERMAN, L.. On the Design and Maintenance of Optimized Relational Representations of Entity-Relationship Schemas. Data & Knowledge Engineering, Amsterdam, v. 11, n. 1, p. 1-20, 1993 Revista SQL Magazine - http://www.sqlmagazine.com.br SETZER, V. W. Banco de dados. 3.ed. So Paulo : Revista Edgard Blucher, 1989. SILBERSCHATZ, Abraham; KORTH, Henry F;SUDARSHAN, S. Sistema de banco de dados. Traduzido por Daniel Vieira. Rio de Janeiro: Elsevier; Campus, 2006.

68

Banco de Dados

Conhea a Autora
Sandra de Albuquerque Siebra
Doutora em Cincia da Computao, pelo Centro de Informtica da UFPE onde trabalhou com Ambientes Virtuais de Aprendizagem e Ambientes Colaborativos em Geral. Ensinou na Faculdade Integrada do Recife (FIR) e na Universidade Catlica de Pernambuco (UNICAP), alm de ter trabalhado como gerente de projetos no Centro de Estudos e Sistemas Avanados do Recife (CESAR). Atualmente, professora da Universidade Federal Rural de Pernambuco (UFRPE). Atua na equipe de Educao a Distncia da UFRPE e no Departamento de Estatstica e Informtica (DEINFO), como professora autora de materiais didticos para cursos a distncia, j tendo tambm atuado como coordenadora de curso e professora executora de disciplinas. Tem experincia, trabalhos desenvolvidos e artigos publicados nas reas de Educao a Distncia, Interfaces Homem- Mquina, Sistemas Colaborativos, Banco de Dados, Anlise e Projeto de Sistemas Orientados a Objetos, Sistemas de Informao e Engenharia de Software. Atualmente, desenvolve pesquisas sobre contextualizao de interaes em ambientes virtuais de aprendizagem e trabalho cooperativo.

69