> For the complete documentation index, see [llms.txt](https://sena-ceet.gitbook.io/2252819-trimestre-2/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sena-ceet.gitbook.io/2252819-trimestre-2/base-de-datos/bases-de-datos/normalizacion-de-base-de-datos.md). # Normalización de base de datos {% embed url="" %} |


Forma normal

| Definido por | In | Breve definición | | | ------------------------ | ------------------------------- | ------------------------------------------------------- | ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1NF | Primera forma normal | Dos versiones: E.F. Codd (1970), C.J. fecha (2003) | 1970\[1] y 2003\[10] | El dominio de cada uno atributo contiene sólo atómico los valores y el valor de cada atributo contiene sólo un único valor de dicho dominio.\[11] | | 2NF | Segunda forma normal | E.F. Codd | 1971\[2] | Ningún atributo de primera en la tabla es funcionalmente dependientes en un subconjunto adecuado de cualquier clave de candidato | | 3NF | Tercera forma normal | Dos versiones: E.F. Codd (1971), C. Zaniolo (1982) | 1971\[2] y 1982\[12] | Cada atributo de primera es no transitivamente dependiente de cada clave candidata en la tabla. Se eliminan los atributos que no contribuyen a la descripción de la clave primaria de la tabla. En otras palabras, no está permitido ninguna dependencia transitiva. | | EKNF | Forma Normal de clave primaria | C. Zaniolo | 1982\[12] | Cada dependencia funcional no triviales en la tabla es la dependencia de un atributo clave primaria o dependencia de un superkey | | BCNF | Forma normal de Boyce-Codd | Boyce y E.F. Codd | 1974\[13] | Cada dependencia funcional no triviales en la tabla es una dependencia en una Superkey | | 4NF | Cuarta forma normal | Ronald Fagin | 1977\[14] | Cada no trivial dependencia multivalor en la tabla es una dependencia de un superkey | | 5NF | Quinta forma normal | Ronald Fagin | 1979\[15] | Cada no trivial Únete a dependencia en la tabla está implícito por los superkeys de la tabla | | DKNF | Forma normal dominio/clave | Ronald Fagin | 1981\[16] | Cada restricción sobre la mesa es un consecuencia lógica de las limitaciones de dominio y restricciones de clave de la tabla | | 6NF | Sexta forma normal | C.J. fecha, Hugh Darwen, y Nikos Lorentzos | 2002\[17] | Tabla no características dependencias unirse no trivial en absoluto (con referencia a operador de unir generalizada) | ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_5yU9Hek0Js16Ai_dF%2F-M_5z8sipwdy4VQ8KRzT%2Fimage.png?alt=media\&token=9f3e1524-3927-4c84-ab24-dc854562fd33) {% embed url="" %} {% embed url="" %} ## Primera forma normal (1NF, 1FN) {% embed url="" %} ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_5yU9Hek0Js16Ai_dF%2F-M_64ieGjcF_WYcVq5W-%2Fimage.png?alt=media\&token=a2fbaeba-49f7-48dd-8b58-6590774f9827) El anterior diseño rompe la primera forma normal por que los tres campos del teléfono tienen el mismo dominio por tal razón existe datos redundantes. Soluciones: es hace una relación uno a muchos ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_5yU9Hek0Js16Ai_dF%2F-M_65F2X6TbYppSWvaaI%2Fimage.png?alt=media\&token=75425b36-56de-4b07-aa33-1b934c65fce5) ## Segunda forma normal (2FN, 2NF) {% embed url="" %} ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_5yU9Hek0Js16Ai_dF%2F-M_66yTrbr-NvvXHuqjF%2Fimage.png?alt=media\&token=65af509d-e7f3-48d9-86ac-fda1f60933ac) nombres y apellidos dependen totalmente de (numero\_*documento y tipo*\_documento) y no parcialmente. ## Tercera Forma Normal (3NF, 3FN) {% embed url="" %} ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_5yU9Hek0Js16Ai_dF%2F-M_6Cgoat_mEqr6xUwWI%2Fimage.png?alt=media\&token=da25edde-db03-4a5e-9089-001d2c9496e5) Se rompe la tercera forma normal por que nombres y apellidos dependen funcionalmente de numero de documento y tipo de documento, además estos dos dependen transitivamente de el id. ## Forma Normal de Llave Elemental (EKNF) {% embed url="" %} ## Forma normal de Boyce-Codd {% embed url="" %} ## Cuarta forma normal {% embed url="" %} Considere el siguiente ejemplo: que no cumple la 4FN | Permutaciones de envíos de pizzas | | | | --------------------------------- | ----------------- | ------------- | | Restaurante | Variedad de Pizza | Área de envío | | Vincenzo's Pizza | Corteza gruesa | Springfield | | Vincenzo's Pizza | Corteza gruesa | Shelbyville | | Vincenzo's Pizza | Corteza fina | Springfield | | Vincenzo's Pizza | Corteza fina | Shelbyville | | Elite Pizza | Corteza fina | Capital City | | Elite Pizza | Corteza rellena | Capital City | | A1 Pizza | Corteza gruesa | Springfield | | A1 Pizza | Corteza gruesa | Shelbyville | | A1 Pizza | Corteza gruesa | Capital City | | A1 Pizza | Corteza rellena | Springfield | | A1 Pizza | Corteza rellena | Shelbyville | | A1 Pizza | Corteza rellena | Capital City | ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_6DBRLx49_L4onBaZz%2F-M_6TDEA6HB07rQIFNTG%2Fimage.png?alt=media\&token=b118e046-ab1d-44fb-840a-cd531928a91c) se arregla de de la siguiente forma: Para satisfacer la 4FN, debemos poner los hechos sobre las variedades de pizza ofrecidas en una tabla diferente de los hechos sobre áreas de envío: ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_6DBRLx49_L4onBaZz%2F-M_6USzjLwJAe2cj0A2e%2Fimage.png?alt=media\&token=b2047f12-4f0b-44ca-acd8-140a79808c56) En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de un área de envío a otra, la tabla original de la tres columnas satisfaría la 4FN. ![](https://2075084147-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MZGNM3do-IXXEttoVGo%2F-M_6DBRLx49_L4onBaZz%2F-M_6U0TBjQSRQh4-N8lq%2Fimage.png?alt=media\&token=b54b682f-0d95-4bc6-b7dd-854a099fd938) ## Forma normal de tupla esencial (Essential Tuple Normal Form, ETNF) {% embed url="." %} ## Forma normal de redundancia libre (redundancy free normal form, RFNF) Definition (redundancy per Vincent): Let relation r be a value of relvar R, let t be a tuple in r, and let v be an attribute value within t. Then that occurrence of v within t is redundant in r, and R is subject to redundancy, if and only if replacing that occurrence of v by an occurrence of v′ (v′ ≠ v), while leaving everything else unchanged, causes some dependency12 of R to be violated. ## Forma Normal de SuperClave (Superkey Normal Form, SKNF) Definition (superkey normal form): Relvar R is in superkey normal form (SKNF) if and only if, for every irreducible JD ☼{X1,...,Xn} that holds in R, each of X1, ..., Xn is a superkey for R. ## Quinta forma normal {% embed url="" %} ## Sexta Forma Normal (6FN, 6NF) {% embed url="" %}