Está en la página 1de 33

INTRODUCCION___________________________________________________________5

NORMALIZACIÓN DE BASES DE DATOS____________________________________6

TERMINOLOGÍA RELACIONAL EQUIVALENTE_____________________________6

DEPENDENCIA____________________________________________________________7

DEPENDENCIA FUNCIONAL____________________________________________________7

PROPIEDADES DE LA DEPENDENCIA FUNCIONAL__________________________8

DEPENDENCIA FUNCIONAL REFLEXIVA____________________________________8

DEPENDENCIA FUNCIONAL AUMENTATIVA________________________________8

DEPENDENCIA FUNCIONAL TRANSITIVA___________________________________8

PROPIEDADES DEDUCIDAS________________________________________________9

CLAVES____________________________________________________________________9

FORMAS NORMALES______________________________________________________9

PRIMERA FORMA NORMAL_______________________________________________10

LAS TABLAS 1NF COMO REPRESENTACIONES DE RELACIONES____________10

GRUPOS REPETIDOS_____________________________________________________11

EJEMPLO 1: DOMINIOS Y VALORES______________________________________________11


EJEMPLO 2: GRUPOS REPETIDOS A TRAVÉS DE COLUMNAS____________________________12
EJEMPLO 3: REPETICIÓN DE GRUPOS DENTRO DE COLUMNAS__________________________12

UN DISEÑO CONFORME CON 1NF_________________________________________13

ATOMICIDAD____________________________________________________________13

SEGUNDA FORMA NORMAL______________________________________________14


EJEMPLO__________________________________________________________________15

2NF Y LAS CLAVES CANDIDATAS__________________________________________16

TERCERA FORMA NORMAL______________________________________________17

EJEMPLO__________________________________________________________________18

NORMALIZACIÓN MÁS ALLÁ DE LA 3NF__________________________________19

FORMA NORMAL DE BOYCE-CODD_______________________________________19

EJEMPLO__________________________________________________________________19

CUARTA FORMA NORMAL________________________________________________20

QUINTA FORMA NORMAL________________________________________________22

EJEMPLO__________________________________________________________________22

USO______________________________________________________________________24

FORMA NORMAL DE DOMINIO/CLAVE____________________________________24

REGLAS DE CODD________________________________________________________25

REGLA NO. 1 - LA REGLA DE LA INFORMACIÓN___________________________25

REGLA NO. 2 - LA REGLA DEL ACCESO GARANTIZADO____________________26

REGLA NO. 3 - TRATAMIENTO SISTEMÁTICO DE LOS VALORES NULOS_____26

REGLA NO. 4 - LA REGLA DE LA DESCRIPCIÓN DE LA BASE DE DATOS______26

REGLA NO. 5 - LA REGLA DEL SUB-LENGUAJE INTEGRAL__________________27

REGLA NO. 6 - LA REGLA DE LA ACTUALIZACIÓN DE VISTAS______________27

REGLA NO. 7 - LA REGLA DE INSERTAR Y ACTUALIZAR____________________27


REGLA NO. 8 - LA REGLA DE INDEPENDENCIA FÍSICA_____________________27

REGLA NO. 9 - LA REGLA DE INDEPENDENCIA LÓGICA____________________27

REGLA NO. 10 - LA REGLA DE LA INDEPENDENCIA DE LA INTEGRIDAD_____28

LAS REGLAS DE INTEGRIDAD____________________________________________28

REGLA NO. 11 - LA REGLA DE LA DISTRIBUCIÓN___________________________28

REGLA NO. 12 - REGLA DE LA NO-SUBVERSIÓN____________________________28

MODELO RELACIONAL__________________________________________________29

DESCRIPCIÓN____________________________________________________________29

ESQUEMA________________________________________________________________30

INSTANCIAS_____________________________________________________________30

BASE DE DATOS RELACIONAL____________________________________________30

DENORMALIZACIÓN (BASE DE DATOS)___________________________________31

CONCLUSION____________________________________________________________33
INTRODUCCION

Siempre que un analista de sistemas de base de datos arma una base de datos, queda a
su cargo descomponer dicha base en grupos y segmentos de registros. Este proceso es
la descomposición; el mismo es necesario independientemente de la arquitectura de la
base de datos - relacional, red o jerárquica-. Sin embargo, para la base de datos
relacional, la acción correspondiente puede dividirse y expresarse en términos
formales y se denomina normalización a la misma.

La normalización convierte una relación en varias sub-relaciones, cada una de las


cuales obedece a reglas. Estas reglas se describen en términos de dependencia. Una
vez que hayamos examinado las distintas formas de dependencia, encontraremos
procedimientos a aplicar a las relaciones de modo tal que las mismas puedan
descomponerse de acuerdo a la dependencia que prevalece. Esto no llevará
indefectiblemente a formar varias subrelaciones a partir de la única relación
preexistente.
Normalización de bases de datos

El proceso de normalización de bases de datos consiste en aplicar una serie de


reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo
relacional.

Las bases de datos relacionales se normalizan para:

 Evitar la redundancia de los datos.


 Evitar problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una
tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

 Cada columna debe tener su nombre único.


 No puede haber dos filas iguales. No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.

Terminología relacional equivalente

Figura 1.0: Trabajo (Código, Nombre, Posición, Salario), donde Código es la Clave
Primaria
 Relación = tabla o archivo
 Tupla = registro, fila o renglón
 Atributo = campo o columna
 Clave = llave o código de identificación
 Clave Candidata = superclave mínima
 Clave Primaria = clave candidata elegida
 Clave Ajena = clave externa o clave foránea
 Clave Alternativa = clave secundaria
 Dependencia Multivaluada = dependencia multivalor
 RDBMS = Del inglés Relational Data Base Manager System que significa,
Sistema Gestor de Bases de Datos Relacionales.
 1FN = Significa, Primera Forma Normal o 1NF del ingles First Normal
Form.

Los términos Relación, Tupla y Atributo derivan de las matemáticas relacionales, que
constituyen la fuente teórica del modelo de base de datos relacional.

Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de valores
que el mismo puede tomar. Una instancia de una tabla puede verse entonces como un
subconjunto del producto cartesiano entre los dominios de los atributos. Sin embargo,
suele haber algunas diferencias con la analogía matemática, dado que algunos
RDBMS permiten filas duplicadas, entre otras cosas. Finalmente, una tupla puede
razonarse matemáticamente como un elemento del producto cartesiano entre los
dominios.

Dependencia

Dependencia funcional

B es funcionalmente dependiente de A.

Una dependencia funcional es una conexión entre uno o más atributos. Por ejemplo si
conocemos el valor de FechaDeNacimiento podemos conocer el valor de Edad.

