Nota:(material que subi al moodle)

UNIDAD II

DISEO Y MODELO ENTIDAD

RELACION

Introduccin
Las etapas del proceso de desarrollo de software

Cualquier sistema de informacin va pasando por una serie de fases a lo largo de su

vida. Su ciclo de vida comprende una serie de etapas entre las que se encuentran las
siguientes:
1. Planificacin
2. Anlisis
3. Diseo
4. Implementacin
5. Pruebas- Instalacin o despliegue
6. Uso y mantenimiento
1.-Planificacin
Antes de que se le de oficialmente el pistoletazo de salida a un proyecto de desarrollo de
un sistema de informacin, es necesario realizar una serie de tareas previas que influirn
decisivamente en la finalizacin con xito del proyecto. Estas tareas se conocen
popularmente como el fuzzy front-end (inicio difuso) del proyecto al no estar sujetas a
plazos.
2.-Anlisis (Responder a la pregunta el que se necesita?)
Lo primero que debemos hacer para construir un sistema de informacin es averiguar
qu es exactamente lo que tiene que hacer el sistema. La etapa de anlisis en el ciclo de
vida del software corresponde al proceso mediante el cual se intenta descubrir qu es
lo que realmente se necesita y se llega a una comprensin adecuada de los
requerimientos del sistema (las caractersticas que el sistema debe poseer).Por qu
resulta esencial la etapa de anlisis? Simplemente, porque si no sabemos con precisin
qu es lo que se necesita, ningn proceso de desarrollo nos permitir obtenerlo. El
problema es que, de primeras, puede que ni nuestro cliente sepa de primeras qu es
exactamente lo que necesita.

3.-Diseo
los modelos que se utilizan en la fase de diseo representan las caractersticas del
sistema que nos permitirn implementarlo de forma efectiva (el cmo).
El diseo de un sistema de informacin tambin presenta distintas facetas:

Por un lado, es necesario abordar el diseo de la base de datos, un tema que

trataremos detalladamente ms adelante.
Por otro lado, tambin hay que disear las aplicaciones que permitirn al usuario
utilizar el sistema de informacin.
Tendremos que disear la interfaz de usuario del sistema y los distintos
componentes en que se descomponen las aplicaciones.

4.- Implementacin
Una vez que sabemos qu funciones debe desempear nuestro sistema de informacin
(anlisis) y hemos decidido cmo vamos a organizar sus distintos componentes
(diseo), es el momento de pasar a la etapa de implementacin, pero nunca antes. Antes
de escribir una sola lnea de cdigo (o de crear una tabla en nuestra base de datos) es
fundamental haber comprendido bien el problema que se pretende resolver y haber
aplicado principios bsicos de diseo que nos permitan construir un sistema de
informacin de calidad.

5.- Pruebas
Errar es humano y la etapa de pruebas tiene como objetivo detectar los errores que se
hayan podido cometer en las etapas anteriores del proyecto

6.-Uso y mantenimiento
La etapa de mantenimiento consume tpicamente del 40 al 80 por ciento de los recursos
de una empresa de desarrollo de software. De hecho, con un 60% de media, es
probablemente la etapa ms importante del ciclo de vida del software. Dada la
naturaleza del software, que ni se rompe ni se desgasta con el uso, su mantenimiento
incluye tres facetas diferentes
mantenimiento correctivo:
Eliminar los defectos que se detecten durante su vida til), lo primero que a uno
se le viene a la cabeza cuando piensa en el mantenimiento de cualquier cosa.mantenimiento adaptativo
Adaptarlo a nuevas necesidades , cuando el sistema ha de funcionar sobre una
nueva versin del sistema operativo o en un entorno hardware diferente, por
ejemplo.mantenimiento perfectivo
Aadirle nueva funcionalidad , cuando se proponen caractersticas deseables
que supondran una mejora del sistema ya existente.

2.1 EL PROCESO DE DISEO

El proceso de diseo de una base de datos
De acuerdo con las etapas del ciclo de vida de un sistema de informacin,
una metodologa de diseo descompone el proceso de diseo en una serie de
etapas. Para cada una de las etapas, propondr el uso de determinadas tcnicas y
herramientas de diseo, as como la generacin de una serie de documentos que
facilitarn la transicin de una etapa a la siguiente:
FASES DEL DISEO DE BASES DE DATOS
1. Anlisis de requisitos:
2. Diseo conceptual:
3. Eleccin del sistema gestor de bases de datos
4. Diseo lgico
5. Diseo fsico
6. Instalacin y mantenimiento

Fase 1: Anlisis de requerimientos

Objetivo:
Recabar informacin sobre el uso que se le piensa dar a la base de datos.
Tareas : identifcacin de los requisitos del sistema:
- Identificacin de las principales reas de la aplicacin y grupos de usuarios.
- Estudio y anlisis de la documentacin existente relativa a las aplicaciones.
- Estudio del entorno de operacin actual
- Estudio del uso de la informacin (transacciones, frecuencias y flujos de
datos).
Resultados:
Documento de especificacin de requerimientos:
- Descripcin del sistema en lenguaje natural.
- Lista de requerimientos (organizados de forma jerrquica).
- Diagramas de flujo de datos (DFD).
- Casos de uso

