database segunda - ¿Qué son las formas normales de la base de datos y puedes dar ejemplos?




primera normalizacion (5)

En el diseño de bases de datos relacionales, existe un concepto de normalización de la base de datos o simplemente normalización, que es un proceso de organización de columnas (atributos) y tablas (relaciones) para reducir la redundancia de datos y mejorar la integridad de los datos. (como está escrito en Wikipedia ).

Como la mayoría de los artículos son algo técnicos y, por lo tanto, más difíciles de entender, le estoy pidiendo a alguien que escriba una explicación más fácil de entender basada en ejemplos sobre el significado de 1NF, 2NF, 3NF, incluso 3.5NF (Boyce-Codd).


Answers

Aquí hay una respuesta rápida, ciertamente masacrada , pero en una oración:

1NF: su tabla está organizada como un conjunto de datos no ordenados, y no hay columnas que se repitan.

2NF: No repite los datos en una columna de su tabla debido a otra columna.

3NF: Cada columna en su tabla se relaciona solo con la clave de su tabla; no tendría una columna en una tabla que describa otra columna en su tabla que no sea la clave.

Para más detalles, vea wikipedia ...


Nunca he tenido una buena memoria para las palabras exactas, pero en mi clase de base de datos creo que el profesor siempre dijo algo como:

Los datos dependen de la clave [1NF], toda la clave [2NF] y nada más que la clave [3NF].


1NF es la forma más básica de las formas normales: cada celda de una tabla debe contener solo una información y no puede haber filas duplicadas.

2NF y 3NF se basan en depender de la clave principal. Recuerde que una clave principal puede estar formada por varias columnas. Como dijo Chris en su respuesta:

Los datos dependen de la clave [1NF], toda la clave [2NF] y nada más que la clave [3NF] (así que ayúdame Codd ).

2NF

Supongamos que tiene una tabla que contiene cursos que se toman en un determinado semestre y tiene los siguientes datos:

|-----Primary Key----|               uh oh |
                                           V
CourseID | SemesterID | #Places  | Course Name  |
------------------------------------------------|
IT101    |   2009-1   | 100      | Programming  |
IT101    |   2009-2   | 100      | Programming  |
IT102    |   2009-1   | 200      | Databases    |
IT102    |   2010-1   | 150      | Databases    |
IT103    |   2009-2   | 120      | Web Design   |

Esto no está en 2NF , porque la cuarta columna no se basa en la clave completa , sino en solo una parte. El nombre del curso depende de la ID del curso, pero no tiene nada que ver con el semestre que cursa. Por lo tanto, como puede ver, tenemos información duplicada: varias filas nos dicen que IT101 está programando y IT102 es Bases de datos. Así que arreglamos eso moviendo el nombre del curso a otra tabla, donde CourseID es la clave ENTERA.

Primary Key |

CourseID    |  Course Name |
---------------------------|
IT101       | Programming  |
IT102       | Databases    |
IT103       | Web Design   |

No hay redundancia!

3NF

Bien, digamos que también agregamos el nombre del profesor del curso, y algunos detalles sobre ellos, en el RDBMS:

|-----Primary Key----|                           uh oh |
                                                       V
Course  |  Semester  |  #Places   |  TeacherID  | TeacherName  |
---------------------------------------------------------------|
IT101   |   2009-1   |  100       |  332        |  Mr Jones    |
IT101   |   2009-2   |  100       |  332        |  Mr Jones    |
IT102   |   2009-1   |  200       |  495        |  Mr Bentley  |
IT102   |   2010-1   |  150       |  332        |  Mr Jones    |
IT103   |   2009-2   |  120       |  242        |  Mrs Smith   |

Ahora, espero que sea obvio que TeacherName depende de TeacherID, por lo que no está en 3NF . Para solucionar esto, hacemos lo mismo que hicimos en 2NF: saque el campo Nombre del profesor de esta tabla y colóquelo en su propia cuenta, que tiene la ID de profesor como la clave.

 Primary Key |

 TeacherID   | TeacherName  |
 ---------------------------|
 332         |  Mr Jones    |
 495         |  Mr Bentley  |
 242         |  Mrs Smith   |

No hay redundancia !!

Una cosa importante a recordar es que si algo no está en 1NF, tampoco lo está en 2NF o 3NF. Por lo tanto, cada forma normal adicional requiere todo lo que tenían las formas normales inferiores, más algunas condiciones adicionales, que deben cumplirse todas .


1NF: solo un valor por columna

2NF: todas las columnas de clave no primaria de la tabla deben depender de la clave principal completa.

3NF: Todas las columnas de clave no primaria de la tabla deben depender DIRECTAMENTE de la clave principal completa.

He escrito un artículo con más detalle here


Es muy probable que tenga un problema que se pueda resolver con NOSQL y tecnologías distribuidas.

i) Escribiría un sistema distribuido utilizando Hadoop / HBase.

ii) Alquile varias máquinas de decenas / cientos de AWS, pero solo por unos segundos (todavía le costará menos de $ 0.50)

iii) Beneficio !!!







database database-design database-normalization