WIXLIB

Normalizaçãode Bases de DadosBases de Dados (CC2005)Departamento de Ciência de ComputadoresFaculdade de Ciências da Universidade do PortoEduardo R. B. Marques — DCC/FCUP

IntroduçãoRequisitosDesenho ConceptualDesenho LógicoBom (“normal”)Modelo EREsquema relacionalcomosaber?comoacertar?Mau (“anormal”)Qual é o critério para aferir se o desenho de uma BD, expresso porum esquema relacional, é “bom” ou “mau”? E e for “mau”, comoacertá-lo?Um “mau” desenho tem “anomalias” (é “anormal”) que deveremosconseguir detectar de forma objectiva, e estas devem poder sereliminadas por um processo de normalização do esquema.Bases de DadosNormalização de Bases de Dados2

Princípios gerais para um bom desenhoPrincípios gerais:Uma tabela deve representar apenas um conceito do universo da BD,em correspondência a uma entidade ou um relacionamento entreentidades, e manter a informação completa associada a este.Informação de uma tabela não deve ser duplicada em outra, comexcepção da chave primária via referências por chaves externas.As tabelas devem relacionar-se apenas também via ligações chaveexterna/chave primária e não por outros atributos.Devemos evitar atributos que sejam NULL em um grande número de casos.A violação destes princípios leva geralmente a:a um significado semântico pouco claro do esquema da BD;anomalias em operações de dados e/ou inconsistências resultantes dasmesmasdesperdício e redundância no armazenamento;Bases de DadosNormalização de Bases de Dados3

“Maus exemplos”Mau stomerIdDurationStreamDateChargeRelação entre STREAM e MOVIE feitaa t r av é s d e T I T L E s e m r e l a ç ã oexpressa no esquema.Embora TITLE seja um atributo chaveem MOVIE, a chave primária éMovieId.Possível ambiguidade semântica:será que STREAM tem um título afinale não se relaciona com MOVIE ?!Anomalias na manipulação de dados: podemos por exemploalterar isoladamente MOVIE (actualizando o título, removendoentradas) ou CUSTOMER (usando um título de filme não existente)levando a inconsistência de dados e perda de informação.Duplicação do atributo Title.Bases de DadosNormalização de Bases de Dados4

“Maus exemplos” itleDurationCustomerIdStreamDateChargeBases de DadosMau desenho:Relação via chave externaagora OK, mas TITLE duplicadoRedundância de informação eanomalias do exemploanterior ainda possíveis,excepto no caso da remoçãode um filme.Possível ambiguidadesemântica mantém-se.Normalização de Bases de Dados5

“Maus exemplos” rBases de DadosSignificado semântico do esquema não é de todoclaro! COUNTRY corresponde a “duas entidades”:REGION “existe escondida” na tabela COUNTRY. Alémdisso, RegionManager depende na prática deRegionName mas o esquema não captura essadependência.Anomalias na manipulação de dados: podemosalterar RegionName sem qualquer restrição ouRegionManager de forma independente de RegionNamelevando a inconsistência dos dados.Mesmo que a consistência da BD de alguma formasobreviva às “intempéries” o esquema é tambémpouco económico em termos de espaço: RegionName eRegionManager são repetidos para vários países (aoinvés de um único atributo RegionId no esquema“bom”).Normalização de Bases de Dados6

“Maus exemplos” (cont.)STREAMStreamIdMovieIdVamos supor que:um cliente poderia atribuir opcionalmente uma valorização a umfilme reflectindo se gostou/não gostou de um filme ex. numaescala de 0 a 5 e também várias “tags” a um filme por exemploem texto separado por vírgulas como em 'classic, Hitchcock, thriller'.CustomerIdque estes dados são gravados na tabela STREAMStreamDateque grande parte dos clientes não atribuem “ratings” ou “tags”deixando esses atributos a NULL.ChargeRatingTagsBases de DadosProblemas:Demasiados registos com entradas NULL levam a desperdício deespaço.Dados de “ratings” e “tags” parecem depender do “stream” emvez do cliente o que seria mais natural: faz pouco sentido que omesmo cliente possa dar vários “ratings” diferentes para omesmo filme.“Ratings” e “tags” podem ser vistas como entidades que merecemexistência concreta na BD. Tags é também implicitamente umatributo multi-valor. Como definiríamos as correspondentestabelas ?Normalização de Bases de Dados7