Fase 2: Diseo conceptual

Objetivo
Producir un esquema conceptual de la base de datos (independiente del sistema
gestor de bases de datos que luego vayamos a utilizar).
Tareas
- Comprensin de la estructura, semntica, relaciones y restricciones
asociados a los datos que deben almacenarse en la base de datos.
- Modelado de los datos del sistema (obtencin de una descripcin estable de
lo que ser el contenido de la base de datos).
- Comunicacin entre usuarios finales, analistas y diseadores para comprobar
la validez del modelo obtenido.
Resultados:
- Diagrama E/R, diagrama CASE*Method o diagrama de clases UML.
- Diccionario de metadatos.

Fase 3: Eleccin del SGBD

La eleccin del sistema gestor de bases de datos que vayamos a utilizar se realiza
en dos etapas:

Primero se realiza la eleccin del modelo de datos, el tipo de sistema gestor

de bases de datos que vamos a usar: relacional, objeto-relacional, orientado a
objetos, multidimensional...
A continuacin se elige el sistema gestor de bases de datos concreto (y su
versin). Por ejemplo, si decidimos utilizar un sistema gestor de bases de
datos relacionales, podemos recurrir al gestor de bases de datos de Oracle, al
DB2 de IBM, al SQL Server de Microsoft, al Interbase de Borland o a
cualquier otro de los muchos sistemas gestores de bases de datos relacionales
que existen en el mercado.

Fase 4: Diseo lgico Objetivo

Crear el esquema conceptual de la base de datos (y todos los esquemas externos
asociados alas distintas aplicaciones del sistema) de acuerdo con el modelo de datos del
sistema gestor de base de datos elegido.
Tareas
Para realizar el diseo lgico de la base de datos, hay que transformar los esquemas
obtenidos en el diseo conceptual en un conjunto de estructuras propias del modelo
abstracto de datos elegido. En el caso de las bases de datos relacionales tendremos que
realizar las siguientes tareas:
- Paso del diagrama E/R (o equivalente) a un conjunto de tablas.
- Normalizacin de las tablas
Resultado
Un conjunto de estructuras propias del modelo abstracto de datos del SGBD elegido
(esto es,un conjunto de tablas si trabajamos con bases de datos relacionales).

Fase 5: Diseo fsico Objetivo

El diseo fsico de la base de datos consiste en elegir las estructuras de almacenamiento
apropiadas (tablas, particiones de tablas, ndices...) para que el rendimiento de la base de
datos sea el adecuado para las distintas aplicaciones a las que ha de dar servicio.
Tareas
Preparar las sentencias DDL correspondientes a las estructuras identificadas durante la
etapa de diseo lgico de la base de datos.
Resultado:
Un conjunto de sentencias DDL escritas en el lenguaje del SGBD elegido (incluyendo la
creacin de ndices, la seleccin de parmetros fsicos de la base de datos, etctera).

Fase 6: Instalacin y mantenimiento

Como en cualquier sistema de informacin, casi siempre resulta necesario modificar el
diseo de la base de datos, ya sea porque el rendimiento observado despus de la
implementacin del sistema de bases de datos no sea el adecuado o porque haya que
introducir cambios en el esquema de la base de datos como consecuencia del
mantenimiento del sistema de informacin
Instalacin y puesta en marcha- La instalacin de la base de datos suele ser responsabilidad del administrador
de la base de datos (DBA:Database Administrator ), que se encarga de
recopilar todas las sentencias DDL necesarias para crear los distintos
esquemas de la base de datos.
Mantenimiento- Cuando los requisitos del sistema cambien y haya que actualizar las
aplicaciones de nuestro sistema de informacin, el esquema de la base de
datos tambin se ver sometido a algunas modificaciones.

ALTERNATIVAS DE DISEO:
Se desea aprovechar los aspectos en comn para tener un diseo conciso, fcilmente
comprensible, pero hay que conservar la suficiente flexibilidad como para poder
representar las diferencias entre las diferentes entidades existentes en el momento del
diseo.
Al disear un esquema se pueden correr dos riesgos:
Redundancia: en un mal diseo se puede repetir la informacin
Incompletitud: Un mal diseo puede hacer que determinados aspectos de la
empresa resulten difciles o imposibles de modelar.

MODELOS DE DATOS
Un modelo de datos es un conjunto de herramientas conceptuales para describir los
datos, las relaciones entre ellos, su semntica y sus limitantes.
Los modelos de datos se clasifican en tres grupos principales:
1. MODELOS LOGICOS BASADOS EN OBJETOS.- Son aquellos que nos
permiten una definicin clara y concisa de los esquemas conceptual y de visin.
Su caracterstica principal es que permiten definir en forma detallada las
limitantes de los datos. Ejemplos de este tipo de modelos son:

