Normalización de bases de datos en MySQL: Cuatro pasos fáciles y rápidos
Menores redundancias, menos anomalías y mejor eficiencia son los beneficios que trae la normalización de bases de datos a MySQL. Aquí un tutorial.
La normalización de bases de datos fue introducida como procedimiento por Edgar Frank Codd, un científico de computación en IBM en su artículo “Un modelo relacional de datos para grandes bancos de datos compartidos” en 1970. La normalización de bases de datos es un proceso por el cual un esquema existente se modifica para traer sus tablas componentes hacia el cumplimiento a través de una serie de formas normales progresivas.
Índice del tutorial:
- Beneficios de la normalización de bases de datos en MySQL
- Normalice sus datos fácilmente
- Paso 1: Crear la primera forma estándar (1NF)
- Paso 2: Definir relaciones
- Paso 3: Hacer la segunda forma estándar (2NF)
- Paso 4: Tercera forma estándar (3NF)
Se centra en librar a los desarrolladores y sus proyectos del “síndrome de la hoja de cálculo". El síndrome de la hoja de cálculo se refiere a la tendencia de los desarrolladores de exprimir tanta información como sea posible en el menor número de tablas posible.
Antes, debido a las nociones de hojas de cálculo y cómo se manejaban los datos en ellas, los desarrolladores seguían diseñando bases de datos MySQL con el mismo marco mental. Hoy, este método no se considera una forma inteligente para diseñar bases de datos MySQL desde que las tablas, cuando son diseñadas con el síndrome de la hoja de cálculo, piden rediseño constante por cada pequeño cambio a la base de datos.
Beneficios de la normalización de bases de datos en MySQL
El uso reducido del espacio de almacenamiento mediante la categorización inteligente de los datos es uno de los muchos beneficios que la normalización de bases de datos presta a MySQL. Esto ayuda a lograr búsquedas mejores, más rápidas, búsquedas y más fuertes, ya que implica un menor número de entidades para escanear en comparación con las búsquedas anteriores basadas en entidades mixtas. La integridad de los datos se mejora a través de la normalización de bases de datos, ya que divide todos los datos en entidades individuales, construyendo aún así fuertes vínculos con los datos relacionados.
Como Mike Hillyer, un escritor técnico en MySQL AB (ahora Oracle Corporation), explica: "El objetivo de la normalización de bases de datos es garantizar que cada columna que no es clave, en cada tabla, depende directamente de la clave: toda la clave y nada más que la clave. Y con este objetivo, vienen los beneficios en forma de menores redundancias, menos anomalías, y la mejora de la eficiencia".
Normalice los datos fácilmente
El siguiente ejemplo ilustrará cómo la normalización de bases de datos ayuda a lograr un buen diseño en MySQL. En el cuadro siguiente se presentan datos que necesitan ser capturados en la base de datos:
Título | Autor | Bio | ISBN | Tema | Páginas | Editorial |
Beginning MySQL Database Design and Optimization | Chad Russell, Jon Stephens |
Chad Russell es un programador y administrador de sistemas que es dueño de su propia empresa de alojamiento de Internet. Jon Stephens es un miembro del equipo de documentación de MySQL AB. | 90593324 | Diseño de bases de datos MySQL | 520 | Apress |
En el ejemplo anterior, se desperdiciará una gran cantidad de espacio de almacenamiento si cualquier criterio (autor o editorial) es considerado como la clave de identificación. La normalización de bases de datos, por lo tanto, es esencial. Es un proceso paso a paso que no puede ser llevado a cabo al azar. Los siguientes pasos le ayudarán en la consecución de la normalización de bases de datos en MySQL.
Paso 1: Crear la primera forma estándar (1NF)
El proceso de normalización de base de datos consiste en la obtención de datos para ajustarse a las formas estándares progresivas, y un mayor nivel de normalización de base de datos no puede ser logrado a menos que los niveles anteriores se han cumplido. La primera forma estándar es el nivel básico de la normalización de la base de datos.
Para 1NF, asegúrese de que los valores de cada columna de una tabla son atómicas; lo que significa que son únicos, y no contiene conjuntos de valores. En nuestro caso, Autor y Tema no cumplen.
Uno de los métodos para llevar una tabla a 1NF es separar las entidades que figuran en la tabla en tablas separadas. En nuestro caso, esto se traduciría en tablas Libro, Autor, Tema y Editorial.
Tabla Libro:
ISBN | Título | Páginas |
1590593324 | Beginning MySQL Database Design and Optimization | 520 |
Tabla Autor:
Autor_ID | Nombre | Apellido |
1 | Chad | Russell |
2 | Jon | Stephens |
3 | Mike | Hilyer |
Tabla Tema:
Tema _ID |
Apellido |
1 | Russell |
2 | Stephens |
Tabla Editorial:
Editorial_ID |
Nombre | Dirección | Ciudad | Estado | ZIP |
1 | Apress | 2 580, Ninth street, station 219 | Berkeley | California | 94710 |
Paso 2: Definir relaciones
Se puede establecer tres tipos de relaciones:
• Uno-a-(Cero o)-uno (Ejemplo: matrimonio)
• Uno-a-(Cero o)-muchos (Ejemplo: hijos)
• Muchos-a-muchos (Ejemplo: facebook)
La tabla del libro puede tener relaciones muchos a muchos con la tabla del Autor.
La tabla del autor puede tener muchos libros y un libro puede tener más de un autor.
La tabla del libro puede tener relaciones muchos a muchos con la tabla de Tema.
Los libros pueden caber en muchos temas y los temas pueden tener muchos libros.
Las relaciones muchos-a-muchos tienen que ser presentadas por tablas “link" (de enlace).
Tabla Autor de Libro:
ISBN |
Tema_ID |
1590593324 | 1 |
1590593324 | 2 |
Tabla Tema_Libro:
ISBN | Tema_ID |
1590593324 | 1 |
1590593324 | 2 |
Uno-a-muchos en nuestro ejemplo será Libros a Editorial. Cada libro tiene solo una Editorial, pero una Editorial puede tener muchos libros. Podemos lograr relaciones ‘uno-a-muchos' con una clave externa. Una clave externa es un mecanismo en sistemas de gestión de bases de datos (DBMS) que define las relaciones y crea restricciones entre los segmentos de datos. No es posible examinar lo que no está relacionado con el libro específico. No es posible tener un libro sin un autor o editorial.
Al borrar una editorial, todos los libros relacionados pueden necesitar ser eliminados junto con las opiniones de esos libros. No sería necesario eliminar los autores.
La clave externa se introduce en la tabla que representa los "muchos", apuntando a la clave primaria en la tabla "uno". Ya que la tabla "Libro" representa la porción de muchos de la relación uno-a-muchos, se añade el valor de la clave primaria de la Editorial como en una columna Editorial_ID como clave externa
ISBN |
Título | Páginas | Editorial_ID |
1590593324 | Beginning MySQL Database Design and Optimization | 520 | 1 |
Paso 3: Hacer la segunda forma estándar (2NF)
La segunda forma estándar (2NF) reduce los datos tautológicos/superfluos en una tabla seleccionándolos, poniéndolos en nuevas tablas y estableciendo relaciones entre ellos. En la normalización de bases de datos, 2NF se trata de las relaciones entre las columnas de clave compuesta y las columnas que no son clave. Eso significa que las columnas sin clave tienen que depender de la clave compuesta completa. Aquí, la clave primaria es compuesta para eliminar la posibilidad de la misma persona escribiendo más de una revisión del libro. El URL de quien revisa solo depende de la ID del Revisor, que es solo una parte de la clave compuesta completa.
Esta tabla no cumple con la 2NF:
ISBN |
Revisor ID | Resumen | Revisor_URL |
1590593324 | 3 | ¡Un gran libro! | http://www.openwin.org |
Paso 4: Tercera forma estándar (3NF)
Esto requiere que todas las columnas dependan directamente de la clave primaria. Las tablas violan la 3NF cuando una columna depende de otra columna, la que a su vez depende de la clave primaria (una dependencia transitiva). En la tabla de la editorial, la Ciudad y el Estado son en realidad dependientes del código postal, no de la Editorial_ID.
Editorial_ID | Nombre | Dirección | Ciudad | Estado | ZIP |
1 | Apress | 2 580, Ninth street, station 219 | Berkeley | California | 94710 |
Para cumplir con la 3NF tenemos que mover estas fuera de la tabla Editorial:
ZIP |
Ciudad |
Estado |
94710 | Berkeley | California |
A través del proceso de normalización de las bases de datos ponemos las tablas de nuestro esquema en conformidad con las formas estándares progresivas. Como resultado, las tablas representan cada una una única entidad (un libro, un autor, un tema, etc.) y nos beneficiamos de la disminución de la redundancia, menos anomalías y una mejora de la eficiencia.
Sobre el autor: Ronen Baram es un consultor de ventas de MySQL en Oracle para los mercados de Australia/Nueva Zelanda. Como parte de su trabajo, se reúne con clientes de toda Australia, Nueva Zelanda, así como el resto de APAC, principalmente la India. Baram tiene 15 años de experiencia en TI y tiene un interés especial en el sistema operativo Linux. (Este tutorial se basa en una presentación realizada por Ronen Baram en la Conferencia de Desarrollo de Oracle, celebrada en Hyderabad. Compilado por Sharon D’Souza).