Normalização / formas normaisProcesso que visa corrigir deficiências de umaesquema de BD por forma a transformá-lo numaforma normal.Uma forma normal tem associados:um conjunto de restrições que a definem;um processo de transformação de um esquema que nãoverifica a forma normal, recorrendo a decomposição e/outransformação de relações.Bases de DadosNormalização de Bases de Dados8

Formas normais (cont.)Formas normais, com restrições progressivamente maisfortes:1NF: 1ª forma normal (“1st Normal Form”)2NF: 2ª forma normal (“2nd Normal Form”)3NF: 3ª forma normal (“3rd Normal Form”)BCNF: Forma normal de Boyce–Codd (“Boyce-Codd NormalForm”)Formas normais mais fortes que BCNF (4NF, 5NF, 6NF, 7NF!)são normalmente pouco consideradas/práticas.Esquemas 3NF são quase sempre também BCNF.Iremos apenas falar de 1NF, 2NF e 3NF.Bases de DadosNormalização de Bases de Dados9

1NF - 1ª forma normalUma relação diz-se na 1ª forma normal se:tiver uma chave primária identificada;e todos os atributos de relações forem atómicos.Não são permitidos atributos que implicitamente codificam subatributos (atributos compostos) ou atributos multi-valor.Conversão para 1NF:Uma das chaves candidatas é escolhida para chave primária.Atributos multi-valor implícitos convertidos em novarelação com chave externa referindo a chave primária databela original.Cada atributo composto implícito é mapeado em vários subatributos atómicos.Bases de DadosNormalização de Bases de Dados10

Normalização 1NF — exemplo ChargeChargeRatingRatingTagsRelação original decomposta em duas em função do atributo“multi-valor” implícito.Bases de DadosNormalização de Bases de Dados11

Normalização 1NF — exemplo 2Suponha que numa empresa os empregados e respectiva dedicação aprojectos em nº de horas é representado por uma única relaçãoSTAFF(SId, SName, { Project(PId, PName, Hours) })STAFFSIdSName{ Project(PId, PName, Hours) }Exemplo de registos:Bases de DadosQuanto um atributo multi-valoré também composto, o atributorepresentada aquilo que sechama uma “relação imbricada”.(1, 'John Doe', { (1,'Proj A', 2), (2,'Proj B', 10) })(2, 'Maria Silva', { (1,'Proj A', 4), (3,'Proj C', 15) })(3, 'Manuel Silva', { (1, 'Proj B', 10 ) })(4, 'Alberto Silva', { (1,'Proj B', 4) } )Normalização de Bases de Dados12