Modelo entidad relacin.

Modelo binario
Modelo semntico de los datos
Modelo infolgico

2. MODELOS LOGICOS BASADOS EN REGISTROS.- Operan sobre niveles

conceptual y de visin. Sus caractersticas principales son que permiten una
descripcin ms amplia de la implantacin, pero no son capaces de especificar
con claridad las limitantes de los datos. Son ejemplos de este tipo de modelos:
Modelo relacional: Los datos y las relaciones se representan
mediante tablas, cada una con diferentes columnas y nombres
nicos.
Modelo jerrquico: Es semejante al modelo de red, pero con una
estructura arbolada. En este modelo los datos se organizan en una
forma similar a un rbol (visto al revs), en donde un nodo padre
de informacin puede tener varios hijos.
Modelo de red: Los datos se representan mediante nombres de
registros y las relaciones mediante conjunto de ligas.
2. MODELOS FISICOS DE DATOS.- describen los datos en el nivel ms bajo y
permiten identificar algunos detalles de implantacin para el manejo del
hardware de almacenamiento. Ejemplos de este tipo de modelos son:

Modelo unificador
Modelo memoria de cuadros

MODELO DE DATOS

2.2 MODELO ENTIDAD-RELACIN

Es uno de los modelos lgicos basados en objetos y por lo tanto se enfoca
primordialmente a los niveles conceptual y de visin. Una de las caractersticas de este
modelo es que permite representar con claridad las limitantes de los datos. El modelo
Entidad-Relacin es en esencia una herramienta para representar el mundo real por
medio de simbologas y expresiones determinadas. Este modelo se basa en la
percepcin del mundo real que consiste en un conjunto de objetos llamados entidades y
relaciones entre estos objetos.
Formalmente, los diagramas ER son un lenguaje grfico para describir conceptos.
Informalmente, son simples dibujos o grficos que describen informacin que trata un
sistema de informacin y el software que lo automatiza.

DIAGRAMAS DE ENTIDAD - RELACIN

Son esquemas que nos permitan representar conjunto de entidades y sus
relaciones mediante la siguiente simbologa.

* Conjunto de entidades o relacin con sus atributos

* Conjunto entidades con relaciones
* Cada elemento debe etiquetarse con su nombre.

ENTIDADES, ATRIBUTOS Y RELACIONES

Entidad: es un objeto que existe y puede ser distinguido de otro objeto. Por ejemplo: el
Numero de control: 05330255, Automvil sentra, La cantante Paulina Rubio, la
telenovela Amor en custodia,la fruta:manzana la fecha 5 de noviembre, La edad
de una persona, algn concepto o frase memorable EL RESPETO AL DERECHO
AJENO ES LA PAZ etc. De tal manera que las entidades pueden ser de dos tipos:
a) Concretas: Son aquellas que se distinguen a simple avista, la mayora son
tangibles. Como el automvil, la manzana, la telenovela o la cantante.
b) Abstractas: Son aquellas que son intangibles y no se distinguen a simple vista,
como una fecha, edad, concepto o frase memorable, etc.
Una entidad es una cosa o un objeto con significado real o imaginado, acerca de la
cual existe la necesidad de informacin que se va a conocer o a mantener.
Representacin grfica
Una entidad se representa con un rectngulo con esquinas redondeadas dentro del cual
se escribe el nombre correspondiente para su identificacin. El nombre se muestra en
SINGULAR en letras MAYSCULAS, y sin ABREVIATURAS, adems debe ser el
que represente un tipo o clase de elemento, NO UNA INSTANCIA. Un ejemplo de
clase es alumno y una instancia es Juanito, por tanto la entidad debe ser ALUMNO.
Conjunto de entidades: grupo de entidades del mismo tipo.
Conjunto de entidades
animal
pajaro
ballena
zorro
mariposa
caballo
borrego

Conjunto de entidades
cantante
Shakira
Paulina Rubio
Thala
JLo
Madona
Yuridia

Conjunto de entidades
alumno
Rosa Mara Arvallo
Marcela Iveth Favela
Alejandro Gutirrez W.
Carlos Razo Huguez
Kimberly Gmez Lpez
Israel Muoz Valdez.

Atributo: Propiedad o caracterstica (adjetivo) que describen a una entidad y la hacen

nica. Un atributo puede hacer tres cosas:
o
o
o

Identificar
Relacionar
Describir

Como en este ejemplo :

Conjunto de entidades alumno
Nocontrol
Nombre
Semestre
Sexo
Estatus

Un atributo puede ser un texto, un color, un dibujo, un sentimiento, etc., segn se

requiera.
Representacin de ATRIBUTOS
Para representar un atributo hay que escribir su nombre en singular, en minsculas y de
forma opcional.

