Criterios de Calidad en Bases de Datos: Consistencia y Trazabilidad

📌 En síntesis: Buenas prácticas de diseño físico, integridad referencial compuesta, trazabilidad de cambios y auditoría en arquitecturas de datos empresariales.

Guía técnica desarrollada por el equipo de Proyecto Luna para formación profesional y consulta técnica abierta.

---

Aprendizaje esperado Representar entidades y atributos de bases de datos a través de un modelo de entidad relación, asegurando su alineación con la realidad y capacidad para resolver consultas.

Introducción Afrontar el diseño de un sistema de información sin un modelamiento riguroso equivale a construir sobre supuestos frágiles. En diseño de bases de datos, los errores más costosos no suelen originarse en el código, sino en decisiones tempranas mal fundamentadas sobre los datos y su estructura. El modelo de entidad-relación y los diagramas de clase surgen precisamente para evitar ese riesgo, ya que permiten representar el dominio del problema antes de comprometerse con tablas, consultas, objetos o capas de software. Ambos modelos ofrecen una mirada complementaria: mientras el modelo ER se concentra en describir la información, sus relaciones y restricciones, el diagrama de clases organiza esa misma realidad desde la lógica del software, integrando datos y comportamiento. Trabajar con estos modelos no es un ejercicio meramente gráfico, sino una estrategia para gestionar la complejidad. Los sistemas reales involucran múltiples actores, reglas de negocio y necesidades de consulta que, si se abordan directamente en SQL o en código, tienden a generar redundancias, inconsistencias y soluciones difíciles de mantener. En cambio, el modelamiento permite validar la comprensión del dominio, anticipar escenarios críticos y justificar decisiones de diseño antes de implementar. Como señalan Capacho y Nieto (2017), las decisiones tomadas en la etapa conceptual condicionan la integridad y el rendimiento del sistema. En una línea similar, Godoc (2018) evidencia que las consultas y validaciones en SQL solo resultan robustas cuando se apoyan en estructuras bien modeladas. Esta base conceptual sostiene todo el desarrollo posterior.

1. Modelo de entidad-relación y diagramas de clase El diseño de un sistema de información suele fracasar cuando el equipo salta demasiado rápido desde el problema hacia la implementación. En , el modelamiento cumple una función preventiva: permite representar con claridad qué datos existen, cómo se conectan y qué reglas deben respetar, antes de decidir tablas, llaves, consultas, objetos o capas de software. En este marco, el modelo de entidad-relación y los diagramas de clase se convierten en dos instrumentos complementarios. El modelo de entidad-relación permite describir el dominio desde la perspectiva de la información y sus vínculos, mientras que el diagrama de clases permite organizar el diseño del software desde un enfoque orientado a objetos, integrando datos y comportamiento. Ambos modelos resuelven un problema común: la complejidad. Los sistemas reales combinan múltiples actores, reglas de negocio, validaciones y necesidades de consulta. Cuando esa complejidad se aborda solo con código, aparecen inconsistencias, redundancia y falta de trazabilidad. Por el contrario, cuando se trabaja con modelos, el equipo puede validar la comprensión del dominio, anticipar escenarios, y justificar decisiones de diseño antes de construir. Capacho y Nieto (2017) explican que el diseño de base de datos requiere una etapa de estructuración conceptual y lógica, porque las decisiones tempranas determinan la consistencia, la integridad y el rendimiento del sistema. En un sentido cercano, Godoc (2018) muestra que las consultas SQL solo se vuelven robustas cuando existe una estructura coherente en tablas y relaciones, lo que exige un trabajo previo de modelamiento. Para evitar redundancias y mantener claridad, este desarrollo organiza el contenido en subpuntos que avanzan desde fundamentos y notación, hacia ejemplos aplicados, integración entre modelos y relación con la implementación. Se incorporan tablas y códigos sólo cuando realmente aportan a comprender el paso desde el concepto hacia la construcción técnica.

1.1. Propósito y alcance del modelo de entidad-relación El modelo de entidad-relación, también llamado modelo ER, representa datos y relaciones en un nivel conceptual. Su propósito es describir el dominio del problema en términos de entidades relevantes, atributos que las caracterizan y relaciones que las vinculan. Esta representación no depende del motor de base de datos, ni obliga a decisiones específicas sobre tipos de datos, índices o sintaxis SQL. Su valor radica en la claridad, porque permite conversar sobre el sistema usando elementos cercanos al dominio, evitando confundir reglas de negocio con detalles de implementación. En , el modelo ER se utiliza como puente entre el levantamiento de requerimientos y la construcción del modelo lógico. Primero se identifica qué información es necesaria y qué reglas de relación existen, luego se traduce esa información a tablas, claves primarias, claves foráneas y restricciones. Capacho y Nieto (2017) sostienen que una base de datos bien diseñada comienza con una representación conceptual, porque allí se pueden detectar entidades omitidas, relaciones mal definidas o atributos que pertenecen a otra entidad. El alcance del modelo ER se centra en datos, no en comportamiento. Un sistema puede requerir validaciones, flujos, autorizaciones o cálculos, y el modelo ER no describe esos procesos en detalle. Aun así, aporta una base estable, porque muchas reglas de negocio se expresan como restricciones de asociación. Un ejemplo simple es el siguiente: “una inscripción no puede existir sin un estudiante y una válidos”. Esa regla se traduce luego en integridad referencial en tablas. Al trabajar esa regla en el modelo ER, el equipo evita inconsistencias posteriores en SQL y reduce la necesidad de validaciones repetidas en código.

