Ejemplo_resuelto_-_Seguros

8/2/2019 Ejemplo_resuelto_-_Seguros

1/8

1. Ejemplo resuelto: Seguros.Como es importante practicar, te vamos a proporcionar unejemplo resuelto para que te pueda servir de gua en el

proceso de transformacin de los diagramas E/R en

esquemas relacionales.

Enunciado:

Una compaa de seguros de automviles quiere crear unabase de datos que recoja el funcionamiento de su negocio

y que se refleja en los siguientes supuestos semnticos:

El elemento fundamental de informacin es la pliza, la cul se identifica mediante un nmeronico, tiene un tipo de seguro (a todo riesgo, a terceros, etc.), un importe de cobertura mxima y

un estado (alta, baja, suspensin, etc.). La pliza pertenece a un nico cliente (un cliente puede

tener ms de una pliza diferente) y referencia a un nico vehculo y cada vehculo slo puedetener una pliza.

Los clientes se identifican mediante su NIF, adems se quiere guardar su nombre y apellidos, sutelfono, fecha de nacimiento, fecha de obtencin del permiso de conducir y su direccin

completa (calle, nmero, ciudad, cdigo postal y provincia). De los vehculos es importante conocer su nmero de chasis, su matrcula, la marca, el modelo,

la potencia, el ao de fabricacin y el color. Adems un vehculo puede tener una serie de extras

(alarma, radio, etc.) de los que guardaremos un cdigo identificador y el nombre del extra.

Una pliza puede tener una serie personas autorizadas, de las cuales se quiere tener su NIF,nombre y apellidos, fecha de nacimiento y relacin con el cliente. Un autorizado slo tendr

relacin con un nico cliente.

Cuando se produce un siniestro, se crea un parte de accidente (identificado por un nmero de

siniestro) donde se recoge la informacin del siniestro: datos de la pliza del cliente, datos delconductor (slo puede ser el cliente, o alguien autorizado), fecha del siniestro, datos del taller

donde se va a reparar el vehculo y fecha e importe de la reparacin. Si el accidente es contra

otro vehculo no se guardan ninguna informacin del vehculo contrario, si es de la misma

compaa el cliente ya dar su propio parte de accidente.

Los datos del taller que se almacenan sern, el nombre, la direccin y el telfono adems de un

cdigo identificador.

Comenzaremos desarrollando el modelo E/R

1.1Identificando Entidades y Relaciones.

Empezamos identificando las entidades, para ello leemos el texto e intentamos identificar los

sustantivos o sintagmas nominales que puedan representar algo importante en nuestro sistema deinformacin. En este caso una compaa de seguros de automviles.

Podemos considerar las siguientes entidades: POLIZA, CLIENTE, VEHICULO, EXTRA,AUTORIZADO, SINIESTRO y TALLER.

Podramos considerarlas todas como entidades fuertes, o hay alguna que en principio pueda ser

una entidad dbil?

Si analizas con detenimiento los requisitos, las entidades AUTORIZADO y SINIESTRO son entidades

dbiles de CLIENTE y POLIZA respectivamente.

Continuamos nuestro estudio identificando las relaciones,para ello volvemos a leer el texto.

De qu manera se relacionan las entidades que hemos descubierto en el paso anterior?

Claramente, POLIZA se relaciona con CLIENTE mediante una relacin que podemos llamar tiene,POLIZA se relaciona mediante referenciacon VEHICULO, que a su vez se relaciona con EXTRA


2/8

mediante esta_equipado. Por otro lado, CLIENTE se relaciona mediante sufre_cli conSINIESTRO, al igual que AUTORIZADO que se relaciona mediante sufre_aut con SINIESTRO.Por ltimo, SINIESTROse relaciona mediante se_repara con TALLER.

1.2Identificando cardinalidades de Entidades y Relaciones.

Ahora que ya sabemos cuales son las entidades y las relacionesimplicadas, cmo calculamos la cardinalidad de las

entidades y por consiguiente de las relaciones?

Muy sencillo, hacindonos la siguiente pregunta para cadaentidad:

Con cuntas instancias participa la entidad que nos

interesa en la relacin en estudio?

De esta forma calculamos la cardinalidad de las entidades, y la cardinalidad de las relaciones la

obtenemos de tomar el mximo de cada una de las cardinalidades de las entidades de dicha relacin. Larespuesta para cada caso es la siguiente:

Para la entidad POLIZA tenemos una cardinalidad (1,n) en la relacin tiene con la entidadCLIENTE. La entidad CLIENTE tiene una cardinalidad (1,1) en la relacin tiene con la

entidad POLIZA. Por lo tanto, la relacin tiene tiene una cardinalidad 1:N

La entidad POLIZA tiene una cardinalidad (1,1) en la relacin referencia con la entidad

VEHICULO. Para la entidad VEHICULO tenemos una cardinalidad (1,1) en la relacinreferencia con la entidad POLIZA. Por lo tanto, la relacin referencia tiene una

cardinalidad 1:1.

La entidad VEHICULO tiene una cardinalidad (0,n) en la relacin esta_equipado con la

entidad EXTRA. Para la entidad EXTRA tenemos una cardinalidad (0,m) en la relacinesta_equipado con la entidad VEHICULO. Por lo tanto, la relacin esta_equipado tiene

una cardinalidad N:M. La entidad CLIENTE tiene una cardinalidad (0,1) en la relacin sufre_cli con la entidad

SINIESTRO. Para la entidad SINIESTRO tenemos una cardinalidad (0,n) en la relacinsufre_cli con la entidad CLIENTE. Por lo tanto, la relacin sufre_cli tiene una cardinalidad

1:N.

La entidad AUTORIZADO tiene una cardinalidad (0,1) en la relacin sufre_aut con la

entidad SINIESTRO. Para la entidad SINIESTRO tenemos una cardinalidad (0,n) en larelacin sufre_aut con la entidad AUTORIZADO. Por lo tanto, la relacin sufre_aut tiene

una cardinalidad 1:N.

La entidad SINIESTRO tiene una cardinalidad (1,n) en la relacin se_repara con la entidad

TALLER. Para la entidad TALLERtenemos una cardinalidad (0,1) en la relacin se_reparacon la entidad SINIESTRO. Por lo tanto, la relacin se_repara tiene una cardinalidad 1:N.

1.3Identificando atributos.

Seguimos el estudio identificando los atributos. Al leer los requerimientos

del sistema nos preguntamos:Qu informacin necesitamos almacenar de las distintas entidades

encontradas?

Para la entidad POLIZA, tenemos los atributos cod_poliza,tipo_seguro, importe_cobertura y estado.


3/8

Para la entidad CLIENTE, tenemos los atributos NIF, nombre, apellidos, telefono,

fecha_nacimiento, fecha_carnet y direccion.

Para la entidad VEHICULO, tenemos los atributos matricula, marca, modelo,

potencia, chasis, anno_fabricacion y color.

Para la entidad EXTRA, tenemos los atributos cod_extra y nombre.

Para la entidad AUTORIZADO, tenemos los atributos NIF, nombre, apellidos,

fecha_nacimiento y relacion_cliente. Para la entidad SINIESTRO, tenemos los atributos n_siniestro y fecha.

Para la entidad TALLER, tenemos los atributos cod_taller, nombre, direccion y

telefono.

Ya hemos identificado todos los atributos de las entidades pero, las relaciones no pueden tenertambin atributos?

Por supuesto que s, y de hecho la relacin se_repara tiene dos atributos, importe y fecha (de la

reparacin), debido a que al considerar estos dos atributos en la relacin puede contemplarse el caso deque una reparacin tenga lugar en distintas fechas y talleres. Si estos atributos estuvieran en la entidad

SINIESTRO no cabra dicha posibilidad, y todas las reparaciones deberan efectuarse en el mismomomento y por un nico importe.

1.4Identificando claves candidatas y eleccin de clave primaria.El siguiente paso a dar es identificar las claves candidatas y elegir la clave principal, pero en estaocasin vamos a elegir directamente las claves principales de nuestras entidades.

POLIZA, clave principal: cod_poliza

CLIENTE clave principal: NIF

VEHICULO clave principal: matricula

EXTRA clave principal: cod_extra

AUTORIZADO clave principal: NIF

SINIESTRO clave principal: n_siniestro

TALLERclave principal: cod_taller

1.5Dibujando la solucin.Crees que ya hemos terminado con el estudio de nuestro

diagrama?

Me temo que no, an nos queda estudiar si existe alguna

generalizacin/ especializacin en nuestro problema. En esta

ocasin no aparece ningn dato que nos haga pensar que tenemosalguna generalizacin/especializacin en nuestro diagrama.

Tambin tendremos que comprobar que no existe redundancia en

nuestro diagrama, sobre todo si existe algn ciclo en nuestrodiseo. En nuestro caso, ninguna de las relaciones que forman el

ciclo se puede eliminar porque no existe ningn camino alternativo para relacionar las entidades que estnunidas mediante las distintas relaciones.

Y por ltimo tendremos que comprobar que se cumplen los criterios de calidad mencionados en la

unidad, es decir, la cualidad de ser completo, la correccin, la minimalidad, la expresividad, lalegibilidad, la autoexplicacin y la flexibilidad del diagrama.

Despus de todas estas comprobaciones podemos construir ya nuestro diagrama E/R.


4/8

Solucin:

sufre_clie

esta_equip

TALLER

CLIENTE

POLIZA

VEHICULO EXTRA

tiene

se_repara

AUTORIZADO

SINIESTRO

sufre_aut

referencia

(0,n)

(0,n)

(0,1)

(1,1)

(1,n)

(1,1)

(1,1)(0,n)

(0,1) (0,n) (1,n)

(0,1)

nombre

apellidos

fecha:nacimient

Relacion

NIF

Como podrs observar en el diagrama no est completo, ya que no se han especificado los atributos dealgunas entidades, ni las cardinalidades de las relaciones. Slo se han aadido los de la entidad

AUTORIZADO. El hecho de no completarlo se debe a que debido a su cantidad, el diagrama se hubieraapelotonado considerablemente, y en vez de ganar en claridad se hubiera complicado. En estos

momentos iniciales, el fin que perseguimos es didctico, y vale ms la claridad que tener un diagramacompleto.

2. Ejemplo de transformacin: Seguros.Igual que para aprender a hacer diagramas E/R la mejormanera es practicar y hacer varios de ellos, para aprender

a transformar los diagramas E/R en esquemasrelacionales, tambin hay que practicar y hacer varios

ejemplos de transformaciones antes de saber hacerlasbien. Por eso es conveniente que te proporcionemos

algn ejemplo resuelto.

El diagrama E/R se ha realizado sin especificar losatributos de las entidades y relaciones para que el

diagrama no resulte demasiado complicado, pero ahora

s que vamos a tener en cuenta todos los atributos para crear el esquema relacional, as que tendrs quevolver a mirar el enunciado del problema para poder obtener todos los atributos.


5/8

2.1Transformamos las entidades.Empezamos nuestra transformacin al Modelo Relacional con este segundo ejemplo:

Entidades, atributos y claves primarias: Como entidades fuertes tenemos CLIENTE, POLIZA,

VEHICULO, EXTRA y TALLER, mientras que como entidades dbiles tememos AUTORIZADO y

SINIESTRO.

Volvemos a recordar que las entidades dbiles heredan los atributos de la clave primaria de la

entidad fuerte de la que dependen y que hay que tener en cuenta si la dependencia es en existencia o enidentificacin para decidir cual es la clave principal de la tabla que representa la entidad dbil.

Te recordamos tambin que es habitual modificar el nombre del campo heredado si es necesario

para evitar posibles ambigedades o confusiones en la identificacin de los atributos heredados.

Teniendo en cuenta todas estas consideraciones, las tablas de este ejemplo son las siguientes:

CLIENTE(NIF,nombre,apellidos,direccion,telefono,fecha_nacimiento,fecha_permiso)

POLIZA(num_poliza,tipo,cobertura,estatus,matricula)VEHICULO(matricula,num_chasis,marca,modelo,potencia,anno_fabricacion,color)EXTRA(cod_extra,descripcion)TALLER(cod_taller,nombre)

AUTORIZADO(NIF,nombre,apellidos,telefono,fecha_nacimiento,relacion,NIF_cliente)

SINIESTRO(num_siniestro,num_poliza,fecha_siniestro)

Los nicos casos que merecen especial atencin en cuanto a la eleccin de la clave primaria son los de lasentidades dbilesAUTORIZADO y SINIESTRO. La entidad dbil SINIESTRO es dbil en existencia,

por lo que hereda la clave primaria de POLIZA, pero no para formar parte de su clave primaria, sin

embargo, la entidad dbil AUTORIZADO es dbil en identificacin, ya que un mismo autorizado, lo puede

ser para varios clientes, con lo que adems de heredar la clave primaria de CLIENTE, sta forma parte desu propia clave primaria.

2.2Transformamos las relaciones.

Pasamos ahora las relaciones a tablas, con los atributos y las claves primarias: Sabemos que, enprincipio, salvo propagacin de claves, cada relacin pasa a ser una tabla en el Modelo Relacional, de esta

manera tenemos las siguientes tablas:

sufre_aut (num_siniestro,NIF_cliente,NIF_autorizado)sufre_cliente (num_siniestro,NIF_cliente)tiene (NIF_cliente, num_poliza)

referencia (num_poliza,matricula)esta_equip (cod_extra,matricula)se_repara (num_siniestro, cod_taller, fecha, importe)

La relacin referencia, al ser de cardinalidad uno a uno, puede tomar como clave primaria

cualquiera de los dos atributos.

Para decidir cules son las claves primarias de estas tablas hemos observado las cardinalidades de cada

relacin. Sabemos que las relaciones sufre_aut, sufre_cliente y se_repara son del tipo uno

a muchos, con cardinalidad mnima cero de la entidad que participa a uno, por lo que todas las relaciones

se tratan como si fueran del tipo muchos a muchos, y por consiguiente heredan las claves primarias de lasentidades que relacionan y adems dichos atributos constituyen la clave primaria de la relacin.

Como podemos ver en el diagrama E/R, la relacin esta_equip es de muchos a muchos, por lo que

tiene como clave primaria la unin de las claves primarias de las entidades que relaciona.


6/8

2.3Fusionamos las tablas.

Fusionamos las tablas siguiendo el criterio de propagacin de claves visto con anterioridad, es decir:

Las claves primarias de las entidades que participan con uno en la relacin uno a muchos y

tienen cardinalidad mnima uno, se propagan a la entidad que participa con muchos.

Adems tambin tenemos en cuenta que las relaciones uno a uno propagan tambin la clave

primaria de una de las entidades que relaciona a la otra.

CLIENTE(NIF,nombre,apellidos,direccion,telefono, fecha_nacimiento,fecha_permiso)

POLIZA(num_poliza,tipo,cobertura,estatus,matricula, NIF_cliente)

VEHICULO(matricula,num_chasis,marca,modelo,potencia, anno_fabricacion,color,num_poliza)

EXTRA(cod_extra,descripcion)TALLER(cod_taller,nombre)

AUTORIZADO(NIF,nombre,apellidos,telefono,fecha_nacimiento,relacion,

NIF_cliente)SINIESTRO(num_siniestro,num_poliza,fecha_siniestro)sufre_aut(num_siniestro,NIF_cliente,NIF_autorizado)sufre_cliente(num_siniestro,NIF_cliente)tiene(NIF_cliente,num_poliza)referencia(num_poliza,matricula)esta_equip(cod_extra,matricula)se_repara(num_siniestro,cod_taller,fecha,importe)

Hay dos tablas que aparecen tachadas porquedesaparecen como consecuencia de la propagacin de las

claves primarias.

2.4Resultado final.Hasta ahora no hemos tenido en cuenta las claves ajenas del Modelo Relacional que estamosconstruyendo. Ahora es el momento de especificar estas claves, y lo hacemos de dos maneras

distintas, subrayando con lnea discontinua el atributo, y vinculndolo con la clave primaria que

referencia.


7/8

De esta manera nos queda el siguiente esquema relacional:

CLIENTE (NIF, nombre, apellidos, direccion, telefono, fecha_nacimiento, fecha_permiso)

POLIZA ( num_poliza, tipo, cobertura, estatus, matricula, NIF_cliente)

VEHICULO (matricula, num_chasis, marca, modelo, potencia, anno_fabricacion, color,num_poliza)

EXTRA (cod_extra, descripcion)

TALLER (cod_taller, nombre)

AUTORIZADO (NIF, nombre, apellidos, telefono, fecha_nacimiento, relacion,NIF_cliente)

SINIESTRO (num_siniestro, num_poliza, fecha_siniestro)

sufre_aut (num_siniestro, NIF_cliente, NIF_autorizado)

sufre_cliente(num_siniestro, NIF_cliente)

esta_equip (cod_extra, matricula)

se_repara (num_siniestro, cod_taller, fecha, importe)


8/8

Y ahora vemos la otra manera de representar el Modelo Relacional:

num_siniestro

NIF_cliente

NIF_autorizado

Tabla:sufre_aut

num_siniestro

num_poliza

fecha_siniestro

Tabla:SINIESTRO

num_siniestro

cod_tallerfecha

importe

Tabla:se_repara

NIFnombre

apellidos

telefono

fecha_nacimiento

relacion

NIF_cliente

Tabla:AUTORIZADO

NIFnombre

apellidos

direccion

telefono

fecha_nacimiento

fecha_permiso

Tabla:CLIENTE

num_siniestro

NIF_cliente

Tabla:sufre_clie

cod_tallernombre

Tabla:TALLER

num_polizatipo

cobertura

estatus

matricula

NIF_cliente

Tabla:POLIZA

cod_extramatricula

Tabla:esta_equip

cod_extra

descripcion

Tabla:EXTRA

Matriculanum_chasis

marca

modelo

potencia

anno_fabricacion

color

num_poliza

Tabla:VEHICULO

Ejemplo_resuelto_-_Seguros

Documents

Transcript of Ejemplo_resuelto_-_Seguros