Caso Practico 1.

El caso práctico que analizaremos corresponde a la Empresa distribuidora de

regalos, novedades y artículos para fiestas “Florería Carmen” Esta compañía ficticia
persigue la meta de automatizar la oficina, enfrentándose a los problemas del mundo
empresarial real.

El gerente de la Compañía, reconoce que, para que el negocio tenga éxito, debe
automatizar gran parte de las transacciones de la compañía, Usted debe debe implantar
sistemas para contactos de clientes, inventario y facturación que sean a la vez
personalizados y lo suficientemente flexibles para cambiar con el tiempo.

También se reconoce que la compañía subirá o bajara en función de su acceso a

la información, por lo que se ha decidido utilizar un sistema de bases de datos
relacionales para administrar la información de la compañía.
 Caso Practico 1.2

Los alumnos del V Semestre de la especialidad de Computación e Informática

han determinado que la “Florería Carmen” necesita un medio para almacenar la
información de los clientes.

Están bastante seguros de que la mayoría de los negocios serán repetitivos y, por
tanto, desea poder volver a ponerse en contacto con los clientes y enviarles los catálogos
dos veces al año.

Inicialmente se propone un esquema básico de la base de datos. Esto es lo que la

empresa necesita controlar (primeros pasos)

 El nombre del cliente

 La dirección, ciudad, estado, código postal y número de teléfono

 Región del país (Noreste, Suroeste, Centro Oeste, Noreste, Sur o Sureste)

 Fecha de la última compra del cliente

Los alumnos de CI también piensan que debería incluir toda esta información en una
única base de datos para mantenerla sencilla.

El intrépido equipo de programadores de base de datos conformado por los alumnos

de CI del V, dicen que seria posible pero tendrían una base de datos ineficaz,
desorganizada y extremadamente inflexible.

La información que los alumnos desean incluir no se corresponde directamente con

los campos de la base de datos. Por ejemplo, debido a que la región es una función del
estado en que reside una persona, no tiene sentido tener un campo Estado y un campo
Región en la misma tabla. Esto significaría que el operador de entrada de datos debería
introducir dos veces información similar acerca de un cliente. En cambio, tendría mucho
mas sentido que la base de datos almacenara el campo Estado en la tabla Clientes y la
información relativa a las regiones en la tabla Región. Si la tabla Región sabe que
estados corresponden a cada una de las regiones, el operador de entrada de datos no
tendrá que introducir la región de cada cliente. Simplemente introducirá el estado y la
tabla Clientes trabajara con la tabla Región para determinar la región a la que pertenece
el cliente.

De forma similar, al dividir el campo de Nombre en Nombre y Apellido, la

ordenación por esos campos será más fácil después de introducir los datos en ellos. Si lo
piensa, este aspecto del diseño puede parecer trivial, pero es sorprendente cuantos
diseños de bases de datos no tienen en cuenta este tipo de cosas y después resulta difícil
corregir este error una vez instalado la base de datos.
 Por tanto, el equipo de diseño de base de datos y el equipo de programadores han
determinado que los clientes de la “Florería Carmen” deben almacenarse en una tabla
denominada tblClientes, que contiene los siguientes campos.

tblClientes

ID

Nombre

Apellido

Compañía

Dirección

Ciudad

Estado

Teléfono

Fax

Email

Los datos que pertenecen a la región del país del cliente deben almacenarse en una tabla
denominada tblRegion. Esta tabla tiene los siguientes campos.

tblRegion

Estado

Región

Existe una relación entre las dos tablas a través del campo Estado.

Observe que este campo está presente en ambas tablas. La relación entre la tabla
Región y la tabla Clientes es una relación de uno a varios; por cada registro de la tabla
tblRegion puede haber ninguno, uno o varios registros que coincidan en la tabla
tblClientes.

Observe como el equipo de diseñadores de base de datos ha asignado los

nombres de los campos y tablas en los diseño preliminares de las tablas. Primero, ha
asignado a cada tabla el prefijo tbl. Esto le permite distinguir, a simple vista, que se trata
de una tabla en lugar de otro tipo de objeto de base de datos que puede almacenar
registros.
 A continuación, observe que el nombre de cada campo esta formado por palabras
completas (en lugar de abreviaturas) que no contienen espacios ni caracteres especiales
como el signo subrayado.

Aun falta una cosa en la lista deseos del equipo de diseñadores de base de datos.
La respuesta a la pregunta. ¿Cuándo fue la última vez que este cliente nos ha comprado
algo?. El equipo de programadores de la base de datos decide que esta información se
puede determinar a partir de los valores de las fecha que aparece en la tabla que
almacena los datos relativos a los pedidos de clientes. Esta tabla tiene el siguiente
esquema.

tblPedidos

ID

ClienteID

FechaDePedido

ItemID

CantidadDePedido

En esta tabla, el campo ID identifica de forma exclusiva cada pedido. Por otra parte, el
campo ClienteID conecta un pedido con un cliente. Para adjuntar un pedido a un cliente,
la identificación del cliente se copia en el campo ClienteID de la tabla tblPedidos. De
este modo será fácil consultar todos los pedidos de un cliente determinado.