Conjunto de atributos: ( Son el grupo de atributos que representan a la entidad.)

Dominio: Conjunto de valores permitidos para un atributo.
Ejemplo:

1.- Atributo: Nocontrol (Desde el ao 2000 hasta el ao 2006)

Dominio: En este caso el rango de valores permitidos para el atributo Nocontrol ser
del: 00330001 al 06339999.
2.- Atributo: Sexo
Dominio: En este caso el rango de valores permitidos son unicamente dos: Masculino o
femenino.

TIPOS DE ATRIBUTOS

Simples y compuestos: ya sea que el atributo sea un todo o bien este compuesto
o
Simples: no estan divididos en subpartes como color, toma valores rojo,
azul, etc
o Compuestos: se puede dividir en subpartes o en otros atributos como
nombre que contiene nombre de pila, apellido paterno, apellido materno
Con valores monovalorados o multivalorados: en base a si consisten de un
solo valor o un conjunto de valores.
o Monovalorados : el atributo puede tener un solo valor , ejemplo: sexo:
masculino o femenino
o Multivalorados: el atributo Telfono puede tener varios nmeros de
telfono
Derivados: que se pueden calcular en base a otros atributos
El atributo edad se se deriva de el atributo fecha de nacimiento

Ejemplo de atributo compuesto

Relacin: es una asociacin entre varias entidades.

Conjunto de relaciones: Un conjunto de relaciones del mismo tipo
Relacin Binaria: Participan dos entidades en la relacin

Relacin Ternaria: particpan 3 entidades en la relacin

2.3 RESTRICCIONES
Un esquema de desarrollo E-R pueden existir ciertas restricciones en la BD a las cuales
tiene que adaptarse
1. Correspondencia de cardinalidades
2. Restricciones de claves
3. Restricciones de participacin

1.- CORRESPONDENCIA DE CARDINALIDADES:

Es aquella mediante la cual puede especificarse la cantidad de entidades que podrn
asociarse mediante una relacin, expresa el nmero de entidades a las que otra entidad
se puede asociar. Es muy til para describir el conjunto de relaciones binarias
A.- UNA A UNA(1: 1): Una entidad de A puede asociarse nicamente con una entidad
de B.

a).-Un director dirige un tecnolgico , y un tecnolgico es dirigido por un director

(1:1)
DIRECTOR

DIRIGE

TECNOLOGICO

b).-Un hombre esta casado con una mujer, y una mujer est casada con un hombre
(1:1)
HOMBRE

CASADO

MUJER

B.-UNA A MUCHAS (1:N) : Una entidad de A puede asociarse con cualquier

cantidad de entidades de B.

a) Un cliente debe muchas facturas y una factura esta a nombre de slo un

cliente (1:N)
CLIENTE

DEBE

FACTURAS

b) En una carrera estn inscritos muchos alumnos y un alumno slo puede estar
escrito en una sola carrera (1:N)
CARRERA

INSCR.

ALUMNOS

C.- MUCHAS A UNA (N:1) : Cualquier cantidad de entidades de A puede

asociarse con una entidad de B.

a) Varias facturas se deben por un cliente y un cliente debe varias facturas (N:1)
FACTURA

DEBE

CLIENTE

b) Muchos alumnos estn inscritos en una carrera y en una carrera existen muchos
alumnos (N:1)
ALUMNO

INSCRIT

CARRERA

D.-MUCHAS A MUCHAS: Cualquier cantidad de entidades de A puede asociarse con

cualquier cantidad de entidades en B.

a) Muchos proveedores surten varios productos , muchos productos son surtidos

por muchos proveedores
PROVEEDOR

SURTEN

PRODUCTO

b) Muchos alumnos estn inscritos en algunas materias, y algunas materias son

llevadas por muchos alumnos

ALUMNO

INSCRIT

MATERIAS

En los esquemas entidad / relacin la cardinalidad se puede indicar de

muchas formas. Actualmente una de las ms populares es esta:

2.- RESTRICIONES DE CLAVES:

Uno de los procesos de mayor relevancia en la manipulacin de una base de
datos es el de distinguir entre las diversas entidades y relaciones que son
manipuladas.
LLAVE: al medio que nos permite identificar en forma unvoca (nica e
inequvoca) a una entidad dentro de un conjunto de entidades.
Existen diversas categoras que permiten clasificar los tipos de llaves a utilizar:
a) LLAVE CANDIDATO.- son aquellos atributos que en determinado
momentos podran constituir una llave pero que por sus caractersticas
pueden volverse inseguros o dudosos, tales como el RFC o el nombre
que en determinado momento se pueden repetir, por lo cual significa
que no son una buena llave, pero si una alternativa de solucin.

b) LLAVE PRIMARIA.- Es aquella llave que el diseador de la base de

datos selecciona entra las llaves candidatos encontradas.

c) SUPER -LLAVE .- conjunto de uno o ms atributos que considerados