Las dependencias funcionales del sistema se escriben utilizando una flecha, de la


siguiente manera:

FechaDeNacimiento -> Edad

Aquí a FechaDeNacimiento se le conoce como un determinante. Se puede leer de dos


formas FechaDeNacimiento determina a Edad o Edad es funcionalmente dependiente
de FechaDeNacimiento. De la normalización (lógica) a la implementación (física o
real) puede ser sugerible tener éstas dependencias funcionales para lograr mayor
eficiencia en las tablas.
Propiedades de la Dependencia funcional

Existen 3 axiomas de Armstong:

Dependencia funcional Reflexiva

Si y esta incluido en x entonces x->y

Si la dirección o el nombre de una persona estan incluidos en el dni, entonces con el


dni podemos determinar la dirección o su nombre.

Dependencia funcional Aumentativa

x->y entonces xz->yz

dni -> nombre

dni,dirección -> nombre,dirección

Si con el dni se determina el nombre de una persona, entonces con el dni más la
dirección también se determina el nombre o su dirección.

Dependencia funcional transitiva

Dependencia funcional transitiva.

FechaDeNacimiento -> Edad

Edad -> Conducir

FechaDeNacimiento -> Edad -> Conducir

Entonces tenemos que FechaDeNacimiento determina a Edad y la Edad determina a


Conducir, indirectamente podemos saber a través de FechaDeNacimiento a Conducir
(En muchos paises , para una persona poder conducir un automovil la persona
necesita ser mayor de X edad, por eso se utiliza este ejemplo).
Propiedades deducidas

Union

x->y y x->z entonces x->yz

Pseudo-transitiva

x->y y wy->z entonces wx->z

Descomposición

x->y y z esta incluido en y entonces x->z

Claves
Una clave primaria es aquella columna (pueden ser también dos columnas o más)
que identifica únicamente a esa fila. La clave primaria es un identificador que va a ser
único para cada fila. Se acostumbra poner la clave primaria como la primera columna
de la tabla pero esto no tiene que ser necesario, si no es más una conveniencia.
Muchas veces la clave primaria es autonumérica.

En una tabla puede que tengamos más de una clave, en tal caso se puede escoger una
para ser la clave primaria, las demas claves son las claves candidatas.ademas es la
posible clave primaria.

Una clave foránea es aquella columna que existiendo como dependiente en una tabla,
es a su vez clave primaria en otra tabla.

Una clave alternativa es aquella clave candidata que no ha sido seleccionada como
clave primaria, pero que también puede identificar de forma unica a una fila dentro de
una tabla.

Una clave compuesta es una clave que está compuesta por más de una columna.

Formas Normales

Las formas normales son aplicadas a las tablas de una base de datos, decir que una
base de datos está en la forma normal N es decir que todas sus tablas están en la
forma normal N.
En general, las primeras tres formas normales son suficientes para cubrir las
necesidades de la mayoría de las bases de datos. El creador de estas 3 primeras
formas normales (o reglas) fue Edgar F. Codd.[1]

Primera forma normal

La primera forma normal (1NF o forma mínima) es una forma normal usada en
normalización de bases de datos. Una tabla de base de datos relacional que se adhiere
a la 1NF es una que satisface cierto conjunto mínimo de criterios. Estos criterios se
refieren básicamente a asegurarse que la tabla es una representación fiel de una
relación[1] y está libre de "grupos repetitivos".[2]

Sin embargo, el concepto de "grupo repetitivo", es entendido de diversas maneras por


diferentes teóricos. Como una consecuencia, no hay un acuerdo universal en cuanto a
qué características descalificarían a una tabla de estar en 1NF. Muy notablemente, la
1NF, tal y como es definida por algunos autores excluye "atributos relación-valor"
(tablas dentro de tablas) siguiendo el precedente establecido por E.F. Codd) (algunos
de esos autores son: Ramez Elmasri y Shamkant B. Navathe [3] ). Por otro lado, según
lo definido por otros autores, la 1NF sí los permite (por ejemplo como la define Chris
Date).

Las tablas 1NF como representaciones de relaciones

Según la definición de Date de la 1NF, una tabla está en 1NF si y solo si es "isomorfa
a alguna relación", lo que significa, específicamente, que satisface las siguientes
cinco condiciones:

1. No hay orden de arriba-a-abajo en las filas.


2. No hay orden de izquierda-a-derecha en las columnas.
3. No hay filas duplicadas.
4. Cada intersección de fila-y-columna contiene exactamente un valor del
dominio aplicable (y nada más).
5. Todas las columnas son regulares [es decir, las filas no tienen componentes
como IDs de fila, IDs de objeto, o timestamps ocultos].
—Chris Date, "What First Normal Form Really Means", pp. 127-8[4]

La violación de cualesquiera de estas condiciones significaría que la tabla no es


estrictamente relacional, y por lo tanto no está en 1NF. Algunos ejemplos de tablas (o
de vistas) que no satisface esta definición de 1NF son:

 Una tabla que carece de una clave primaria. Esta tabla podría acomodar filas
duplicadas, en violación de la condición 3.
 Una vista cuya definición exige que los resultados sean retornados en un
orden particular, de modo que el orden de la fila sea un aspecto intrínseco y
significativo de la vista.[5] Esto viola la condición 1. Las tuplas en relaciones
verdaderas no están ordenados con respecto a una de la otra.
 Una tabla con por lo menos un atributo que pueda ser nulo. Una atributo que
pueda ser nulo estaría en violación de la condición 4, que requiere a cada
campo contener exactamente un valor de su dominio de columna. Sin
embargo, debe ser observado que este aspecto de la condición 4 es
controvertido. Muchos autores consideran que una tabla está en 1FN si
ninguna clave candidata puede contener valores nulos, pero se aceptan éstos
para atributos (campos) que no sean clave, según el modelo original de Codd
sobre el modelo relacional, el cual hizo disposición explícita para los nulos.[6]

Grupos repetidos

La cuarta condición de Date, que expresa "lo que la mayoría de la gente piensa como
la característica que define la 1NF",[7] concierne a grupos repetidos. El siguiente
ejemplo ilustra cómo un diseño de base de datos puede incorporar la repetición de
grupos, en violación de la 1NF.

Ejemplo 1: Dominios y valores

Suponga que un diseñador principiante desea guardar los nombres y los números
telefónicos de los clientes. Procede a definir una tabla de cliente como la que sigue:

Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659
789 Maria Fernandez 555-808-9633

En este punto, el diseñador se da cuenta de un requisito debe guardar múltiples