1.1.1. Componentes del modelo ER El modelo ER se construye con tres componentes principales: entidades, atributos y relaciones, detalladas a continuación:

• Entidad: representa un objeto o concepto distinguible del

dominio. Ejemplos: estudiante, , cliente, pedido, producto, factura.

• Atributo: representa una característica de una entidad. Ejemplos: nombre de estudiante, correo del cliente, precio del producto.

• Relación: representa un vínculo entre entidades. Ejemplos: estudiante se inscribe en , cliente realiza pedido, pedido contiene productos. Para mantener precisión, se suelen agregar restricciones como cardinalidad y opcionalidad. Cardinalidad indica cuántas ocurrencias de una entidad se asocian con otra. Por ejemplo, uno a muchos, muchos a muchos. Opcionalidad indica si la relación es obligatoria o no. Por ejemplo, un estudiante puede existir sin inscripciones, pero una inscripción no puede existir sin estudiante. 1.1.2. Ejemplo aplicado: sistema académico A continuación, se presenta un ejemplo conceptual, con entidades y relaciones frecuentes en un sistema académico. El ejemplo es intencionalmente acotado para focalizar el modelamiento. Entidades principales: Estudiante, , Docente, Inscripción. Relaciones principales:

• Estudiante se asocia con Inscripción.

• se asocia con Inscripción.

• Docente dicta . Una decisión conceptual relevante aparece de inmediato: la inscripción contiene atributos propios como fecha y estado. En el modelo ER, cuando una relación muchos a muchos posee atributos, la estrategia habitual consiste en convertir esa relación en una entidad asociativa, en este caso Inscripción. Esta decisión evita registrar fecha y estado en Estudiante o en , lo que generaría duplicación y confusión. Capacho y Nieto (2017) describen esta transformación como parte de la construcción de estructuras coherentes, ya que permite conservar información dependiente de la relación y no de una entidad aislada. 1.1.3. Reglas de negocio y restricciones de integridad En sistemas reales, el modelo ER se valida con reglas del negocio. Esas reglas se expresan como restricciones. Ejemplos:

• Regla 1: un docente puede dictar varias s, pero cada tiene un docente responsable. Esto se modela como relación uno a muchos entre Docente y .

• Regla 2: una inscripción pertenece a un solo estudiante y a una sola . Esto se modela con relaciones uno a muchos desde Estudiante a Inscripción, y desde a Inscripción.

• Regla 3: un estudiante puede existir en el sistema sin estar inscrito. Esto se refleja como opcionalidad en la relación entre Estudiante e Inscripción, porque el lado de Estudiante permite cero o más inscripciones. Estas reglas luego se traducen a claves foráneas, restricciones not null, unicidad compuesta y, cuando corresponde, triggers o procedimientos. Aun así, el primer paso es conceptual, porque define qué debe ser cierto en el sistema.

1.2. Notación y lectura del modelo ER con foco en el diseño relacional El modelo entidad–relación puede representarse mediante distintas notaciones gráficas. Independiente del estilo visual utilizado, lo relevante es la capacidad de leer el diagrama y extraer sus implicancias para el diseño relacional. En la práctica, el análisis del modelo ER busca responder preguntas como las siguientes:

• Qué entidades se transformarán en tablas.

• Qué atributos se transformarán en columnas.

• Qué relaciones requieren la incorporación de claves foráneas.

• Qué relaciones muchos a muchos exigen una tabla intermedia o entidad asociativa.

• Qué atributos conforman la clave primaria de cada tabla. Capacho y Nieto (2017) plantean que la fase conceptual debe permitir un tránsito ordenado hacia el modelo lógico. En este sentido, un diagrama ER no constituye únicamente una representación gráfica, sino un artefacto de análisis que orienta decisiones estructurales clave. 1.2.1. Tabla de mapeo general: ER a tablas La siguiente tabla sintetiza mapeos habituales al pasar del modelo ER hacia una estructura relacional. Se presenta como guía, porque es una de las conexiones más útiles entre modelamiento y programación. Elemento en ER Forma común en modelo relacional Observación clave Entidad fuerte Tabla Posee clave primaria propia Atributo simple Columna El tipo de dato se define en la implementación Continúa en la siguiente página

