🛠️ Ejercicios Prácticos

Clase 016 - Conversión de ER a Modelo Relacional

🎯 Introducción a los Ejercicios Prácticos

Objetivo: Aplicar los conocimientos teóricos del modelo relacional mediante ejercicios prácticos de conversión desde diagramas ER.

🗂️ Diagrama ER

Entidades, atributos y relaciones conceptuales

📝 Modelo Textual

Tablas y campos definidos

📊 Tablas Físicas

Estructura final con tipos de datos

Pasos del Proceso de Conversión

Identificar Entidades

Cada entidad (rectángulo) se convierte en una tabla

Convertir Atributos

Los atributos (óvalos) se convierten en columnas

Definir Claves Primarias

Atributos subrayados → Claves primarias

Gestionar Relaciones

Aplicar reglas según cardinalidad (1:1, 1:N, N:M)

Verificar Normalización

Comprobar formas normales (1FN, 2FN, 3FN)

📝 Ejercicio 1: Relación 1:N (Categorías-Productos)

Diagrama ER Inicial

[CATEGORÍAS] ----< CONTIENEN >---- [PRODUCTOS]
| |
• ID (PK) • ID (PK)
• Nombre • Nombre
• Cantidad

Cardinalidad: 1:N (Una categoría contiene N productos)

Paso 1: Conversión a Modelo Textual

CATEGORÍAS (ID_Categoría, Nombre) PRODUCTOS (ID_Producto, Nombre, Cantidad, ID_Categoría)
Recomendación: Cambiar nombres genéricos como "ID" por nombres específicos como "ID_Categoría" para mayor claridad.

Paso 2: Definición de Tablas con Tipos de Datos

Tabla: CATEGORÍAS
Tipo Clave Nombre Campo Tipo Dato
PK ID_Categoría TINYINT (0-255)
- Nombre VARCHAR(50)
Tabla: PRODUCTOS
Tipo Clave Nombre Campo Tipo Dato
PK ID_Producto INTEGER
- Nombre VARCHAR(50)
- Cantidad INTEGER
FK ID_Categoría TINYINT

Paso 3: Datos de Ejemplo

Datos: CATEGORÍAS
ID_Categoría Nombre
1 Carnes
2 Pescados
3 Electrónica
4 Bebidas
Datos: PRODUCTOS
ID_Producto Nombre Cantidad ID_Categoría
1 Entrecot de Ternera 7 1
2 Chuletón de Buey 3 1
3 Cerveza Mahou 24 4

📝 Ejercicio 2: Relación N:M (Profesores-Alumnos)

Diagrama ER Inicial

[PROFESORES] ----< IMPARTEN CLASE >---- [ALUMNOS]
| |
• ID (PK) • ID (PK)
• Nombre • Nombre
• Asignatura • Curso

Cardinalidad: N:M (Un profesor puede enseñar a varios alumnos,
un alumno puede tener varios profesores)

Paso 1: Conversión a Modelo Textual

PROFESORES (ID_Profesor, Nombre, Asignatura) ALUMNOS (ID_Alumno, Nombre, Curso) IMPARTEN (ID_Profesor, ID_Alumno)
Regla N:M: Se crea una nueva tabla cuya clave primaria es la unión de las claves primarias de las entidades relacionadas.

Paso 2: Definición de Tablas

Tabla: PROFESORES
Tipo Clave Nombre Campo Tipo Dato
PK ID_Profesor INTEGER
- Nombre VARCHAR(50)
- Asignatura VARCHAR(50)
Tabla: ALUMNOS
Tipo Clave Nombre Campo Tipo Dato
PK ID_Alumno INTEGER
- Nombre VARCHAR(50)
- Curso VARCHAR(10)
Tabla: IMPARTEN (Tabla de Relación)
Tipo Clave Nombre Campo Tipo Dato
PK/FK ID_Profesor INTEGER
PK/FK ID_Alumno INTEGER

Alternativa: Clave Primaria Separada

