Normalização de banco de dados

Transcrição

1 Nrmalizaçã de banc de dads é um cnjunt de regras que visa, principalmente, a rganizaçã de um prjet de banc de dads, evitand perda u repetiçã e infrmações. Para nrmalizar banc de dads, deve-se examinar s atributs de uma entidade, cm bjetiv de se evitar anmalias bservadas na inclusã, exclusã e alteraçã de registrs. Atualmente, é cmum verificarms rganizações cm bases de dads da rdem ds terabytes. Além diss, é sabid que a necessidade de infrmações pr parte ds gestres é enrme e vem crescend diariamente. Ist prque a tmada de decisões, cm base em infrmações, trna-se muit mais precisa. E, para que estas infrmações sejam geradas cm qualidade, é necessári um bm prjet de banc de dads. Sabems que bjetiv de um prjet de banc de dads é bter um cnjunt de esquemas de tabelas que ns permita armazenar dads sem redundância e que as infrmações pssam ser geradas facilmente. Para verificar se um prjet de banc de dads atende a estes pressupsts, pdems aplicar algumas regras as prjets em questã. A estas regras, dams nme de Frmas Nrmais. Originalmente, Edgar F. Cdd definiu três destas frmas nrmais (Primeira Frma Nrmal, Segunda Frma Nrmal e Terceira Frma Nrmal), mas hje existem algumas utras (Frma Nrmal de Byce-Cdd, Quarta Frma Nrmal e Quinta Frma Nrmal) cm verems ns tópics a seguir. Muits autres dizem que aplicand as três frmas nrmais definidas pr Cdd, prjet d banc de dads já estará livre de redundâncias e incnsistências. Entretant, utrs autres definem cm de extrema imprtância a aplicaçã das utras frmas nrmais. Neste artig, nã entrarems nesta discussã e apresentarems tdas as frmas nrmais existentes atualmente. Dessa frma, leitr terá cndições de verificar a imprtância u nã da aplicaçã de tdas elas. Para efetuar a nrmalizaçã, aplicam-se na rdem as seguintes frmas nrmais: primeira frma nrmal, segunda frma nrmal, terceira frma nrmal. Neste pnt, pdems dar cntinuidade à nrmalizaçã seguind pelas frmas nrmais de Byce-Cdd, quarta frma nrmal e pr últim a Quinta Frma Nrmal u, iniciar diretamente da frma nrmal Byce-Cdd. Estas frmas nrmais devem ser aplicadas a mdel de dads definid pel prfissinal. A final da aplicaçã das frmas nrmais, pdems dizer que prjet de banc de dads está livre de redundâncias e cnseqüentemente de incnsistência. Neste mment, pdems definir nrmalizaçã cm send uma série de passs que se segue n prjet de um banc de dads que permite um armazenament cnsistente e um eficiente acess as dads em um banc de dads relacinal. Esses passs evitam a redundância de dads e as chances ds dads se trnarem incnsistentes. Devems fazer us destes passs sempre que estiverms prjetand nssas sluções de banc de dads, salv cass específics nde trabalhams cm cnceit de desnrmalizaçã. Cm vims, us da nrmalizaçã traz grandes benefícis (cnsistência, evita redundância, integridade) e sua nã utilizaçã pderá trazer exatamente s prblemas reslvids cm nrmalizaçã, u seja: prblemas de incnsistência, redundância e integridade. Este artig será dividid da seguinte frma: inicialmente, serã abrdads cnceits imprtantes envlvids n cntext. Psterirmente, serã apresentadas

