Modelo de Base de Datos para Un Sistema DEFINITIVO

Modelo de base de datos para
un sistema de facturación
Michael Velásquez Rodríguez

1. Creamos la identidad principal
FACTURA
#Id-factura Una vez creada la identidad principal, se puede apreciar

*Fecha de factura que algunos atributos tienen una mayor relación entre
*Total factura
*Número cliente interno ellos, que con su llave principal. Por tal motivo, nos
*Número vendedor interno remitimos a la 3 Forma Normal y eliminamos los
*Nombre vendedor atributos dependientes de atributos que no son parte del
*Nit del vendedor
*Dirección del vendedor
identificador único, y creamos nuevas identidades.
*Contacto del vendedor
*Id-cliente Como se puede apreciar en la imagen de la entidad
*Nombre-cliente factura, hay 4 grupos de atributos que tienen más
*Dirección-cliente
*Teléfono del cliente relación entre ellos que con su llave principal. Por lo
*Identificación del cliente tanto, creamos una identidad para cada uno.
*Forma de pago
*Número de pago
*Detalles de pago Nota: No se observa la 2 Forma Normal de modelado
*Id-producto porque como se puede apreciar en la entidad FACTURA
*Categoría producto
solo hay una llave principal o identificador único, no hay
*Nombre producto
*Cantidad de producto una llave compuesta.
*Precio producto
*Stock
2. Creamos las entidades con su llave y las relacionamos con las demás entidades.
VENDEDOR
#Nit del vendedor

*Nombre vendedor
PRODUCTO
CLIENTE
FACTURA
#Id-producto
#Identificación del cliente
#Id-factura *Categoría producto
*Nombre-cliente
*Fecha de factura *Nombre producto
*Dirección-cliente
*Stock
*Teléfono del cliente
*Precio producto
MODO DE PAGO
#Número de pago
*Forma de pago
*Detalles de pago
Explicación de la relaciones anteriores:
• Existe una relación uno a muchos entre cliente y factura (Un solo cliente puede tener
muchas facturas, pero debe tener al menos 1, no viceversa).
• Existe una relación uno a muchos entre vendedor y facturas (Un solo vendedor puede
dar muchas facturas, pero debe dar al menos 1, no viceversa).
• Existe una relación uno a muchos entre factura y método de pago, donde el negocio
recibe un pago por los productos y el cliente puede usar varios métodos de pago.
• Pero, existe una relación muchos a muchos entre las entidades PRODUCTO y
FACTURA, ya que una factura puede tener muchos productos, y un producto puede estar
en muchas facturas (Debemos reemplazar esta relación dada su complejidad).
Solución a la relación compleja muchos a muchos entre
producto y factura.
• Creamos una nueva entidad que relaciona estas dos entidades: La denominaremos DETALLE y le asignamos su llave foránea de detalle para
ordenar mejor los datos.
VENDEDOR
#Nit del vendedor

*Nombre vendedor
PRODUCTO
CLIENTE
FACTURA DETALLE
#Id-producto
#Id-cliente
#Id-factura #número detalle *Categoría producto
*Nombre-cliente
*Fecha de factura #Id-factura *Nombre producto
*Dirección-cliente
*Cantidad de producto *Stock
*Teléfono del cliente
*Precio producto
MODO DE PAGO
#Número de pago
*Forma de pago
*Detalles de pago
Explicación de la relación entre DETALLE, FACTURA
Y PRODUCTO.
• Nótese que ahora la relación entre FACTURA y DETALLE es de uno a muchos y

entre PRODUCTO y DETALLE es igualmente uno a muchos. Se ha eliminado el
problema que existía con la relación muchos a muchos.
• Se aclara que en la entidad DETALLE se escogió la llave compuesta: número detalle y Id-
factura porque existe pocos tipos para Id-factura lo que permite ordenar la tabla de
datos más fácilmente. Si se hubiera escogido la llave compuesta: número detalle y Id-
producto, es probable que existan muchos códigos de Id-producto, tantos como
productos existan, lo que dificultaría el orden de la base de datos. Aunque ambas
opciones son posibles.
Hacemos una revisión y notamos que en la entidad PRODUCTO, el
atributo Categoría producto se repetirá varias veces por todos los
registros (es redundante).
• Aquí nos encontramos con la 1ra forma normal, que indica que si un
atributo se repite en una entidad, lo óptimo es convertirlos en otra
entidad.
• De esta manera establecemos la entidad CATEGORÍA y se le asigna su
llave foránea: Id-categoría.
MODELO FINAL DE FACTURACIÓN.
VENDEDOR
#Nit del vendedor

*Nombre vendedor
CLIENTE DETALLE PRODUCTO

FACTURA
#Id-cliente #número detalle #Id-producto
*Nombre-cliente #Número factura #Id-factura *Nombre producto
*Dirección-cliente *Fecha de factura *Id-producto *Stock
*Teléfono del cliente *Cantidad de producto *Precio producto
CATEGORIA
MODO DE PAGO
#Id-categoria
#Número de pago *Nombre
*Forma de pago *Descripción
*Detalles de pago
*Id-producto
Apreciaciones finales
• Se construyó el modelo de base de datos para un sistema de

facturación, iniciando desde la entidad principal FACTURA, y
revisando cada una de las formas normales.
• Se corrigieron los relaciones complejas muchos a muchos.

Modelo de Base de Datos para Un Sistema DEFINITIVO

Cargado por

Copyright:

Formatos disponibles

Modelo de Base de Datos para Un Sistema DEFINITIVO

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Modelo de Base de Datos para Un Sistema DEFINITIVO

Cargado por

Copyright:

Formatos disponibles

Modelo de base de datos para

Michael Velásquez Rodríguez

#Id-factura Una vez creada la identidad principal, se puede apreciar

#Nit del vendedor

#Nit del vendedor

• Nótese que ahora la relación entre FACTURA y DETALLE es de uno a muchos y

#Nit del vendedor

CLIENTE DETALLE PRODUCTO

• Se construyó el modelo de base de datos para un sistema de

• Se corrigieron los relaciones complejas muchos a muchos.

También podría gustarte