Elemento en ER Forma común en modelo relacional Observación clave Atributo compuesto Columnas múltiples Ejemplo: nombre y apellidos por separado Atributo multivaluado Tabla aparte Relación uno a muchos con la entidad principal Relación 1 a N Clave foránea en el lado N Puede requerir NOT NULL si la relación es obligatoria Relación N a M Tabla intermedia Puede convertirse en entidad asociativa Relación N a M con atributos Entidad asociativa La tabla contiene atributos propios de la relación Tabla 1. Tabla de mapeo general: ER a tablas Esta tabla resulta especialmente útil cuando el equipo debe justificar decisiones. Por ejemplo, si una relación N a M se implementa sin tabla intermedia, aparecen duplicaciones o anomalías. 1.2.2. Ejemplo de traducción a tablas: sistema académico Se presenta una traducción lógica inicial, para mostrar cómo el modelo conceptual guía la implementación. No se profundiza todavía en normalización avanzada, porque el foco aquí es el vínculo ER y diagrama de clases. Tablas esperables:

• Estudiante(id_estudiante, nombre, correo, fecha_ingreso)
• Docente(id_docente, nombre, especialidad)
• (id_, nombre, creditos, id_docente)
• Inscripcion(id_estudiante, id_, fecha_inscripcion, estado) Decisión relevante: la tabla Inscripcion puede usar una clave primaria compuesta (id_estudiante, id_) o una clave

artificial id_inscripcion. Ambas estrategias son válidas y se justifican por necesidades de consultas y trazabilidad. Capacho y Nieto (2017) explican que las claves deben elegirse considerando unicidad y estabilidad. Si el negocio define que un estudiante solo puede inscribirse una vez por en un periodo, una clave compuesta puede ser suficiente, aunque si existe historial por periodo, se agrega id_periodo a la clave o se usa un id artificial. A continuación, se muestra un ejemplo de implementación SQL para este escenario, con claves primarias y foráneas. La intención no es cubrir toda la sintaxis posible, sino mostrar cómo el diseño conceptual aterriza a estructuras coherentes. Godoc (2018) destaca que las llaves y restricciones permiten que la base de datos rechace inconsistencias sin depender de validaciones externas, lo que mejora la confiabilidad del sistema. CREATE DATABASE SistemaAcademico; USE SistemaAcademico; CREATE TABLE docente ( id_docente INT PRIMARY KEY, nombre VARCHAR(120) NOT NULL, especialidad VARCHAR(120) NULL ); CREATE TABLE estudiante ( id_estudiante INT PRIMARY KEY, nombre VARCHAR(120) NOT NULL, correo VARCHAR(120) NOT NULL UNIQUE, fecha_ingreso DATE NOT NULL ); CREATE TABLE ( id_ INT PRIMARY KEY, nombre VARCHAR(120) NOT NULL, creditos INT NOT NULL, id_docente INT NOT NULL, CONSTRAINT fk__docente FOREIGN KEY (id_docente) REFERENCES docente(id_docente) );

CREATE TABLE inscripcion ( id_estudiante INT NOT NULL, id_ INT NOT NULL, fecha_inscripcion DATE NOT NULL, estado VARCHAR(30) NOT NULL, CONSTRAINT pk_inscripcion PRIMARY KEY (id_estudiante, id_), CONSTRAINT fk_inscripcion_estudiante FOREIGN KEY (id_estudiante) REFE­ RENCES estudiante(id_estudiante), CONSTRAINT fk_inscripcion_ FOREIGN KEY (id_) REFE­ RENCES (id_) );

Figura 1. SQL que define la creación de tablas y relaciones de una base de datos

académica, incluyendo docentes, s, estudiantes e inscripciones, con claves primarias y foráneas. Este código refleja reglas conceptuales: no existe inscripción sin estudiante o , cada tiene docente responsable y el correo de estudiante es único. Según Godoc (2018), la presencia de restricciones como primary key, foreign key y unique no solo garantiza integridad, también orienta la forma correcta de consultar y relacionar datos. A continuación, se muestra la representación del diagrama físico de la base de datos implementada, junto con la forma en que se visualizan las relaciones correspondientes entre las tablas.

Figura 2: Diagrama físico de la base de datos del sistema académico