2 as frmas nrmais e um exempl de aplicaçã. Lg após, abrdarems tópic sbre desnrmalizaçã e pr últim, farems as cnsiderações finais relacinadas a artig. Cnceit 1: Dependência Funcinal Uma dependência funcinal é um relacinament entre dis u mais atributs de frma que valr de um atribut identifique valr para cada um ds utrs atributs, u seja, um atribut está relacinad a utr. Pr exempl: A B Nesse exempl, atribut B é dependente (funcinalmente) d atribut A. Em utras palavras, para descbrirms valr de B, precisams saber valr de A (bserve que a recíprca NÃO é verdadeira). Veja mais um exempl: Códig d cliente Nme d cliente Nesse exempl, para descbrirms nme d cliente (dentr de um cnjunt de clientes), primeiramente precisams saber qual é códig dele. Assim, camp/atribut nme é dependente d camp/atribut códig. Observe que a recíprca NÃO é verdadeira! Vcê pderia pensar: Ora, eu pss cnhecer nme d cliente, e nã seu códig. Nem sempre eu vu precisar saber códig d cliente para bter nme dele. Esse pensament é incrret, pis vcê pde ter clientes cm mesm nme. Outr detalhe imprtante é que em uma tabela pdems ter mais de uma dependência funcinal. Pr exempl: Códig d cliente Nme d cliente Códig d cliente UF d cliente Essa mesma afirmaçã pde ser descrita da seguinte frma: Códig d Cliente [Nme d Cliente, UF d cliente] Vams ver agra um exempl mais cmplet. Vams supr uma tabela cntend códig d cliente, nme d cliente, tip de lgradur, lgradur, númer, cmplement, bairr, cidade e UF. Nesta tabela, para cada códig de cliente terems um só valr para nme d cliente, tip de lgradur, lgradur, númer, cmplement, bairr, cidade e UF. Pr ist, dizems que s atributs nme d cliente, tip de lgradur, lgradur, númer, cmplement, bairr, cidade e UF estã funcinalmente dependentes d códig d cliente. Perceba que neste cas estams cnsiderand que será armazenad apenas endereç residencial da pessa (cas cntrári, a dependência funcinal deixaria de existir). Esta dependência funcinal pde ser escrita da seguinte frma: Códig nme, tip_lgradur, lgradur, nr, cmpl, bairr, cidade, UF Cm iss, pdems perceber que valr de um atribut determina valr de utr atribut. Prvavelmente vcê já tenha se deparad cm a frma mais cmum de

3 dependência funcinal, que é gerada pela chave primária. Obviamente valr da chave primária determina valr ds utrs atributs d mesm registr. Cnceit 2: Dependência Funcinal Parcial Uma dependência funcinal parcial crre quand s atributs nã chave nã dependam funcinalmente de tda a chave primária quand esta fr cmpsta. Assim, nas tabelas nde a chave primária fr cmpsta, tds s atributs devem depender de tda a chave primária. Cas a dependência seja de parte da chave, verificams a existência de dependência funcinal parcial. Pr exempl: AB C, D Cnsidere que atribut C dependa funcinalmente de A, mas nã dependa de B. Já tems um exempl de dependência funcinal parcial. Vams ver agra um exempl mais cmplet. Supnha uma tabela ntas (matricula_alun, CdDisciplina, Perid, NmeDisciplina, Nta) (ver Tabela 1). Supnha que a chave primária desta tabela seja matricula_alun, Perid e CdDisciplina. Nesta tabela, verificams que atribut NmeDisciplina depende apenas d CdDisciplina e nã depende da matrícula d alun junt cm seu períd. Assim, existe uma dependência funcinal parcial. Iss pde trazer prblemas para mdel cm redundância de infrmações. Imagine que alun de matricula 123 tenha perdid a disciplina Engenharia de Requisits n primeir períd e tenha que repeti-la n segund. Perceba na Tabela 1 que neste cas teríams valr d camp NmeDisciplina replicad. Esta certamente nã é uma ba prática de prjet. A sluçã neste cas seria criarms utra tabela cntend apenas s dads da disciplina (verems esta sluçã detalhadamente mais adiante quand falarems sbre as frmas nrmais). Matricula_Alun Perid CdDisciplin a NmeDisciplina Nta Engenharia de Requisits 4, Qualidade de Sftware 10, Engenharia de Sftware 7, Engenharia de Requisits 9,0 Tabela 1. Tabela cntend dependência funcinal parcial. Cnceit 3: Dependência Funcinal Transitiva Na definiçã ds camps de uma entidade pdem crrer cass em que um camp nã seja dependente diretamente da chave primária u de parte dela, mas sim dependente de utr camp da tabela, camp este que nã a Chave Primária.