Opción alternativa: Crear un ID_Imparten como clave primaria única y dejar ID_Profesor e ID_Alumno solo como claves foráneas. Esto es útil cuando la misma combinación puede repetirse (ej: diferentes semestres).
Tabla: IMPARTEN (Alternativa)
Tipo Clave Nombre Campo Tipo Dato
PK ID_Imparten INTEGER
FK ID_Profesor INTEGER
FK ID_Alumno INTEGER

✅ Verificación de Normalización

🔍 Primera Forma Normal (1FN)

  • Valores atómicos: Cada campo contiene un solo valor
  • Granularidad: Datos lo más específicos posible
  • Consistencia: Mismo número de columnas en todos los registros

Ejemplo de optimización: En lugar de un campo "Dirección" completo, separar en "Calle", "Número", "Ciudad", "Código_Postal".

🔍 Segunda Forma Normal (2FN)

  • Cumple 1FN
  • Dependencia completa: Atributos no clave dependen completamente de la clave primaria
  • Solo aplica: A tablas con clave primaria compuesta

Problema común: Si la clave compuesta permite duplicados, considerar crear una clave primaria simple adicional.

🔍 Tercera Forma Normal (3FN)

  • Cumple 1FN y 2FN
  • Sin dependencias transitivas: Los campos no clave no dependen entre sí
  • Dependencia directa: Todo campo depende directamente de la clave primaria

Verificación: Asegurar que el nombre del profesor no depende de la asignatura, sino del ID_Profesor.

Ejemplo de Optimización: Campos Repetitivos

Problema: Campo "País" Repetitivo

Si en la tabla ALUMNOS muchos registros repiten "España", "Francia", etc., optimizar creando:

Nueva Tabla: PAÍSES
ID_País Nombre_País
1 España
2 Francia

Y en la tabla ALUMNOS, usar ID_País (INTEGER) en lugar de Nombre_País (VARCHAR).

Beneficio: En Big Data, ahorrar caracteres por millones de registros supone gigabytes de espacio.

🔄 Proceso Completo de Conversión

Análisis del Texto

Identificar entidades, atributos y relaciones a partir del enunciado del problema.

Diagrama ER

Dibujar entidades (rectángulos), atributos (óvalos), relaciones (rombos) y cardinalidades.

Conversión a Modelo Textual

Aplicar reglas de conversión según tipos de relación (1:1, 1:N, N:M).

Definición de Tablas

Especificar tipos de datos, claves primarias y foráneas.

Verificación de Normalización

Comprobar cumplimiento de formas normales (1FN, 2FN, 3FN).

Datos de Ejemplo

Incluir registros de muestra para validar el diseño.

Documentación Adicional

Añadir restricciones, jerarquías u otras reglas no representables en el modelo.

💡 Consejos Prácticos

🎯 Nomenclatura

  • Usar nombres descriptivos: ID_Cliente en lugar de ID
  • Mantener consistencia en los nombres entre tablas
  • Las claves foráneas deben coincidir con las primarias que referencian

🔧 Tipos de Datos

  • TINYINT: Para catálogos pequeños (0-255)
  • INTEGER: Para identificadores generales
  • VARCHAR(n): Para textos con longitud máxima estimada
  • Análisis previo: Estimar volúmenes y longitudes máximas

⚡ Optimización

  • Identificar campos repetitivos para crear tablas de catálogo
  • Separar campos compuestos (dirección, nombre completo)
  • Considerar la frecuencia de consultas para índices futuros

🚨 Errores Comunes

Relaciones N:M sin tabla intermedia: Siempre crear tabla de relación
Claves foráneas con tipos diferentes: Deben coincidir exactamente
Campos multivalor: Violan 1FN, separar en campos individuales

📋 Documentación Extra

Ejemplo de Restricciones Adicionales
• Jerarquía: Profesores Senior > Profesores Junior • Validación: Campo 'Cantidad' no puede ser negativo • Control: Tabla PRODUCTOS no permite campos en blanco • Índices: Crear índice en 'Nombre' para búsquedas frecuentes