números teléfonicos para algunos clientes. Razona que la manera más simple de hacer
esto es permitir que el campo "Teléfono" contenga más de un valor en cualquier
registro dado:

Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
555-403-1659
456 James Wright
555-776-4100
789 Maria Fernandez 555-808-9633
Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de
dominio de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres
de longitud), la representación de arriba no está en 1NF. La 1NF (y, para esa materia,
el RDBMS) prohíbe a un campo contener más de un valor de su dominio de columna.

Ejemplo 2: Grupos repetidos a través de columnas

El diseñador puede evitar esta restricción definiendo múltiples columnas del número
telefónico:

Cliente
ID Cliente Nombre Apellido Teléfono 1 Teléfono 2 Teléfono 3
123 Osvaldo Ingram 555-861-2025
456 James Wright 555-403-1659 555-776-4100
789 Maria Fernandez 555-808-9633

Sin embargo, esta representación hace uso de columnas que permiten valores nulos, y
por lo tanto no se conforman con la definición de la 1NF de Date. Incluso si se
contempla la posibilidad de columnas con valores nulos, el diseño no está en armonía
con el espíritu de 1NF. Teléfono 1, Teléfono 2, y Teléfono 3, comparten exactamente
el mismo dominio y exactamente el mismo significado; el dividir del número de
teléfono en tres encabezados es artificial y causa problemas lógicos. Estos problemas
incluyen:

 Dificultad en hacer consultas a la tabla. Es difícil contestar preguntas tales


como "¿Qué clientes tienen el teléfono X?" y "¿Qué pares de clientes
comparten un número de teléfono?".
 La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Teléfono
por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un
valor para el Teléfono 2 que es exactamente igual que el valor de su Teléfono
1.
 La restricción de los números de teléfono por cliente a tres. Si viene un cliente
con cuatro números de teléfono, estamos obligados a guardar solamente tres y
dejar el cuarto sin guardar. Esto significa que el diseño de la base de datos está
imponiendo restricciones al proceso del negocio, en vez de (como idealmente
debe ser el caso) al revés.

Ejemplo 3: Repetición de grupos dentro de columnas

El diseñador puede, alternativamente, conservar una sola columna de número de


teléfono, pero alterando su dominio, haciendo una cadena de suficiente longitud para
acomodar múltiples números telefónicos:

Cliente
ID Cliente Nombre Apellido Teléfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1659, 555-776-4100
789 Maria Fernandez 555-808-9633

Éste es defendiblemente el peor diseño de todos, y otra vez no mantiene el espíritu de


la 1NF. El encabezado "Teléfono" llega a ser semánticamente difuso, ya que ahora
puede representar, o un número de teléfono, o una lista de números de teléfono, o de
hecho cualquier cosa. Una consulta como "¿Qué pares de clientes comparten un
número telefónico?" es virtualmente imposible de formular, dada la necesidad de
proveerse de listas de números telefónicos así como números telefónicos individuales.
Con este diseño en la RDBMS, son también imposibles de definir significativas
restricciones en números telefónicos.

Un diseño conforme con 1NF

Un diseño que está inequívocamente en 1NF hace uso de dos tablas: una tabla de
cliente y una tabla de teléfono del cliente.

Cliente
ID Cliente Nombre Apellido
123 Rachel Ingram
456 James Wright
789 Maria Fernandez
Teléfono del cliente
ID Cliente Teléfono
123 555-861-2025
456 555-403-1659
456 555-776-4100
789 555-808-9633

En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso,


cada enlace Cliente-a-Teléfono aparece en su propio registro.

Atomicidad

Algunas definiciones de 1NF, más notablemente la de E.F. Codd, hacen referencia al


concepto de atomicidad. Codd indica que "se requiere que los valores sean atómicos
con respecto al DBMS en los dominios en los que cada relación es definida". [8] Codd
define un valor atómico como uno que "no puede ser descompuesto en pedazos más
pequeños por el DBMS (excepto ciertas funciones especiales)".[9]
Hugh Darwen y Chris Date han sugerido que el concepto de Codd de un "valor
atómico" es ambiguo, y que esta ambigüedad ha conducido a una extensa confusión
sobre cómo debe ser entendida la 1NF.[10] [11] En particular, la noción de un "valor que
no puede ser descompuesto" es problemática, pues parecería implicar que pocos, si
algún, tipos de datos son atómicos:

 Una cadena de caracteres parecería no ser atómica, ya que el RDBMS


típicamente proporciona operadores para descomponerla en subcadenas.
 Una fecha parecería no ser atómica, ya que el RDBMS proporciona
típicamente operadores para descomponerla los componentes de día, mes, y
año.
 Un número de punto fijo parecería no ser atómico, ya que el RDBMS
proporciona típicamente operadores para descomponerlo en componentes de
números enteros y fraccionarios.