4 Quand ist crre, dizems que a tabela pssui dependência funcinal transitiva. É imprtante deixar clar a diferença entre dependência funcinal parcial e a transitiva. Na parcial, pel mens um atribut da tabela depende de parte da chave primária (e nã dela tda); na transitiva, pel mens um atribut da tabela depende de utr atribut que nã seja chave primária. Para definir melhr cnceit de dependência funcinal transitiva, trabalharems pr mei de um exempl. Vams supr a existência de uma tabela funcinári cntend a matrícula d funcinári (chave primária), nme d funcinári, códig d carg, nme d carg e salári d carg, cnfrme Tabela 2. Matricula NmeFuncinari CdCarg NmeCarg SalariCarg 1 Ary 1 Prfessr R$ 7.500,00 2 Tatiana 2 Advgad R$ 6.900,00 3 Ana 3 Secretária R$ 1.550,00 4 Luis 4 Analista de Sistemas R$ 8.000,00 5 Rdrig 1 Prfessr R$ 7.500,00 Tabela 2. Tabela Funcinári Perceba que a matrícula d funcinári determina apenas s atributs nme d funcinári e códig d carg. Entretant, códig d carg (que nã é chave primária) determina nme d carg e salári d carg e estes dis últims atributs nã dependem diretamente d atribut matrícula. Matricula NmeFuncinari, CdCarg CdCarg NmeCarg, SalariCarg Assim, tems uma dependência funcinal transitiva. Perceba n exempl da Tabela 2 que quand este tip de dependência está presente, tems infrmações redundantes na tabela ( funcinári Rdrig também é prfessr e pssui s camps NmeCarg e SalariCarg repetids em relaçã a funcinári Ary) e sabems que este tip de situaçã é uma das causas para a perda de integridade em prjets de banc de dads. Analisand esta situaçã, fica bastante clar que sabend valr d atribut CdCarg, saberíams autmaticamente valr ds atributs NmeCarg, SalariCarg e iss pderia estar armazenad em utra tabela para evitar prblemas de redundância.

5 Cnceit 4: Atributs Multivalrads Atributs multivalrads sã atributs que pdem cnter mais de um valr para um mesm registr. Na Tabela 3 apresentams uma tabela pessa (Cdig, Nme, Telefne). Perceba atribut telefne para s dis primeirs registrs apresentads. Existe mais de um telefne para cada pessa. Desta frma, atribut Telefne é multivalrad. Cdig Nme Telefne 1 Ary (34) (34) (34) Tatiana (34) (34) Ana (11) Jã (31) Tabela 3. Tabela Pessa Cm Atributs Multivalrads. Cnceit 5: Atributs Cmpsts Atributs cmpsts sã atributs que pdem ser subdividids em váris atributs. Na Tabela 4 apresentams a tabela Pessa (Cdig, Nme, Enderec). Nesta tabela, atribut endereç é multivalrad, uma vez que ele pde ser dividid em váris atributs. Cdig Nme Enderec 1 Ary Av. Getúli Vargas, 1000, apt 201 Centr Pats de Minas-MG 2 Tatiana Av. Brasil, 966 Centr Bel Hriznte-MG 3 Ana Rua Minas Gerais, 100 Bairr Brasil Recife-PE 4 Jã Praça da Liberdade, 27 Bairr Esperança Sã Paul-SP Tabela 4. Tabela Pessa cm Atribut Cmpst

6 Na Tabela 5 apresentams a tabela pessa (Cdig, Nme, TipLgradur, Lgradur, Nr, Cmp, Bairr, Cidade, UF). Esta tabela é a mesma tabela da Tabela 4, prém cm atribut endereç send dividid em: Tip de Lgradur, Lgradur, Númer, Cmplement, Bairr, Cidade e Estad(UF). Cdig Nme Tip Lgradur Lgradur Nr Cm p Bairr Cidade UF 1 Ary Avenida Getúli Vargas Apt 201 Centr Pats de Minas M G 2 Tatian a Avenida Brasil 966 Centr Bel Hriznt e M G 3 Ana Rua Minas Gerais 100 " Primeira Frma Nrmal Um esquema de relaçã R está na 1FN se tds s seus atributs frem atômics (simples) e mnvalrads, u seja, nã sã permitids atributs multivalrads, atributs cmpsts u atributs multivalrads cmpsts. Exempl: FUNCIONÁRIOS = {CODFUNC + NOME + CARGO + {PROJETO + DATAINI + DATA FIM}} Para clcar na 1FN: FUNCIONÁRIOS = {CODFUNC + NOME + CARGO} FUNC_PROJ = {CODFUNC + PROJETO + DATAINI + DATA FIM} OBS: A chave primária de FUNCIONÁRIOS vai ser a chave estrangeira de FUNC_PROJ. Veja abaix utr exempl de tabela que nã está na 1FN (cnsiderand que camp TELEFONES é multivalrad): PESSOAS = {ID + NOME + ENDERECO + TELEFONES} Para deixar esta tabela na 1FN, deve-se separar camp multivalrad TELEFONES em uma tabela adicinal, desta frma:

