Tercera Forma

Una tabla está en 3NF si está en 2NF y además todos los atributos dependen directamente de la clave candidata sin que existan dependencias transitivas a través de cualquier otro atributo que no pertenezca a la clave. 

• La tabla está en la segunda forma normal (2NF)
• Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria
• Es una relación que no incluye ningún atributo clave

Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata. 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 → Ye Y → Z.

Por poner un ejemplo, supongamos que tenemos una tabla de ponencias de un certamen, indicando además la persona que realizará la ponencia y su año de nacimiento:

Como vemos, la tabla cumple 2NF, pero sin embargo la fecha de nacimiento no depende del tema, sino del ponente. Esto implica que hay que hacer una tabla de ponentes relacionada con la de ponencias:

Segunda Forma

 La Segunda Forma Normal nos habla de que cada columna de la tabla debe depender de la clave.Esto significa que todo un registro debe depender únicamente de la clave principal, si tuvieramos alguna columna que se repite a lo largo de todos los registros, dichos datos deberian atomizarse en una nueva tabla.Veamos un ejemplo

VentaID	ItemID	FechaVenta	ClienteVenta	ProductoId	Cantidad
1	1	01/12/2007	2	2334	10
1	2	01/12/2007	2	3333	2
1	3	01/12/2007	2	66643	34
1	4	01/12/2007	2	21	3
2	1	02/12/2007	5	3566	6

Ahi tenemos un claro problema !!!Acaso no se busca NO REPETIR DATOS ?Si toda una venta tendrá el mismo numero de Cliente y la misma Fecha…Por que no crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos ?Es evidente que la columnaClienteVenta y FechaVenta se repetirán por cada venta realizada.Es por ello que proponemos el siguiente esquema 

VentaID	ItemID	ProductoId	Cantidad
1	1	2334	10
1	2	3333	2
1	3	66643	34
1	4	21	3
2	1	3566	6

Y ahora nuestra nueva tabla maestra

VentaId	FechaVenta	ClienteVenta
1	01/12/2007	2
2	02/12/2007	5

Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una tabla debe depender de toda la clave y no constituir un dato unico para cada grupo de registros

Primera Forma

 En la mayoría de casos la simplifican diciendo que  todos los atributos deben ser atómicos, y no multivaluados. Esto es cierto en tanto en cuanto el resto de reglas son implícitas de los sistemas de gestión de bases de datos. Pero las reglas completas son las siguientes:

• No hay orden de arriba-a-abajo en las filas, es decir, el orden de las tuplas no importa para la información.
• No hay orden de izquierda-a-derecha en las columnas, es decir, el orden de las columntas no importa para la información.
• No hay filas duplicadas.
• Cada atributo tiene un único dominio aplicable y un único valor de dicho dominio, y aun más allá, la solución a esto no es crear nuevos atributos para contemplar posibles valores de la multivaluación.

Vamos a explicarlo de manera sencilla. Supongamos una entidad “Persona” que contiene una clave primaria, nombre, apellido y teléfono. Pero claro, una persona puede tener múltiples teléfonos de contacto, así que podríamos pensar en utilizar el campo teléfono para meter varios separados por comas, por ejemplo. Esto sería incorrecto, por ejemplo:

También se nos podría ocurrir poner varias columnas Telefono1, Telefono2,… pero esto solamente cubriría parte de las posibilidades, y además tendríamos columnas muy repletas de nulos, con muchos huecos:

La solución correcta, para cumplir la 1NF, es crear una tabla nueva para los teléfonos, relacionada con la tabla Persona por su clave primaria:

Normalizacion BD

El proceso de normalización de bases de datos consiste en designar y 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.

·         Disminuir 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 bidimensional sea considerada como una relación tiene 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 equivalente

o    relación = tabla o archivo

o    tupla = registro, fila o renglón

o    atributo = campo o columna

o    base de datos = banco de datos

o    dependencia multivaluada = dependencia multivalor

o    clave = llave

o    clave primaria = superclave

o    clave ajena = clave extranjera o clave foránea

o    RDBMS = del inglés Relational Data Base Manager System que significa, Sistema Gestor de Base de Datos Relacionales

modelo en red

una base de datos de red es una base de datos conformada por una colección o set de registros, los cuales están conectados entre sí por medio de enlaces en una red. El registro es similar al de una entidad como las empleadas en el modelo relacional.

Un registro es una colección o conjunto de campos (atributos), donde cada uno de ellos contiene solamente un único valor almacenado.

El enlace es exclusivamente la asociación entre dos registros, así que podemos verla como una relación estrictamente binaria.

Una estructura de base de datos de red, llamada algunas veces estructura de plex, abarca más que la estructura de árbol: un nodo hijo en la estructura redpuede tener más de un nodo padre. En otras palabras, la restricción de que en un árbol jerárquico cada hijo puede tener sólo un padre, se hace menos severa.

Así, la estructura de árbol se puede considerar como un caso especial de la estructura de red.

https://es.wikipedia.org/wiki/Modelo_de_red