1.3. Diagramas de clase: propósito y estructura en UML El diagrama de clases, en UML, representa la estructura estática del software. Su propósito consiste en describir las clases, sus atributos, sus métodos y las relaciones que existen entre ellas. A diferencia del modelo ER, el diagrama de clases no se limita únicamente a la representación de datos, sino que también describe el comportamiento, lo que permite anticipar cómo se implementará el sistema en un contexto de programación orientada a objetos. En términos prácticos, un diagrama de clases funciona como un plano del código. Si el sistema se implementa en lenguajes como Java o C#, cada clase del diagrama suele transformarse directamente en una clase del lenguaje, donde los atributos se representan como campos y los métodos como funciones. En Python también se aplica este enfoque, aunque con mayor flexibilidad en el tipado. El uso del diagrama ayuda a mantener la consistencia entre el diseño y el código, y facilita la colaboración en equipos de desarrollo de mayor tamaño. Desde el punto de vista del diseño de bases de datos, el diagrama de clases aporta valor cuando se utiliza en conjunto con el modelo ER. Mientras el modelo ER define la estructura de los datos, el diagrama de clases define cómo esos datos son manipulados dentro del software. Esta articulación reduce riesgos comunes, como contar con una base de datos coherente pero un software mal organizado, o un software bien estructurado apoyado en una base de datos inconsistente. 1.3.1. Elementos centrales del diagrama de clases Clase: representa un tipo de objeto con atributos y métodos. Se suele dibujar como un rectángulo con secciones: nombre, atributos, métodos.

Atributo: propiedad de la clase. Puede incluir tipo, visibilidad y nombre. Método: operación de la clase. Puede incluir parámetros y tipo de retorno. Relaciones entre clases:

• Asociación: vínculo general entre clases.
• Agregación: relación todo parte con independencia de vida.
• Composición: relación todo parte con dependencia de vida.
• Herencia: relación es un, permite reutilización y polimorfismo.
• Dependencia: uso temporal de una clase por otra. Estas relaciones ayudan a modelar arquitectura. Por ejemplo, en un sistema de ventas, una clase Pedido se asocia con Cliente y contiene ítems de pedido. La composición se usa cuando la vida del ítem depende del pedido. 1.3.2. Ejemplo aplicado: diagrama de clases para sistema académico Se utiliza el mismo dominio del sistema académico para mostrar la continuidad entre modelos. En un diseño orientado a objetos, se podrían definir clases como Estudiante, , Docente e Inscripción. La diferencia respecto al modelo ER es que Inscripción, además de almacenar datos, puede incluir operaciones como cambiarEstado() o validarInscripcion(). A continuación, se muestra una representación textual de tipo UML, útil cuando no se dispone de una herramienta gráfica. Se incluyen únicamente atributos y métodos mínimos con el fin de no sobrecargar el ejemplo.

Figura 3: diagrama de clases UML que modela un sistema académico con las clases Estudiante, Docente, Asignatu

Estudiante, Docente, e Inscripción, incluyendo atributos y métodos que representan sus responsabilidades y relaciones. Relaciones esperables:

• Estudiante 1 a muchos Inscripcion.
• 1 a muchos Inscripcion.
• Docente 1 a muchos . Este diseño permite que el software opere sobre el dominio sin perder consistencia con la base de datos. Capacho y Nieto (2017) señalan que el diseño de datos debe alinearse con las necesidades del sistema. Por eso, si el sistema requiere consultar inscripciones por estado, la clase Inscripcion debe exponer esa información y el modelo relacional debe almacenarla correctamente. Docente - idDocente:int - nombre: string - especialidad: string + asignarA(asig: ): void - id:int - nombre: string - creditos: int - docente: Docente + cambiarDocente(nuevo: Docente): void Estudiante - idEstudiante:int - nombre: string - correo: string - fechaIngreso: date + inscribirse(asig: ): Inscripcion + listarInscripciones(): List Inscripcion - fechaInscripcion: date - estado: string - estudiante: Estudiante - : + cambiarEstado(nuevoEstado: string): void 0..* 0..* 0..*

En el diagrama de clases presentado, la clase Inscripción incluye referencias explícitas a Estudiante y como atributos. Desde una perspectiva UML estricta, estas referencias podrían representarse únicamente mediante asociaciones, evitando la duplicación entre atributos y relaciones. Sin embargo, en este caso se opta por mantener dichas referencias de forma explícita con fines pedagógicos. Esta decisión facilita la comprensión del modelo por parte del estudiante, ya que permite visualizar de manera directa cómo una inscripción vincula a un estudiante con una , reforzando el paralelismo entre el modelo conceptual, el diseño orientado a objetos y la implementación en código. En la práctica, esta representación resulta coherente con lenguajes como Java o C#, donde una clase suele mantener referencias directas a otros objetos relacionados. Por lo tanto, la duplicación observada no constituye un error de diseño, sino una elección didáctica orientada a favorecer la claridad conceptual y la comprensión del dominio del problema. 1.4. Diferencias esenciales entre modelo ER y diagrama de clases Aunque ambos diagramas pueden verse similares, no representan lo mismo. Confundirlos provoca errores frecuentes, por ejemplo: diseñar clases como si fueran tablas, o diseñar tablas como si fueran objetos. A continuación, se presenta una tabla comparativa para fijar diferencias clave.