Normalização 1NF — exemplo 2As seguintes 2 alternativas a STAFF(SId, SName, { Project(PId, PName, Hours) })estão na 1ª forma NamePNameHours(1, 1, ’John Doe','Proj A', 2)(1, 2, 'John Doe', 'Proj B', 10)(2, 1, ’Maria Silva’, 'Proj A', 4)(2, 3, 'Maria Silva', 'Proj C', 15) Bases de DadosPName(1, ’John Doe’)(2, ’Maria Silva’) Hours(1, 1,'Proj A', 2)(1, 2, 'Proj B', 10)(2, 1, 'Proj A', 4)(2, 3, 'Proj C', 15) Normalização de Bases de Dados13

Normalização 1NF — exemplo 2As seguintes 2 alternativas a STAFF(SId, SName, { Project(PId, PName, Hours) })estão na 1ª forma NamePNamePNameHoursHoursNenhuma é inteiramente satisfatória:Haverá muita redundância de informação nos dois casos.Em (1) uma só tabela mistura dados de duas entidades implícitas:empregado e projecto;Em (2) projecto não existe de forma independente da entidadefuncionário — não conseguimos por exemplo definir um projecto semempregados associados.Bases de DadosNormalização de Bases de Dados14

Dependência funcionalPara uma relação R, sendo X e Y sub-conjuntos nãovazios de atributos de R, dizemos que Y dependefuncionalmente de X ou que X determina Y, se:X Ydef r1, r2 R,r1[X] r2[X] r1[Y ] r2[Y ]Caso particular — uma chave (primária ou não) K de Rdetermina sempre qualquer sub-conjunto deatributos, isto é, X Attrs(R),Bases de DadosK XNormalização de Bases de Dados15

Dependências parciais, completas e transitivasUma dependência X Y é parcial se pudermosremover algum atributo A de X e o valor Y continuarfuncionalmente dependente de X - A A X :(X A) YCaso contrário a dependência diz-se completa: A X :(X A) YUma dependência X Y é transitiva se existir umatributo não-chave Y’ tal queX Y′ Y′ YBases de DadosNormalização de Bases de Dados16

Dependências funcionais — exemplos(1)STAFFSId SNameSIdPId PNamePIdSName{SId,PId} oursSTAFF.SId STAFF.SNamePROJECT.PId PROJECT.PName{ PROJECT.SId, PROJECT.PId} PROJECT.HoursAcima detalhamos apenas as dependências funcionais completas.Dependências parciais são irrelevantes na análise p/normalização2NF e 3NF discutido a seguir, ex:{ PROJECT.SId, PROJECT.PId} { PROJECT.PName }Bases de DadosNormalização de Bases de Dados17

Dependências funcionais — exemplos suma que para cada par filme-cliente nãodeverá haver mais do que um rating ouconjunto de “tags” correspondentes, mesmo queum filme possa ser visto mais do que uma vezpor um cliente.ChargeTemos as seguintes dependências funcionaiscompletas:RatingStreamId { MovieId, CustomerId, StreamDate, Charge}Tags{CustomerId, MovieId} {Rating, Tags} e a dependência transitiva:StreamId {CustomerId, MovieId} {Rating, Tags}Bases de DadosNormalização de Bases de Dados18

2ª Forma NormalUma relação R está na 2ª forma normal (2NF) se:1. R estiver na 1ª forma normal;2.nenhum atributo não-chave dependefuncionalmente de uma chave parcial, umsubconjunto estrito de uma chave da tabela(primária ou candidata).Normalização decomposição em relações tal queos atributos não-chave dependam apenas dechaves primárias.Bases de DadosNormalização de Bases de Dados19

Violação da 2NF — exemplos(1)STAFFSId SNameSIdPId PNamePIdSName{SId,PId} oursSTAFF.SId STAFF.SNamePROJECT.PId PROJECT.PName{ PROJECT.SId, PROJECT.PId} PROJECT.HoursEm ambos os casos temos uma chave parcial a determinar um atributonão chave — as dependências assinaladas a vermelho. Em (2) note queSTAFF está na 2ª forma normal mas PROJECT não.Bases de DadosNormalização de Bases de Dados20

Normalização 2NF — exemploSTAFFWORKS ONPROJECTSIdSIdPIdSNamePIdPNameHoursDecompondo PROJECT apropriadamente todas as relaçõesficam na 2ª forma normal. Note também que todas asdependências funcionais do esquema de partida sãopreservados.Bases de DadosNormalização de Bases de Dados21

Normalização 2NF — exemplos IdStreamDateChargeRatingStreamId { MovieId, CustomerId, StreamDate, Charge}{CustomerId, MovieId} {Rating}O esquema é 2NF, mas não expressa que o “rating” e as “tags” deveriamdepender apenas de { CustomerId , MovieId }Bases de DadosNormalização de Bases de Dados22

3ª Forma Normal (3NF)Uma relação está na 3ª forma normal (3NF) se:1. estiver na 2ª forma normal;2. nenhum atributo não-chave depender transitivamenteda chave primária.Exemplo 2NF anterior: STREAM não está na 3ª forma normalpois StreamId { MovieId, CustomerId } RatingPor outras palavras, em uma relação na 3ª forma normal todosos atributos dependem única e exclusivamente da chaveprimária.Normalização decomposição em relações tal que nenhumatributo não-chave dependa transitivamente da chavesprimária.Bases de DadosNormalização de Bases de Dados23

Normalização 3NF — mDateStreamDateChargeChargeRatingTagsStreamId { MovieId, CustomerId,StreamDate, Charge}{CustomerId, MovieId} {Rating, Tags}Bases de DadosRATINGCustomerIdMovieIdRatingNormalização de Bases de Dados24

Normalização 3NF — “mau treamDateChargeChargeRating{ Tags }StreamId { MovieId, CustomerId,StreamDate, Charge}{CustomerId, MovieId} {Rating, Tags}Bases de DadosRATINGStreamIdRatingEsquema 3NF não expressa adependência funcional:{CustomerId, MovieId} {Rating, Tags}Normalização de Bases de Dados25

ExemplosBases de DadosNormalização de Bases de Dados26