conjuntamente, nos permiten identificar de forma nica a una entidad,
dentro del conjunto de entidades. ( puede ser la unin de de entidades
como por ejemplo el RFC+NOMBRE).

3.- RESTRICCIONES DE PARTICIPACIN

Participacin total u obligatoria:
En un conjunto de relaciones R es total si cada entidad de E participa al menos en una
Relacin R. Utiliza como smbolo una lnea vertical que cruza la lnea de la relacin
Participacin parcial u opcional:
Si slo algunas entidades de E participan en relaciones R se dice que la participacin es
parcial. Utiliza como smbolo una ruedita vaca que cruza la lnea de la relacin

Participacin Total u Obligatoria

Participacin Parcial u opcional

Como no todos los clientes puedan tener un prstamo se dice que de clientes a prstamo
es una participacin parcial u opcional. (pueden haber 0 instancias y en el diagrama se
representa por el signo: O)
Un prstamo, tiene una participacin total u obligatoria, porque un prstamo debe
pertenecer a un cliente.
EJEMPLO.-

a).-Grado de cardinalidad
En un equipo pueden jugar muchos jugadores, muchos jugadores pueden jugar en un
quipo. Un entrenador entrena a equipo, un equipo es entrenado por un entrenador.
b).-Grado de participacin: .
Cada Equipo cuenta con varios jugadores .Un jugador juega como mucho en un equipo
y podra no jugar en ninguno. Cada entrenador entrena a un equipo (podra no entrenar a
ninguno), el cual tiene un solo entrenador

Conclusin de Cardinalidades:

Conclusin :

En la figura (a) Podemos notar que la relacin prestario tiene una relacin de
uno a varios prestamos
En la figura (b)Tiene una relacin de muchos a uno, muchos clientes pueden
solicitar un prstamo y un prstamo puede ser solicitado por varios clientes
En la figura (c)Tiene una relacin de uno a uno, en donde un cliente puede
solicitar un prstamo y un prstamo slo puede pertenecer a un cliente.
La punta de la flecha apuntar a donde solo exista una entidad
En donde no haya punta o exista pata de gallo significar varios

2.4 DIAGRAMAS E-R

2.5 DISEO CON DIAGRAMAS E-R
1.- En las oficinas de la agencia fiscal, se desea administrar las licencias que se van a
otorgar los datos que se van a almacenar del conjunto de entidades HABITANTE son
curp, nombre, direccin, fecha de nacimiento, cdigo postal y se tiene un conjunto de
entidades LICENCIA la cual se identifica con un nmero de identificacin, tipo de
licencia (chofer, automovilista), ao de expedicin , vigencia y ao de expiracin
Hacer el modelo E-R y distinguir:
a).- Correspondencia de cardinalidad
b).- Grado de participacin
c).- Llaves primarias
d).- Atributos compuestos y derivados

2.- Se tiene un conjunto de entidades PERSONA y un conjunto de entidades ESTADO,

en donde interesa almacenar la siguiente informacin: el rfc, el nombre, telfono, fecha
de nacimiento y estado al que pertenece, se desea saber la edad de la persona, clave del
estado y nombre del estado. Hacer el modelo E-R y distinguir:
a).- Correspondencia de cardinalidad
b).- Grado de participacin
c).- Llaves primarias
d).- Atributos compuestos y derivados

3.- Se tiene un conjunto de entidades MAESTRO Y un conjunto de entidades

MATERIA, en donde interesa almacenar la siguiente informacin: la clave del maestro,
nombre, rfc, direccin, telfono, clave de la materia, nombre de la materia, crditos.
Hacer el modelo E-R y distinguir:
a).- Correspondencia de cardinalidad
b).- Grado de participacin
c).- Llaves primarias
d).- Atributos compuestos y derivados

2.6 ENTIDADES DBILES

Una entidad dbil es aquella que no posee una llave primaria

Para existir dependen de una relacin con una entidad fuerte

Pueden contener algn atributo "discriminante" que podra considerarse como
aquel que lo distingue pero no de manera nica, de ah que no se considere como
llave .
Son conjuntos de entidades que no poseen los atributos necesarios para
conformar una llave primaria.
Las entidades dbiles se subordinan a las entidades fuertes.
Se le conoce como entidad dbil o entidad subordinada
Las entidades se representan con doble rectngulo

ENTIDAD FUERTE. Cuando existen los atributos necesarios para formar una llave
primaria, es la entidad dominante. Se le conoce como entidad fuerte, entidad dominante
o entidad padre.
DISCRIMINADOR: Las entidades dbiles no pueden ser conocidas por si solas, con
el objeto de diferenciarlas se seleccionan algunos de sus atributos para formar un
discriminador. Este discriminador se asocia con la llave primaria de la entidad fuerte
para formar una llave primaria propia.

DEPENDENCIA DE EXISTENCIA Y DE IDENTIFICACION:

Nos permiten definir que un conjunto de entidades esta condicionado a la existencia de
otro un ejemplo de este condicionamiento se da entre una entidad alumno y la entidad
calificacin.
A esta limitante se le denomina dependencia por existencia. Si una entidad Y requiere
de una entidad X para existir se dice que Y es dependiente por existencia de X; esto
implica que si eliminamos a la entidad X; deber eliminarse la entidad Y. Para el caso
anterior, se nombrara a X como la entidad dominante, y a Y como entidad
subordinada.
Ejemplos:
a) Entre las Entidades alumnos y kardex , la entidad dominante es alumnos y la
entidad subordinada es kardex, por que si no existieran alumnos, no hubiera
calificaciones que almacenar en la entidad kardex.
b) Entre las entidades pacientes y citas, la entidad dominante es pacientes y la
entidad subordinada citas, puesto que si no existiera la entidad pacientes
tampoco hubiera una cita que registrar.
c) Entre las entidades persona y telfono Persona es la entidad fuerte y telfono la
entidad fuerte

Fases para la Obtencin del modelo E-R

Ejercicio.Se tienen los datos Id y Nombre de la entidad persona las cuales se puede localizar
varios telfonos en donde se posee el numero. Cada persona puede tener varios
telfonos

Ejercicio.Se tiene la entidad prstamo con los datos nmero_prstamo e importe asociada a la
entidad pago que pose un numero de pago, fecha de pago e importe de pago .Un
prstamo se puede pagar en varios pagos. Cada pago debe corresponder a un prstamo

Conclusin:
Entre el conjunto de Entidades Pago y Prstamo se establece la relacin pago de de
prstamo, El conjunto de Entidad Pago es totalmente dependiente de el Conjunto de
Entidades Prstamo. Si no existiera un prstamo no tendra sentido la existencia de un
Pago
Ejercicio

Se tiene que organizar la informacin de los asegurados dependientes de los empleados

de una empresa . Cada empleado puede tener muchos dependientes en donde interesa
guardar su nombre, fecha de nacimiento, sexo y la relacin de parentesco con el
empleado, del empleado guardaremos su nombre, sexo, salario, fecha de nacimiento y
una clave de identificacin

2.7 MODELO E-R EXTENDIDO

CLASIFICACION:
Es una relacin de contencin que existe entre una entidad de alto nivel y una o mas
entidades de bajo nivel. A la entidad de alto nivel se le conoce como superclase y a las
entidades de bajo nivel se le conoce como subclase.
ISA: derivado del ingles es parte de, o tambin se utiliza ES: derivado de
Especializacin

Caractersticas de la clasificacin:
1. Una instancia de una subclase debe existir tambin en la superclase. Ejemplo:
Mara es miembro de secretaras pero secretaria es miembro de empleados, por
lo tanto Mara es miembro de empleados.
2. Una instancia de una superclase se incluye opcionalmente en una subclase.
Ejemplo: Hay alumnos que probablemente no sean becados , ni se encuentren en
el equipo representativo pero independientemente de esto van a ser parte de la
entidad ALUMNOS
3. La relacin que existe entre una superclase y la subclase es relacin uno a uno.
Ejemplo: Un alumno le corresponde una beca y una beca slo le corresponde a
un alumno.
4. Una entidad que es miembro de una subclase hereda todos los atributos de la
entidad superclase Ejemplo : El equipo representativo tiene los atributos de
deporte, adems tiene matricula, Nombre, Direccin y la entidad BECA, tiene
los atributos de tipo_beca ademas tiene matricula, Nombre, y direccion

La clasificacin puede ser de dos tipos:

a)
Generalizacin
b)
Especializacin.

a).-Generalizacin
Es el proceso segn el cual se crea un conjunto de entidades a partir de otros que
comparten ciertos atributos. Tienen por objeto la fusin o descomposicin de atributos
que conforman entidades. La generalizacin persigue la minimizaron de redundancia en
la base de datos de tal manera que puedan ocultarse las diferencias entre entidades
formando as entidades comunes.

A veces existen situaciones en que sea conveniente crear una entidad como una fusin
de otras, en principio, diferentes, aunque con atributos comunes. Esto disminuye el
nmero de conjuntos de entidades y facilita el establecimiento de interrelaciones.
Por ejemplo, estamos modelando la gestin de una biblioteca, en la que adems de
libros se pueden consultar y prestar revistas y pelculas. Desde el punto de vista del
modelo E-R, deberamos crear conjuntos de entidades distintos para estos tres tipos de
entidad, sin embargo, todos ellos tienen comportamientos y caractersticas comunes:
prstamos, ubicaciones, ejemplares, editorial. Tambin tienen atributos especficos,
como el nmero de revista, o la duracin de la pelcula.
La idea es crear una entidad con una nica copia de los atributos comunes y aadir los
atributos no comunes. Adems se debe aadir un atributo que indique que tipo de
entidad estamos usando, este atributo es un discriminador.
La desventaja de la generalizacin es que se desperdicia espacio de almacenamiento, ya
que slo algunos de los atributos no comunes contienen informacin en cada entidad, el
resto se desperdicia.
La ventaja es que podemos establecer el mismo tipo de interrelacin con cualquier
entidad del conjunto. En nuestro ejemplo, en lugar de tener que establecer tres
interrelaciones de prstamo, o ubicacin, bastar con una de cada tipo.
Otra ventaja es que se disminuye el nmero de entidades.

