Representación abstracta de los datos, enfocada en qué información será almacenada, sin detalles técnicos.
Objetivo: Entender y representar la estructura de la información. Solo se identifican los más importantes (nombre del libro, nombre del cliente, etc.).
Define estructuras de datos como tablas y claves, sin depender de una tecnología específica.
Elementos claves:
Describe cómo los datos serán almacenados en un DBMS específico, incluyendo detalles técnicos. Ya son las propias tablas, condiciones, variables… Aquí sí importa la tecnología.
Usa diagramas para representar entidades y sus relaciones.
Extiende el ER con jerarquías, superclases y subclases, representando relaciones más complejas.
Diagrama que representa el flujo de datos en procesos.
Organiza los datos en tablas (relaciones) con filas y columnas. Utiliza claves primarias y foráneas para identificar registros y establecer relaciones entre tablas.
Combina conceptos del modelo lógico con paradigmas de programación orientada a objetos. Representa los datos como objetos que tienen atributos y métodos.
Organiza los datos en una estructura de árbol, donde cada nodo tiene un único padre. Es útil para representar relaciones uno a muchos de forma jerárquica.
La normalización en bases de datos es un proceso sistemático para organizar los datos en una base de datos con el fin de reducir la redundancia (duplicación de datos) y mejorar la integridad.
Objetivo: Garantizar que los datos se almacenen de manera eficiente y que las relaciones entre las tablas se mantengan correctamente.
Evita valores repetitivos en un mismo campo. Esto evita la redundancia de datos y mejora la eficiencia en la base de datos. Una tabla no debe contener listas o grupos de valores en una sola celda.
Ejemplo: Supongamos que tenemos una tabla llamada "Clientes" con una columna "Dirección" que almacena varias direcciones en un solo campo. Esto no cumple con 1FN, ya que se deben almacenar las direcciones como registros separados. La tabla corregida debería ser:
Elimina dependencias parciales. Establece que una tabla debe estar en 1FN y, además, todos los atributos no clave deben depender completamente de la clave primaria, es decir, no debe haber dependencias parciales. Una dependencia parcial ocurre cuando un atributo depende solo de una parte de la clave primaria compuesta.
Ejemplo: Supongamos que tenemos una tabla llamada "Pedidos" con una clave primaria compuesta por "ID Cliente" y "ID Pedido", y una columna adicional llamada "Nombre Cliente". Si el "Nombre Cliente" depende solo de "ID Cliente", estamos ante una dependencia parcial, ya que depende solo de una parte de la clave primaria. Esto viola la 2FN. Para corregirlo, movemos la información del cliente a una tabla separada. La estructura corregida sería:
Elimina dependencias transitivas. Debe estar en 2FN y, además, no debe haber dependencias transitivas. Una dependencia transitoria ocurre cuando un atributo no clave depende de otro atributo no clave. Esto puede generar redundancia y anomalías en la base de datos.
Ejemplo: Imagina una tabla llamada "Empleados" con las columnas "ID Empleado", "Nombre Empleado", "Departamento" y "Jefe Departamento". Si "Jefe Departamento" depende de "Departamento", y "Departamento" depende de "ID Empleado", esto sería una dependencia transitoria. Para corregirlo, la información del jefe debe almacenarse en una tabla separada relacionada solo con el "Departamento". La estructura corregida sería:
Debe estar en 3FN y todas las dependencias funcionales deben ser determinadas por una clave candidata.
Debe estar en FNBC y no tener dependencias multivaluadas no triviales. Separa valores múltiples en diferentes tablas.
Ejemplos de herramientas más utilizadas: