Especialización en Gestión de Tecnologías de la Información

FUNDAMENTOS DE INTELIGENCIA DE NEGOCIO

ACA 3

DISEÑO DE BASE DE DATOS PARA MARKETSMART S.A.S.

Presentado por:

Luis Efren Murillo Asprilla

Alexander Alfonso Gutiérrez Igiri0

Emir Johan Mena Velásquez

Apartadó, Antioquia. Abril 18 de 202

Introducción

En el contexto actual, donde las decisiones empresariales deben ser tomadas con base en
información precisa y en tiempo real, el diseño de bases de datos cobra un papel
fundamental para garantizar el adecuado manejo y análisis de los datos. El presente trabajo
tiene como propósito transformar un requerimiento empresarial, en este caso el de la
empresa MarketSmart S.A.S., en una estructura de datos organizada, eficiente y coherente
que soporte su sistema de inteligencia de negocios. A través de un proceso estructurado de
análisis, diseño conceptual, lógico y físico, se establece una base de datos relacional que
representa fielmente los procesos operativos y transaccionales de la empresa. El desarrollo
de este ejercicio permite afianzar competencias clave en modelado de datos, normalización,
integridad referencial y planificación de estructuras que respondan a necesidades reales del
entorno empresarial.

Objetivo General

Diseñar una base de datos relacional a partir de un requerimiento empresarial para

garantizar una estructura de datos organizada, funcional y alineada con los procesos de
negocio de la empresa MarketSmart S.A.S.

Objetivos Específicos

 Analizar el requerimiento de información suministrado por la empresa para

identificar las entidades, atributos y relaciones clave del negocio.
 Elaborar un modelo Entidad-Relación (ER) que represente conceptualmente la
estructura de datos necesaria.
 Transformar el modelo conceptual en un modelo lógico relacional que garantice
integridad, coherencia y escalabilidad.
 Establecer el diseño físico con los tipos de datos y restricciones apropiadas para la
implementación de la base de datos.
 Reflexionar sobre la experiencia y el proceso de traducción de un requerimiento
empresarial a una solución técnica de almacenamiento de datos.
1. Análisis del requerimiento
El primer paso fundamental en el diseño de una base de datos es realizar un análisis
detallado del requerimiento del negocio, ya que de este proceso depende la calidad y
funcionalidad del modelo final. En este caso, el requerimiento es presentado por la empresa
ficticia MarketSmart S.A.S., dedicada a la comercialización en línea de productos
tecnológicos como computadores, celulares y accesorios. La empresa ha manifestado su
intención de implementar una solución de inteligencia de negocios, lo cual implica la
necesidad de estructurar adecuadamente su información para posibilitar su posterior
análisis.

A partir del requerimiento, se identifican cinco procesos clave que deben estar
representados en la base de datos: la gestión de clientes, productos, proveedores, ventas y
medios de pago. Para representar estos procesos, se deben establecer entidades principales
y sus respectivas relaciones. Por ejemplo, un cliente puede realizar múltiples compras, una
venta puede incluir varios productos, y cada producto tiene un proveedor asociado. Esta
relación entre los distintos componentes del negocio debe quedar plasmada de forma clara
y precisa en el modelo de datos.

El análisis también permite definir los atributos clave que deben ser registrados para cada
entidad, tales como nombre, identificación, correo, precio, cantidad, fechas, entre otros.
Asimismo, se deben tener en cuenta restricciones del negocio, como la unicidad de los
identificadores, la obligatoriedad de ciertos campos y la necesidad de garantizar la
integridad referencial mediante el uso de claves primarias y foráneas.

Además, se contempla desde esta etapa la necesidad de evitar la redundancia de datos, lo

que será abordado en fases posteriores mediante el proceso de normalización. El análisis
inicial incluye una lluvia de ideas que permite visualizar desde un enfoque lógico y práctico
cómo deberían organizarse los datos, lo cual guía las decisiones de modelado conceptual.

Este primer acercamiento sienta las bases para construir una base de datos sólida, alineada
con los objetivos de negocio de MarketSmart S.A.S., y lo suficientemente flexible para
responder a futuras necesidades de análisis y expansión
2. Diagrama Entidad-Relación (Modelo conceptual)

El modelo conceptual está representado mediante un diagrama Entidad-Relación (ER)

que define de forma gráfica y estructurada las entidades principales del sistema, sus
atributos, claves primarias y foráneas, así como las relaciones entre ellas. Este modelo
facilita la comprensión del dominio del problema y es la base para el diseño lógico
posterior.

Entidades incluidas:

 Cliente: Representa a los usuarios que realizan compras. Se identifican por un ID

único y tienen atributos como nombre, identificación, correo, celular y dirección.
 Proveedor: Representa las empresas o personas que suministran productos a
MarketSmart. Incluye atributos como NIT, ciudad, país y contacto.
 Producto: Son los bienes disponibles para la venta. Tienen nombre, categoría,
descripción, precio unitario y están asociados a un proveedor.
 Medio de Pago: Define las distintas formas en las que un cliente puede pagar
(efectivo, tarjeta, etc.).
 Venta: Registra cada transacción realizada por un cliente, indicando la fecha, total
pagado y medio de pago.
 Detalle de Venta: Tabla intermedia que vincula productos y ventas, permitiendo
registrar múltiples productos por venta y las cantidades correspondientes.

Relación entre entidades:

 Cliente - Venta (1:N): Un cliente puede hacer muchas ventas. Cada venta es
realizada por un solo cliente.
 Proveedor - Producto (1:N): Un proveedor puede ofrecer múltiples productos.
Cada producto pertenece a un solo proveedor.
 Venta - Detalle de Venta (1:N): Una venta puede tener múltiples productos
(detalles). Cada detalle pertenece a una venta específica.
 Producto - Detalle de Venta (1:N): Un producto puede estar en muchas ventas
distintas. Cada detalle contiene un único producto.
 Medio de Pago - Venta (1:N): Un medio de pago puede estar asociado a varias
ventas. Cada venta se paga con un único medio.

Propósito del modelo ER:

El modelo conceptual permite:

 Visualizar de forma clara la estructura del sistema.

 Identificar cómo se relacionan las entidades clave del negocio.
 Establecer las restricciones de integridad y relaciones necesarias.
 Servir como guía para la implementación lógica y física de la base de datos.

A continuación, se presenta una descripción estructurada del modelo conceptual mediante

entidades y relaciones:
3. Modelo lógico relacional (tablas y relaciones)

El modelo lógico relacional es una representación estructurada de la información definida

en el modelo conceptual, adaptada a una base de datos relacional. En este modelo se definen
las tablas (entidades), sus atributos (columnas), así como las relaciones entre ellas
mediante claves primarias y foráneas, respetando las reglas de normalización para
garantizar la integridad y eficiencia.

Características del modelo:

 Cada entidad conceptual fue transformada en una tabla relacional.

 Se definieron claves primarias para identificar de forma única cada registro.
 Se asignaron claves foráneas para establecer las relaciones entre las tablas.
 Se aplicó normalización hasta 3FN para eliminar redundancias y dependencias
innecesarias.
  Se asignaron tipos de datos apropiados para cada atributo, teniendo en cuenta su
naturaleza (texto, fecha, número, etc.).

Ventajas del modelo lógico relacional:

 Integridad referencial: Gracias al uso de claves foráneas, se asegura que los datos
estén correctamente relacionados. Por ejemplo, no se pueden registrar ventas de
productos inexistentes.
 Eficiencia en las consultas: La organización en tablas independientes y bien
relacionadas permite realizar búsquedas, filtros y reportes complejos de forma
rápida y precisa.
 Escalabilidad: La estructura puede crecer fácilmente a medida que aumentan los
datos, sin perder coherencia.
 Mantenimiento y actualización simplificados: Al eliminar la redundancia, se
minimiza el riesgo de inconsistencias al modificar los datos.

Ejemplo de relaciones establecidas:

 La tabla CLIENTES se relaciona con VENTAS mediante id_cliente, estableciendo

una relación de uno a muchos.
 PRODUCTOS está relacionada con DETALLE_VENTA, permitiendo registrar
múltiples productos por venta.
 PROVEEDORES se asocian con PRODUCTOS, permitiendo conocer el origen de
cada artículo.
 La tabla VENTAS contiene una referencia a MEDIOS_DE_PAGO, indicando cómo se
efectuó cada compra.

Este modelo es esencial para la implementación efectiva del sistema en un gestor de bases
de datos como MySQL, PostgreSQL o SQL Server, permitiendo tanto el almacenamiento
como el análisis de datos que respalden la toma de decisiones de la empresa.

A continuación el modelo

1. CLIENTES

Campo Tipo de Dato Clave

id_cliente INT PK
nombre_completo VARCHAR(100)
identificacion VARCHAR(20) UNIQUE
correo VARCHAR(100)
celular VARCHAR(20)
direccion VARCHAR(150)

2. PROVEEDORES
 Campo Tipo de Dato Clave
id_proveedor INT PK
nombre_proveedor VARCHAR(100)
NIT VARCHAR(20) UNIQUE
ciudad VARCHAR(50)
pais VARCHAR(50)
correo VARCHAR(100)
telefono VARCHAR(20)

3. PRODUCTOS

Campo Tipo de Dato Clave

id_producto INT PK
nombre_producto VARCHAR(100)
descripcion TEXT
categoria VARCHAR(50)
precio_unitario DECIMAL(10,2)
stock_disponible INT
id_proveedor INT FK → PROVEEDORES(id_proveedor)

4. MEDIOS_DE_PAGO

Campo Tipo de Dato Clave

id_medio_pago INT PK
nombre VARCHAR(50)
descripcion VARCHAR(150)

5. VENTAS

Campo Tipo de Dato Clave

id_venta INT PK
id_cliente INT FK → CLIENTES(id_cliente)
fecha_venta DATE
total_pagado DECIMAL(12,2)
id_medio_pago INT FK → MEDIOS_DE_PAGO(id_medio_pago)

6. DETALLE_VENTA (Tabla intermedia entre VENTAS y PRODUCTOS)

 Campo Tipo de Dato Clave
id_detalle INT PK
id_venta INT FK → VENTAS(id_venta)
id_producto INT FK → PRODUCTOS(id_producto)
cantidad INT
precio_unitario DECIMAL(10,2)
subtotal DECIMAL(12,2)

🔄 Relaciones entre tablas

 CLIENTES 1 ←→ N VENTAS
 PROVEEDORES 1 ←→ N PRODUCTOS
 PRODUCTOS N ←→ N VENTAS a través de DETALLE_VENTA
 MEDIOS_DE_PAGO 1 ←→ N VENTAS
4. Listado de atributos y tipos de datos sugeridos

Para llevar a cabo la implementación física de la base de datos es fundamental definir, de

manera precisa, los atributos que conforman cada entidad, junto con sus respectivos tipos
de datos y restricciones. Esta definición no solo garantiza la integridad de la información,
sino que también optimiza el rendimiento de las consultas, facilita el mantenimiento y
asegura la escalabilidad del sistema. A continuación, se presenta un listado detallado de
los atributos por tabla, especificando el tipo de dato más adecuado para cada uno, de
acuerdo con su naturaleza y función dentro del modelo relacional diseñado.

TABLA ATRIBUTO TIPO DE DATO SUGERIDO

CLIENTE id_cliente INT AUTO_INCREMENT

CLIENTE nombre VARCHAR(100)

CLIENTE identificacion VARCHAR(20) UNIQUE

CLIENTE correo VARCHAR(100)

CLIENTE celular VARCHAR(15)

CLIENTE direccion VARCHAR(150)

PROVEEDOR id_proveedor INT AUTO_INCREMENT

PROVEEDOR nombre VARCHAR(100)

PROVEEDOR NIT VARCHAR(20) UNIQUE

PROVEEDOR ciudad VARCHAR(50)

PROVEEDOR pais VARCHAR(50)

PROVEEDOR correo VARCHAR(100)

PROVEEDOR telefono VARCHAR(15)

PRODUCTO id_producto INT AUTO_INCREMENT

PRODUCTO nombre VARCHAR(100)

PRODUCTO descripcion TEXT

PRODUCTO categoria VARCHAR(50)

PRODUCTO precio_unitario DECIMAL(10,2)

 PRODUCTO stock INT

PRODUCTO id_proveedor INT (FK)

MEDIO_PAGO id_medio_pago INT AUTO_INCREMENT

MEDIO_PAGO nombre VARCHAR(50)

MEDIO_PAGO descripcion TEXT

VENTA id_venta INT AUTO_INCREMENT

VENTA fecha DATE

VENTA total_pagado DECIMAL(12,2)

VENTA id_cliente INT (FK)

VENTA id_medio_pago INT (FK)

DETALLE_VENTA id_venta INT (PK, FK)

DETALLE_VENTA id_producto INT (PK, FK)

DETALLE_VENTA cantidad INT

DETALLE_VENTA precio_unitario DECIMAL(10,2)

DETALLE_VENTA subtotal DECIMAL(12,2)

5. Justificación de decisiones tomadas

Las decisiones tomadas durante el diseño de la base de datos responden a la necesidad de
lograr un modelo eficiente, normalizado y fácilmente escalable. Se utilizaron claves
primarias con autoincremento para garantizar unicidad y facilitar la gestión de registros.
Las claves foráneas aseguran la integridad referencial entre las entidades, evitando
inconsistencias.

La creación de la tabla intermedia DetalleVenta permite modelar correctamente la relación

muchos a muchos entre ventas y productos, además de registrar información detallada
como cantidad, precio aplicado y subtotal por ítem. Los medios de pago se almacenan en
una tabla independiente para evitar duplicación de datos en cada venta.

Además, se respetaron los principios de normalización hasta la Tercera Forma Normal

(3FN), eliminando la redundancia de datos y garantizando la integridad lógica del modelo.
6. Reflexión final
El proceso de transformar un requerimiento empresarial en una base de datos funcional ha
sido altamente formativo. Esta experiencia permite comprender cómo las estructuras
abstractas del negocio se traducen en elementos técnicos que, organizados de forma
coherente, permiten un análisis eficaz de la información. A través del diseño conceptual,
lógico y físico, se evidencia la importancia de identificar correctamente las entidades,
relaciones y atributos para construir una base de datos robusta, que garantice la integridad
y disponibilidad de los datos.

Este tipo de ejercicios también muestra cómo una base de datos bien diseñada es
fundamental para procesos de inteligencia de negocios, ya que facilita la toma de decisiones
informadas a partir de datos reales. En resumen, este trabajo refuerza la importancia del
análisis estructurado, la planificación y el uso adecuado de las herramientas de modelado
para responder de manera efectiva a las necesidades informativas de las organizaciones
modernas.

Anexo: Ejemplos de consultas SQL útiles

-- Obtener todas las ventas realizadas por un cliente específico

SELECT v.id_venta, [Link], v.total_pagado
FROM VENTA v
JOIN CLIENTE c ON v.id_cliente = c.id_cliente
WHERE [Link] = '123456789';

-- Consultar el stock actual de los productos de una categoría específica

SELECT nombre, stock
FROM PRODUCTO
WHERE categoria = 'Celulares';

-- Listar los productos vendidos en una venta específica

SELECT [Link], [Link], dv.precio_unitario, [Link]
FROM DETALLE_VENTA dv
JOIN PRODUCTO p ON dv.id_producto = p.id_producto
WHERE dv.id_venta = 1001;

Bibliografía

 Coronel, C., & Morris, S. (2019). Database Systems: Design, Implementation, &
Management (13th ed.). Cengage Learning.
 Elmasri, R., & Navathe, S. (2017). Fundamentals of Database Systems (7th ed.).
Pearson.
 Silberschatz, A., Korth, H. F., & Sudarshan, S. (2020). Database System Concepts (7th
ed.). McGraw-Hill Education.
 Microsoft. (2024). SQL Server Documentation. Recuperado de:
[Link]
 Oracle. (2024). Oracle Database Concepts Guide. Recuperado de:
[Link]