Modelamiento y Normalizacion BBDD

Control 1: “Modelamiento y normalización de base de datos”

Marco A. González Ledezma

Administración de Bases de Datos

Instituto IACC

18 de diciembre de 2016

Desarrollo

Con respecto al siguiente caso de ejemplo:

“Una empresa de ventas de electrodomésticos al detalle lo ha contratado en su calidad de experto, para el modelamiento de su futuro sistema de ventas, inventario y cuentas por cobrar, por lo que le solicitan realizar el diseño de una base de datos”

1. Con respecto al tipo de modelado en mi caso utilizaré el de “Entidad-Relación” ya que es el que más utilizado y considero práctico para el modelamiento de una base de datos y sus respectivas tablas.
2. El modelado de datos para un sistema como el solicitado sería más complejo que lo que aquí se presentará, pero como para un ejemplo básico de modelamiento considero que las siguientes entidades son más que necesarias para cumplir con ese objetivo:

Entidad: Clientes

Atributos: RUT, Nombre, Dirección, Teléfono, Correo Electrónico

Entidad: Facturas

Atributos: Número, Fecha, RUT Cliente, Nombre Cliente, Dirección Cliente, Teléfono Cliente, Correo Electrónico Cliente, Productos, Cantidad Productos, Precio Productos

Entidad: Productos

Atributos: Código, Descripción, Valor

1. Tomando las entidades antes mencionadas para una base de datos de facturación muy sencillo, tal como explique en el punto anterior, procederé a llevarlo a la Tercera Forma de Normalización de Datos (trataré de ser breve debido a la restricción de palabras a utilizar en este control):

1. Comprendiendo que debo de verificar que cada dato contenido en una BD no deben de estar repetidos ya que provocarán redundancia y un espacio físico “desperdiciado” en disco es que de la entidad “Facturas” comprendo que hay varios datos que se repetirán como por ejemplo los datos de los clientes que no dependen directamente una factura ya que estos existirán aunque no existan facturas, por lo cual si quito los campos de los clientes y dejo solamente un identificados cumpliría una forma.
2. Al igual que el caso anterior de los clientes, de la entidad “Facturas” puedo quitar los datos de los productos ya que la descripción y el valor (y por ejemplo el color, marca y otros representativos) son datos que no dependen de una factura ya que un producto puede existir haya o no hayan facturas.
3. Tomando lo antes planteado es que comienzo a definir cada entidad en una tabla de la siguiente forma:

Tabla: Clientes

Columnas: RUT Cliente (como llave primaria ya que no puede haber dos clientes con el mismo RUT), Nombre, Dirección (debo aclarar que este campo podría estar compuesto por datos que podrían repetirse pero como esto es un ejemplo básico de modelamiento favor de no tomar en consideración), Teléfono y Correo Electrónico.

Tabla: Productos

Columnas: Código Producto (como llave primaria ya que no puede haber dos productos con el mismo código), Descripción, Valor.

Tabla: Facturas

Columnas: Número Factura (como llave primaria para identificarla y para posteriormente asociar cada producto a esta), Fecha, RUT Cliente

Tabla: ProductosXFactura

Columnas: Número Factura, Código Producto, Cantidad Producto

1. Ahora bien, finalmente, no se considera la columna para almacenar el total de un producto en una factura ya que este se calcularía tomando la cantidad de producto por el valor del producto y si este campo se almacena en la BD provocaría redundancia (obviamente esto es subjetivo ya que en algún caso el cliente que solicita el sistema podría solicitar por ejemplo hacer cálculos de valor tomando variables tales como tipo de pesos sea chilenos, dólares, etc. Como además usando otras tablas de valores).

...