Date sugiere que "la noción de atomicidad no tiene ningún significado absoluto":[12]
un valor puede ser considerado atómico para algunos propósitos, pero puede ser
considerado un ensamblaje de elementos más básicos para otros propósitos. Si esta
posición es aceptada, la 1NF no puede ser definida con referencia a la atomicidad.
Las columnas de cualquier tipo de datos concebible (desde tipos de cadenas y tipos
numéricos hasta tipos de arreglos y tipos de tabla) son entonces aceptables en un tabla
1NF - aunque quizás no siempre deseable. Date discute que los atributos relación-
valor, por medio de los cuales un campo dentro de una tabla puede contener una
tabla, son útiles en casos raros.[13

Segunda forma normal

La segunda forma normal (2NF) es una forma normal usada en normalización de


bases de datos. La 2NF definida originalmente por E.F. Codd[1] en 1971. Una tabla
que está en la primera forma normal (1NF) debe satisfacer criterios adicionales para
calificar para la segunda forma normal. Específicamente: una tabla 1NF está en 2NF
si y solo si, dada cualquier clave candidata y cualquier atributo que no sea un
constituyente de la clave candidato, el atributo no clave depende de toda la clave
candidata en vez de solo una parte de ella.

En términos levemente más formales: una tabla 1NF está en 2NF si y solo si ninguno
de sus atributos no-principales son funcionalmente dependientes en una parte
(subconjunto apropiado) de una clave candidata. (Un atributo no-principal de A es
uno que no pertenece a ninguna clave candidato).

Observe que cuando una tabla 1NF no tiene ninguna clave candidato compuesta
(claves candidato consistiendo en más de un atributo), la tabla está automáticamente
en 2NF.
Ejemplo
Considere una tabla describiendo las habilidades de los empleados:

Habilidades de los empleados


Empleado Habilidad Lugar actual de trabajo
Jones Mecanografía 114 Main Street
Jones Taquigrafía 114 Main Street
Jones Tallado 114 Main Street
Roberts Limpieza ligera 73 Industrial Way
Ellis Alquimia 73 Industrial Way
Ellis Malabarismo 73 Industrial Way
Harrison Limpieza ligera 73 Industrial Way

La única clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente en solo parte de la clave


candidata, llamada Empleado. Por lo tanto la tabla no está en 2NF. Observe la
redundancia de la manera en que son representadas los Lugares actuales de trabajo:
nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis
trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable anomalías
de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en
sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado".
Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el
lugar actual de trabajo de Jones?".

Un alternativa 2NF a este diseño representaría la misma información en dos tablas:

Empleados
Empleado Lugar actual de trabajo
Jones 114 Main Street
Roberts 73 Industrial Way
Ellis 73 Industrial Way
Harrison 73 Industrial Way
Habilidades de los empleados
Empleado Habilidad
Jones Mecanografía
Jones Taquigrafía
Jones Tallado
Roberts Limpieza ligera
Ellis Alquimia
Ellis Malabarismo
Harrison Limpieza ligera

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en
2NF.

Sin embargo, no todas las tablas 2NF están libres de anomalías de actualización. Un
ejemplo de una tabla 2NF que sufre de anomalías de actualización es:

Ganadores del torneo


Torneo Año Ganador Fecha de nacimiento del ganador
Des Moines Masters 1998 Chip Masterson 14 de marzo de 1977
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por


una clave completa {Torneo, Año} y no son partes de ella, particularmente las
combinaciones Ganador / Fecha de nacimiento del ganador son mostradas
redundantemente en múltiples registros. Este problema es tratado por la tercera forma
normal (3NF).

2NF y las claves candidatas

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria
está típicamente, pero no siempre, en 2NF. Además de la clave principal, la tabla
puede contener otras claves candidatas; es necesario establecer que ningún atributo
no-principal tienen dependencias de clave parciales en cualesquiera de estas claves
candidato.

Las múltiples claves candidato ocurren en la siguiente tabla:

Modelos eléctricos de cepillo de dientes


Fabricante Modelo Nombre completo del modelo País del fabricante
Forte X-Prime Forte X-Prime Italia
Forte Ultraclean Forte Ultraclean Italia
Dent-o-Fresh EZBrush Dent-o-Fresh EZBrush USA
Kobayashi ST-60 Kobayashi ST-60 Japón
Hoch Toothmaster Hoch Toothmaster Alemania
Hoch Contender Hoch Contender Alemania

Aun si el diseñador ha especificado la clave principal como {Nombre completo del


modelo}, la tabla no está en 2NF. {fabricante, modelo} es también una clave
candidato, y País del fabricante es dependiente en un subconjunto apropiado de él:
Fabricante.

Tercera forma normal

La tercera forma normal (3NF) es una forma normal usada en la normalización de


bases de datos. La 3NF fue definida originalmente por E.F. Codd[1] en 1971. La
definición de Codd indica que una tabla está en 3NF si y solo si las dos condiciones
siguientes se mantienen:

 La tabla está en la segunda forma normal (2NF)


 Ningún atributo no-primario de la tabla es dependiente transitivamente en una
clave candidata

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidato.


Una dependencia transitiva es una dependencia funcional X → Z en la cual Z no es
inmediatamente dependiente de X, pero sí de un tercer conjunto de atributos Y, que a
su vez depende de X. Es decir, X → Z por virtud de X → Y y Y → Z.

Una formulación alternativa de la definición de Codd, dada por Carlo Zaniolo [2] en
1982, es ésta: Una tabla está en 3NF si y solo si, para cada una de sus dependencias
funcionales X → A, por lo menos una de las condiciones siguientes se mantiene:

 X contiene A, ó
 X es una superclave, ó
 A es un atributo primario (es decir, A está contenido dentro de una clave
candidato)

La definición de Zaniolo tiene la ventaja de dar un claro sentido de la diferencia entre


la 3NF y la más rigurosa forma normal de Boyce-Codd (BCNF). La BCNF
simplemente elimina la tercera alternativa ("A es un atributo primario").

Ejemplo

Un ejemplo de una tabla 2NF que falla en satisfacer los requisitos de la 3NF es:

Ganadores del torneo


Torneo Año Ganador Fecha de nacimiento del ganador
Indiana Invitational 1998 Al Fredrickson 21 de julio de 1975
Cleveland Open 1999 Bob Albertson 28 de septiembre de 1968
Des Moines Masters 1999 Al Fredrickson 21 de julio de 1975
Indiana Invitational 1999 Chip Masterson 14 de marzo de 1977

La única clave candidato es {Torneo, Año}.

La violación de la 3NF ocurre porque el atributo no primario Fecha de nacimiento


del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no
primario Ganador. El hecho de que la Fecha de nacimiento del ganador es
funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias
lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes
fechas de nacimiento en diversos registros.

Para expresar los mismos hechos sin violar la 3NF, es necesario dividir la tabla en
dos:

Ganadores del torneo


Torneo Año Ganador
Indiana Invitational 1998 Al Fredrickson
Cleveland Open 1999 Bob Albertson
Des Moines Masters 1999 Al Fredrickson
Indiana Invitational 1999 Chip Masterson
Fecha de nacimiento del jugador
Jugador Fecha de nacimiento
Chip Masterson 14 de marzo de 1977
Al Fredrickson 21 julio de 1975
Bob Albertson 28 septiembre de 1968

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en
3NF.

Normalización más allá de la 3NF

La mayoría de las tablas 3NF están libres anomalías de actualización, inserción, y


borrado. Ciertos tipos de tablas 3NF, que en la práctica raramente se encuentran, son
afectadas por tales anomalías; éstas son tablas que no satisfacen la forma normal de
Boyce-Codd (BCNF) o, si satisfacen la BCNF, son insuficientes para satisfacer las
formas normales más altas 4NF o 5NF.
Forma normal de Boyce-Codd
La Forma Normal de Boyce-Codd (o FNBC) es una forma normal utilizada en la
normalización de bases de datos. Es una versión ligeramente más fuerte de la Tercera
forma normal (3FN). La forma normal de Boyce-Codd requiere que no existan
dependencias funcionales no triviales de los atributos que no sean un conjunto de la
clave candidata. En una tabla en 3FN, todos los atributos dependen de una clave, de
la clave completa y de ninguna otra cosa excepto de la clave (excluyendo
dependencias triviales, como ). Se dice que una tabla está en FNBC si y solo
si está en 3FN y cada dependencia funcional no trivial tiene una clave candidata
como determinante. En terminos menos formales, una tabla está en FNBC si está en
3FN y los únicos determinantes son claves candidatas.

Ejemplo
Solamente en casos raros una tabla en 3NF no satisface los requerimientos de la
BCNF. Un ejemplo de tal tabla es (teniendo en cuenta que cada estudiante puede
tener más de un tutor):

Referencia cruzada de Tutor/Estudiante


ID Tutor Número de seguro social del tutor ID Estudiante
1078 088-51-0074 31850
1078 088-51-0074 37921
1293 096-77-4146 46224
1480 072-21-2223 31850

El propósito de la tabla es mostrar qué tutores están asignados a qué estudiantes. Las
claves candidatas de la tabla son:

 {ID Tutor, ID Estudiante}


 {Número de seguro social del tutor, ID Estudiante}

Por lo tanto los tres atributos de la tabla son atributos primarios, es decir, los tres
atributos pertenecen a las claves candidatas.

Recuerde que la 2NF prohíbe dependencias funcionales parciales de atributos no-


primarios en las claves candidatas, y la 3NF prohíbe dependencias funcionales
transitivas de atributos no-primarios en claves candidatas. Dado que la tabla de arriba
carece de cualquier atributo no-primario, está en 2NF y 3NF.

La FNBC es más rigurosa que la 3NF en que no permite ninguna dependencia


funcional en la cual el conjunto determinante de atributos no sea una clave candidato
(o superconjunto de eso). La dependencia de ID Tutor en Número de seguro social
del tutor es ese tipo de dependencia. Por consiguiente, la tabla de arriba no está en
FNBC

Cualquier tabla que sea insuficiente en FNBC será vulnerable a inconsistencias


lógicas. En la tabla de arriba podía ser representada una combinación inconsistente de
ID Tutor y Número de seguro social del tutor.

En este caso, corregir el problema sería una simple cuestión de usar solo un esquema
de identificación para los tutores: o el ID, o el número del seguro social, pero no
ambos.

Cuarta forma normal

La cuarta forma normal (4NF) es una forma normal usada en la normalización de


bases de datos. La 4NF se asegura de que los hechos multivalores independientes
estén correcta y eficientemente representados en un diseño de base de datos. La 4NF
es el siguiente nivel de normalización después de la forma normal de Boyce-Codd
(BCNF).

La definición de la 4NF confía en la noción de una dependencia multivalor. Una tabla


con una dependencia multivalor es una donde la existencia de dos o más relaciones
independientes muchos a muchos causa redundancia; y es esta redundancia la que es
removida por la cuarta forma normal.

Considere el siguiente ejemplo:

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
Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a
un área dada.

Note que debido a que la tabla tiene una clave única y ningún atributo no-clave, no
viola ninguna forma normal hasta el BCNF. Pero debido a que las variedades de pizza
que un restaurante ofrece son independientes de las áreas a las cuales el restaurante
envía, hay redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza
ofrece la Corteza rellena, y si A1 Pizza comienza a producir pizzas de Corteza de
queso entonces necesitaremos agregar múltiples registros, uno para cada una de las
Áreas de envío de A1 Pizza. En términos formales, esto se describe como que
Variedad de pizza está teniendo una dependencia multivalor en Restaurante.

Para satisfacer la 4NF, debemos poner los hechos sobre las variedades de pizza
ofrecidas en una tabla diferente de los hechos sobre áreas de envío:

Variedades por restaurante


Restaurante Variedad de pizza
Vincenzo's Pizza Corteza gruesa
Vincenzo's Pizza Corteza fina
Elite Pizza Corteza fina
Elite Pizza Corteza rellena
A1 Pizza Corteza gruesa
A1 Pizza Corteza rellena
Áreas de envío por restaurante
Restaurante Área de envío
Vincenzo's Pizza Springfield
Vincenzo's Pizza Shelbyville
Elite Pizza Capital City
A1 Pizza Springfield
A1 Pizza Shelbyville
A1 Pizza Capital City

En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran


de una área de envío a otra, la tabla original de la tres columnas satisfaría la 4NF.

Ronald Fagin demostró que es siempre posible alcanzar la 4NF (pero no siempre
deseable). El teorema de Rissanen es también aplicable en dependencias multivalor.

Quinta forma normal

La quinta forma normal (5NF), también conocida como forma normal de


proyección-unión (PJ/NF), es un nivel de normalización de bases de datos
designado para reducir redundancia en las bases de datos relacionales que guardan
hechos multi-valores aislando semánticamente relaciones múltiples relacionadas. Una
tabla se dice que está en 5NF si y solo si está en 4NF y cada dependencia de unión
(join) en ella es implicada por las claves candidato.

Ejemplo

Considere el siguiente ejemplo:

Psiquiatra-para-Asegurador-para-Condición
Psiquiatra Asegurador Condición
Dr. James Healthco Ansiedad
Dr. James Healthco Depresión
Dr. Kendrick FriendlyCare OCD
Dr. Kendrick FriendlyCare Ansiedad
Dr. Kendrick FriendlyCare Depresión
Dr. Lowenstein FriendlyCare Esquizofrenia
Dr. Lowenstein Healthco Ansiedad
Dr. Lowenstein Healthco Demencia
Dr. Lowenstein Victorian Life Trastorno de conversión

El psiquiatra puede ofrecer tratamiento reembolsable a los pacientes que sufren de la


condición dada y que son asegurados por el asegurador dado. En ausencia de
cualquier regla que restrinja las combinaciones válidas posibles de psiquiatra,
asegurador, y condición, la tabla de tres atributos Psiquiatra-para-Asegurador-para-
Condición es necesaria para modelar la situación correctamente.

Sin embargo, suponga que la regla siguiente se aplica:

Cuando un psiquiatra es autorizado a ofrecer el tratamiento reembolsable a


los pacientes asegurados por el asegurador P, y el psiquiatra puede tratar la
condición C, entonces - en caso que el asegurador P cubra la condición C -
debe ser cierto que el psiquiatra puede ofrecer el tratamiento reembolsable a
los pacientes que sufren de la condición C y están asegurados por el
asegurador P.

Con estas restricciones es posible dividir la relación en tres partes.

Psiquiatra-para-Condición Psiquiatra-para- Asegurador-para-Condición


Psiquiatra Condición Asegurador Asegurador Condición
Dr. James Ansiedad Psiquiatra Asegurador Healthco Ansiedad
Dr. James Depresión Dr. James Healthco Healthco Depresión
Dr. OCD Dr. Healthco Demencia
FriendlyCare
Kendrick
Kendrick
Dr.
Ansiedad
Kendrick
Dr. FriendlyCare OCD
Depresión
Kendrick
Dr. FriendlyCare Ansiedad
Dr. Trastorno FriendlyCare
Lowenstein FriendlyCare Depresión
Kendrick emocional
Dr. Trastorno
Dr. Healthco FriendlyCare
Esquisofrenia Lowenstein emocional
Lowenstein
Dr. Victorian FriendlyCare Esquisofrenia
Dr.
Ansiedad Lowenstein Life Victorian Trastorno de
Lowenstein
Life conversión
Dr.
Demencia
Lowenstein
Dr. Trastorno de
Lowenstein conversión

Note como esta disposición ayuda a quitar redundancia. Suponga que el Dr. James se
convierte en un proveedor de tratamientos para FriendlyCare. En la disposición
anterior tendríamos que agregar dos nuevas entradas puesto que el Dr. James puede
tratar dos condiciones cubiertas por FriendlyCare: ansiedad y depresión. Con la nueva
disposición necesitamos agregar una sola entrada (en la tabla Psiquiatra-para-
Asegurador).

Uso

Solamente en raras situaciones una tabla 4NF no se conforma con la 5NF. Éstas son
situaciones en las cuales un complejo constreñimiento del mundo real gobernando las
combinaciones válidas de los valores de atributos en la tabla 4NF no es implícito en
la estructura de esa tabla. Si esa tabla no se normaliza a 5NF, la carga de mantener la
consistencia lógica de los datos dentro de la tabla debe ser llevada en parte por la
aplicación responsable de inserciones, borrados, y actualizaciones a ella; y hay un
aumentado riesgo que los datos dentro de la tabla se volverán inconsistentes. En
contraste, el diseño 5NF excluye la posibilidad de tales inconsistencias.

Forma normal de dominio/clave


La forma normal de dominio/clave (DKNF) es una forma normal usada en
normalización de bases de datos que requiere que la base de datos no contenga
ninguna restricción con excepción de restricciones de dominios y de claves.

Un constreñimiento del dominio especifica los valores permitidos para un atributo


dado, mientras que un constreñimiento de la clave especifica los atributos que
identifican únicamente una fila en una tabla dada.

La forma normal de dominio/clave es el Santo Grial del diseño de base de datos


relacional[cita requerida], alcanzado cuando cada constreñimiento en la relación es una
consecuencia lógica de la definición de claves y dominios, y, haciendo cumplir las
restricciones y condiciones de la clave y del dominio, causa que sean satisfechas
todas las restricciones. Así, esto evita todas las anomalías no-temporales.

Es mucho más fácil construir una base de datos en forma normal de dominio/clave
que convertir pequeñas bases de datos que puedan contener numerosas anomalías. Sin
embargo, construir con éxito una base de datos en forma normal de dominio/clave
sigue siendo una tarea difícil, incluso para programadores experimentados de bases
de datos. Así, mientras que la forma normal de dominio/clave elimina los problemas
encontrados en la mayoría de las bases de datos, tiende para ser la forma normal más
costosa de alcanzar. Sin embargo, el no poder alcanzar la forma normal de
dominio/clave puede llevar costos ocultos a largo plazo, debido a anomalías que
aparecen con el tiempo en las bases de datos que solamente se adhieren a formas
normales más bajas.

Una violación de DKNF ocurre en la siguiente tabla:

Persona rica
Persona rica Tipo de persona rica Valor neto en dólares
Steve Millonario excéntrico 124,543,621
Roderick Multimillonario malvado 6,553,228,893
Katrina Multimillonario excéntrico 8,829,462,998
Gary Millonario malvado 495,565,211

Asuma que el dominio para la 'Persona rica consiste en los nombres de toda la gente
rica en una muestra predefinida de gente rica; el dominio para el Tipo de persona rica
consiste de los valores 'Millonario excéntrico', 'Multimillonario excéntrico',
'Millonario malvado', y 'Multimillonario malvado'; y el dominio para el Valor neto en
dólares consiste de todos los números enteros mayor que o igual a 1.000.000.

Hay un constreñimiento que liga el Tipo de persona rica al Valor neto en dólares,
incluso aunque no podemos deducir uno del otro. El constreñimiento dicta que un
Millonario excéntrico o Millonario malvado tendrá un valor neto de 1.000.000 a
999.999.999 inclusive, mientras que un Multimillonario excéntrico o un
Multimillonario malvado tendrá un valor neto de 1.000.000.000 o más. Este
constreñimiento no es ni un constreñimiento de dominio ni un constreñimiento de
clave; por lo tanto no podemos confiar en los constreñimientos de dominio y los
constreñimientos de clave para garantizar que una combinación de anómala de Tipo
de persona rica / Valor neto en dólares no tenga cabida en la base de datos.

La violación de la DKNF podría ser eliminada alterando dominio Tipo de persona


rica para hacer que sea consistente con solo dos valores, 'Malvado' y 'Excéntrico' (el
estatus de persona rica como un millonario o un multimillonario es implícito en su
Valor neto en dólares, así que no se pierde ninguna información útil).

DKNF es frecuentemente difícil de alcanzar en la práctica.

Reglas de Codd

Codd se percató de que existían bases de datos en el mercado las cuales decían ser
relacionales, pero lo único que hacían era guardar la información en las tablas, sin
estar estas tablas literalmente normalizadas; entonces éste publicó 12 reglas que un
verdadero sistema relacional debería tener, en la práctica algunas de ellas son difíciles
de realizar. Un sistema podrá considerarse "más relacional" cuanto más siga estas
reglas.

Regla No. 1 - La Regla de la información

Toda la información en un RDBMS está explícitamente representada de una sola


manera por valores en una tabla.

Cualquier cosa que no exista en una tabla no existe del todo. Toda la información,
incluyendo nombres de tablas, nombres de vistas, nombres de columnas, y los datos
de las columnas deben estar almacenados en tablas dentro de las bases de datos. Las
tablas que contienen tal información constituyen el Diccionario de Datos. Esto
significa que todo tiene que estar almacenado en las tablas.

Toda la información en una base de datos relacional se representa explícitamente en


el nivel lógico exactamente de una manera: con valores en tablas. Por tanto los
metadatos (diccionario, catálogo) se representan exactamente igual que los datos de
usuario.

Y puede usarse el mismo lenguaje (ej. SQL) para acceder a los datos
y a los metadatos (regla 4)

Regla No. 2 - La regla del acceso garantizado


Cada ítem de datos debe ser lógicamente accesible al ejecutar una búsqueda que
combine el nombre de la tabla, su clave primaria, y el nombre de la columna.

Esto significa que dado un nombre de tabla, dado el valor de la clave primaria, y dado
el nombre de la columna requerida, deberá encontrarse uno y solamente un valor. Por
esta razón la definición de claves primarias para todas las tablas es prácticamente
obligatoria.

Regla No. 3 - Tratamiento sistemático de los valores nulos

La información inaplicable o faltante puede ser representada a través de valores


nulos.

Un RDBMS (Sistema Gestor de Bases de Datos Relacionales) debe ser capaz de


soportar el uso de valores nulos en el lugar de columnas cuyos valores sean
desconocidos o inaplicables.

Regla No. 4 - La regla de la descripción de la base de datos

La descripción de la base de datos es almacenada de la misma manera que los datos


ordinarios, esto es, en tablas y columnas, y debe ser accesible a los usuarios
autorizados.

La información de tablas, vistas, permisos de acceso de usuarios autorizados, etc,


debe ser almacenada exactamente de la misma manera: En tablas. Estas tablas deben
ser accesibles igual que todas las tablas, a través de sentencias de SQL.

Regla No. 5 - La regla del sub-lenguaje Integral

Debe haber al menos un lenguaje que sea integral para soportar la definición de
datos, manipulación de datos, definición de vistas, restricciones de integridad, y
control de autorizaciones y transacciones.

Esto significa que debe haber por lo menos un lenguaje con una sintaxis bien definida
que pueda ser usado para administrar completamente la base de datos.

Regla No. 6 - La regla de la actualización de vistas

Todas las vistas que son teóricamente actualizables, deben ser actualizables por el
sistema mismo.
La mayoría de las RDBMS permiten actualizar vistas simples, pero deshabilitan los
intentos de actualizar vistas complejas.

Regla No. 7 - La regla de insertar y actualizar

La capacidad de manejar una base de datos con operandos simples aplica no sólo
para la recuperación o consulta de datos, sino también para la inserción,
actualización y borrado de datos'.

Esto significa que las cláusulas SELECT, UPDATE, DELETE e INSERT deben estar
disponibles y operables sobre los registros, independientemente del tipo de relaciones
y restricciones que haya entre las tablas.

Regla No. 8 - La regla de independencia física

El acceso de usuarios a la base de datos a través de terminales o programas de


aplicación, debe permanecer consistente lógicamente cuando quiera que haya
cambios en los datos almacenados, o sean cambiados los métodos de acceso a los
datos.

El comportamiento de los programas de aplicación y de la actividad de usuarios vía


terminales debería ser predecible basados en la definición lógica de la base de datos,
y éste comportamiento debería permanecer inalterado, independientemente de los
cambios en la definición física de ésta.

Regla No. 9 - La regla de independencia lógica

Los programas de aplicación y las actividades de acceso por terminal deben


permanecer lógicamente inalteradas cuando quiera que se hagan cambios (según los
permisos asignados) en las tablas de la base de datos.

La independencia lógica de los datos especifica que los programas de aplicación y las
actividades de terminal deben ser independientes de la estructura lógica, por lo tanto
los cambios en la estructura lógica no deben alterar o modificar estos programas de
aplicación.

Regla No. 10 - La regla de la independencia de la integridad

Todas las restricciones de integridad deben ser definibles en los datos, y


almacenables en el catalogo, no en el programa de aplicación.

Las reglas de integridad


1. Ningún componente de una clave primaria puede tener valores en blanco o
nulos. (esta es la norma básica de integridad).
2. Para cada valor de clave foránea deberá existir un valor de clave primaria
concordante. La combinación de estas reglas aseguran que haya Integridad
referencial.

Regla No. 11 - La regla de la distribución

El sistema debe poseer un lenguaje de datos que pueda soportar que la base de datos
esté distribuida físicamente en distintos lugares sin que esto afecte o altere a los
programas de aplicación.

El soporte para bases de datos distribuidas significa que una colección arbitraria de
relaciones, bases de datos corriendo en una mezcla de distintas máquinas y distintos
sistemas operativos y que esté conectada por una variedad de redes, pueda funcionar
como si estuviera disponible como en una única base de datos en una sola máquina.

Regla No. 12 - Regla de la no-subversión

Si el sistema tiene lenguajes de bajo nivel, estos lenguajes de ninguna manera


pueden ser usados para violar la integridad de las reglas y restricciones expresadas
en un lenguaje de alto nivel (como SQL).

Algunos productos solamente construyen una interfaz relacional para sus bases de
datos No relacionales, lo que hace posible la subversión (violación) de las
restricciones de integridad. Esto no debe ser permitido.

Modelo relacional

Es posible que, a causa de ello, haya lagunas de contenido o deficiencias de formato.


Por favor, antes de realizar correcciones mayores o reescrituras, contacta con ellos en
su página de usuario o la página de discusión del artículo para poder coordinar la
redacción.

El modelo relacional para la gestión de una base de datos es un modelo de datos


basado en la lógica de predicado y en la teoría de conjuntos. Es el modelo más
utilizado en la actualidad para modelar problemas reales y administrar datos
dinámicamente. Tras ser postuladas sus bases en 1970 por Edgar Frank Codd, de los
laboratorios IBM en San José (California), no tardó en consolidarse como un nuevo
paradigma en los modelos de base de datos.

Su idea fundamental es el uso de «relaciones». Estas relaciones podrían considerarse


en forma lógica como conjuntos de datos llamados «tuplas». Pese a que ésta es la
teoría de las bases de datos relacionales creadas por Edgar Frank Codd, la mayoría de
las veces se conceptualiza de una manera más fácil de imaginar, esto es, pensando en
cada relación como si fuese una tabla que está compuestas por registros (cada fila de
la tabla sería un registro), que representarían las tuplas, y campos (las columnas de
una tabla).

Descripción

En este modelo todos los datos son almacenados en relaciones, y como cada relación
es un conjunto de datos, el orden en el que estos se almacenen no tiene mayor
relevancia (a diferencia de otros modelos como el jerárquico y el de red). Esto tiene la
considerable ventaja de que es más fácil de entender y de utilizar por un usuario no
experto. La información puede ser recuperada o almacenada por medio de
«consultas» que ofrecen una amplia flexibilidad y poder para administrar la
información.

Este modelo considera la base de datos como una colección de relaciones. De manera
simple, una relación representa una tabla que no es más que un conjunto de filas, cada
fila es un conjunto de campos y cada campo representa un valor que interpretado
describe el mundo real. Cada fila también se puede denominar tupla o registro y a
cada columna también se le puede llamar campo o atributo.

Para manipular la información utilizamos un lenguaje relacional, actualmente se


cuenta con dos lenguajes formales el Álgebra relacional y el Cálculo relacional. El
Álgebra relacional permite describir la forma de realizar una consulta, en cambio, el
Cálculo relacional sólo indica lo que se desea devolver.

El lenguaje más común para construir las consultas a bases de datos relacionales es
SQL, Structured Query Language o Lenguaje Estructurado de Consultas, un estándar
implementado por los principales motores o sistemas de gestión de bases de datos
relacionales.

Esquema

Un esquema es la definición de una estructura (generalmente relaciones o tablas de


una base de datos), es decir, determina la identidad de la relación y que tipo de
información podrá ser almacenada dentro de ella; en otras palabras, es esquema son
los metadatos de la relación. Todo esquema constará de:
 Nombre de la relación (su identificador).
 Nombre de los atributos (o campos) de la relación y sus dominios; el dominio
de un atributo o campo define los valores permitidos para el mismo, es
equivalente al tipo de dato por ejemplo character, integer, date, string, etc.

Instancias

Una instancia de manera formal es la aplicación de un esquema a un conjunto finito


de datos. En palabras no tan técnicas, se puede definir como el contenido de una tabla
en un momento dado, pero también es valido referirnos a una instancia cuando
trabajamos o mostramos únicamente un subconjunto de la información contenida en
una relación o tabla, como por ejemplo:

 Ciertos caracteres y números (una sola columna de una sola fila).


 Algunas o todas las filas con todas o algunas columnas

 Cada fila es una tupla. El número de filas es llamado cardinalidad.


 El número de columnas es llamado aridad o grado.

Base de datos relacional

Una base de datos relacional es un conjunto de una o más tablas estructuradas en


registros (líneas) y campos (columnas), que se vinculan entre sí por un campo en
común, en ambos casos posee las mismas características como por ejemplo el nombre
de campo, tipo y longitud; a este campo generalmente se le denomina ID,
identificador o clave. A esta manera de construir bases de datos se le denomina
modelo relacional.

Estrictamente hablando el término se refiere a una colección específica de datos pero


a menudo se le usa, en forma errónea como sinónimo del software usado para
gestionar esa colección de datos. Ese software se conoce como SGBD (sistema gestor
de base de datos) relacional o RDBMS (del inglés relational database management
system).

Las bases de datos relacionales pasan por un proceso al que se le conoce como
normalización de una base de datos, el cual es entendido como el proceso necesario
para que una base de datos sea utilizada de manera óptima.

Entre las ventajas de este modelo están:

1. Garantiza herramientas para evitar la duplicidad de registros, a través de


campos claves o llaves.
2. Garantiza la integridad referencial: Así al eliminar un registro elimina todos
los registros relacionados dependientes.
3. Favorece la normalización por ser más comprensible y aplicable.

Desnormalización (base de datos)

La desnormalización es el proceso de procurar optimizar el desempeño de una base


de datos por medio de agregar datos redundantes. A veces es necesaria porque las
actuales DBMSs implementan el modelo relacional pobremente. Una verdadera
DBMS relacional debe permitir una base de datos completamente normalizada a nivel
lógico, mientras proporciona el almacenamiento físico de los datos afinado para alto
rendimiento.

Un diseño normalizado a menudo almacenará diferentes, pero relacionadas, piezas de


información en tablas lógicas separadas (llamadas relaciones). Si estas relaciones
están almacenadas físicamente como archivos de disco separados, puede ser lento
terminar una consulta de la base de datos que tome información de varias relaciones
(una operación unión). Si muchas relaciones son unidas (join), puede ser
prohibitivamente lento. Hay dos estrategias para tratar con esto. El método preferido
es mantener normalizado el diseño lógico, pero permite al DBMS almacenar en el
disco información redundante adicional para optimizar la respuesta a la consulta. En
este caso, es responsabilidad del software del DBMS asegurarse de que cualquier
copia redundante se mantenga consistente. Este método es a menudo implementado
en SQL como vistas indexadas (MS SQL) o vistas materializadas (Oracle). Una vista
representa la información en un formato conveniente para consultar, y el índice
asegura que las consultas contra la vista estén optimizadas.

El acercamiento más usual es desnormalizar el diseño de datos lógico. Con cuidado,


esto puede alcanzar una mejora similar en respuesta de consulta, pero a un costo -
ahora es la responsabilidad del diseñador de la base de datos de asegurarse de que la
base de datos desnormalizada no llegue a ser inconsistente. Esto es hecho creando
reglas en la base de datos llamadas restricciones, que especifican cómo las copias
redundantes de información se deben mantener sincronizadas. Es el aumento en la
complejidad lógica del diseño de la base de datos y la complejidad añadida de las
restricciones adicionales que hacen a este acercamiento peligroso. Por otra parte,
debido a los gastos indirectos de evaluación de restricciones al insertar, actualizar, o
eliminar datos, una base de datos desnormalizada puede realmente ofrecer un
desempeño peor que sus funcionalmente equivalentes contrapartes normalizadas.
Cuando se está seleccionado o leyendo datos a menudo el desempeño será mejor.

Un modelo de datos desnormalizado no es lo mismo que un modelo de datos que no


ha sido normalizado, y la desnomarlización debe tomar lugar solamente después de
que haya ocurrido un nivel satisfactorio de normalización y de que hayan sido creadas
las restricciones y/o reglas requeridas para ocuparse de las anomalías inherentes en el
diseño. Por ejemplo, que todas las relaciones estén en la tercera forma normal y
cualquier relación con dependencias de unión (join) y multi-valor sean manejadas
apropiadamente.

Ejemplos de técnicas de desnormalización incluyen:

 Vistas materializadas, que pueden implementar lo siguiente:


o Almacenando la cuenta de "muchos" objetos en una relación uno-a-
muchos como un atributo de la relación "uno"
o Agregando atributos a una relación de otra relación con la cual será
unida (join)
 Esquemas en estrella que también son conocidos como modelos hecho-
dimensión y se han extendido a los esquemas de copo de nieve
 Información de resumen preconstruida (útil para informes, data warehouse o
data mining) o cubos OLAP.
CONCLUSION

La normalización también hace las cosas fáciles de entender. Los seres humanos
tenemos la tendencia de simplificar las cosas al máximo. Lo hacemos con casi
todo desde los animales hasta con los automóviles. Vemos una imagen de gran
tamaño y la hacemos menos compleja agrupando cosas similares juntas. Las
guías que la normalización provee crean el marco de referencia para simplificar
la estructura. En su base de datos de muestra es fácil detectar que usted tiene tres
diferentes grupos: clientes, productos y pedidos. Si sigue las guías de la
normalización, podría crear las tablas basándose en estos grupos.

Otra ventaja de la normalización de su base de datos es el consumo de espacio. Una


base de datos normalizada puede ocupar menos espacio en disco que una no
normalizada. Hay menos repetición de datos, lo que tiene como consecuencia un
mucho menor uso de espacio en disco
INSTITUTO UNIVERSITARIO DE TECNOLOGIA

DE ADMINISTRACION INDUSTRIAL
IUTA- SEDE ANACO

NORMALIZACION

Autor: Suescun Z, Carlos J.

Anaco, Mayo 2008