7 PESSOAS = {ID + NOME + ENDERECO} TELEFONES = {PESSOA_ID + TELEFONE} Outra frma de identificar se a tabela está na 1NF é verificand se existe tabela aninhadas, u seja, mais de um registr para uma chave primária. Observe exempl: Cnsidere um Pedid númer 00001, para este pedid se bservarms frmulári em papel terems muits camps a cnsiderar, cntud usarems apenas alguns para facilitar entendiment. PEDIDOS = {COD_PEDIDO + CLIENTE + VENDEDOR + ATENDENTE + PRODUTO + QUANT + VALOR} Neste mment devems idealizar pedid númer: e efetuar s seguintes testes: {COD_PEDIDO CLIENTE VENDEDOR ATENDENTE PRODUTO QUANT VALOR} {00001 "DOUGLAS TYBEL" "MARCO" "JOAO" "TENIS " "1" "50.00"} {00001 "DOUGLAS TYBEL" "MARCO" "JOAO" "SANDALIA" "2" "80.00"} {00001 "DOUGLAS TYBEL" "MARCO" "JOAO" "CARTEIRA" "1" "35.00"} Observe que para s dads d pedid lançads acima, apenas s atributs que estã em negrit SÃO ÚNICOS, pis nã se diferem. Os demais atributs mudam, nã cumprind a 1NF nde s atributs devem ser atômics, quer dizer únics. Para testarms um ds atributs e ter certeza que este é atômic, pdems efetuar uma pergunta cnfrme exempl abaix: Pdems ter utr cliente para pedid 00001? = Nã. Pdems ter apenas 1 cliente pr pedid, send assim este atribut é atômic únic para 1 pedid. Pdems ter utr vendedr para pedid 00001? = Nã. Pdems ter apenas 1 vendedr pr pedid. Pdems ter utr prdut para pedid 00001? = Sim. Pdems ter váris prduts para um pedid, send assim, s camps aninhads devem ser extraíds para utra tabela. Segunda Frma Nrmal Para estar na 2NF uma tabela deve (1) estar na 1NF e (2) tds s seus atributs que nã façam parte de alguma chave candidata devem ser determinads unicamente pr qualquer chave candidata da tabela. Se tdas as chaves candidatas de uma tabela cntiverem smente 1 atribut, esta já se encntra na 2NF.

8 Em utras palavras, se algum camp depender smente de parte de uma chave candidata cmpsta (e nã da chave cmpsta cm um td), entã este camp deve ser extraíd para utra tabela. A tabela abaix nã está na 2NF: ALUNOS_CURSOS = {ID_ALUNO + ID_CURSO + NOTA + DESCRICAO_CURSO} O prblema cnsiste n fat de que camp DESCRICAO_CURSO depende smente d camp ID_CURSO (apesar da chave ser cmpsta), que é parte da chave primária da tabela. Para que esta tabela esteja na 2NF, camp DESCRICAO_CURSO deve ser extraíd para utra tabela: ALUNOS_CURSOS = {ID_ALUNO + ID_CURSO + NOTA} CURSOS = {ID_CURSO + DESCRICAO} Terceira Frma Nrmal A terceira frma nrmal (3NF) exige que a tabela esteja em 2NF e que tds s atributs que nã sã chave sejam mutuamente independentes, ist é, que nã existam funções que definam um a utr. Prtant, sempre a chave pr inteir deve definir tda a tabela. Ist exige que atributs que nã dependem diretamente da chave sejam separads em uma tabela distinta. Em utras palavras, cas exista um u mais atributs que dependam de um atribut nãchave, estes atributs deverã ser extraíds para utra tabela. A tabela abaix nã está na 3NF: FUNCIONARIOS = {ID + NOME + ID_CARGO + DESCRICAO_CARGO} O prblema é que camp DESCRICAO_CARGO depende exclusivamente d camp ID_CARGO, que nã faz parte da chave da tabela. Para deixar esta tabela na 3NF, basta extrair camp para utra tabela: FUNCIONARIOS = {ID + NOME + ID_CARGO} CARGOS = {ID_CARGO + DESCRICAO} Observaçã imprtante: Muitas pessas cnfundem a 2NF cm a 3NF. Entretant, a 2NF príbe que determinads atributs dependam de parte de uma chave cmpsta, enquant que a 3NF príbe que determinads atributs dependam de atributs nãchave.