b).-Especializacin
Es el proceso inverso al de generalizacin, en lugar de crear una entidad a partir de
varias, descomponemos una entidad en varias ms especializadas.

Tiene por objeto reducir el espacio de almacenamiento requerido por la base de datos
en el medio fsico. Trae como consecuencia una redundancia necesaria, pero suprime el
gasto de espacio en el medio secundario para aquellas columnas que no almacenan
informacin por entidades bien determinadas.
Se crean varios tipos de entidades a partir de uno. Cada una de los conjuntos de
entidades resultantes contendr slo algunos de los atributos del conjunto original.
La idea es lgica: si la generalizacin tiene ventajas e inconvenientes, cuando los
inconvenientes superan a las ventajas, ser conveniente hacer una especializacin.
Por ejemplo, para gestionar la flota de vehculos de una empresa usamos un nico
conjunto de entidades, de modo que tratamos del mismo modo motocicletas, utilitarios,
limusinas, furgonetas y camiones. Pero, desde el punto de vista de mantenimiento, se
pueden considerar entidades diferentes: cada una de ellas tiene revisiones distintas y en
talleres diferentes. Es decir, las diferencias superan a los atributos comunes. Este
conjunto de entidades es un buen candidato a la especializacin.
En realidad, es irrelevante si una entidad en fruto de una generalizacin o de una
especializacin, no deja de ser una entidad, y por lo tanto, no afecta al modelo.

EJEMPLO.-

INCONVENIENTES DEL MODELO (destacan dos)

-No pueden presentarse relaciones entre conjunto de relaciones.
-No pueden visualizarse instancias mediante los diagramas E-R.
VENTAJA:
- se reduce el espacio de almacenamiento

Ejemplo:_

EJERCICIOS
1- -- Un vdeo club mantiene el control de sus clientes utilizando los siguientes datos:
numero de credencial, nombre, direccin y telfono; l catalogo de pelculas contiene
para cada video los datos clave, titulo, clasificacin y costo de renta. Para cada renta que
el cliente hace se guarda la fecha, y los das.

2.- Este modelo especifica la existencia de tres entidades, Profesor, Curso y

Departamento, que se corresponden con otras tantas relaciones. Un departamento tiene
muchos profesores y un profesor puede dar muchos cursos. Para cada una de las
entidades existe una propiedad que las identifica nicamente y que se corresponde con
la clave primaria (en este caso clave subrogada) de cada una de las tablas en la
implementacin relacional. Las entidades tienen otras propiedades que las describen y
que se corresponden con los distintos campos de la tabla (relacin). Finalmente, las tres
entidades contempladas son consideradas como independientes, aunque tambin
habramos podido modelar la existencia de alguna de ellas como dependiente de otra;
por ejemplo podramos haber establecido la restriccin de que un profesor no puede
existir sin estar adscrito a ningn departamento, o que un curso no puede existir sin un
profesor que lo imparta.

3.-Realice un diagrama E-R para representar 3 entidades en donde un estudio puede

producir muchas pelculas y en una pelcula pueden actuar muchos actores , cada
pelcula cuenta con una clave de identificacin y tiene un nombre y un ao en el que se
hizo, un actor cuenta con una clave y un nombre, el estudio cuenta con una clave de
identificacin un nombre y una direccin.

4.-a).-La compaia est organizada en departamentos. Cada departamento tiene un

nombre nico. un nmero nico, y un empleado particular quien lo administra. Se
quiere saber la fecha en que el empleado administrador empez a hacerse cargo del
departamento.
Un
departamento
puede
tener
varios
locales.
b).- Cada departamento controla un cierto nmero de proyectos. Cada proyecto tiene un
nombre
y
nmero
nicos,
y
un
local.
c).-Para cada empleado se desea tener su nombre, rut, direccin, salario, sexo y ao de
nacimiento. Un empleado es asignado a un departamento, pero puede trabajar en varios
proyectos, los que no son necesariamente controlados por el mismo departamento. Se
quiere saber el nmero de horas semanales que un empleado trabaja en cada proyecto.
d).-Se desea conocer las personas dependientes de cada empleado para propsitos de
seguros. De cada dependiente se desea conocer el nombre, sexo, fecha de nacimiento y
relacin con el empleado.

Elaborar el diagrama anterior en donde muestres los grados de participacin de

cada una de las entidades.

2.8 OTROS ASPECTOS DEL DISEO DE BASES DE DATOS