Criterio Modelo ER Diagrama de clases foco principal datos y relaciones estructura del software y comportamiento unidad central entidad clase contiene métodos no sí representa herencia no es central sí, es frecuente destino típico diseño lógico de base de datos diseño e implementación de código restricción típica cardinalidad y opcionalidad asociaciones, composición, herencia, dependencias validación típica con reglas del negocio de datos con arquitectura y responsabilidades del software Tabla 2. diferencias esenciales entre modelo ER y diagrama de clases Según Capacho y Nieto (2017), el modelamiento de datos busca integridad y coherencia, mientras que el diseño orientado a objetos busca modularidad y mantenimiento. Ambas metas se necesitan en sistemas modernos. 1.5. Integración entre ER y diagramas de clase en proyectos reales La integración entre modelo ER y diagrama de clases no ocurre por casualidad. Requiere reglas de traducción y criterios de decisión. En un proyecto típico, el equipo puede seguir una secuencia como esta: 1. Levantar requerimientos y reglas del negocio. 2. Construir modelo ER y validarlo. 3. Traducir a modelo lógico relacional. 4. Diseñar diagramas de clase alineados con el dominio y con la estructura de datos.

5. Implementar base de datos y capa de acceso a datos. 6. Implementar lógica de negocio y presentación. Esta secuencia permite trazabilidad: cada elemento del código y de la base de datos se justifica desde el dominio. 1.5.1. Reglas de mapeo útiles: entidad a clase, relación a asociación En muchos casos, una entidad del modelo ER se transforma en una clase en UML. Esto ocurre porque ambas representan conceptos del dominio. Sin embargo, el detalle cambia:

• Una entidad se vuelve clase.
• Un atributo se vuelve atributo de clase.
• Una relación se vuelve asociación entre clases.
• Una relación con atributos se vuelve clase propia, similar a entidad asociativa. Esto se observa con Inscripcion: en ER es entidad asociativa y en UML puede ser clase con métodos. Aun así, la herencia en UML no suele aparecer en ER, porque el ER se enfoca en datos. Por ejemplo, en UML se podría tener Usuario como clase base y Estudiante y Docente como subclases, pero en ER esto se modela con estrategias distintas: tabla por jerarquía, tabla por clase concreta, etc. Capacho y Nieto (2017) explican que estas decisiones pertenecen al diseño lógico y dependen del contexto. 1.5.2. Ejemplo aplicado completo: mini caso de comercio electrónico Para mostrar integración con otro dominio, se propone un escenario breve. Escenario: una tienda en línea registra clientes, productos y pedidos. Un cliente realiza pedidos. Cada pedido contiene productos con

cantidades. Se requiere consultar historial por cliente, total por pedido y stock por producto. Modelo ER conceptual: Entidades: Cliente, Producto, Pedido, DetallePedido. Relaciones:

• Cliente 1 a muchos Pedido.

• Pedido 1 a muchos DetallePedido.

• Producto 1 a muchos DetallePedido. Detallado: DetallePedido es entidad asociativa, porque resuelve la relación muchos a muchos entre Pedido y Producto, y además almacena cantidad y precio unitario. Modelo relacional sugerido:

• cliente(id_cliente, nombre, correo)

• producto(id_producto, nombre, precio, stock)

• pedido(id_pedido, id_cliente, fecha, estado)

• detalle_pedido(id_pedido, id_producto, cantidad, precio_ unitario)

SQL base para detalle: CREATE DATABASE sistema_ventas; USE sistema_ventas; CREATE TABLE producto ( id_producto INT PRIMARY KEY, nombre VARCHAR(120) NOT NULL, precio DECIMAL(10,2) NOT NULL ); CREATE TABLE pedido ( id_pedido INT PRIMARY KEY, fecha DATE NOT NULL, estado VARCHAR(30) NOT NULL ); CREATE TABLE detalle_pedido ( id_pedido INT NOT NULL, id_producto INT NOT NULL, cantidad INT NOT NULL, precio_unitario DECIMAL(10,2) NOT NULL, CONSTRAINT pk_detalle PRIMARY KEY (id_pedido, id_producto), CONSTRAINT fk_detalle_pedido FOREIGN KEY (id_pedido) REFERENCES pedi­ do(id_pedido), CONSTRAINT fk_detalle_producto FOREIGN KEY (id_producto) REFERENCES producto(id_producto) );

Figura 4: tabla detalle_pedido con una clave primaria compuesta y claves foráneas hacia pedido y producto, mo

hacia pedido y producto, modelando la relación muchos a muchos entre pedidos y productos con atributos propios. Según Godoc (2018), esta estructura permite consultas robustas porque la relación entre pedido y producto se formaliza mediante claves. Con ello, un total por pedido se calcula con sumas sobre detalle_pedido sin duplicación.

