7. Transformación de Diagramas E/R y Normalización en Bases de Datos

By · · · · · · · · ·

Transformación de Diagramas E/R y Normalización en Bases de Datos: Guía Completa con Ejemplos Prácticos

En el mundo de las bases de datos, el diseño es un paso crucial para garantizar que la información se almacene de manera eficiente y sin redundancias. En este artículo, exploraremos cómo transformar un diagrama entidad-relación (E/R) en un modelo relacional, y cómo aplicar la normalización para optimizar nuestras tablas. Además, te proporcionaremos ejemplos prácticos y código SQL para que puedas aplicar estos conceptos en tus propios proyectos.

🎯 Objetivos del Artículo

  • Comprender el proceso de transformación del modelo E/R al modelo relacional.
  • Aprender el concepto de normalización y cómo aplicarlo en el diseño de bases de datos.
  • Manejar con soltura la creación de diagramas E/R y su posterior transformación en tablas relacionales.

🛠 Transformación al Modelo Relacional

1. Transformación de Entidades Fuertes

Una entidad fuerte se convierte en una tabla en el modelo relacional. Cada atributo de la entidad se convierte en una columna de la tabla, y el identificador principal de la entidad se convierte en la clave primaria de la tabla.

Ejemplo:

Supongamos que tenemos una entidad EMPLEADO con los siguientes atributos:

  • DNI (identificador principal)
  • Teléfono
  • Dirección
  • Salario

La transformación al modelo relacional sería:



CREATE TABLE EMPLEADOS (
    DNI VARCHAR(9) PRIMARY KEY,
    Teléfono VARCHAR(15),
    Dirección VARCHAR(100),
    Salario DECIMAL(10, 2)
);

2. Transformación de Entidades Débiles y Relaciones 1:1

Las entidades débiles dependen de una entidad fuerte, por lo que su tabla incluirá la clave primaria de la entidad fuerte como clave externa.

Ejemplo:

Si tenemos una entidad débil MOVIMIENTO que depende de la entidad fuerte CUENTA_BANCO, las tablas serían:



CREATE TABLE CUENTA_BANCO (
    Nº_Cuenta INT PRIMARY KEY,
    Saldo DECIMAL(10, 2)
);

CREATE TABLE MOVIMIENTO (
    Nº_Cuenta INT,
    Código INT,
    Tipo VARCHAR(50),
    Cantidad DECIMAL(10, 2),
    PRIMARY KEY (Nº_Cuenta, Código),
    FOREIGN KEY (Nº_Cuenta) REFERENCES CUENTA_BANCO(Nº_Cuenta)
);

Para las relaciones 1:1, podemos incorporar la clave de una entidad como clave externa en la otra.

3. Transformación de Relaciones 1:N y N:M

En las relaciones 1:N, la tabla de la entidad con cardinalidad “N” incluye la clave de la entidad con cardinalidad “1” como clave externa.

Ejemplo:

Si tenemos una relación 1:N entre ACTORES y REPRESENTANTES, las tablas serían:



CREATE TABLE REPRESENTANTES (
    Id_Representante INT PRIMARY KEY,
    Nombre VARCHAR(100)
);

CREATE TABLE ACTORES (
    Código INT PRIMARY KEY,
    NombreArtístico VARCHAR(100),
    Nombre VARCHAR(100),
    Id_Representante INT,
    Contrato VARCHAR(100),
    FOREIGN KEY (Id_Representante) REFERENCES REPRESENTANTES(Id_Representante)
);

En las relaciones N:M, se crea una nueva tabla que incluye las claves primarias de ambas entidades como clave compuesta.

Ejemplo:

Si tenemos una relación N:M entre PRODUCTOS y MÁQUINAS, las tablas serían:



CREATE TABLE PRODUCTOS (
    Referencia INT PRIMARY KEY,
    Precio DECIMAL(10, 2)
);

CREATE TABLE MÁQUINAS (
    Número_serie INT PRIMARY KEY,
    Localización VARCHAR(100)
);

CREATE TABLE FABRICA (
    Referencia INT,
    Número_serie INT,
    Fecha_fabricación DATE,
    PRIMARY KEY (Referencia, Número_serie),
    FOREIGN KEY (Referencia) REFERENCES PRODUCTOS(Referencia),
    FOREIGN KEY (Número_serie) REFERENCES MÁQUINAS(Número_serie)
);

📊 Normalización: Evitando Redundancias y Dependencias Erróneas

La normalización es un proceso que garantiza que nuestras tablas cumplan con ciertas reglas para evitar redundancias y dependencias erróneas. A continuación, veremos las principales formas normales:

1. Primera Forma Normal (1FN)

Una tabla está en 1FN si no tiene atributos que puedan tomar más de un valor.

Ejemplo:



-- Tabla que NO cumple con 1FN
CREATE TABLE EMPLEADOS (
    DNI VARCHAR(9) PRIMARY KEY,
    Nombre VARCHAR(100),
    Departamento VARCHAR(100)
);