AGREGACIN

Es una tcnica que permite representar a un bloque de entidades relacionadas como si

fueran un solo conjunto de entidades; permitiendo as la relacin entre conjunto de
relaciones.
La agregacin surge de la limitacin que existe en el modelado de E-R, al no permitir
expresar las relaciones entre relaciones de un modelo E-R en el caso de que una relacin
X se quiera unir con una entidad cualquiera para formar otra relacin.
La agregacin consiste en agrupar por medio de un rectngulo a la relacin
(representada por un rombo) junto con las entidades y atributos involucrados en ella,
para formar un grupo que es considerado una entidad y ahora s podemos relacionarla
con otra entidad.
Para ejemplificar lo anterior consideremos el ejemplo del libro de fundamentos de
Base de Datos de Henry F. Korth. En donde el problema consiste en que existen
trabajando muchos empleados que trabajan en diferentes proyectos, pero dependiendo
del trabajo que realiza en pueden llegar a utilizar un equipo o maquinaria; en este
problema intervienen 3 entidades: Empleado, Proyecto y Maquinaria, el diagrama E-R
correspondiente es:

Como el modelo E-R no permite la unin entre dos o ms relaciones, la relacin trabajo
es englobada como si fuera una entidad ms de la relacin usa, grficamente queda
como:

Ahora podemos decir que la entidad trabajo se relaciona con la entidad maquinaria a
travs de la relacin usar. Para indicarnos que un trabajo usa un determinado equipo o
maquinaria segn el tipo de trabajo que se trate.

2.9 LA NOTACION E-R CON UML (Diagramas vistos en el laboratorio)

Los diagramas entidad-relacin ayudan a modelar el componente de representacin de
datos de un sistema software. La representacin de datos, sin embargo, slo forma parte
de un diseo completo de un sistema. Otros componentes son modelos de interaccin
del usuario con el sistema, especificacin de mdulos funcionales del sistema y su
interaccin, etc.

El lenguaje de modelado unificado (UML, Unified Modeling Language) es un estndar

propuesto para la creacin de especificaciones de varios componentes de un sistema
software. Algunas de las partes de UML son:

Diagrama de clase. Un diagrama de clase es similar a un diagrama E-R. Ms adelante en

este apartado se mostrarn algunas caractersticas de los diagramas de clase y cmo se
corresponden con los diagramas E-R.

Diagrama de caso de uso. Los diagramas de caso de uso muestran la interaccin entre
los usuarios y el sistema, en particular los pasos de las tareas que realiza el usuario
(tales como prestar dinero o matricularse de una asignatura).

Diagrama de actividad. Los diagramas de actividad describen el flujo de tareas entre

varios componentes de un sistema.

Diagrama de implementacin. Los diagramas de implementacin muestran los

componentes del sistema y sus interconexiones tanto en el nivel del componente
software como el hardware.

La figura siguiente muestra varios constructores de diagramas E-R y sus constructores

equivalentes de los diagramas de clase UML. Ms abajo se describen estos
constructores.

UML muestra los conjuntos de entidades como cuadros y, a diferencia de E-R, muestra
los atributos dentro del cuadro en lugar de como elipses separadas. UML modela
realmente objetos, mientras que E-R modela entidades. Los objetos son como entidades
y tienen atributos, pero adems proporcionan un conjunto de funciones (denominadas
mtodos) que se pueden invocar para calcular valores en trminos de los atributos de los
objetos, o para modificar el propio objeto. Los diagramas de clase pueden describir
mtodos adems de atributos.

Los conjuntos de relaciones binarias se representan en UML dibujando simplemente una

lnea que conecte los conjuntos de entidades. Se escribe el nombre del conjunto de
relaciones adyacente a la lnea. Tambin se puede especificar el papel que juega un
conjunto de entidades en un conjunto de relaciones escribiendo el nombre del papel en
un cuadro, junto con los atributos del conjunto de relaciones, y conectar el cuadro con
una lnea discontinua a la lnea que describe el conjunto de relaciones. Este cuadro se
puede tratar entonces como un conjunto de entidades, de la misma forma que una
agregacin en los diagramas E-R puede participar en relaciones con otros conjuntos de
entidades. La relaciones no binarias no se pueden representar directamente en UML se
deben convertir en relaciones binarias (vease Apartado 2.4.3). Las restricciones de
cardinalidad se especifican en UML de la misma forma que en los diagramas E-R, de la
forma i..s, donde i denota el mnimo y s el mximo nmero de relaciones en que puede
participar una entidad. Sin embargo, se debera ser consciente que la ubicacin de las
restricciones es exactamente el inverso de la ubicacin de las restricciones en los
diagramas E-R, como muestra la figura. La restriccin 0..* en el lado E2 y 0..1 en el
lado E1. Cuando se hace el diagrama en UML esto se invierte quedando en E1 de 0:1 y
en el lado E2 0:*