A continuación, se procederá a insertar datos de prueba y, posteriormente, a ejecutar la consulta SELECT con el fin de verificar los resultados obtenidos. INSERT INTO producto (id_producto, nombre, precio) VALUES (1, ‘Mouse’, 8000), (2, ‘Teclado’, 15000), (3, ‘Monitor’, 120000); INSERT INTO pedido (id_pedido, fecha, estado) VALUES (1001, ‘2025-03-01’, ‘Emitido’), (1002, ‘2025-03-02’, ‘Emitido’); INSERT INTO detalle_pedido (id_pedido, id_producto, cantidad, precio_unitario) VALUES – Pedido 1001 (1001, 1, 2, 8000), (1001, 2, 1, 15000), – Pedido 1002 (1002, 2, 2, 15000), (1002, 3, 1, 120000);

Figura 5: Inserción de datos de prueba para productos, pedidos y detalles de pedido.

Consulta de total por pedido: SELECT p.id_pedido, p.fecha, p.estado, SUM(dp.cantidad * dp.precio_unitario) AS total FROM pedido p JOIN detalle_pedido dp ON p.id_pedido = dp.id_pedido GROUP BY p.id_pedido, p.fecha, p.estado;

Figura 6. total, monetario de cada pedido sumando el producto de la cantidad por el

precio unitario de sus detalles y agrupando los resultados por id_pedido. El desarrollo presentado evidencia el proceso completo de modelamiento y diseño de una base de datos relacional a partir de un dominio realista, integrando de forma coherente el modelo entidad–relación, el modelo relacional y su implementación en SQL. A través del modelo ER conceptual se identificaron las entidades principales del sistema, sus relaciones y las reglas de negocio fundamentales, lo que permitió comprender la estructura de la información antes de pasar a decisiones técnicas. Posteriormente, el modelo relacional tradujo estas entidades y relaciones en tablas, claves primarias y claves foráneas, resolviendo adecuadamente la relación muchos a muchos entre pedidos y productos mediante la entidad asociativa detalle_pedido. Esta tabla no solo vincula ambas entidades, sino que además almacena atributos propios, como la cantidad y el precio unitario, lo que evita redundancias y preserva información histórica relevante para el cálculo de totales.

La implementación en SQL refleja directamente estas decisiones de diseño, incorporando restricciones de integridad que garantizan la consistencia de los datos. El uso de claves primarias compuestas y claves foráneas formaliza las relaciones entre tablas, permitiendo que la base de datos rechace inconsistencias y facilite la construcción de consultas confiables. Tal como señala Godoc (2018), una estructura correctamente modelada permite realizar consultas robustas sin depender exclusivamente de validaciones externas. Finalmente, la inserción de datos de prueba y la ejecución de consultas de agregación demuestran el correcto funcionamiento del modelo implementado. El cálculo del total por pedido se realiza de manera eficiente mediante operaciones sobre la tabla detalle_ pedido, confirmando que el diseño propuesto permite responder adecuadamente a los requerimientos del sistema. En conjunto, este ejercicio muestra cómo un modelamiento riguroso constituye la base para sistemas de información coherentes, mantenibles y alineados con las necesidades del negocio. Diagrama de clases coherente con el modelo: Como continuación del modelo entidad–relación y del diseño relacional implementado, se presenta un diagrama de clases coherente con la base de datos del sistema. Las clases identificadas son Cliente, Producto, Pedido y DetallePedido, las cuales representan los mismos conceptos definidos previamente en el modelo de datos. En este contexto, la clase Pedido incorpora comportamiento propio del dominio mediante métodos como calcularTotal() y agregarProducto(). El método calcularTotal() permite obtener el total monetario del pedido a partir de los detalles asociados, mientras que agregarProducto() encapsula la lógica necesaria para incorporar productos al pedido, creando o actualizando instancias

de DetallePedido. De esta forma, el comportamiento del sistema se mantiene alineado con la estructura definida en la base de datos, donde los productos de un pedido se representan mediante registros en la tabla intermedia.

Figura 7: Diseño de clase Pedido, Producto, DetallePedido en un diagrama de clases UML

DetallePedido en un diagrama de clases UML Esta integración pone de manifiesto una idea esencial del diseño de sistemas de información: mientras el modelo entidad– relación organiza los datos, el diagrama de clases organiza el comportamiento. Cuando ambos enfoques no se integran adecuadamente, el desarrollo suele recurrir a soluciones improvisadas, como el almacenamiento de totales duplicados en las tablas o el recálculo descontrolado de valores en el código. En cambio, una integración coherente entre el diseño de datos y el diseño orientado a objetos favorece la consistencia, la mantenibilidad y la correcta evolución del sistema. Producto - idProducto:int - nombre: string - precio: decimal DetallePedido - cantidad: int - precioUnitario: decimal - producto: Producto Pedido - idPedido:int - fecha: date - estado: string - detalles: list + calcularTotal(): decimal + agregarProducto(p: Producto, cant: int): void 1..* 0..*