-- Tabla que SÍ cumple con 1FN
CREATE TABLE EMPLEADOS (
    DNI VARCHAR(9),
    Nombre VARCHAR(100),
    Departamento VARCHAR(100),
    PRIMARY KEY (DNI, Departamento)
);

2. Segunda Forma Normal (2FN)

Una tabla está en 2FN si está en 1FN y todos los atributos no clave dependen completamente de la clave primaria.

Ejemplo:



-- Tabla que NO cumple con 2FN
CREATE TABLE COMPRAS (
    CódProd INT,
    CódProveedor INT,
    NombreProducto VARCHAR(100),
    Cantidad INT,
    PRIMARY KEY (CódProd, CódProveedor)
);

-- Tabla que SÍ cumple con 2FN
CREATE TABLE PRODUCTOS (
    CódProd INT PRIMARY KEY,
    NombreProducto VARCHAR(100)
);

CREATE TABLE COMPRAS (
    CódProd INT,
    CódProveedor INT,
    Cantidad INT,
    PRIMARY KEY (CódProd, CódProveedor),
    FOREIGN KEY (CódProd) REFERENCES PRODUCTOS(CódProd)
);

3. Tercera Forma Normal (3FN)

Una tabla está en 3FN si está en 2FN y no hay atributos que dependan de otros atributos no clave.

Ejemplo:



-- Tabla que NO cumple con 3FN
CREATE TABLE EMPLEADOS (
    DNI VARCHAR(9) PRIMARY KEY,
    Cód_Provincia INT,
    Provincia VARCHAR(100)
);

-- Tabla que SÍ cumple con 3FN
CREATE TABLE EMPLEADOS (
    DNI VARCHAR(9) PRIMARY KEY,
    Cód_Provincia INT,
    FOREIGN KEY (Cód_Provincia) REFERENCES PROVINCIAS(Cód_Provincia)
);

CREATE TABLE PROVINCIAS (
    Cód_Provincia INT PRIMARY KEY,
    Provincia VARCHAR(100)
);

4. Forma Normal de Boyce-Codd (FNBC)

Una tabla está en FNBC si está en 3FN y todo atributo es clave candidata.

Ejemplo:



-- Tabla que NO cumple con FNBC
CREATE TABLE ORGANIZACIÓN (
    Empleado VARCHAR(100),
    Departamento VARCHAR(100),
    Responsable VARCHAR(100),
    PRIMARY KEY (Empleado, Departamento)
);

-- Tabla que SÍ cumple con FNBC
CREATE TABLE PERSONAL (
    Empleado VARCHAR(100) PRIMARY KEY,
    Responsable VARCHAR(100)
);

CREATE TABLE RESPONSABLES (
    Departamento VARCHAR(100) PRIMARY KEY,
    Responsable VARCHAR(100)
);

🎬 Paso a Modelo Relacional

Vamos a aplicar todo lo aprendido en un ejercicio. Supongamos que tenemos una relación M:N entre CLASES y ALUMNOS. La transformación al modelo relacional sería:



CREATE TABLE ALUMNOS (
    DNI VARCHAR(9) PRIMARY KEY,
    Nombre_AL VARCHAR(100)
);

CREATE TABLE CLASES (
    Num_Clase INT PRIMARY KEY,
    Nombre_cl VARCHAR(100)
);

CREATE TABLE TIENE (
    DNI VARCHAR(9),
    Num_Clase INT,
    PRIMARY KEY (DNI, Num_Clase),
    FOREIGN KEY (DNI) REFERENCES ALUMNOS(DNI),
    FOREIGN KEY (Num_Clase) REFERENCES CLASES(Num_Clase)
);

📝 Resumen y Conclusión

En este artículo, hemos explorado cómo transformar un diagrama E/R en un modelo relacional y cómo aplicar la normalización para optimizar nuestras tablas. Hemos visto ejemplos prácticos y código SQL para que puedas aplicar estos conceptos en tus propios proyectos.

La normalización es un paso crucial en el diseño de bases de datos, ya que nos ayuda a evitar redundancias y dependencias erróneas, lo que garantiza que nuestra base de datos sea eficiente y fácil de mantener.

¡Esperamos que esta guía te haya sido útil! Si tienes alguna pregunta o comentario, no dudes en dejarlo en la sección de comentarios.

Bibliografía:

  • Oppel, A. (2009). Databases: A Beginner’s Guide. McGraw-Hill.
  • Elmásri, R. y Navathe, S. (2007). Fundamentos de Bases de Datos. Pearson Addison-Wesley.
  • López, I.; Castellano, M.J., y Ospino, J. (2011). Bases de datos. Garceta.
  • Cabrera, G. (2011). Sistemas gestores de bases de datos. Paraninfo.
  • Pérez Marqués, M. (2016). Administración básica de bases de datos con Oracle 12c SQL. Alfaomega.


No hay comentarios:

Publicar un comentario