![\"lu282015g3s_tmp_f84a4ad331b604d4\"](\"https:\/\/www.pauloacosta.com\/wp-content\/uploads\/2023\/02\/lu282015g3s_tmp_f84a4ad331b604d4.png\" "\\"lu282015g3s_tmp_f84a4ad331b604d4\\"")
<\/a><\/p>\nNormaliza\u00e7\u00e3o \u00e9 uma Ferramenta para Valida\u00e7\u00e3o da Qualidade de um Esquema<\/u>.<\/p>\n
As formas normais at\u00e9 FNBC s\u00e3o baseadas em depend\u00eancias funcionais<\/b>, exceto a 1FN<\/u>, que faz parte da defini\u00e7\u00e3o do modelo relacional.<\/u><\/p>\n
O design conceitual baseado no modelo ER tende naturalmente a produzir esquemas normalizados, a menos da 1FN. A separa\u00e7\u00e3o de conceitos<\/u> \u00e9 o resultado natural do design conceitual bem feito. Na pr\u00e1tica, esquemas que violam a normaliza\u00e7\u00e3o s\u00e3o exemplos de esquemas mal projetados<\/u>. <\/p>\n
A utilidade pr\u00e1tica da 4FN e 5FN \u00e9 limitada, porque num banco de dados real com muitos atributos, \u00e9 muito dif\u00edcil (e praticamente irrelevante) descobrir tais depend\u00eancias e restri\u00e7\u00f5es.<\/p>\n
S\u00e3o objetivos<\/u> do processo de normaliza\u00e7\u00e3o:<\/p>\n Reduzir redund\u00e2ncias.<\/p>\n Evitar anomalias de atualiza\u00e7\u00e3o.<\/p>\n Simplificar imposi\u00e7\u00e3o de restri\u00e7\u00f5es de integridade, com a redu\u00e7\u00e3o de redund\u00e2ncias, se torna mais f\u00e1cil impor restri\u00e7\u00e3o de integridade.<\/p>\n Produzir uma boa base para crescimento futuro. O modelo normalizado \u00e9 escal\u00e1vel.<\/p>\n<\/li>\n<\/ul>\n <\/a>Rela\u00e7\u00f5es n\u00e3o normalizadas s\u00e3o sujeitas a anomalias durante as atualiza\u00e7\u00f5es: <\/p>\n Anomalias de inser\u00e7\u00e3o: <\/b>Inserir empregado requer repetir dados de departamento.<\/p>\n Anomalias de exclus\u00e3o: <\/b>Excluir \u00fanico empregado de departamento tamb\u00e9m exclui o departamento.<\/p>\n Anomalias de modifica\u00e7\u00e3o:<\/b> Mudar gerente de departamento requer modificar v\u00e1rias tuplas.<\/p>\n<\/li>\n<\/ul>\n Um percentual significativo dos sistemas de informa\u00e7\u00e3o hoje usados foram desenvolvidos ao longo dos \u00faltimos vinte anos e n\u00e3o utilizam bancos de dados relacionais<\/u>. S\u00e3o os chamados sistemas legados (\u201cLegacy Systems\u201d). Os dados destes sistemas est\u00e3o armazenados em arquivos de linguagens de terceira gera\u00e7\u00e3o, como Basic, COBOL, MUMPS e outras, ou ent\u00e3o em bancos de dados da era pr\u00e9-relacional, como IMS, ADABAS, DMS-II e os SGBD do tipo CODASYL (IDMS, IDS\/2,\u2026). Raramente, os arquivos destes sistemas est\u00e3o documentados atrav\u00e9s de modelos conceituais. Al\u00e9m disso, muitos dos bancos de dados relacionais existentes, principalmente em microcomputadores, n\u00e3o possuem documenta\u00e7\u00e3o na forma de modelo conceitual.<\/p>\n Com a tentativa de migrar estes sistemas para uma nova plataforma tecnol\u00f3gica, ou para realizar a manuten\u00e7\u00e3o dos mesmos softwares. Passou a existir a necessidade conseguir gerar o modelo conceitual dos dados destes sistemas.<\/p>\n Um exemplo \u00e9 a manuten\u00e7\u00e3o rotineira de software de um sistema de informa\u00e7\u00f5es. Neste caso, o modelo conceitual pode ser usado como documenta\u00e7\u00e3o abstrata dos dados<\/u> durante discuss\u00f5es entre usu\u00e1rios, analistas e programadores. A exist\u00eancia de um modelo conceitual permite que pessoas que n\u00e3o conhe\u00e7am o sistema possam aprender mais rapidamente<\/u> o seu funcionamento.<\/p>\n Outro exemplo no qual \u00e9 importante possuir o modelo conceitual de um banco de dados j\u00e1 implementado \u00e9 o da migra\u00e7\u00e3o do banco de dados para uma nova plataforma de implementa\u00e7\u00e3o. Por exemplo, usando um SGBD relacional. A disponibilidade de uma documenta\u00e7\u00e3o abstrata, na forma de um modelo conceitual dos dados do sistema existente, pode acelerar em muito o processo de migra\u00e7\u00e3o, pois permite encurtar a etapa de modelagem de dados do novo banco de dados.<\/p>\n Para obter este modelo conceitual, \u00e9 necess\u00e1rio a utiliza\u00e7\u00e3o de engenharia reversa em sa\u00eddas de dados<\/u> destes sistemas legados, geralmente relat\u00f3rios (um arquivo contendo informa\u00e7\u00f5es). E a partir destes arquivos tentava-se realizar a engenharia reversa.<\/p>\n O primeiro passo \u00e9 a representa\u00e7\u00e3o da descri\u00e7\u00e3o de cada arquivo existente na forma de um esquema de uma tabela relacional n\u00e3o normalizada. Este primeiro passo objetiva obter uma descri\u00e7\u00e3o independente do tipo de arquivo que est\u00e1 sendo utilizado. A partir da\u00ed, o processo trabalha apenas com tabelas relacionais, o que o torna independente do tipo de arquivo que est\u00e1 sendo usado como entrada ao processo de normaliza\u00e7\u00e3o. <\/p>\n \u00c9 parte da defini\u00e7\u00e3o formal de uma rela\u00e7\u00e3o<\/u>. Foi definida para n\u00e3o permitir atributos multivalorados, atributos compostos e suas combina\u00e7\u00f5es<\/u>.<\/p>\n Um esquema de rela\u00e7\u00e3o R est\u00e1 na 1FN se todos os seus atributos forem at\u00f4micos (simples e monovalorados)<\/u>, ou seja, n\u00e3o s\u00e3o permitidos atributos multivalorados, atributos compostos ou atributos multivalorados compostos. Uma tabela est\u00e1 na 1FN, se e somente se, n\u00e3o contiver tabelas aninhadas.<\/p>\n Um atributo que representa uma abstra\u00e7\u00e3o de outros atributos \u00e9 do tipo Composto. Atributos At\u00f4micos<\/b><\/u> tamb\u00e9m s\u00e3o conhecidos como <\/u>Atributos Escalares<\/b><\/u>.<\/p>\n Observa\u00e7\u00e3o:<\/b> O Peter Chen no modelo conceitual prev\u00ea o uso do atributo multivalorado<\/u> (telefone = telefone1, telefone2, telefone3). Ent\u00e3o quando deseja se converter em uma tabela no modelo relacional, ser\u00e1 necess\u00e1rio normalizar esta tabela<\/u>.<\/p>\n Observa\u00e7\u00e3o:<\/b> Atributo composto \u00e9 a utiliza\u00e7\u00e3o de um campo para armazenagem de diversas informa\u00e7\u00f5es. <\/u>Por exemplo: Endere\u00e7os contendo bairro, rua, etc. este problema \u00e9 solucionado realizando a decomposi\u00e7\u00e3o do campo em v\u00e1rios campos.<\/p>\n Por defini\u00e7\u00e3o, toda tabela j\u00e1 est\u00e1 na tabela normal. Mas na pr\u00e1tica n\u00e3o \u00e9 bem assim.<\/p>\n Exemplo de Tabela que n\u00e3o est\u00e1 na 1FN, devido ao campo Localiza\u00e7\u00e3o que \u00e9 multivalorado. Ou seja, provocando uma tabela aninhada.<\/p>\n A solu\u00e7\u00e3o para este problema \u00e9 remover a tabela aninhada \u201cLocal\u201d de dentro da tabela departamento: <\/a>Existem algumas representa\u00e7\u00f5es, que podem identificar que existe uma rela\u00e7\u00e3o dentro de uma rela\u00e7\u00e3o (tabelas aninhadas), o que demonstra n\u00e3o estar na 1FN<\/p>\n Exemplo:<\/p>\n FUNCION\u00c1RIOS = {CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATA FIM}}<\/b><\/p>\n ou<\/b><\/p>\n FUNCION\u00c1RIOS = (CODFUNC + NOME + CARGO + (PROJETO + DATAINI + DATA FIM))<\/b><\/p>\n Para colocar na 1FN:<\/p>\n FUNCION\u00c1RIOS = {CODFUNC<\/u> + NOME + CARGO}<\/b><\/p>\n FUNC_PROJ = {CODFUNC<\/u> + PROJETO + DATAINI + DATA FIM}<\/b><\/p>\n OBS: A chave prim\u00e1ria de \u201cFuncion\u00e1rios\u201d ser\u00e1 chave estrangeira de FUNC_PROJ.<\/p>\n O exemplo abaixo exibe outro problema, o nome \u201cTelefones\u201d como est\u00e1 no plural indica um campo composto, o que vai contra a 1FN (considerando que o campo TELEFONES \u00e9 multivalorado):<\/p>\n PESSOAS = {ID + NOME + ENDERECO + TELEFONES}<\/b><\/p>\n Para deixar esta tabela na 1FN, deve-se separar o campo multivalorado TELEFONES em uma tabela adicional, desta forma:<\/p>\n PESSOAS = {ID + NOME + ENDERECO}<\/b><\/p>\n TELEFONES = {PESSOA_ID + TELEFONE}<\/b><\/p>\n Outra forma de identificar se a tabela est\u00e1 na 1NF \u00e9 verificando se existem tabelas aninhadas, ou seja, mais de um registro para uma chave prim\u00e1ria.<\/p>\n Em uma tabela relacional, diz-se que uma coluna C2 depende funcionalmente de uma coluna C1 (ou que uma coluna C1 determina a coluna C2) quando, em todas as linhas da tabela, para cada valor de C1 que aparece na tabela, aparece o mesmo valor de C2.<\/p>\n C1 \u2192 C2 A depend\u00eancia Funcional (DF) deve ser explicitamente definida por algu\u00e9m que conhe\u00e7a a sem\u00e2ntica dos atributos de uma rela\u00e7\u00e3o.<\/p>\n Ou seja, Para C1 determinar C2 sempre que eu ver o valor de C1 eu j\u00e1 saberei o valor de C2. Digamos que CPF seja C1, e nome C2. Toda vez que CPF tiver o valor \u201c111\u201d n\u00f3s j\u00e1 sabemos que C2 ser\u00e1 \u201cAna\u201d; toda vez que C1 for \u201c555\u201d, sabemos que C2 ser\u00e1 \u201cJo\u00e3o\u201d. Podemos dizer que C1 (CPF) determina C2 (Nome), ou que C2 (Nome) depende funcionalmente de C1 (CPF).<\/p>\n Com os dados acima, percebemos que \u00e9 poss\u00edvel fazer o inverso, que a partir de C2 tamb\u00e9m podemos saber quem \u00e9 C1, o que nos leva a uma li\u00e7\u00e3o. Para determinar a depend\u00eancia funcional, n\u00e3o pode ser considerado um pequeno conjunto de ocorr\u00eancias<\/u> em uma tabela. \u00c9 necess\u00e1rio o conjunto mais amplo poss\u00edvel, para que n\u00e3o seja passada uma falsa ideia.<\/p>\n Sempre que eu vejo Ana, eu sei que o CPF ser\u00e1 111?<\/p>\n Estendendo o n\u00famero de dados, \u00e9 poss\u00edvel visualizar melhor, chegando a conclus\u00e3o de que apenas a partir de CPF podemos saber qual o nome, ou seja CPF \u2192 Nome<\/b> (CPF determina Nome, ou Nome \u00e9 dependente funcional de CPF).<\/p>\n O objetivo \u00e9 descobrir qual campo ser\u00e1 a chave prim\u00e1ria da tabela.<\/p>\n \u201cUma rela\u00e7\u00e3o encontra-se na 2FN se e somente se estiver em 1FN e n\u00e3o cont\u00e9m depend\u00eancias parciais<\/u>.\u201d<\/p>\n Depend\u00eancia Parcial:<\/b> ocorre quando uma coluna depende apenas de uma parte de uma chave prim\u00e1ria composta<\/u>.<\/p>\n Na tabela abaixo, que n\u00e3o est\u00e1 na segunda forma normal, percebemos as Depend\u00eancias funcionais dos campos.<\/p>\n Na tabela a cima \u00e9 poss\u00edvel visualizar que temos dados de 2 entidades diferentes, pois alguns campos dependem funcionalmente de CPF, e outros dependem do campo Num\u00e9ro do Projeto. Para ficar na 2FN a tabela acima seria convertida em:<\/p>\n \u201cUma rela\u00e7\u00e3o est\u00e1 em 3FN se e somente se estiver em 2FN e nenhum atributo n\u00e3o-primo (isto \u00e9, que n\u00e3o seja membro de uma chave) for transitivamente dependente da chave prim\u00e1ria<\/u>.\u201d<\/p>\n Ou seja, para estar na 3\u00aa forma normal n\u00e3o pode haver depend\u00eancia funcional transitiva<\/u>.<\/p>\n A rela\u00e7\u00e3o n\u00e3o deve ter um atributo n\u00e3o-chave funcionalmente determinado por um outro atributo n\u00e3o-chave(ou por um conjunto de atributos n\u00e3o-chave).<\/p>\n Depend\u00eancia Transitiva:<\/b> ocorre quando uma coluna, al\u00e9m de depender da chave prim\u00e1ria de uma tabela<\/u>, depende de outra coluna ou conjunto de colunas da tabela<\/u>.<\/p>\n Como podemos perceber \u201cNum-Dept\u201d \u00e9 dependente funcional de CPF. Nome-Dept e Ger-Dept s\u00e3o dependentes funcionais de \u201cNum-Dept\u201d, logo eles ocorre uma depend\u00eancia transitiva de Nome-dept e Ger-Dept com CPF. E na 3FN isso n\u00e3o pode ocorrer.<\/p>\n Para solucionar este problema, divide-se em duas tabelas:<\/p>\n Uma tabela est\u00e1 na terceira forma normal (3FN) se estiver na 2FN e n\u00e3o possuir depend\u00eancias transitivas, ou indiretas. Uma depend\u00eancia transitiva ocorre quando A -> B e B -> C, ent\u00e3o A -> C. Em outras palavras, deve-se evitar que qualquer atributo n\u00e3o-chave<\/u> seja dependente funcional de outro atributo n\u00e3o-chave<\/u>.<\/p>\n Observe o exemplo:<\/p>\n Considere um Pedido n\u00famero 00001, para este pedido se observarmos o formul\u00e1rio em papel teremos muitos campos a considerar, contudo usaremos apenas alguns para facilitar o entendimento.<\/p>\n PEDIDOS = {CD_PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR}<\/b><\/p>\n Neste momento devemos idealizar o pedido n\u00famero: 00001 e efetuar os seguintes testes:<\/p>\n Cd_Pedido<\/b><\/p>\n Cliente<\/b><\/p>\n Vendedor<\/b><\/p>\n Atendente<\/b><\/p>\n Produto<\/b><\/p>\n Qntd.<\/b><\/p>\n Valor<\/b><\/p>\n 00001<\/b><\/p>\n \u201cDouglas Tybel\u201d<\/b><\/p>\n \u201cMarco\u201d<\/b><\/p>\n \u201cJo\u00e3o\u201d<\/b><\/p>\n \u201cTenis\u201d<\/p>\n \u201c1\u201d<\/p>\n \u201c50.00\u201d<\/p>\n 00001<\/b><\/p>\n \u201cDouglas Tybel\u201d<\/b><\/p>\n \u201cMarco\u201d<\/b><\/p>\n \u201cJo\u00e3o\u201d<\/b><\/p>\n \u201cSand\u00e1lia\u201d<\/p>\n \u201c2\u201d<\/p>\n \u201c80.00\u201d<\/p>\n 00001<\/b><\/p>\n \u201cDouglas Tybel\u201d<\/b><\/p>\n \u201cMarco\u201d<\/b><\/p>\n \u201cJo\u00e3o\u201d<\/b><\/p>\n \u201cCarteira\u201d<\/p>\n \u201c1\u201d<\/p>\n \u201c35.00\u201d<\/p>\n Observe que temos uma Depend\u00eancia Funcional Transitiva, pois Quantidade e Valor dependem de produto, e este depende do c\u00f3digo do pedido.<\/p>\n Aplicando a 3FN, teremos:<\/p>\n Cd_Pedido<\/b><\/p>\n Cliente<\/b><\/p>\n Vendedor<\/b><\/p>\n Atendente<\/b><\/p>\n 00001<\/b><\/p>\n \u201cDouglas Tybel\u201d<\/b><\/p>\n \u201cMarco\u201d<\/b><\/p>\n \u201cJo\u00e3o\u201d<\/b><\/p>\n 00001<\/b><\/p>\n \u201cDouglas Tybel\u201d<\/b><\/p>\n \u201cMarco\u201d<\/b><\/p>\n \u201cJo\u00e3o\u201d<\/b><\/p>\n 00001<\/b><\/p>\n \u201cDouglas Tybel\u201d<\/b><\/p>\n \u201cMarco\u201d<\/b><\/p>\n \u201cJo\u00e3o\u201d<\/b><\/p>\n Cd_Pedido<\/b><\/p>\n Produto<\/b><\/p>\n Qntd.<\/b><\/p>\n Valor<\/b><\/p>\n 00001<\/b><\/p>\n \u201cTenis\u201d<\/p>\n \u201c1\u201d<\/p>\n \u201c50.00\u201d<\/p>\n 00001<\/b><\/p>\n \u201cSand\u00e1lia\u201d<\/p>\n \u201c2\u201d<\/p>\n \u201c80.00\u201d<\/p>\n 00001<\/b><\/p>\n \u201cCarteira\u201d<\/p>\n \u201c1\u201d<\/p>\n \u201c35.00\u201d<\/p>\n <\/a>O conceito de normaliza\u00e7\u00e3o foi introduzido por E. F. Codd em 1972. Inicialmente Codd criou as tr\u00eas primeiras formas de normaliza\u00e7\u00e3o chamando-as de: primeira forma normal (1NF), segunda forma normal (2NF) e terceira forma normal (3NF). Uma defini\u00e7\u00e3o mais forte da 3NF foi proposta depois por Boyce-Codd, e \u00e9 conhecida como forma normal de Boyce-Codd (FNBC).<\/u><\/p>\n \u00c9 uma forma mais restritiva de 3FN<\/u>, isto \u00e9 toda rela\u00e7\u00e3o em FNBC est\u00e1 tamb\u00e9m em 3FN; entretanto, uma rela\u00e7\u00e3o em 3FN n\u00e3o est\u00e1 necessariamente em FNBC.<\/p>\n \u201cUma rela\u00e7\u00e3o est\u00e1 em FNBC se para toda df X \u2192 Z, X \u00e9 uma Superchave.\u201d<\/p>\n Uma Superchave SK especifica uma restri\u00e7\u00e3o de unicidade de que duas tuplas distintas em um estado r de R n\u00e3o podem possuir o mesmo valor para SK.<\/p>\n Chave prim\u00e1ria \u00e9 a Superchave m\u00ednima.<\/p>\n A BCNF diz que todo elemento deve depender apenas de uma chave.<\/p>\n Df2: {Professor} \u2192 { Disciplina}, por\u00e9m {Professor} n\u00e3o \u00e9 uma Superchave.<\/p>\n Devido a este problema, poder\u00e1 ocorrer uma anomalia de exclus\u00e3o: se Carlos sair da aula de F\u00edsica, n\u00e3o teremos nenhum registro de que Antonio leciona F\u00edsica.<\/p>\n A solu\u00e7\u00e3o para este problema \u00e9 a cria\u00e7\u00e3o de duas tabelas:<\/p>\n Defini\u00e7\u00e3o que engloba as outras formas normais, e define que uma tabela est\u00e1 em BCNF se, e somente se, todo determinante funcional for em rela\u00e7\u00e3o a uma chave candidata.<\/p>\n Na pr\u00e1tica, uma tabela est\u00e1 em BCNF se estiver em 3NF e n\u00e3o existir depend\u00eancia funcional dentro da chave prim\u00e1ria.<\/u><\/p>\n Ou seja, se todos os atributos s\u00e3o funcionalmente dependentes da chave, de toda a chave e nada mais do que a chave. Ou, em outras palavras, todos os determinantes s\u00e3o chaves candidatas.<\/u><\/p>\n Um modelo que est\u00e1 em BCNF est\u00e1 pronto para ser implementado numa arquitetura de banco de dados relacional.<\/p>\n \u201cUma rela\u00e7\u00e3o est\u00e1 em 4\u00aa Forma Normal (4FN) se, e somente se, estiver na 3FN e n\u00e3o contiver depend\u00eancias multivaloradas<\/u>.\u201d<\/p>\n Dada uma rela\u00e7\u00e3o qualquer com tr\u00eas atributos x, y e z, diz-se que y depende de forma multivalorada de x se e somente se sempre que existirem duas tuplas (x1,y1,z1) e (x1,y2,z2) existir\u00e3o tamb\u00e9m duas tuplas (x1,y1,z2) e (x1,y2,z1).<\/p>\n Refere-se \u00e0 combina\u00e7\u00e3o de valores de atributos multivalorados disjuntos (y e z).<\/p>\n x na verdade, relaciona-se com y e com z de forma independente.<\/p>\n \u201cUma rela\u00e7\u00e3o R est\u00e1 na 5FN , tamb\u00e9m chamada de forma normalizada de proje\u00e7\u00e3o-jun\u00e7\u00e3o (PJ\/NF) se, e somente se, toda depend\u00eancia de jun\u00e7\u00e3o em R for consequ\u00eancia de chaves candidatas de R.\u201d<\/p>\n As DM s\u00e3o uma tentativa de detectar decomposi\u00e7\u00f5es sem perdas que se apliquem a todas as rela\u00e7\u00f5es de um dado esquema.<\/p>\n Se n\u00e3o \u00e9 poss\u00edvel reconhecer qualquer DM em R, n\u00e3o existe decomposi\u00e7\u00e3o sem perdas em duas rela\u00e7\u00f5es.<\/p>\n Existem rela\u00e7\u00f5es que n\u00e3o podem ser decompostas em duas proje\u00e7\u00f5es sem perda, mas podem ser decompostas em tr\u00eas ou mais. Estas rela\u00e7\u00f5es podem ser descritas como \u201cdecompon\u00edvel n\u201d (n>2) (Date), significando que a rela\u00e7\u00e3o em quest\u00e3o pode ser decomposta sem perda em n proje\u00e7\u00f5es, mas n\u00e3o em m proje\u00e7\u00f5es, m < n.<\/p>\n Esta limita\u00e7\u00e3o \u00e9 denominada depend\u00eancia de jun\u00e7\u00e3o (DJ).<\/p>\n Uma rela\u00e7\u00e3o R satisfaz a depend\u00eancia de jun\u00e7\u00e3o * (X, Y, …Z) se, e somente se, R for igual \u00e0 jun\u00e7\u00e3o de suas proje\u00e7\u00f5es em X, Y, …Z, onde X, Y, …Z forem subconjuntos do conjunto de atributos de R.<\/p>\n\n
\n
Origem<\/h4>\n
<\/a><\/p>\n<\/a>1\u00ba Forma Normal (1FN)<\/h4>\n
<\/a><\/p>\n<\/a><\/p>\nDepend\u00eancia Funcional<\/h4>\n
C1 determina a coluna C2
C2 depende funcionalmente de C1<\/b><\/p>\n<\/a><\/p>\n<\/a><\/p>\n<\/a>2\u00aa Forma Normal (2FN): N\u00e3o Parciais<\/h4>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a>3\u00aa Forma Normal (3FN): N\u00e3o Transitivas<\/h4>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a>Forma Normal Boyce-Codd (BCNF): Depend\u00eancia apenas da Superchave<\/h4>\n
<\/a><\/p>\n<\/a><\/p>\n<\/a>4\u00aa Forma Normal (4FN)<\/h4>\n
<\/a>5\u00aa Forma Normal (4FN)<\/h4>\n