1.6. Errores comunes y criterios de calidad en ambos modelos Una parte crítica del aprendizaje y del ejercicio profesional consiste en reconocer errores típicos de diseño. Muchos problemas en bases de datos y en software no se originan en el uso de SQL o en la programación en sí, sino en un modelamiento incompleto, ambiguo o incoherente del dominio del problema. 1.6.1. Errores frecuentes en modelo ER Error 1: entidades que en realidad son atributos. Ejemplo: crear entidad Dirección cuando solo se necesita un texto simple. Esto se resuelve evaluando si Dirección tiene identidad propia y relaciones propias. Si no, puede ser atributo. Error 2: relaciones muchos a muchos sin entidad asociativa. Esto genera duplicación o imposibilidad de representar atributos de la relación. Ejemplo: pedido y producto sin detalle_pedido. Error 3: atributos multivaluados guardados en una sola columna. Ejemplo: teléfonos separados por comas en una columna. El diseño correcto suele ser una tabla teléfonos con relación uno a muchos. Error 4: cardinalidades mal definidas. Ejemplo: asignar relación uno a uno cuando en realidad es uno a muchos. Esto afecta claves foráneas y consultas. Capacho y Nieto (2017) sugieren validar cardinalidades con preguntas concretas del dominio. Por ejemplo: un docente puede dictar más de una . Si la respuesta es sí, entonces la relación no puede ser uno a uno.

1.6.2. Errores frecuentes en diagramas de clase Error 1: clases infladas con demasiadas responsabilidades. Ejemplo: una clase Pedido que valida pagos, actualiza stock, envía correos y genera reportes. Esto rompe cohesión. Error 2: uso incorrecto de herencia. Herencia debe representar una relación es un. Si solo se comparte código, puede ser mejor composición. Error 3: asociaciones sin sentido de propiedad. No distinguir composición y agregación puede causar diseños confusos, especialmente cuando la vida de objetos depende de otros. Error 4: diagrama desalineado con base de datos. Si el diagrama de clases asume relaciones que no existen en la base de datos, el código termina haciendo consultas complejas o duplicando datos. 1.6.3. Criterios de calidad integrados: consistencia, trazabilidad y consultas clave Un modelo de calidad permite responder consultas clave del sistema sin distorsionar datos. Godoc (2018) muestra que muchas consultas frecuentes se vuelven costosas o erróneas cuando faltan claves, cuando hay duplicación o cuando no se formalizan relaciones. Para evaluar calidad, se puede usar una lista breve de verificación:

• Cada entidad tiene clave primaria definida.

• Cada relación uno a muchos se implementa con clave foránea en el lado muchos.

• Cada relación muchos a muchos se resuelve con tabla intermedia.

• Los atributos pertenecen a la entidad correcta.

• No se guardan listas en una columna cuando se requiere normalización.

• El diagrama de clases refleja el dominio y se alinea con la estructura de datos.

• Los métodos están en clases con responsabilidades claras.

• Las relaciones UML no contradicen las restricciones de integridad. A modo de ejemplo, se presentan consultas clave del sistema académico y se indica qué diseño las soporta: consulta clave soporte en ER y relacional soporte en UML listar s de un estudiante entidad Inscripcion con fk a Estudiante y Estudiante. listaInscripciones() y asociaciones listar estudiantes por Inscripcion como tabla puente puede exponer detalles identificar docente responsable por fk en hacia Docente .docente filtrar inscripciones por estado atributo estado en Inscripcion Inscripcion.estado y métodos de cambio Tabla 3. consultas clave del sistema académico y su soporte Según Capacho y Nieto (2017), estas consultas se deben anticipar durante el diseño, porque influyen en claves, relaciones y consistencia. 1.7. Vínculo con procedimientos, triggers y scripts SQL de mediana complejidad Aunque el foco principal de este contenido es el modelo ER y el diagrama de clases, en proyectos reales se requiere implementar reglas y automatizaciones. En bases de datos, esto suele realizarse

con procedimientos almacenados y triggers. Godoc (2018) describe que SQL no solo sirve para consultar, también permite definir operaciones repetibles y consistentes, lo que resulta clave cuando se busca asegurar integridad y estandarizar comportamientos. Se presentan dos ejemplos breves, porque ilustran cómo una regla del negocio identificada en el modelo se implementa de forma controlada. 1.7.1. Ejemplo: procedimiento para inscribir estudiante Regla: no se debe permitir inscripción duplicada para el mismo estudiante y . Si se usa clave primaria compuesta, la base de datos evita duplicados. Aun así, un procedimiento puede manejar mensajes y estados. CREATE PROCEDURE sp_inscribir_estudiante ( IN p_id_estudiante INT, IN p_id_ INT, IN p_fecha DATE ) BEGIN INSERT INTO inscripcion ( id_estudiante, id_, fecha_inscripcion, estado ) VALUES ( p_id_estudiante, p_id_, p_fecha, ‘inscrito’ ); END;

Figura 8: procedimiento almacenado en SQL que inserta un registro de inscripción para

un estudiante en una , asignando automáticamente el estado “inscrito” y la fecha indicada.

