CLIENTE Persona Empresa

CC42A – BASES DE DATOS
Profesores: Claudio Gutiérrez, Gonzalo Navarro
Auxiliar: Mauricio Monsalve
Auxiliar 1
Modelo Entidad-Relación – 16 de agosto de 2004
Recomendaciones preliminares:
- Un buen modelo ER se debería entender a simple vista;
más aún, debería dar a entender qué se está modelando
sin problemas.
- Cuando hagan un modelo ER deben tratar de evitar crear
campos id. Simplemente porque van en contra de la idea
de entender el problema a simple vista y porque no son
parte de lo que se quiere modelar (a menos que se
explicite lo contrario, naturalmente).
- Traten de evitar atributos con alta posibilidad de ser
NULL. Un NULL va en contra de un buen diseño ya que
aporta ambigüedad.
- En lo posible traten de evitar relaciones ternarias (o de
mayor aridad) y entidades débiles.
- Escojan llaves simples y representativas.
Problema 1: Modelar un sistema de ventas
Le contratan para hacer una BD que permita apoyar
la gestión de un sistema de ventas. La empresa
necesita llevar un control de proveedores, clientes,
productos y ventas.
Un proveedor tiene un RUT, nombre, dirección,
teléfono y página web. Un cliente también tiene RUT,
nombre, dirección, pero puede tener varios teléfonos
de contacto. La dirección se entiende por calle,
número, comuna y ciudad.
Un producto tiene un id único, nombre, precio actual,
stock y nombre del proveedor. Además se organizan
en categorías, y cada producto va sólo en una
categoría. Una categoría tiene id, nombre y
descripción.
Por razones de contabilidad, se debe registrar la
información de cada venta con un id, fecha, cliente,
descuento y monto final. Además se debe guardar el
precio al momento de la venta, la cantidad vendida y
el monto total por el producto.
Problema 2: Trabajos de fin de carrera (TFC)
Se ha decidido crear una BD de los TFC, que modele
a alumnos que los realizan, profesores que los
dirigen, temas de los que tratan y tribunales que los
corrigen. Por tanto, es de interés:
· Que los alumnos se definan por su número de
matrícula, RUT y nombre. Un alumno realiza,
evidentemente, sólo un T.F.C.
· Que los T.F.C. se definen por su tema, por un
número de orden y por la fecha de comienzo. Un
T.F.C. determinado, no puede ser realizado por
varios alumnos.
· Que un profesor se define por su RUT, nombre y
domicilio; y puesto que los T.F.C. son del área en el
que trabaja, NO interesa conocer el T.F.C. que dirige
sino a qué alumno se lo dirige.
· Que un Comité está formado por varios profesores
y los profesores pueden formar parte de varios
Comités. Por otra parte, sí es de interés para el
comité conocer qué alumno es el que se presenta,
con qué T.F.C. y en qué fecha lo ha defendido. El
comité se define por un número de tribunal, lugar de
examen y por el número de componentes.
· Al margen de esto, un alumno puede haber
pertenecido a algún grupo de investigación del que
haya surgido la idea del T.F.C. Dichos grupos se
identifican por un número de grupo, su nombre y por
su número de componentes. Un alumno no puede
pertenecer a más de un grupo y no es de interés
saber si el grupo tiene algo que ver o no con el
T.F.C. del alumno; sí siendo de interés la fecha de
incorporación a dicho grupo.
· Por otra parte, un profesor, al margen de dirigir el
T.F.C. de algunos alumnos, puede haber colaborado
con otros en la realización de dicho T.F.C. pero
siendo otro profesor el que lo dirige. En este caso,
sólo es interesante conocer qué profesor ha ayudado
a qué alumno (a un alumno le pueden ayudar varios
profesores).
Problema 3: ¿Modelo de datos?
El siguiente modelo ER ha llamado la atención del
auxiliar por su curiosa constitución. En efecto el
ejercicio es mejorar el modelo que está ahí.
Balance
#Cliente
Cta. Ahorro
Balance
CLIENTE
Cta. Corriente
Pers. De
Contacto
Persona
Sexo
Empresa
Fecha de
Nacimiento
Tipo
#Empleados
El modelo trata de un banco extraño que no deja que
sus clientes tengan más de una cuenta de ahorro ni
más de una cuenta corriente. Sí se quiere acceso
independiente a estos tipos de cuentas (tienen
manejos distintos, por ej. una cuenta de ahorro es
eterna, teóricamente). También se desea registrar los
movimientos de dinero y asociarlos a cada cuenta.
Además se desea tener la posibilidad de contactar y
tratar cordialmente a los clientes (de partida se
necesita el nombre).
Problema 4: Servicio Militar
¡Hay que hacer más expedito el proceso de
reclutamiento! Por ello se le ha contratado para servir
a la patria y bla-bla… bases de datos. Los datos
significativos a tener en cuenta son:
Un soldado se define por su código de soldado
(único), su nombre y apellidos, y su graduación.
Existen varios cuarteles, cada uno se define por su
código de cuartel, nombre y ubicación.
Hay que tener en cuenta que existen diferentes
Cuerpos del Ejército (Infantería, Artillería,...), y cada
uno se define por un código de Cuerpo y
denominación.
Los soldados están agrupados en compañías, siendo
significativa para cada una de éstas, el número de
compañía y la actividad principal que realiza.
Se desea controlar los servicios que realizan los
soldados (guardias, imaginarias, cuarteleros,...), y se
definen por el código de servicio y descripción.
Consideraciones de diseño:
Un soldado pertenece a un único cuerpo y a una
única compañía, durante todo el servicio militar. A
una compañía pueden pertenecer soldados de
diferentes cuerpos, no habiendo relación directa
entre compañías y cuerpos. Los soldados de una
misma compañía pueden estar destinados en
diferentes cuarteles, es decir, una compañía puede
estar ubicada en varios cuarteles, y en un cuartel
puede haber varias compañías. Eso si, un soldado
sólo esta en un cuartel. Además, un soldado realiza
varios servicios a lo largo de la mili. Un mismo
servicio puede ser realizado por más de un soldado
(con independencia de la compañía), siendo
significativa la fecha de realización.
SOLUCIÓN
•
P1.- Sistema de ventas
Nombre
ID
Descripción
Categoría
Número
Calle
(1,n)
Comuna
se
Ciudad
clasifica
Dirección
ID
Teléfono
Nombre
(1,1)
Proveedor
(1,n)
(1,1)
Provee
Precio
Producto
Stock
•
Exploten su conocimiento sobre los
problemas para hacer supuestos razonables.
Hay más de una forma de modelar un
problema.
Podría ser útil, además, recordar cómo se expresan
las cardinalidades. El siguiente dibujo representa
cómo se entiende una cardinalidad según la aridad
de una relación respecto a una entidad:
Diagrama explicativo de cardinalidad, formato (x,y):
(0,n)
RUT
(1,n)
Nombre
WEB
Cantidad
Detalle
ID
(1,n)
Venta
(1,1)
Nombre
RUT
Cliente
Teléfonos
Fecha
Monto Final
Descuento
Compra
(1,n)
Dirección
Comuna
Calle
Ciudad
Número
•
Recuerden usar el sentido común para
obtener las cardinalidades.
Este formato con forma de tuplas es bastante útil
pues especifica el número mínimo y máximo (o
simplemente la variedad) de la aridad de una relación
respecto a una entidad.
P2.- TFC
(Ejercicio para recalcar la forma de hacer modelos ER)
Cta. Ahorro
(0,1)
Nombre
Grupo
Balance
#Cliente
(1,1)
Se usa
Tipo
(1,1)
Nº matrícula
Pers.Natural
Alumno
Hace
(1,1)
Empresa
T.F.C.
(1,1)
(0,m)
RUT
(1,1)
(1,1)
Contacto
Examina
Dirige
C.I.
(1,1)
(0,n)
Es
parte
(n,m)
(1,n)
Tribunal
Nº
Monto
Fecha
#Empleados
Persona
Fecha de
Nacimiento
Nombre
Nombres
Sexo
Dirección
Teléfono
Apellido1
Nombre
Domicilio
GIRO
(0,1)
Fecha
Profesor
Nombre
(1,1)
Ayuda
(1,n)
(1,1)
(1,1)
Fecha
Nombre
RUT
Cta. Corriente
Tema
Nº
Se usa
Balance
de
(0,1)
Está
en
(0,n)
(1,1)
(1,1)
CLIENTE
(1,n)
Nº
de
Lugar
Apellido2
Número
Ciudad
Comuna
Nº tribunal
Calle
(Ahora sólo contempla alumnos que hacen TFC, ver enunciado)
Nota: Aquí no extendí ni los atributos Nombre ni
Domicilio, pero uds. saben que suelen ser atributos
compuestos; en Nombre van nombres y apellidos, y
en Domicilio van el número, la calle, la comuna, la
ciudad, etc. Domicilio es bien expandible.
Además puse, en Persona, a Nombres como un
atributo multivaluado. Es porque soy una excepción a
Igual esa no es la
la regla de los dos nombres…
solución óptima, ni tampoco es muy buena que
digamos. ¿Por qué? (Para meditar, varios motivos,
pero
nombres no debe ser multivaluado).
Ahora queda propuesto mejorar lo anterior (es
perfectamente mejorable). Para meditar: ¿Cómo
modelaría el caso de 40 tipos distintos de cuenta?
Por ejemplo, cuenta para la vivienda, cuentas PYME,
planes ejecutivos, cuentas para capital de trabajo,
etc. (Hint: Debe quedar más simple).
P3.- ¿Modelo de datos?
Viendo el dibujo original es posible percatarse que no
hay llaves, no hay cardinalidades y que no hay
información suficiente en éste como para trabajar el
problema. Entonces del dibujo original:
Balance
#Cliente
Cta. Ahorro
(Ejercicio sencillo para llenar 10 minutos de auxiliar)
Balance
CLIENTE
Cta. Corriente
Pers. De
Contacto
Persona
Sexo
Empresa
Fecha de
Nacimiento
P4.- Servicio Militar
Tipo
#Empleados
Se puede elaborar un poquito y conseguir lo
siguiente (una de tantas alternativas):