Aquí la consistencia depende del modelo: la pk compuesta impide duplicación, y el procedimiento se limita a insertar. Según Godoc (2018), cuando las restricciones están bien definidas, los procedimientos se simplifican, porque la base de datos ya aplica reglas estructurales. 1.7.2. Ejemplo: trigger para validar stock en detalle de pedido Regla: no se debe registrar un detalle si la cantidad supera el stock disponible. CREATE TRIGGER trg_validar_stock BEFORE INSERT ON detalle_pedido FOR EACH ROW BEGIN DECLARE v_stock INT; SELECT stock INTO v_stock FROM producto WHERE id_producto = NEW.id_producto; IF NEW.cantidad > v_stock THEN SIGNAL SQLSTATE ‘45000’ SET MESSAGE_TEXT = ‘stock insuficiente para el producto’; END IF; END;

Figura 9: trigger en SQL que, antes de insertar un detalle de pedido, valida que la cantidad solicitada no su

cantidad solicitada no supere el stock disponible del producto y genera un error si no se cumple esta condición. Esta regla se relaciona con el modelo ER, porque existe una relación formal entre detalle_pedido y producto mediante fk. Si esa relación no existiera, el trigger no tendría un camino confiable para validar. Según Godoc (2018), la integridad referencial y la validación operativa se refuerzan cuando el esquema está bien modelado.

1.8. Cierre integrado: por qué ambos modelos son indispensables El modelo de entidad-relación y los diagramas de clase no compiten. Se necesitan mutuamente, porque resuelven problemas distintos de un mismo sistema. El modelo ER permite representar datos y relaciones con precisión conceptual, lo que se traduce luego en tablas, claves y restricciones. Los diagramas de clase permiten organizar el software con un enfoque orientado a objetos, incorporando atributos y métodos que expresan comportamiento. La integración entre ambos modelos sostiene la coherencia entre base de datos y aplicación, reduce errores, y mejora la capacidad de mantener y evolucionar sistemas complejos. Capacho y Nieto (2017) muestran que el requiere claridad conceptual para evitar inconsistencias y para asegurar integridad. Godoc (2018) evidencia que el trabajo con SQL resulta más eficaz cuando el esquema se construye con reglas sólidas, porque las consultas, procedimientos y validaciones se apoyan en una estructura coherente. En consecuencia, dominar el modelo ER y los diagramas de clase permite diseñar sistemas que no solo funcionan, sino que también se entienden, se justifican y se mejoran con el tiempo.

---

💡 Conclusión

El modelo de entidad-relación y los diagramas de clase constituyen pilares del diseño de sistemas de información coherentes y sostenibles. Su valor no reside solo en la representación gráfica, sino en la capacidad de ordenar el pensamiento, explicitar reglas del negocio y establecer una base común entre quienes analizan, diseñan y programan un sistema. Cuando ambos modelos se aplican de forma articulada, el diseño deja de ser una colección de decisiones aisladas y se transforma en un proceso trazable, en el que cada tabla, cada relación y cada clase responde a una necesidad concreta del dominio. El modelo ER asegura que los datos se almacenen con integridad, evitando redundancias y ambigüedades que luego encarecen las consultas y las validaciones. Los diagramas de clase, por su parte, permiten organizar el software con responsabilidades claras, favoreciendo la mantenibilidad y la evolución del sistema. Separados, ambos modelos resuelven problemas parciales; integrados, permiten que la base de datos y la aplicación se refuercen mutuamente. Un diseño que parte desde el modelamiento reduce la dependencia de soluciones correctivas posteriores, como validaciones excesivas en código o estructuras duplicadas en la base de datos. Tal como plantean Capacho y Nieto (2017), la claridad conceptual es condición para la integridad del sistema, y como muestra Godoc (2018), un esquema bien diseñado simplifica consultas, procedimientos y automatizaciones. En consecuencia, dominar y aplicar correctamente estos modelos no solo mejora la calidad técnica del sistema, sino que fortalece su comprensión, justificación y capacidad de adaptación en el tiempo.

---

---

🚀 Potencia tus proyectos tecnológicos con Proyecto Luna

En Proyecto Luna desarrollamos arquitectura de software de alto rendimiento, optimización de bases de datos críticas y soluciones aplicadas de inteligencia artificial y automatización para empresas y profesionales.

• 💼 Soluciones de ingeniería: Conoce nuestras capacidades y casos de estudio en proyectoluna.com/work/.
• 🛡️ Seguridad y auditoría: Orientación técnica y respuesta ante incidentes en ¿Te han hackeado?.
• 📩 Contacto directo: Escríbenos a través de nuestro formulario de contacto o a contacto@proyectoluna.com.

📚 Fuentes y lecturas recomendadas

• Godoc, E. (2018). SQL: los fundamentos del lenguaje (con ejercicios corregidos). ENI. Capacho, J., & Nieto, W. (2017). . Universidad del Norte.