Bases de Datos Unidad 2

UNIVERSIDAD NACIONAL AUTÓNOMA DE
MÉXICO
FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN
Licenciatura En Informática
Bases de
Datos
Autor: L.I. María de Lourdes Isabel
Ponce Vásquez
AGOSTO - DICIEMBRE 2008

Contenido
UNIDAD 2. DISEÑO DE BASES DE DATOS.......................................................................................................4
Objetivos Específicos.......................................................................................................................4
2.1. Introducción al Diseño...............................................................................................................4
2.1.1. Aproximación Mediante Análisis de sistemas.....................................................................4
2.1.2. Aproximación Mediante Etapas de Diseño de la BD..........................................................5
2.1.1.1. Análisis del ambiente del usuario.................................................................................5
2.1.1.2. Desarrollo del modelo de datos conceptual..................................................................5
2.1.1.3. Elegir un DBMS............................................................................................................5
2.1.1.4. Desarrollo del modelo lógico........................................................................................6
2.1.1.5. Desarrollo del modelo físico.........................................................................................6
2.1.1.6. Evaluación del modelo físico........................................................................................6
2.1.1.7. Desarrollar la afinación si la evaluación lo indica.........................................................6
2.1.1.8. Implementar el modelo físico........................................................................................6
2.2. Arquitectura de BD en Tres Niveles..........................................................................................6
2.2.1. Modelo Externo..................................................................................................................7
2.2.2. Modelo Lógico....................................................................................................................8
2.2.3. Modelo Físico.....................................................................................................................8
2.2.4. Independencia de Datos....................................................................................................9
2.3. Modelo Semántico....................................................................................................................9
2.4. Modelo Entidad/Relación (MER).............................................................................................10
2.4.1. Entidades.........................................................................................................................11
2.4.2. Atributos...........................................................................................................................11
2.1.1.9. Dominios....................................................................................................................12
2.1.1.10. Valores Nulos...........................................................................................................12
2.1.1.11. Atributos multivaluados............................................................................................12
2.1.1.12. Atributos compuestos...............................................................................................12
2.1.1.13. Atributos derivados...................................................................................................12
2.4.3. Llaves .............................................................................................................................12
2.1.1.14. Llave primaria...........................................................................................................13
2.1.1.15. Llave candidata........................................................................................................13
2.1.1.16. Llave alterna.............................................................................................................13
2.1.1.17. Llave secundaria......................................................................................................13
2.1.1.18. Llave compuesta......................................................................................................13
2.4.4. Interrelaciones..................................................................................................................13
2.1.1.19. Tipos de interrelaciones...........................................................................................14
2.1.1.20. Atributos e interrelaciones........................................................................................14
2.1.1.21. Cardinalidad de una Interrelación (Cardinalidad máxima)........................................14
2.1.1.22. Restricciones de participación (Cardinalidad Mínima)..............................................16
2.1.1.23. Roles........................................................................................................................17
2.1.1.24. Interrelaciones dependientes y entidades débiles....................................................17
2.5. Modelo Entidad/Relación Extendido........................................................................................17
2.5.1. Generalización y Especialización (Sutipos)......................................................................17
2.1.1.25. Especialización.........................................................................................................18
2.1.1.26. Generalización.........................................................................................................18
2.1.1.27. Restricciones de Generalización..............................................................................18
Unidad 2. Diseño de Bases de Datos Página 2

2.5.2. Agregación.......................................................................................................................18
2.6. Metodología de Diseño con el Modelo Entidad/Relación........................................................19
2.6.1. Situaciones.......................................................................................................................19
2.6.2. Pasos...............................................................................................................................20
2.6.3. Paso 1- Modelar Entidades..............................................................................................20
2.1.1.28. Entidades Mayores...................................................................................................21
2.1.1.29. Entidades Menores..................................................................................................21
2.1.1.30. Descubrir una entidad..............................................................................................21
2.1.1.31. Definir el alcance de la entidad.................................................................................21
2.1.1.32. Determinar la llave primaria de la entidad................................................................22
2.1.1.33. Documentar la entidad.............................................................................................22
2.6.4. Paso 2- Modelar Interrelaciones.......................................................................................22
2.1.1.34. Descubrir una interrelación.......................................................................................23
2.1.1.35. Definir el alcance de la interrelación.........................................................................23
2.1.1.36. Determinar el tipo de la interrelación........................................................................23
2.1.1.37. Documentar la interrelación......................................................................................24
2.6.5. Paso 3- Modelar Atributos................................................................................................24
2.1.1.38. Atributos reales de entidades...................................................................................24
2.1.1.39. Atributos reales de interrelaciones...........................................................................24
2.1.1.40. Datos derivados.......................................................................................................24
2.1.1.41. Descubrir un atributo................................................................................................25
2.1.1.42. Definir el alcance del atributo...................................................................................25
2.1.1.43. Determinar la llave del atributo.................................................................................25
2.1.1.44. Documentar el atributo.............................................................................................26
2.6.6. Modelar Generalización / Especialización (Subtipos).......................................................26
2.1.1.45. Paso 1 - Modelar Subtipos......................................................................................27
2.1.1.46. Paso 2 - Modelar Interrelaciones.............................................................................27
2.1.1.47. Paso 3 - Modelar Atributos......................................................................................27
2.6.7. Modelar Entidades Débiles .............................................................................................27
2.1.1.48. Paso 1 - Modelar Entidades dependientes..............................................................28
2.1.1.49. Paso 2 - Modelar Interrelaciones.............................................................................28
2.6.8. Modelar Interrelaciones Recursivas ................................................................................29
2.1.1.51. Paso 1 - Modelar Entidades ...................................................................................29
2.1.1.52. Paso 2 - Modelar Interrelaciones Recursivas..........................................................29
2.6.9. Modelar Interrelaciones Complejas (Agregaciones).........................................................29
2.1.1.54. Paso 1 - Modelar Entidades ...................................................................................30
2.1.1.55. Paso 2 - Modelar Agregaciones .............................................................................30
2.6.10. Modelar Interrelaciones De Tiempo ..............................................................................30
2.7. Modelo de Clases de UML......................................................................................................31
2.7.1. Estereotipos.....................................................................................................................32
2.7.2. Clases Entidad.................................................................................................................32
2.7.3. Clases Frontera................................................................................................................33
2.7.4. Clases Control..................................................................................................................33
2.7.5. Métodos...........................................................................................................................33
2.7.6. Atributos...........................................................................................................................34
2.8. Herramientas de Diseño.........................................................................................................34

UNIDAD 2. DISEÑO DE BASES DE DATOS
Objetivos Específicos
 Describir el ciclo de vida del desarrollo de aplicaciones con BD
 Explicar las diferencias entre el modelo externo, interno y lógico
 Comprender y crear modelos lógicos para el diseño de BD mediante el modelo
entidad/relación
 Comprender los conceptos básicos del modelado de datos.
 Aumentar la semántica del MER mediante el MEER
 Describir el modelo de clases de UML para el diseño de BD
2.1. Introducción al Diseño
El proceso de análisis de la organización y su ambiente, para desarrollar un modelo de BD que
refleje adecuadamente las funciones de la organización en el mundo real, e implementar el modelo
para crear una BD requiere de una metodología adecuada. El análisis de sistemas tradicional
proporciona una aproximación, pero una aproximación por etapas del diseño de BD ofrece una mejor
solución.
2.1.1. Aproximación Mediante Análisis de sistemas

Un proyecto de diseño e implementación de BD puede verse como un proyecto de desarrollo de
sistemas. Tradicionalmente, los sistemas de software se desarrollan usando un análisis de sistema
que identifica las etapas de diseño e implementación del sistema. Existe la suposición de que cada
sistema posee un ciclo de vida, un periodo de tiempo durante el cual el sistema se diseña, crea, usa
y se remplaza por un nuevo sistema. Un ciclo de vida se extiende a través de varios años y consiste
de las etapas mostradas a continuación. Usando el ciclo de vida tradicional, el sistema
eventualmente cumplirá con las necesidades del usuario, los problemas serán identificados y el ciclo
de vida inicia otra vez.
Etapa Actividades
Investigación Entrevistar usuarios, estudiar reportes, transacciones, software y documentación
Preliminar para identificar problemas en el sistema actual, y los objetivos del nuevo sistema.
Estudio de Estudiar las alternativas, estimar costos, estudiar el calendario y beneficios, y
Factibilidad hacer recomendaciones.
Diseño Trabajar con los usuarios para desarrollar el diseño del sistema general. Elegir el
Preliminar mejor diseño. Desarrollar el diagrama de flujo del sistema. Identificar las
necesidades de hardware, software y personal. Revisar los estimados.
Diseño Hacer el diseño técnico. Planear los módulos del sistema, algoritmos, archivos,
Detallado base de datos, formularios de E/S. Revisar estimados.
Implementació Programar módulos, convertir archivos, probar sistema, escribir documentación,
n del desarrollar procedimientos de operación, capacitar al personal, hacer corrida en
Sistema paralelo, poner en funcionamiento el nuevo sistema.
Operación del Evaluar el sistema. Monitorear y modificar el sistema de acuerdo a las
Sistema necesidades.

2.1.2. Aproximación Mediante Etapas de Diseño de la BD
Una suposición básica detrás de la aproximación mediante el análisis del ciclo de vida del sistema es
que los sistemas eventualmente se volverán obsoletos y tendrán que ser remplazados. En el
ambiente de BD, existen razones para cuestionar esta suposición. La BD puede ser diseñada de
modo que pueda evolucionar, cambiando para cumplir las necesidades futuras de la organización.
Esta evolución es posible cuando el diseñador desarrolla un verdadero modelo conceptual de la
organización con las siguientes características:
 El modelo refleja adecuadamente las operaciones de la organización.

 Es suficientemente flexible para permitir cambios como cuando se necesita nueva
información.
 Soporta muchas y diferentes vistas de los usuarios.
 Es independiente de la implementación física.
 No depende del modelo de datos usado por un DBMS particular.
Un buen diseño del modelo conceptual de la BD protege los recursos de datos permitiendo que
evolucionen y sirvan para las necesidades de información, actuales y futuras. Si el sistema es
verdaderamente independiente de su implementación física, entonces puede moverse a un nuevo
hardware para sacar ventaja del desarrollo tecnológico. Aún cuando el DBMS elegido para la
implementación se remplace, el modelo lógico puede cambiar, pero el modelo conceptual de la
empresa sobrevive. La aproximación mediante etapas de diseño de la BD es un método top-down
(de arriba abajo) que inicia con las declaraciones generales de las necesidades, y progresa a mayor
y mayor detalle considerando los problemas. Los diversos problemas se consideran en diferentes
fases del proyecto. Cada etapa usa una herramienta de diseño que es apropiada para el nivel de
problema. Las etapas de esta aproximación son:
2.1.1.1. Análisis del ambiente del usuario

El primer paso en el diseño de BD es determinar el ambiente del usuario actual. El diseñador estudia
todas las aplicaciones presentes, determina sus entradas y salidas, examina todos los reportes
generados por el sistema actual, y entrevista a los usuarios para determinar cómo usan el sistema.
Después de que el sistema actual es comprendido, el diseñador trabaja cercano a los usuarios
actuales y potenciales del nuevo sistema para identificar sus necesidades. El diseñador considera no
sólo las necesidades presentes sino las posibles nuevas aplicaciones o futuros usos de la BD. El
resultado de este análisis es un modelo del ambiente y necesidades de los usuarios.
2.1.1.2. Desarrollo del modelo de datos conceptual

Usando el modelo del ambiente de los usuarios, el diseñador desarrolla un modelo conceptual
detallado de la BD, identifica las entidades, atributos e interrelaciones que serán presentadas.
Además del modelo conceptual, el diseñador tiene que considerar cómo será usada la BD. Los tipos
de aplicaciones y transacciones y las clases de accesos. Otras restricciones como el presupuesto y
los requerimientos de desempeño también deben identificarse. El resultado de esta fase es un
conjunto de especificaciones de la BD.
2.1.1.3. Elegir un DBMS

El diseñador usa las especificaciones y sus conocimientos de los recursos de hardware y software
disponible para evaluar DBMSs alternativos. Cada DBMS impone sus propias restricciones. El
diseñador intenta elegir el sistema que satisfaga mejor las especificaciones para el ambiente.

2.1.1.4. Desarrollo del modelo lógico
El diseñador mapea el diseño conceptual al modelo de datos usado por el DBMS, creando el modelo
lógico. Por ejemplo, en el caso de una BD relacional diseña las tablas y vistas del modelo.
2.1.1.5. Desarrollo del modelo físico

El diseñador planea el formato de datos considerando la estructura soportada por el DBMS elegido, y
los recursos de hardware y software disponibles. Diseña índices, clusters, etc.
2.1.1.6. Evaluación del modelo físico

El diseñador estima el desempeño de todas las aplicaciones y transacciones, considerando los datos
cuantitativos previamente identificados y da prioridades a las aplicaciones y transacciones. Puede
ser de ayuda desarrollar un prototipo, implementando una porción de la BD de modo que las vistas
de usuario puedan ser validadas y realizar medidas de desempeño más adecuadamente.
2.1.1.7. Desarrollar la afinación si la evaluación lo indica

Pueden realizarse ajustes, como modificar la estructura física u optimizar el software, para mejorar el
desempeño.
2.1.1.8. Implementar el modelo físico

Si la evaluación es positiva, el diseñador implementa el diseño físico y la BD se pone en operación.
Varias etapas pueden repetirse para dar oportunidad de hacer modificaciones en el proceso de
diseño. Por ejemplo, después de desarrollar el modelo conceptual, el diseñador lo comunica a los
grupos de usuarios para asegurarse de que sus requerimientos son presentados apropiadamente. Si
no es así, el modelo conceptual debe ajustarse. Si el modelo conceptual no se mapea bien con un
modelo de datos particular, se debe considerar algún otro. Para un DBMS particular, pueden existir
varios posibles mapeos lógicos que pueden ser evaluados. Si el modelo físico no se acepta, debe
considerarse un mapeo diferente o un DBMS diferente. Si el resultado de la evaluación de
desempeño no es satisfactorio, debe realizarse más afinación y evaluación. El modelo físico puede
cambiar si la afinación no produce el desempeño requerido. Si las repetidas afinaciones y
optimizaciones no son suficientes, puede ser necesario cambiar el modo en que el modelo lógico es
mapeado al DBMS o considerar un DBMS diferente. Aún después de que el sistema es
implementado, pueden requerirse cambios para responder a las necesidades cambiantes del
ambiente de los usuarios.
2.2. Arquitectura de BD en Tres Niveles

Cuando se discute de BD, se necesitan algunos términos para describir los diversos aspectos de su
estructura. Un vocabulario y arquitectura fue desarrollado y publicado en 1975 por la
ANSI/X3/SPARC y como resultado de este y otros reportes posteriores, las BD pueden ser vistas en
tres niveles de abstracción. Estos tres niveles forman una arquitectura de tres niveles y es descrita
por tres esquemas, los cuales son descripciones escritas de sus estructuras. El propósito de esta
arquitectura es separar los modelos de usuarios de la estructura física de la BD y esta separación es
deseable por las siguientes razones:
 Los diferentes usuarios necesitan diferentes vistas de los mismos datos.

 El modo en que un usuario particular necesita ver los datos puede cambiar con el tiempo.

 Los usuarios no deben tener que enfrentarse a las complejidades de las estructuras de
almacenamiento de los datos.
 El DBA debe ser capaz de hacer cambios al modelo conceptual de la BD sin afectar a todos
los usuarios.
 El DBA debe ser capaz de cambiar el modelo lógico, y las estructuras de datos y archivos, sin
afectar la vista del modelo conceptual del usuario.
 La estructura de la BD no debe afectarse por cambios en aspectos físicos de
almacenamiento, como cambios de dispositivos de almacenamiento.
En esta arquitectura, el modo en que los usuarios piensan acerca de los datos es llamado nivel
externo. El nivel interno es el modo en que los datos están actualmente almacenados usando
estructuras de datos estándar y organizaciones de archivos. Sin embargo, existen muchas y
diferentes vistas de usuarios y muchas estructuras físicas, de modo que debe haber algún método
para mapear las vistas externas a las estructuras físicas. Un mapeo directo no es deseable, ya que
los cambios hechos a las estructuras o dispositivos de almacenamiento podrían requerir hacer
cambios en la estructura externa correspondiente. Sin embargo, existe un nivel intermedio que
proporciona ambos mapeos e independencia entre los niveles externo e interno. Éste es el nivel
lógico.
2.2.1. Modelo Externo

El nivel externo consiste de muchas y diferentes vistas externas o modelos externos de la BD. Cada
usuario tiene un modelo que representa el mundo real de modo que es comprensible para el usuario.
Un usuario particular interactúa sólo con ciertos aspectos del minimundo, y sólo está interesado en
algunas entidades, y sólo algunos de sus atributos e interrelaciones. Por lo tanto, la vista del usuario
contendrá información sólo de esos aspectos. Otras entidades, atributos o interrelaciones pueden ser
representados actualmente en la BD, pero el usuario no las tendrá disponibles. Además de incluir
diferentes entidades, atributos o interrelaciones, diferentes vistas pueden tener diferentes
representaciones de los mismos datos. Algunas vistas pueden incluir datos virtuales o calculados,
que son datos que no están almacenados en la BD como tal, pero se crean cuando se necesitan. Las
vistas pueden incluir incluso datos combinados o calculados de diferentes registros. Un registro
externo es un registro como es visto por un usuario particular desde su vista externa. Una vista
externa es actualmente una colección de registros externos. Las vistas externas se describen en
esquemas externos (también llamados subesquemas) que son escritos en el DDL. Cada esquema
del usuario da una completa descripción de cada tipo de registro externo que aparece en esa vista
del usuario. Los esquemas son compilados por el DBMS y almacenados en forma de objetos para
ser usados por el diccionario de datos para extraer los registros. También se mantiene el código
fuente como documentación. El DBMS usa el esquema externo para crear una interfaz de usuario
que es tanto una barrera como una interfaz fácil de usar. Un usuario individual ve la BD a través de
esta interfaz. Ésta define y crea un ambiente de trabajo para los usuarios, aceptando y desplegando
información en el formato que los usuarios esperan. También actúa como un límite por debajo del
que los usuarios no pueden ver. Esconde los detalles lógicos, internos y físicos del usuario.
Para desarrollar una vista de usuario, primero interviene el usuario y examina los reportes y
transacciones que crea o recibe. Después de diseñar las entidades de la BD es planeado, el DBA
determina qué datos estarán disponibles para el usuario y qué representación verá el usuario, y
escribe un esquema externo para ese usuario. Si es posible, este esquema externo incluye toda la
información que puede ser vista. Generalmente, los nuevos datos requeridos ya están disponibles en
la BD, y el esquema externo del usuario es rescrito para permitir el acceso a ellos.

2.2.2. Modelo Lógico
El nivel intermedio en la arquitectura de tres niveles es el nivel lógico, este modelo incluye toda la
información de la estructura de la BD, como la ve el DBA. Es la vista común de los datos e incluye
una descripción de todos los datos que están disponibles para compartir. Es un modelo comprensivo
o una vista del trabajo de la organización en el minimundo. Todas las entidades, con sus atributos e
interrelaciones se presentan en el modelo lógico usando los datos del modelo que el DBMS soporta.
El modelo incluye cualquier restricción de datos e información semántica sobre el significado de los
datos. El modelo lógico soporta las vistas externas, ya que cualquier dato disponible para el usuario
debe estar presente o ser derivado del modelo lógico. El modelo lógico es relativamente constante.
Cuando el DBA originalmente lo diseña, intenta determinar las necesidades de información presentes
y futuras e intenta desarrollar un modelo actualizado de la organización. Por tanto, aunque se
requieran nuevos datos, el modelo lógico puede contener los objetos necesarios. Si éste no es el
caso, el DBA expande el modelo lógico para incluir los nuevos objetos.
Un buen modelo lógico será capaz de acomodar estos cambios y aún soportar las vistas externas
anteriores. Sólo los usuarios que necesitan acceso a los nuevos datos deben ser afectados por los
cambios. El esquema lógico es una descripción completa de la información contenida en la BD. Se
escribe en el DDL, compilado por el DBMS y almacenado en forma de objeto en el diccionario de
datos y en formato original como documentación. El DBMS usa el esquema lógico para crear la
interfaz lógica de registros, la cual es un límite por debajo del cual todo es invisible al nivel lógico.
Ni detalles internos o físicos de cómo están almacenados los registros o secuencias cruzan este
límite. El modelo lógico es actualmente la colección de registros lógicos. El modelo de datos lógico
es el corazón de la BD. Soporta todas las vistas externas y es soportado por el modelo interno. Sin
embargo, el modelo interno es meramente la implementación física del modelo lógico. El modelo
lógico es por sí mismo derivado del modelo conceptual.
El desarrollo del modelo conceptual es la parte más desafiante, interesante y de mayor recompensa
en el diseño de BD. El diseñador de la BD debe ser capaz de identificar, clasificar y estructurar
objetos en el diseño. El proceso de abstracción, que implica identificar propiedades comunes de un
conjunto de objetos en vez de enfocarse en detalles, es usado para categorizar los datos. Por
ejemplo, los tipos de datos abstractos se consideran aparte de la implementación; el comportamiento
de colas y pilas puede describirse sin considerar cómo se representan. El diseñador puede ver
diferentes niveles de abstracción, de modo que un objeto abstracto en un nivel se convierte en
componente de un alto nivel de abstracción. Durante el proceso del diseño conceptual puede haber
muchos errores e inicios en falso. Como muchos otros procesos de solución de problemas, el diseño
conceptual de la BD es un arte, guiado por el conocimiento. Pueden haber muchas posibles
soluciones, pero algunas serán mejores que otras. El proceso por sí mismo es una situación de
aprendizaje. El diseñador gradualmente empieza a entender el trabajo de la organización y el
significado de los datos y expresa ese entendimiento en el modelo elegido. Si el diseñador produce
un buen modelo conceptual, es relativamente fácil convertirlo en un modelo lógico y completar el
interno y el diseño físico.
Si el modelo conceptual es bueno, las vistas externas son fáciles de definir también. Por otro lado, un
modelo conceptual malo puede ser difícil de implementar adecuadamente, particularmente si las
interrelaciones no son bien definidas. Continuará causando problemas durante la vida de la BD,
porque necesitará ser parchado cada vez que se necesite diferente información. La habilidad de
ajustarse a cambios es uno de los indicadores de un buen diseño conceptual. Por tanto, es
importante dedicar todo el tiempo y energía necesarios a producir el mejor diseño conceptual.
2.2.3. Modelo Físico

El nivel físico cubre la implementación física de la BD. Este incluye las estructuras de datos y
organización de archivos usada para almacenar los datos en los dispositivos de almacenamiento
físico. El DBMS elegido determina, qué estructuras están disponibles. Trabaja con los métodos de
acceso del SO para colocar los datos en el dispositivo de almacenamiento, construye los índices y/o
conjuntos de apuntadores que serán usados para extraer los datos. Por tanto, este nivel es
responsabilidad del DBMS y manejado por el SO bajo la dirección del DBMS. La línea entre las
responsabilidades del DBMS y el SO no son claras y actualmente varían de sistema a sistema.
Algunos DBMSs toman ventaja de muchas facilidades de los métodos de acceso del SO, mientras
que otros ignoran todo acerca del manejo más básico de E/S y crean su propia organización alterna
de archivos. El DBA debe tener cuidado de las posibilidades de mapeo del modelo lógico al modelo
interno y elegir un mapeo que soporte las vistas lógicas y proporcione un desempeño adecuado. El
esquema interno escrito en DDL, es una descripción completa del modelo interno. Incluye
elementos de cómo se representan los datos, cómo se almacenan los registros, qué índices existen,
que apuntadores existen y qué esquemas de búsqueda se usan. Un registro interno es un registro
almacenado. Es la unidad que es pasada al nivel interno. La interfaz de registro almacenado es el
límite entre el nivel físico, del cual el SO puede ser responsable, y el nivel interno para el cual el
DBMS es responsable. Esta interfaz es proporcionada al DBMS por el SO. En algunos casos donde
el DBMS desarrolla algunas funciones del SO, el DBMS puede crear esta interfaz. El nivel físico
debajo de esta interfaz consiste de elementos que sólo el SO conoce, tales como la secuenciación
implementada y si los campos de los registros internos son almacenados actualmente como bytes
continuos en el disco. El SO crea la interfaz de registro físico, la cual es el límite más bajo que
oculta el detalle de almacenamiento, como qué porción de qué pista contiene qué dato.
El DD no sólo almacena los esquemas externos, lógicos e internos completos, también almacena el
mapeo entre ellos. El mapeo externo/lógico indica al DBMS qué objetos en nivel lógico
corresponden con qué objetos en una vista externa particular. Debe haber diferencias entre los
nombres de los registros, nombres de atributos, elementos de orden de datos, tipos de datos, etc. Si
cambian en el modelo lógico o externo, el mapeo debe cambiar. El mapeo lógico/interno
proporciona la correspondencia entre objetos lógicos e internos, indicando cómo los objetos lógicos
se representan físicamente. Si la estructura de almacenamiento cambia, el mapeo también.
2.2.4. Independencia de Datos

La principal ventaja de la arquitectura de tres niveles es que proporciona independencia de datos,
lo cual significa que los niveles superiores no se ven afectados por cambios realizados en los niveles
inferiores. Existen dos clases de independencia de datos:
 Independencia lógica. Se refiere a la inmunidad de los modelos externos a cambios en el

modelo lógico. El modelo lógico cambia al agregar nuevos tipos de registros, nuevos atributos
y nuevas interrelaciones, esto debe ser posible sin afectar las vistas externas existentes. Sólo
los usuarios para los que se hacen los cambios necesitan visualizarlos, pero otros usuarios
no. En particular, los programas de aplicación existentes no deben necesitar volverse a
escribir cuando se modifica el nivel lógico.
 Independencia física. Se refiere a la inmunidad del modelo lógico a cambios en el modelo
interno. Los cambios internos o físicos como secuencia diferente de registros, intercambio
entre un método de acceso y otro, el algoritmo de búsqueda, uso de diferentes estructuras de
datos y uso de nuevos dispositivos de almacenamiento no debe afectar el modelo lógico. En
el nivel externo, el único efecto que se puede sentir es un cambio en el desempeño. De
hecho, el deterioro en el desempeño es la razón más común para cambiar el modelo interno.
2.3. Modelo Semántico

Los modelos semánticos sirven para describir los niveles externo y conceptual de los datos, y son
independientes de aspectos físicos o internos. Además de especificar lo que está representado en la
BD, intentan incorporar algunos significados o aspectos semánticos de los datos como la
representación explícita de objetos, atributos e interrelaciones, categorías de objetos, abstracciones
y restricciones explícitas de los datos.
2.4. Modelo Entidad/Relación (MER)

Símbolo Nombre Significado Ejemplo
Rectángulo Entidad Fuerte Alumno
Rectángulo Doble Entidad Débil Precio
Elipse u Óvalo Atributo Id_cuenta nombr
Diamante o Rombo Interrelación Estud
Línea Liga:
Atributo a Entidad Id_cuent
a
Alumno
Entidad a Interrelación
Alumno
Estud
Atributo a Interrelación
Id_cuent
a
Estud
Símbolos Básicos para Diagramas Entidad/Relación
El Modelo Entidad/Relación (MER) es un ejemplo de modelo semántico. El MER fue desarrollado por
P.P. Chen en 1976 para permitir al diseñador expresar las propiedades conceptuales de la BD en un
esquema y es ampliamente usado para el diseño conceptual. El esquema es independiente del
DBMS particular, por lo que no está limitado al DDL del DBMS y puede permanecer correcto aún si
se cambia el DBMS. Sin embargo a diferencia de los esquemas descritos en el DDL, los diagramas
E/R generalmente no están disponibles para usarse por el DBMS para crear la estructura lógica o
establecer las relaciones externa/lógica o lógica/interna.

Se basa en identificar objetos llamados entidades que representan objetos reales en el minimundo.
Las entidades se describen por sus atributos y son conectadas por interrelaciones. Las entidades
describen personas, lugares, eventos, objetos o conceptos acerca de los datos recolectados. Una
descripción más apropiada es que una entidad es cualquier objeto que exista y sea distinguible de
otros objetos. Los atributos describen las entidades y las distinguen de otras. Una entidad es una
colección de entidades del mismo tipo. Una interrelación es una colección de interrelaciones del
mismo tipo y también pueden tener atributos descriptivos. El MER también permite expresar
restricciones en entidades e interrelaciones. Aunque este modelo es ampliamente usado, no existe
un estándar, por lo que existen muchas variantes al momento de hacer un diagrama E/R.
Este modelo sólo realiza el diseño, no realiza la implementación, por lo tanto una vez hecho el diseño
se puede llevar al modelo relacional, de red o jerárquico.
Una de las características más útiles y atractivas del MER es que proporciona un método gráfico
para especificar la estructura conceptual de la BD. Los diagrama E/R contienen símbolos para
entidades, atributos e interrelaciones. La tabla anterior muestra algunos de los símbolos con su
nombre y significado.
2.4.1. Entidades
Como se mencionó, las entidades describen los objetos del mundo real, una instancia de una
entidad representa un objeto particular, por ejemplo el cliente número 21. Un tipo de entidad
representa una categoría de entidades con propiedades comunes. El tipo de entidad forma la
intensión de la entidad, la parte permanente de la definición. Todas las instancias de una entidad en
un momento dado forman la extensión de la entidad.
Una entidad es cualquier objeto importante identificado en el ambiente de trabajo de los usuarios,
del cual, se desea almacenar información. Todas las entidades son sustantivos, pero no todos los
sustantivos son entidades.
Todas las entidades deben cumplir las siguientes reglas:
 Los nombres de las entidades deben ser únicos. En un modelo de datos, no debe haber
dos entidades con el mismo nombre. Esto permite especificar precisamente qué entidades
son de interés sin ambigüedad.
 Cada entidad debe tener una llave primaria. Cada entidad debe tener una llave primaria y
sólo una llave primaria ya sea simple o compuesta.
2.4.2. Atributos
Los atributos de una entidad representan la definición de propiedades, características o cualidades
de un tipo de entidad o de una interrelación. Por ejemplo para un cliente podría ser su RFC, nombre,
apellido, domicilio fiscal, etc. Normalmente, una entidad tendrá un valor para cada uno de estos
atributos. Para decidir si un objeto debe representarse como entidad o atributo, el diseñador debe
considerar si el objeto describe a otro objeto y si tiene valores para sus instancias. En ese caso, es
mejor representar el objeto como un atributo, si es difícil identificar valores, el objeto podría ser una
entidad.
Todos los atributos son sustantivos o adjetivos calificativos, pero no todos los sustantivos o adjetivos
calificativos son atributos.

Un atributo clave ó identificador es el atributo que identifica de manera única a cada instancia de
la entidad y un atributo simple o descriptor es cualquier otro atributo.
Todas las entidades deben cumplir las siguientes reglas:
 Los nombres de los atributos deben ser únicos en la entidad. Cada atributo en una
entidad debe tener un nombre único. Sin embargo, los atributos en diferentes entidades
pueden compartir el mismo nombre.
 Los datos de los atributos deben ser atómicos. Si un atributo puede descomponerse en
partes, debe ser redefinido como dos o más atributos. La excepción a esta regla se aplica a
valores de fecha y hora que generalmente son tratados como un tipo de dato.
2.1.1.9. Dominios
El conjunto de valores permitidos para cada atributo se llama dominio del atributo. Diferentes
atributos pueden tener el mismo dominio. Por ejemplo valores positivos para una edad o para un
número de cuenta. El nombre del atributo y su dominio son parte de la intensión del modelo, mientras
que los valores de los atributos son parte de la extensión.
2.1.1.10. Valores Nulos

Algunas veces el valor para un atributo es desconocido en tiempo presente o es indefinido (no aplica)
para una instancia en particular. En una BD, algunos atributos pueden permitir tener valores nulos
para algunas instancias de la entidad. En ese caso, la instancia de la entidad no corresponderá al
dominio del atributo, aunque otras instancias de la misma entidad si corresponderán al dominio del
atributo. Nótese que los valores cero o cadena en blanco para campos de tipo cadena son
considerados como valores no nulos. Nulo significa sin valor.
2.1.1.11. Atributos multivaluados

Algunos atributos pueden tener múltiples valores para una instancia de la entidad. Por ejemplo,
varios teléfonos. Si es posible que un atributo tenga valores múltiples se puede usar una elipse
doble alrededor del nombre del atributo. Esto no implica que todas las instancias tengan valores
múltiples, sólo que algunas instancias pueden tenerlos.
2.1.1.12. Atributos compuestos

Algunos atributos pueden descomponerse en pequeños elementos, por ejemplo una fecha, estos
atributos son llamados atributos compuestos. Para indicar que un atributo es compuesto, se pone
una elipse para el atributo compuesto y otra por cada atributo que lo compone uniéndolos con líneas
al atributo compuesto.
2.1.1.13. Atributos derivados

Algunas veces se requiere incluir en el diseño un atributo cuyo valor puede ser calculado cuando se
necesite, por ejemplo la edad a partir de la fecha de nacimiento. Los atributos que no serán
almacenados, pero su valor será calculado u obtenido de otras fuentes, son derivados. Estos se
indican con elipses punteadas en el diagrama E/R. Los atributos también pueden derivarse de otras
entidades o interrelaciones.
2.4.3. Llaves

Una llave es el conjunto mínimo de atributos que identifica unívocamente cada registro en una
entidad.
2.1.1.14. Llave primaria

Una llave primaria es uno o más atributos que identifican de forma única a una entidad. Esto
significa que siempre permite distinguir una instancia de la entidad de otra. Para identificar una llave
primaria se requiere considerar el significado de los atributos, una noción semántica, antes de decidir
si existen extensiones únicas. Las llaves primarias representan una restricción que previene que dos
entidades tengan el mismo valor para estos atributos. Representan una suposición del minimundo
que se está usando en el modelo. Una característica importante de las llaves primarias, es que sus
atributos no pueden tener valores nulos por lo que, generalmente, el DBMS no permite los valores
nulos o duplicados en los atributos identificados como llaves primarias.
2.1.1.15. Llave candidata

Se deben tener cuidado que las llaves primarias no tengan atributos adicionales que no se necesiten
para identificar de manera única las instancias de la entidad, una llave candidata es aquella que no
contiene atributos adicionales, son llaves que pueden elegirse como llaves primarias donde ninguno
de sus atributos es por sí mismo una llave primaria. Puede haber varias llaves candidatas para una
entidad pero sólo una llave primaria.
2.1.1.16. Llave alterna

Todas las llaves candidatas que no se convierten en llaves primarias se pueden convertir en llaves
alternas, cuyos valores únicos proporcionan otro método de acceso a los registros.
2.1.1.17. Llave secundaria

Una llave secundaria generalmente se entiende como un atributo o más, cuyos valores, no
necesariamente únicos, se usan para acceder a los registros. Normalmente, se crean índices sobre
campos de llaves secundarias para permitir un acceso más rápido a los registros.
2.1.1.18. Llave compuesta

Una llave compuesta es aquella que tiene más de un atributo. Tanto las llaves primarias, como las
candidatas, alternas y secundarias pueden ser compuestas.
2.4.4. Interrelaciones
Las entidades se unen a otras mediante asociaciones o interrelaciones, las cuales son conexiones
o interacciones entre las instancias de las entidades. Mediante la abstracción, podemos identificar las
propiedades comunes de ciertas interrelaciones y definir un tipo de interrelación y su
correspondiente conjunto de interrelaciones como la colección de interrelaciones de ese tipo. Las
interrelaciones que satisfacen los requerimientos para los miembros en el conjunto de interrelaciones
en cualquier momento son las instancias o miembros del conjunto de interrelaciones. Como con las
entidades y atributos, los tipos de interrelaciones son parte de la intensión y las instancias son parte
de la extensión del modelo. El significado de las interrelaciones se captura con un verbo adecuado.
Si no se le da un nombre, nos referimos a la interrelación usando los nombres de las entidades
relacionadas, con un guión entre ellas (Estudiante-Materia). Todas las interrelaciones son verbos,
pero no todos los verbos son interrelaciones.

2.1.1.19. Tipos de interrelaciones
La mayoría de las interrelaciones son binarias, en las que se asocian dos entidades. Esta
interrelación se puede describir más formalmente como un conjunto de pares ordenados, en el cual
el primer elemento representa a una entidad y el segundo a otra.
Las entidades involucradas en una interrelación no necesitan ser distintas, estas interrelaciones se
llaman recursivas.
Una interrelación puede involucrar más de dos entidades, pudiendo tener interrelaciones ternarias,
que involucran tres entidades. En este caso las interrelaciones se pueden definir como un conjunto
ordenados de tripletas, en las cuales cada uno de los elementos corresponde a cada una de las
diferentes entidades.
Aunque la mayoría de las interrelaciones en un modelo de datos son binarias o a lo mucho ternarias,
se pueden definir interrelaciones ligando cualquier número de entidades. Por lo que en general, se
pueden definir como un conjunto de interrelaciones n-arias de la forma:
{(e1, e2, …, en) | e1 ∈ E1, e2 ∈ E2, …, en ∈ En }
Donde E son entidades, e son instancias de las entidades y cada n-tupla ordenada representa una
instancia de la interrelación. Esto se puede reconocer como la notación usada para el Producto
Cartesiano en matemáticas, y de hecho, una interrelación es un subconjunto del producto Cartesiano
de las entidades involucradas, o sea que, si R es una interrelación y E 1, E2, …, En son entidades,
entonces
R ⊂ E1 x E2 x … x En
2.1.1.20. Atributos e interrelaciones

Algunas veces las interrelaciones tienen atributos descriptivos que pertenecen a la interrelación y
no a las entidades involucradas. En un diagrama E/R, estos atributos se colocan en elipses unidas a
los diamantes de las interrelaciones.
2.1.1.21. Cardinalidad de una Interrelación (Cardinalidad máxima)

Es importante identificar restricciones en las interrelaciones, de modo que las interrelaciones
correspondan lo más posible a asociaciones en el mundo real. Dos tipos de restricciones son la de
participación y la cardinalidad. La cardinalidad de la interrelación es el número de entidades con
las que se puede relacionar otra entidad bajo la interrelación. Suponiendo que X y Y son entidades y
R es una interrelación binaria de X a Y, entonces si no se restringe la cardinalidad en R, cualquier
número de entidades en X podría relacionarse con cualquier cantidad de entidades en Y.
Generalmente, sin embargo, existen restricciones en el número de entidades asociadas. Se
distinguen cuatro tipos de interrelaciones binarias:
 Uno a Uno. Una interrelación R de X a Y es de uno a uno si cada instancia de la entidad X

se asocia con cero ó máximo con una instancia de la entidad Y, e inversamente, cada
instancia de la entidad Y es asociada con cero ó máximo una instancia de la entidad X. Este
tipo de interrelación es poco común, y puede o no aparecer en un modelo dado.
 Uno a Muchos. Una interrelación R de X a Y es de uno a muchos si cada instancia de la
entidad X puede asociarse con cero, una o muchas instancias de la entidad Y pero cada
instancia de la entidad Y se asocia máximo con una instancia de la entidad X. La palabra
“muchos” aplica al posible número de instancias de la entidad con que se asocia. Para una
instancia dada, puede ser cero, uno, dos o más instancias de entidad asociadas, pero si es
posible tener más de una, se usa la palabra muchos para describir la asociación. Este tipo de
asociación es muy común y puede aparecer en prácticamente todos los modelos.
 Muchos a Uno. Una interrelación muchos a uno es lo mismo que una muchos a uno, pero
vista desde el lado opuesto.
 Muchos a Muchos. Una interrelación R de X a Y es de muchos a muchos si cada instancia
de la entidad en X puede asociarse con cero, una ó muchas instancias de la entidad Y, y
cada instancia de la entidad Y puede asociarse con cero, una o muchas instancias de la
entidad X. Este tipo de interrelación también es muy común y aparece en la mayoría de los
modelos pero en menor cantidad.
Si las entidades A, B y C están relacionadas en una interrelación ternaria R, se puede determinar la

cardinalidad para la participación de cada entidad en la interrelación. Para cada combinación
particular de B y C, si existe sólo un valor de A, entonces A participa como una interrelación “uno”. Si
puede haber más que un valor de A para una combinación particular B-C, entonces A participa como
una interrelación “muchos”. Lo mismo ocurre con B y su interrelación A-C, y con C y su interrelación
A-B.
En un diagrama E/R, las líneas conectan los rectángulos de las entidades a los diamantes de las
interrelaciones para mostrar sus asociaciones. Existen diversos métodos para mostrar la cardinalidad
de la interrelación:
 Método 1, mostrar la cardinalidad poniendo 1, N o M sobre la línea que une la entidad a la

interrelación, dependiendo del número máximo de entidades asociadas.
1 M
Universidad Impar Carrera
te
1 Direct 1
Director or-
Departamento
M Se N
Alumno ins- Materia
 Método 2, mostrar la cardinalidad con flecha simple o doble en la línea que une la entidad a
la interrelación, dependiendo del número máximo de entidades asociadas.

te
Direct
Director or-
Departamento
Se
Alumno ins- Materia
 Método 3, mostrar la cardinalidad con o sin flecha en la línea que une la entidad a la

te
Direct
Director or-
Departamento
Se
Alumno ins- Materia
 Método 4, mostrar la cardinalidad con o sin punto en la línea que une la entidad a la

te
Direct
Director or-
Departamento
Se
Alumno ins- Materia
 Método 5, mostrar la cardinalidad con o sin patas de gallo en la línea que une la entidad a la

te
Direct
Director or-
Departamento
Se
Alumno ins- Materia
Aunque estos no son los únicos métodos para representar las interrelaciones entre entidades, son de
los métodos más empleados, sobre todo por herramientas CASE y de diseño de BD, existen también
algunos métodos que no incluyen los diamantes, sólo las líneas que conectan a las entidades.
2.1.1.22. Restricciones de participación (Cardinalidad Mínima)
Es posible que no todos los miembros de una entidad participen en la interrelación. Si cada miembro
de una entidad debe participar en la interrelación, es una participación total de la entidad en la
interrelación, esto se puede indicar en el diagrama E/R con una doble línea de la entidad a la
interrelación o agregando un 1 sobre la línea. Cuando algún miembro de la entidad puede no

participar en la interrelación, se tiene una participación parcial y se representa con una línea simple
o un cero sobre la línea.
2.1.1.23. Roles
En una interrelación, cada entidad tiene una función llamada rol en la interrelación. Generalmente es
claro en el contexto qué rol juega una entidad dentro de la interrelación, sin embargo, en las
interrelaciones recursivas es necesario indicar los roles que cada miembro juega en la interrelación;
en las interrelaciones donde la misma entidad se asocia con otra de dos formas diferentes, también
es necesaria la indicación de cada rol. Cuando las entidades se conectan a múltiples interrelaciones,
los roles pueden escribirse en la liga apropiada.
2.1.1.24. Interrelaciones dependientes y entidades débiles

En ocasiones, se necesita almacenar información acerca de una entidad que no sería interesante a
menos que exista ya una entidad relacionada en la BD; puede existir por tanto una interrelación de
dependencia entre dos entidades. Si X y Y son entidades y cada instancia de Y debe tener una
instancia correspondiente de X, entonces se dice que Y es dependiente de X. Esto significa que la
entidad Y no puede existir sin alguna entidad X. Si la existencia de Y depende de la existencia de X,
entonces Y debe tener participación total en su interrelación con X. Ocurre un tipo especial de
dependencia cuando la entidad dependiente no tiene una llave candidata y sus instancias no son
distinguibles sin una interrelación con otra entidad. En este caso, X es una entidad fuerte (también
llamada padre, dueña o dominante) y es aquella que puede existir por si misma, sin requerir la
existencia de otras; Y es una entidad débil (también llamada hija, dependiente o subordinada) y es
una entidad cuya existencia depende de otra u otras entidades. Una entidad débil se representa en el
diagrama E/R con un rectángulo y diamante de doble línea. Cuando una entidad es débil, no tiene
llave primaria por si misma, pero es única en referencia a su interrelación con su padre. Sin embargo,
generalmente tiene una llave parcial, llamada discriminador, que permite identificar de manera
única las entidades débiles que pertenecen al mismo padre. La llave parcial puede ser un atributo
simple o compuesto.
2.5. Modelo Entidad/Relación Extendido

Aunque el MER es suficiente para representar las necesidades de datos para aplicaciones
tradicionales de negocios, no es suficientemente rico semánticamente para modelar ambientes más
complejos usados por aplicaciones más avanzadas. Las BD usadas para sistemas de información
geográfica, minería de datos, multimedia, diseño asistido por computadora y manufactura asistida
por computadora (CAD/CAM), desarrollo de software, ingeniería de diseño y otras aplicaciones
sofisticadas deben ser capaces de representar más información semántica que el MER estándar
puede expresar. El Modelo Entidad Relación Extendido aumenta el MER para incluir varios tipos
de abstracción y expresar restricciones de modo más claro. Se han agregado símbolos a los
diagramas E/R para crear diagramas EE/R que expresan estos conceptos.
2.5.1. Generalización y Especialización (Sutipos)

El proceso de generalización y su inverso, especialización, son dos abstracciones que se usan para
incorporar más significado en diagramas EE/R. Estas son tipos de interrelaciones que implican que
una entidad es un subtipo de otra.

2.1.1.25. Especialización
Es común que una entidad contenga uno o más subconjuntos que tienen atributos especiales o que
participan en interrelaciones que otros miembros de la misma entidad no. Por ejemplo, se puede
tener una entidad empleado que puede dividirse en empleados asalariados o por honorarios.
El método de identificación de subtipos de entidades existentes llamado especialización,

corresponde a la noción de subclases y herencia de clases en el diseño orientado a objetos, donde
se representa por jerarquía de clases. En los diagramas EE/R la interrelación de herencia se
representa con un triángulo que se conecta al supertipo y a los subtipos. Los subtipos heredan los
atributos de los supertipos, y pueden opcionalmente tener atributos adicionales. Ya que un miembro
de un subtipo es un miembro del supertipo, la especialización en ocasiones se le llama interrelación
es un.
2.1.1.26. Generalización
Con el proceso de especialización, se desarrolla una jerarquía de tipos separando una entidad
existente en subtipos. La jerarquía de tipos también puede crearse reconociendo que dos o más
entidades tienen propiedades comunes e identificando un supertipo común para ellas, este proceso
se llama generalización. Estos dos procesos son inversos uno del otro, pero ambos resultan en el
mismo tipo de diagrama de jerarquía. Usando generalización se desarrollan estos diagramas de
abajo hacia arriba y con la especialización se desarrolla de arriba abajo.
2.1.1.27. Restricciones de Generalización

Los subtipos pueden ser traslapados, lo que indica que la misma instancia de entidad puede
pertenecer a más de un subtipo; o pueden ser excluyentes, lo que implica que sólo pueden
pertenecer a un subtipo, en el primer caso se puede poner una línea curva con una M y en el
segundo se indicará un 1. La especialización también puede tener una restricción de pertenencia, si
cada miembro del supertipo debe pertenecer a algún subtipo, se tiene especialización total. Si
miembros del supertipo pueden no pertenecer a ninguno de los subtipos, la especialización es
parcial. En el primer caso se indica con un 1 al lado del 1 o M que indica el número máximo de
subtipos a los que puede pertenecer, y en el segundo caso se indica con un 0.
En algunas especializaciones, es posible identificar el subtipo al que pertenece una entidad

examinando una condición específica para cada subtipo. En un diagrama EE/R, se puede escribir el
predicado o condición sobre la línea que une el triángulo con el subtipo al que pertenece, en este
caso es llamada especialización definida por el atributo. Si no se indica una condición, se trata de
una especialización definida por el usuario, ya que el usuario es responsable de colocar una
entidad en el subtipo correcto.
Es un Es un
0,1 1,M
2.5.2. Agregación
Una interrelación es una asociación entre conjuntos de entidades. Algunas veces se tiene que
modelar una interrelación entre una colección de entidades e interrelaciones. Suponiendo que existe
una entidad llamada Proyecto y que cada Proyecto se asigna a uno o más departamentos. La
interrelación Asignación de Proyectos captura esta información. Un departamento que tenga un

proyecto puede asignar empleados para monitorear las interrelaciones. Intuitivamente, la entidad
Monitor debería ser una interrelación que asocia Asignaciones de Proyectos con Empleados. Sin
embargo, se ha definido una interrelación para asociar dos o más entidades.
Para definir interrelaciones como la de Monitores, se introduce un nuevo tipo de interrelación llamado
agregación. Una Agregación permite indicar que una interrelación identificada como un rectángulo
con línea punteada, participa en otra interrelación. Esto se ilustra en la siguiente figura, dentro del
rectángulo punteado se indica la interrelación Asignado A y las entidades participantes. Esto permite
tratar la interrelación Asignado A como una entidad para propósitos de identificar la interrelación de
Monitoreo.
De modo intuitivo, la agregación se usa cuando se necesita expresar una interrelación entre
interrelaciones. Esta interrelación no se puede representar como interrelación ternaria porque
existen dos interrelaciones distintas Monitorea y Asigna A, y cada una tiene atributos. Por ejemplo la
interrelación Monitorea tiene el atributo hasta que almacena la fecha final en que un empleado
monitorea la asignación de un proyecto. Comparando este atributo con el atributo desde de la
interrelación Asigna A, que es la fecha cuando se asigna un proyecto. El uso de agregación contra la
interrelación ternaria puede guiarse por ciertas restricciones de integridad.
idEmpleado nombre puesto
Empleado
Monitorear hasta
desde
idProyecto idDepto
Proyecto Asignado a Depto
2.6. Metodología de Diseño con el Modelo

Entidad/Relación
Las siguientes líneas presentan un proceso de tres pasos muy sencillos para obtener un diagrama
entidad/relación.
2.6.1. Situaciones
Una situación es un conjunto bien definido de circunstancias que pueden describirse usando un
lenguaje natural suficientemente completo. Un lenguaje natural suficientemente completo incluye al
menos las siguientes estructuras gramaticales:

 Sustantivos. Un sustantivo es el nombre de un tipo de persona, animal, planta, cosa,
sustancia o idea. Un sustantivo propio es el nombre de una particular instancia o instancia de
un sustantivo. Un pronombre es una palabra usada para sustituir un sustantivo y que se
refiere a un sustantivo nombrado o comprendido en el contexto en el cual se usa. Los
sustantivos pueden representar objetos animados o inanimados y tales objetos pueden ser
tangibles o intangibles. Es imposible describir cualquier situación sin usar al menos un
sustantivo.
 Verbos. Un verbo es una palabra que describe un modo de ser, una asociación, una acción o
un evento. Los verbos describen el estado de sustantivos y relacionan los sustantivos de
situaciones con otros. Los verbos pueden ser activos o pasivos.
 Modificadores. Un modificador es una palabra que califica un sustantivo o un verbo
indicando sus características, cantidad, grado y extensión. Los modificadores de sustantivos
son llamados adjetivos y los modificadores de verbos son llamados adverbios.
Las situaciones que pueden ser descritas sin el uso de modificadores generalmente son muy triviales
para ser de interés.
Ejemplo:
Una compañía imaginaria emplea actualmente a Dorantes, Fernández, García, Nieto y Sebastián;
cada uno es identificado por un Número de Empleado único. Dorantes trabaja en Ventas, mientras
que Fernández y Sebastián trabajan en Nómina. Los otros no han sido asignados a un
departamento. Se han establecido otros tres departamentos: Investigación, Mercadotecnia y
Sistemas, pero estos no tienen empleados actualmente. Todos los departamentos se identifican con
dos caracteres de Código de Departamento. Dorantes es el que recibe el menor sueldo con un
salario de $120,000 al año, Nieto recibe dos veces esa cantidad y Sebastián también recibe
$240,000; García, el director, recibe $120,000 más que el anterior.
2.6.2. Pasos
 Paso 1 – Modelar Entidades. Las entidades son sustantivos de una situación. Como se
indicará pueden ser mayores o menores en tamaño e importancia y pueden ser subtipos o
dependientes de otras entidades.
 Paso 2 - Modelar Interrelaciones. Las interrelaciones son los verbos de una situación.
Pueden ser de tres tipos: uno a uno, uno a muchos y muchos a muchos. Casos especiales de
interrelaciones peden ser las recursivas, agregaciones o pueden variar en el tiempo.
 Paso 3 – Modelar Atributos. Los atributos son modificadores de situaciones. Los atributos
pueden ser reales o derivados, y pueden aplicar a sus entidades (como adjetivos) o a
interrelaciones (como adverbios).
2.6.3. Paso 1- Modelar Entidades
Una entidad es una persona, animal, planta, lugar, cosa, sustancia o idea que puede ser identificada
por un tipo e instancia. El primer paso para obtener un MER es el modelado de entidades que
consiste en cuatro pasos:
 Descubrir una entidad. Antes de modelar una entidad hay que encontrarla.
 Definir el alcance de la entidad. Habiendo encontrado una entidad, se debe establecer qué
nivel de detalle es de interés.
 Determinar la llave primaria de la entidad. Después, se debe localizar un identificador
apropiado para cada instancia de la entidad.
 Documentar la entidad en forma de rectángulo. Lo siguiente es modelar la entidad en el
diagrama como un rectángulo.
Las entidades pueden ser de dos tipos:
2.1.1.28. Entidades Mayores

Las entidades mayores son grandes, importantes, entidades dinámicas de una situación. El número
de instancias es grande y las inserciones y eliminaciones son constantes.
Las instancias de entidades mayores generalmente, pero no siempre, son identificadas por un
número asignado por sistema, ya que las llaves asignadas por usuarios pueden ser difíciles de
manejar e imposibles de memorizar.
2.1.1.29. Entidades Menores

Las entidades menores, por otro lado, son pequeñas entidades estáticas. El número de instancias
es generalmente menor a 100 y las inserciones y eliminaciones son pocas.
Las entidades menores generalmente se identifican con códigos generados por el usuario por
conveniencia. Tales códigos son fáciles de recordar y significativas cuando se despliegan.
A excepción de la clave, no existen diferencias reales entre las entidades mayores y menores,
ambas se modelan igual.
2.1.1.30. Descubrir una entidad

Este es el primer paso y la parte más critica del desarrollo del modelo. Si esto se hace
correctamente, proporcionará un principio sólido sobre el cual puede crearse el resto del modelo.
Para hacerlo:
 Preguntar. La mejor forma y más simple de encontrar una entidad es preguntar por ella. Por
ejemplo: ¿Cuales son los nombres de las personas, lugares o cosas de las que se desea
mantener información?”.
 Concentrarse en sustantivos. El usuario generalmente responde a la pregunta anterior con
varios nombres de entidades. Esto es normal, pero es mejor concentrarse en el primero que
indique el usuario. Es importante recordar que las entidades pueden ser animadas o
inanimadas, tangibles o intangibles. Algunas veces, las entidades son obvias, objetos físicos
y otras son sólo conceptos o ideas.
 Tener cuidado con los atributos. Todas las entidades son sustantivos, pero no todos los
sustantivos son entidades. Muchos sustantivos son atributos, características, cualidades o
propiedades de las entidades. Las entidades existen por si mismas, los atributos tiene
significado sólo en el contexto de las entidades que las describen. Las entidades se
caracterizan por sus atributos, los atributos no tienen características por sí mismos.
2.1.1.31. Definir el alcance de la entidad

Este paso se realiza por dos razones: verificar que corresponden a los propósitos del desarrollo para
el usuario y establecer el nivel de detalle que se incluirá en el modelo. En este caso:
 Verificar el interés del usuario. Es probable que los usuarios mencionen entidades que no
pertenecen realmente al alcance del modelo. Puede ser que se interesen por una cosa en
particular, pero no lo suficiente para mantener su información almacenada; o puede ser que
están suficientemente interesados, pero económicamente, por cuestiones de tiempo u otras

consideraciones requieren que la entidad en el modelo se posponga para después. En
cualquier caso, si la entidad se determina fuera del alcance del modelo, eliminarla y regresar
al paso anterior.
 Concentrarse en tipos, no en instancias. Es importante en esta etapa distinguir entre tipos
de entidades e instancias de esos tipos de entidades. En este punto del proceso, es
importante el tipo de entidades, no las instancias.
 Establecer el nivel apropiado de detalle. Algunas veces una entidad es una clase de cosa,
en vez de una cosa particular, individual por si misma. En este caso se puede renombrar la
entidad como Tipo de…, aunque esto no es esencial.
2.1.1.32. Determinar la llave primaria de la entidad

El nombre de la entidad distingue cada tipo de entidad del resto de tipos de entidades. Pero es la
llave primaria la que identifica cada instancia particular de un tipo específico de entidad. Para
localizar una llave primaria apropiada:
 Preguntar. La mejor forma y más simple de encontrar una llave primaria de una entidad es
preguntar por ella. Por ejemplo: “¿Cómo se puede distinguir una <nombreEntidad> de otra?”,
o “Cómo se identifica de forma única una <nombreEntidad>?”.
 Verificar valores nulos. Una vez que se encuentra una llave primaria potencial, se debe
verificar que nunca puede ser nula. Cada instancia de una entidad debe tener un valor de
llave primaria todo el tiempo.
 Verificar valores duplicados. Verificar que no pueda tener valores duplicados, siempre
deben ser únicos.
 Verificar valores modificables. Las llaves primarias no deben ser modificadas por ninguna
razón.
 Verificar si se pueden asignar por sistema. Si no se puede localizar una llave, se puede
sugerir una llave asignada por sistema con un nombre apropiado como <Numero de -nombre
de Entidad-> ó <código de -nombre de Entidad->.
2.1.1.33. Documentar la entidad

Dibujar la entidad como un rectángulo con el nombre de la entidad dentro de él. El nombre de la
entidad es el nombre del tipo de entidad. La llave primaria se agrega como una elipse con el nombre
de la llave primaria subrayado. Cada rectángulo representa un tipo de entidad, representando la
entidad como un todo. Al principio su representación sólo incluye la llave primaria
El proceso de modelar entidades debe seguirse para cada entidad en el modelo.
2.6.4. Paso 2- Modelar Interrelaciones

El segundo paso para obtener un MER también se practica en cuatro pasos:
 Descubrir una interrelación. Antes de modelar una interrelación hay que encontrarla.
 Definir el alcance de la interrelación. Habiendo encontrado una interrelación, se debe
establecer qué nivel de detalle es de interés.
 Determinar el tipo de interrelación. Se requiere conocer con qué tipo de interrelación se
está trabajando.
 Documentar la interrelación en forma de rombo. Y finalmente se puede dibujar la
interrelación en el modelo.

2.1.1.34. Descubrir una interrelación
Cuando se realizó el primer paso de descubrir entidades, el proceso fue dirigido por el usuario, en
este puno, sin embargo, el modelo como ha sido diseñado hasta el momento toma el control.
 Preguntar. La mejor forma y más simple de encontrar una interrelación es preguntar por ella.
Tomar a la vez, dos de las entidades que se han definido previamente y preguntar,
remplazando <nombre de Entidad A> y <nombre de Entidad B> con el nombre apropiado de
las entidades: ¿Existe una interrelación entre <nombre de Entidad A> y <nombre de Entidad
B>?”. La respuesta puede ser Si o No. Si es Si, continuar, si es No, tomar otro par de
entidades y seguir el proceso.
 Considerar solo una interrelación. No considerar más de una interrelación a la vez, o sólo
habrá confusión. Si una interrelación existe, continuar con ella hasta modelarla.
 Proceder en cierto orden. Puede ayudar si las entidades se organizan alfabéticamente y se
pregunta en un orden de A contra B, C y D, luego B contra C y D y finalmente entre C y D.
2.1.1.35. Definir el alcance de la interrelación

Hay tres cosas que determinan si una interrelación se encuentra en el alcance de un modelo: el
interés del usuario, qué tan directa es la asociación y el tiempo.
 Verificar el interés del usuario. Pueden existir interrelaciones que no se usan o no son de
interés del usuario del sistema. Tales interrelaciones peden ser obvias, razonables y simples
de representar pero no deben incluirse en el modelo.
 Concentrarse en interrelaciones directas. Un problema es determinar si una interrelación
es directa o indirecta (implicada en otra interrelación). Sólo las interrelaciones directas deben
modelarse y las indirectas pueden derivarse de las otras.
 Establecer el nivel apropiado de detalle. Las interrelaciones pueden cambiar con el tiempo,
por lo que es importante descubrir si los usuarios están interesados sólo en el estado actual
de una interrelación o en el pasado, presente y posibles estados futuros de la interrelación.
Las interrelaciones en el tiempo se verán más adelante.
2.1.1.36. Determinar el tipo de la interrelación

Determinar el tipo de la interrelación es una cuestión sencilla, pero debe hacerse con consistencia y
disciplina del siguiente modo:
 Hacer dos preguntas. Se deben hacer dos preguntas y responderlas antes de que se pueda
conocer el tipo de una interrelación con concierto grado de certeza: “¿Puede una <nombre de
Entidad A> interrelacionarse con más de una <nombre de Entidad B>?” y “¿Puede una
<nombre de Entidad B> interrelacionarse con más de una <nombre de Entidad B>?”. Los
términos <nombre de Entidad A> y <nombre de Entidad B> son, por supuesto, remplazados
con nombres de entidades apropiados. Las palabras “interrelacionarse con” pueden
sustituirse con un verbo apropiado a la frase, por ejemplo ¿Puede un empleado trabajar en
más de un departamento? Nótese que la conjugación del verbo no es siempre una cuestión
trivial.
 Obtener dos respuestas. Cada una de las preguntas anteriores, pueden tener respuestas
ciertas o falsas, el tipo de interrelación se determina como:
o Dos respuestas NO indican una interrelación Uno-A-Uno.
o Una respuesta Si y otra No indican una interrelación Uno-A-Muchos.
o Dos respuestas Si indican una interrelación Muchos-A-Muchos.

 Preguntar por la cardinalidad mínima. Preguntar si Todas las instancias deben participar
en la interrelación o si pueden haber algunas que no participen, en caso afirmativo a la primer
pregunta, la cardinalidad mínima será uno, en caso contrario, será cero.
2.1.1.37. Documentar la interrelación

Una vez que se conoce el tipo de interrelación, se puede modelar.
 Modelar la interrelación. Se agrega un rombo con el verbo o nombre de cada interrelación.

 Modelar una interrelación uno a uno. Se modela con una línea recta que una a la entidad A
y otra que una a la entidad B.
 Modelar una interrelación uno a muchos. Se modela con una línea recta del lado de la
entidad con interrelación uno y con una línea con terminación de pata de gallo uniendo la
entidad con interrelación muchos (la que se respondió con SI).
 Modelar una interrelación muchos a muchos. Se modela con líneas con terminaciones de
pata de gallo uniendo ambas entidades.
 Agregar la cardinalidad mínima. Una vez que se ha documentado la cardinalidad máxima
con la definición uno o muchos, se debe agregar la cardinalidad mínima poniendo un cero en
caso de interrelaciones parciales y un uno en caso de interrelaciones totales.
El proceso de modelar interrelaciones debe seguirse para cada interrelación en el modelo.
2.6.5. Paso 3- Modelar Atributos

El tercer y último paso para obtener un MER se lleva a cabo en cuatro pasos:
 Descubrir un atributo. Antes de modelar un atributo, hay que encontrarlo.

 Definir el alcance del atributo. Habiendo encontrado un atributo, se debe establecer qué
nivel de detalle es de interés.
 Determinar la llave del atributo. En seguida, se localiza una entidad apropiada para colocar
el atributo.
 Documentar el atributo en forma de elipse. Y finalmente se puede dibujar el atributo en el
modelo.
2.1.1.38. Atributos reales de entidades

Casi todas las entidades tienen al menos un atributo real, una característica o cualidad cuyo valor
debe proporcionar el usuario. Es concebible, sin embargo, que un usuario pueda estar interesado en
una identidad de una entidad y sus interrelaciones sin estar interesado en ninguno de sus atributos.
2.1.1.39. Atributos reales de interrelaciones

Muchas, pero no todas las interrelaciones también tienen atributos descriptivos. Esto es porque es
importante modelar todas las interrelaciones antes de cualquier atributo: de otra forma, se puede
descubrir un atributo y no tener un lugar para colocarlo.
2.1.1.40. Datos derivados

Los datos derivados pueden ser calculados a partir de valores en otro lugar del modelo.
Normalmente se incluyen en el modelo sólo cuando las consideraciones de desempeño dictan que
es necesario.

2.1.1.41. Descubrir un atributo
Descubrir un atributo no es un proceso difícil. Para ello:
 Preguntar. La mejor forma y más simple de encontrar un atributo es preguntar por uno.
Simplemente hay que tomar cada entidad e interrelación que ha sido definida previamente, y
preguntar lo siguiente, sustituyendo <nombre de Entidad> con el nombre de la entidad o
interrelación. “¿Qué otras características de <nombre de Entidad> son de interés?”. La
respuesta será el nombre de un atributo potencial. Si no se pueden encontrar más atributos,
proceder con la siguiente entidad o interrelación
 Considerar sólo un atributo. No considerar más de un atributo a la vez, o sólo habrá
confusión. Si un atributo existe, continuar con el hasta modelarlo.
 Proceder en cierto orden. Se debe evitar brincar por todo el modelo. Organizar las
entidades alfabéticamente y preguntar por cada una en orden. Puede no seguirse esta
secuencia de modo estricto, pero un esfuerzo ayudará a no perder alguno de los atributos de
la situación.
2.1.1.42. Definir el alcance del atributo

Hay dos razones para realizar este paso: verificar que no nos hemos alejado del propósito del
usuario en el desarrollo del modelo, y establecer el nivel de detalle que se debe incluir en el modelo.
 Verificar el interés del usuario. Probablemente existen atributos que no se usan o no son
de interés para el usuario del sistema. Tales atributos pueden ser obvios, razonables y
simples de representar, pero no deben incluirse en el modelo.
 Concentrarse en atributos reales. Cada vez que encontramos un atributo, se debe estar
seguro que los valores deseados no existen ya en el modelo (probablemente en diferente
forma). Recordar que los atributos derivados sólo se incluyen en un modelo como una
solución para mejorar el desempeño. Esto también significa que cada vez que se agrega un
atributo, se debe verificar para estar seguros que el agregarlo no causa que otro atributo que
antes era real, se convierta en derivado.
 Establecer el nivel apropiado de detalle. Los atributos normalmente cambian con el tiempo,
por lo que es importante descubrir si los usuarios están interesados sólo en el estado actual
del atributo o en el pasado, presente y posibles valores futuros de un atributo. Los atributos
en el tiempo se verán más adelante.
2.1.1.43. Determinar la llave del atributo

Existen dos métodos para determinar dónde colocar un atributo en el modelo. Cada uno se muestra
a continuación.
 Método de frase preposicional. El primer método para determinar la llave de un atributo es

el Método de Frase Preposicional basado en principios comunes de la gramática, es un
método relativamente fácil de aprender y aplicar. Este método es un método importante, no
sólo porque es simple y eficiente, sino porque muestra la interrelación entre la gramática y el
diseño del modelo de datos.
Las preposiciones son palabras como a, ante, bajo, etc. que junto con los artículos y/o
adjetivos y un sujeto forman frases preposicionales. Estas frases generalmente indican
localización, duración o posesión, por ejemplo, sobre la mesa, para el día, en la caja, del
cliente.

El punto importante aquí es que las frases preposicionales acompañando la descripción del
usuario de un atributo siempre describen la llave de ese atributo. En otras palabras, cuando el
usuario habla de un atributo, también describe, tal vez inconcientemente, la llave del atributo
con la frase preposicional que usa. Esas frases pueden aparecer en tres formas distintas:
o Freses Preposicionales Explícitas. Estas frases se expresan por el usuario. Un

usuario por ejemplo puede decir que está interesado en “el nombre de cada
departamento” o en “el salario de cada empleado”.
o Frases Preposicionales Implícitas. Estas no son expresadas por el usuario, pero se
comprenden del contexto, generalmente de una frase dicha previamente de la
variedad explícita. Por ejemplo, después de decir que está interesado en “el nombre
de cada empleado”, un usuario puede agregar “…y el número telefónico”, donde la
frase “de cada empleado” es implícita.
o Posesivos. Los posesivos nos indican a quién pertenece un objeto, por lo que nos
permiten saber a qué entidad pertenece el atributo, “su número de cuenta”, podría
corresponder al cliente.
 Aproximación intuitiva. El otro método, Aproximación intuitiva, también es importante
porque convierte el método en un proceso de verificación. Este método por definición, no
requiere de explicación, como lo indica en el nombre, es intuitivo. Y así es exactamente como
funciona, la llave de un atributo dado debe ser obvia.
Es este hecho el que hace al método en proceso de verificación. Si se encuentra un atributo y

no se sabe inmediatamente a dónde pertenece, entonces o está mal definido, o es una pieza
de un dato derivado, o porque se omitió algo en los pasos 1 y 2. En tales casos es mejor
generalmente borrar el atributo y regresar al escenario donde se pudo cometer el error, hacer
las correcciones necesarias y reaplicar esta aproximación.
2.1.1.44. Documentar el atributo

Todo lo que se requiere es agregar el atributo dentro de una elipse a una entidad o interrelación
existente.
El modelo está completo cuando el usuario no puede pensar en algo más que quisiera en el modelo,
y no hay información que sea derivada del modelo que no se pueda obtener.
2.6.6. Modelar Generalización / Especialización (Subtipos)

Una vez que se han definido las entidades, interrelaciones y atributos, se puede analizar el modelo
para buscar situaciones especiales como los subtipos y agregaciones.
Un subtipo de una entidad es una colección de ocurrencias de un tipo de entidad que participa en
interrelaciones o posee atributos que son comunes al tipo de entidad como un todo. La entidad como
un todo es llamada supertipo en este contexto.
Por ejemplo, en un modelo de empleados, todos los empleados tienen nombre, pero sólo los
empleados asalariados tienen departamento y salario. El pago por hora sólo aplica al personal no
asalariado. Si se modela sólo la entidad empleado con todos los atributos, existirán muchos valores
nulos en el código de departamento y el pago por hora, además no habrá una distinción clara entre
los tipos de empleados. La clasificación de Empleados asalariados y Empleados por Hora como
subtipos de Empleado sin embargo, resulta en un modelo diferente. En este caso, todos los

empleados aparecen en la entidad Empleado, pero sólo algunos de ellos aparecen en cada subtipo,
ya que sólo pueden ser de un tipo, pero no de ambos, estos subtipos son mutuamente excluyentes.
Otra situación, describe Clientes y Empleados, donde un empleado puede ser cliente y empleado a
la vez, si sólo se modelan las dos entidades separadas, se tendrán duplicados los datos de la
persona que es cliente y empleado en ambas entidades, con dos llaves primarias diferentes también.
Cuando un objeto puede ser de dos tipos al mismo tiempo, se pueden considerar las dos entidades
como subtipos de una tercera, en este caso Empleado o Cliente serían subtipos de una gran entidad
Persona. De este modo, los datos comunes se pueden almacenar en la entidad supertipo Persona,
evitando redundancia y mejorando la consistencia. La entidad Persona también podría modelar
personas que no son ni empleados, ni clientes, podrían ser posibles clientes o proveedores. Ya que
un individuo puede ser tanto cliente como empleado, estos subtipos son traslapados.
2.1.1.45. Paso 1 - Modelar Subtipos

 Descubrir una entidad. Aquí se extiende la definición de la palabra entidad para también
incluir subtipos de entidades. Los subtipos de entidades son sustantivos y por tanto se
descubren durante el primer paso del proceso. El supertipo, debe modelarse antes de los
subtipos, en caso de que el usuario nombre primero a los subtipos, se debe modelar tan
pronto como sea posible el supertipo y ajustar las llaves primarias de los subtipos definidos
previamente de forma apropiada.
 Definir el alcance de la entidad. Se aplican las mismas consideraciones que con entidades
simples.
 Determinar la llave primaria. La llave primaria de un subtipo es siempre la llave primaria del
supertipo.
 Documentar la entidad. Los subtipos se modelan igual que cualquier entidad.
2.1.1.46. Paso 2 - Modelar Interrelaciones

 Puede haber interrelaciones en una situación que involucren un subtipo específico de una
entidad pero no involucren la entidad como un todo.
 El modelado se realiza igual que en los casos anteriores. Generalmente el usuario hace
obligatoria la interrelación indicando que sólo una parte de la entidad se interrelaciona con
otra. Por ejemplo: los departamentos se interrelaciones con los empleados, pero sólo con los
empleados asalariados.
 Después de indicar la interrelación con el triángulo correspondiente, se debe definir la
cardinalidad para indicar si los subtipos son mutuamente excluyentes o traslapados y en caso
de que sea una especialización definida por atributo, agregar la condición para identificar el
subtipo correspondiente.
2.1.1.47. Paso 3 - Modelar Atributos

 Los atributos de los subtipos se descubren y modelan igual que los atributos de otras
entidades e interrelaciones.
 Los subtipos comparten o heredan todas las propiedades del supertipo de cual son parte.
Pero los subtipos generalmente tienen uno o más atributos diferentes por sí mismos, lo
cuales se modelan de la misma forma.
2.6.7. Modelar Entidades Débiles

Las entidades dependientes son sustantivos que pueden tener atributos propios pero que existen
sólo como parte de, o subordinadas a otra entidad. La entidad, en este contexto se llama padre de la
entidad débil o fuerte.
Un ejemplo puede ser el modelo de la entidad Edificio que está compuesto por Pisos, cada piso será
una entidad débil de Edificio; por su parte, cada Piso está compuesto por Cuartos, donde cada
Cuarto será una entidad débil de Piso. La llave primaria de Edificio se pasa como parte de la llave
primaria de Piso, la cual será el edificio y piso, y por último la llave primaria de Cuarto será la llave
primaria de Edificio, más el número de Piso, más el número de Cuarto.
Las entidades débiles son un tipo especial de entidad que generalmente no tienen llaves primarias
simples. La entidad fuerte se modela primero y después las dependientes.
Las entidades débiles siempre cumplen las siguientes reglas:
 Las entidades dependientes siempre tienen un padre. Siempre se necesita hacer

referencia al padre para poder hablar de la entidad dependiente, por ejemplo, para hablar de
un piso, se debe indicar de qué edificio es.
 Las entidades dependientes siempre tienen un solo padre. Si la entidad débil se asocia
con más de un padre, entonces no es dependiente, sino una interrelación con los padres
mencionados. Un piso existe sólo en un Edificio no en dos o tres al mismo tiempo.
 Las entidades dependientes siempre tienen el mismo padre. Las entidades deben
mantener el mismo padre durante toda su existencia. Un piso no puede cambiarse a otro
edificio.
2.1.1.48. Paso 1 - Modelar Entidades dependientes

 Descubrir una entidad. Aquí se extiende la definición de la palabra entidad para también
incluir entidades débiles. Las entidades débiles son sustantivos y por tanto se descubren
durante el primer paso del proceso. El padre, debe modelarse antes de las entidades débiles,
en caso de que el usuario nombre primero a las entidades débiles, se debe modelar tan
pronto como sea posible el padre y ajustar las llaves primarias de las entidades débiles
definidas previamente de forma apropiada.
 Definir el alcance de la entidad. Se aplican las mismas consideraciones que con entidades
simples, pero debe cuidarse que una entidad débil puede aparecer como entidad fuerte en
ciertas circunstancias, por ejemplo, si se desean modelar los cuartos de un único piso, los
cuartos no serán entidades débiles.
 Determinar la llave primaria. La llave primaria de una entidad débil siempre es la llave
primaria del padre más un atributo adicional. Este atributo adicional (discriminador) puede ser
presentado como el único atributo de la llave primaria si la entidad débil se modela antes que
la entidad padre, esto es un error. Se debe observar que las llaves primarias son únicas sólo
con algo más, por ejemplo el número de piso de un edificio, no es único por si mismo.
 Documentar la entidad. Las entidades débiles se modelan con un rectángulo de doble línea.
2.1.1.49. Paso 2 - Modelar Interrelaciones

 El modelado se realiza igual que en los casos anteriores y el diamante se puede dibujar
también con doble línea.

 Las entidades dependientes, como parte de una entidad padre, comparten los atributos de
ese padre. Pero las entidades débiles pueden tener uno o más atributos diferentes por sí
mismos que se modelan de la misma forma.
2.6.8. Modelar Interrelaciones Recursivas
Una interrelación recursiva es una interrelación entre ocurrencias de un tipo de entidad particular y
otras ocurrencias de ese mismo tipo de entidad. La palabra entidad se extiende para incluir subtipos
y entidades dependientes también.
Las interrelaciones recursivas son un tipo de interrelación especial y pueden ser de uno a uno, uno a
muchos o muchos a muchos. Este tipo de interrelación no ocurre muy frecuentemente, pero esto no
quiere decir que no sea importante, de hecho, este tipo de interrelación es una herramienta
excepcionalmente poderosa y generalmente se propone como una alternativa flexible a las entidades
débiles (dependientes).
2.1.1.51. Paso 1 - Modelar Entidades

 Las interrelaciones recursivas afectan este paso sólo cuando se consideran como una
alternativa para las entidades débiles. Si el número de niveles dependientes se conoce, es fijo
y el mismo para cada ocurrencia en la estructura, la entidad débil es probablemente una
mejor opción. Si por el contrario, el número de niveles no se conoce, o varía, o difiere
dependiendo de las instancias, definir la entidad en términos más generales preparándola
para una interrelación recursiva.
2.1.1.52. Paso 2 - Modelar Interrelaciones Recursivas

 Descubrir una interrelación. Las interrelaciones recursivas se descubren normalmente
durante el paso 2. Las posibles combinaciones de dos entidades ahora incluyen la misma
entidad.
 Definir el alcance de la interrelación. Se realiza de la misma forma.
 Determinar el tipo de la interrelación. Se realiza de la misma forma, pero nótese que las
preguntas son más fáciles de hacer y entender si se asigna un alias a la entidad antes de
empezar.
 Documentar la interrelación. La interrelación se hace uniendo la entidad consigo misma el
verbo describe la interrelación.

 No hay cambios. Los atributos se modelan usando los mismos métodos discutidos
previamente, en este caso los atributos se dibujan para el diamante.
2.6.9. Modelar Interrelaciones Complejas (Agregaciones)

Las interrelaciones complejas son interrelaciones entre más de dos entidades, incluyendo entidades
débiles y subtipos; y son vistas como una extensión de las interrelaciones básicas descritas
previamente.

2.1.1.54. Paso 1 - Modelar Entidades
 Las interrelaciones complejas no afectan el modelado de entidades.
2.1.1.55. Paso 2 - Modelar Agregaciones

 Descubrir una interrelación. Preguntar, no sólo por posibles interrelaciones entre cada
entidad y las otras, sino entre cada entidad y cualquier interrelación muchos a muchos que
haya sido definida previamente.
 Definir el alcance de la interrelación. No hay cambios.
 Determinar el tipo de interrelación. Tampoco aquí ha cambios. Los pasos usuales se
emplean para determinar si la interrelación es uno a uno, uno a muchos o muchos a muchos.
 Documentar la interrelación. Se agrupan las entidades con interrelación muchos a muchos
en un rectángulo punteado y se unen a la entidad con la que se interrelacionan.

 No hay cambios. Los atributos se modelan usando los mismos métodos discutidos
previamente.
2.6.10. Modelar Interrelaciones De Tiempo
Una interrelación de tiempo es una interrelación entre una entidad, un subtipo, entidad débil o
interrelación y el tiempo. Las interrelaciones de tiempo siempre son interrelaciones muchos a
muchos, por lo que no es necesario determinar el tipo de interrelación.
Modelar datos en tiempo presente es significativamente más fácil que modelar datos a través del
tiempo, de modo que, mientras los modelos de datos pueden representar no sólo estados actuales,
sino pasados y futuros, tales modelos deben desarrollarse con gran cuidado.
Una forma de representar el tiempo es como una interrelación compleja entre años, meses, días,
horas, minutos y segundo, sin embargo, esta forma no es muy práctica.
En vez de eso, se considera que cada modelo incluye, por omisión, una entidad virtual llamada
Tiempo. La entidad Tiempo contiene un solo renglón para cada punto del tiempo que puede ser de
interés para el usuario de un modelo.
Nótese que la palabra virtual sugiere que la entidad Tiempo no se implementa físicamente, pero
existe como un objeto conceptual en cualquier modelo. La mayoría de las interrelaciones de las
bases de datos proporcionan facilidades especiales para definir, editar y manipular datos de tiempo,
y es por tanto innecesario definir una entidad adicional.
Sin embargo, es importante notar que todas las entidades e interrelaciones se interrelacionan a esta
entidad virtual Tiempo, y que estas interrelaciones son siempre de la variedad muchos a muchos.
El grado de precisión del punto del Tiempo puede variar; en ocasiones puede ser suficiente
especificar el año, mes y día, en otras se requerirá indicar las horas, minutos y segundos.
Las situaciones históricas requerirán pues incluir un atributo de tipo Tiempo en su llave primaria. Por
ejemplo, los empleados se asignan a un departamento a la vez, pero si se desea mantener un
registro de las asignaciones a departamentos anteriores y también se desea insertar futuras
transferencias en el modelo, se agregará una entidad que tenga como llave primaria la clave del

empleado y la fecha del movimiento, agregando un atributo que indique el departamento al que es
asignado el empleado en esa fecha.
2.7. Modelo de Clases de UML

Los diagramas ER y EER no son muy eficientes para representar objetos, ya que no permiten
representar los métodos. Una técnica de diagramación altamente usada llamada diagrama de clases
UML (Unified Modeling Language) permite expresar conceptos orientados a objetos de modo más
natural que las técnicas anteriores.
El modelo de clases de UML muestra un conjunto de clases, interfaces y colaboraciones, así como
sus interrelaciones. Estos diagramas son los diagramas más comunes en el modelado de sistemas
OO. Los diagramas de clases cubren la vista de diseño estática de un sistema. Los diagramas de
clases que incluyen clases activas cubren la vista de procesos estática de un sistema.
Conforme más y más clases se agregan a un modelo, una representación textual de las clases no es
suficiente. Los diagramas de clases se crean para proporcionar un vista de algunas o todas las
clases en el modelo.
Una clase captura una y sólo una abstracción, debe tener sólo un tema principal. Si una clase tiene
más de un tema, se debe dividir en tantas clases relacionadas como temas sean identificados en
ellas.
Las clases se nombran usando el vocabulario del dominio, el nombre debe ser un sustantivo en
singular que caracterice mejor la abstracción. Se pueden usar acrónimos si el acrónimo tiene el
mismo significado para todos los involucrados, pero si un acrónimo tiene diferentes significados para
algunos, entonces se debe usar el nombre completo. Si la clase se nombra con un acrónimo, el
nombre completo debe indicarse en la documentación de la clase. Si existen problemas para
nombrar o documentar una clase, puede ser porque no es una buena abstracción. La siguiente lista
tipifica las cosas que pueden ocurrir cuando se nombran o documentan las clases:
 Se puede identificar el nombre y una clara definición de ella, es una buena clase candidata.
 Se puede identificar un nombre, pero la definición es la misma que otra clase, combinar las
clases.
 Se puede identificar un nombre, pero se necesita un libro para documentar el propósito,
dividir la clase.
 No se puede identificar un nombre o una definición, se requiere más análisis para determinar
la abstracción correcta.
En ocasiones es difícil distinguir entre objeto y clase, pero observando si la estructura y

comportamiento de varios objetos es la misma, entonces pertenecen a una misma clase.
En UML las clases se representan como rectángulos con tres secciones. La sección superior
contiene el nombre de la clase, la sección siguiente contiene la estructura de la clase (atributos) y la
tercera sección contiene el comportamiento de la clase (operaciones).
En UML se distingue entre asociaciones, que son interrelaciones unidireccionales o bidireccionales

entre clases, y agregaciones, que son tipos de interrelaciones que conectan un todo a sus partas.
Las asociaciones, o conexiones binarias entre clases se representan por líneas conectando los
rectángulos. El nombre de las asociaciones puede aparecer opcionalmente sobre las líneas.
Cualquier atributo descriptivo de la interrelación se muestra en una caja conectada a la línea de

asociación con una línea punteada. El rol puede aparecer sobre las líneas de asociación, si se
necesita aclarar. La agregación es un tipo especial interrelación que conecta un todo a sus partes.
Si la frase describe la interrelación de una clase a otra indica que “es parte de” la otra y la clase es
claramente subordinada a la otra, entonces la agregación es la mejor representación de la
interrelación. La agregación se representa por una línea con un diamante en el lado de la clase que
es el agregado (padre). Si la agregación no tiene nombre, la línea de la agregación se interpreta
como “tiene”. Las restricciones de participación y cardinalidad para ambos tipos de interrelaciones se
especifican usando una variación de (min, max) del modo min..max sin paréntesis y se llaman
indicadores de multiplicidad en UML. El * indica muchos, y 1 significa uno. Las interrelaciones
recursivas entre miembros de la misma clase, llamadas asociaciones reflexivas o agregaciones
reflexivas, se muestran con líneas que asocian una clase consigo misma. Las jerarquías de
generalización se representan por líneas conectando las subclases a la superclase, con un triángulo
apuntando a la superclase. Un triángulo lleno representa subclases traslapadas, mientras que los
triángulos vacíos representan subclases excluyentes. Las restricciones de especialización pueden
escribirse sobre la línea cerca del triángulo, encerradas entre llaves. Las entidades débiles pueden
representarse con cajas unidas a la clase padre, con el discriminador apareciendo en una caja
pegada a la clase padre.
2.7.1. Estereotipos
Mediante “mecanismos de extensibilidad” se pueden crear estereotipos que permiten crear una
nueva clase de elementos en el modelo. Algunos estereotipos de clases son entidad, frontera,
control, utilidad y excepción. El estereotipo de una clase se muestra bajo del nombre de la clase
encerrado entre paréntesis angulares (<< >>). Se puede asociar un icono gráfico o un color
específico a un estereotipo.
No existe una receta para encontrar clases, pero el Proceso Unificado de Desarrollo recomienda
localizar clases para un sistema buscan clases de frontera, control y entidad. Estos tres estereotipos
conforman el punto de vista del “Modelo Vista-Controlador” y permite al analista dividir el sistema
separando la vista del dominio de control necesario para el sistema.
2.7.2. Clases Entidad

Una clase entidad modela información y asocia comportamiento que generalmente es persistente.
Este tipo de clase puede reflejar una entidad del mundo real o puede ser necesaria para realizar
tareas internas del sistema (información temporal). Generalmente son independientes de su entorno;
esto es, no son sensibles a cómo el entorno se comunica con el sistema. Muchas veces, son
independientes de la aplicación, lo que quiere decir que pueden ser usadas en más de una
aplicación.
El primer paso es examinar las responsabilidades documentadas en el flujo de eventos para los
casos de uso identificados (qué debe hacer el sistema). Las clases entidad generalmente son clases
que se requieren por el sistema para cumplir alguna responsabilidad. Los sustantivos y frases
sustantivos usados para describir la responsabilidad pueden ser un buen principio. La lista inicial de
sustantivos debe filtrarse ya que puede contener sustantivos que están fuera del dominio del
problema, sustantivos que sólo son expresiones del lenguaje, sustantivos que son redundantes y
sustantivos que son descripciones de estructuras de clases.
Las clases entidad generalmente se localizan en la Fase de Elaboración del Proceso Unificado de
Desarrollo. Estas son llamadas clases de “dominio” ya que generalmente son entidades abstractas
del mundo real.

2.7.3. Clases Frontera
Las clases frontera manejan la comunicación entre el contexto del sistema y el interior del sistema.
Estas pueden proporcionar la interfaz al usuario o a otro sistema (interfaz del actor). Constituyen la
parte dependiente del contexto del sistema. Las clases frontera se usan para modelar las interfaces
del sistema.
Cada par escenario/actor físico se examina para descubrir las clases frontera. Las clases frontera
seleccionadas en la Fase de Elaboración del desarrollo son generalmente de alto nivel. Por ejemplo,
se puede modelar una ventana pero no cada uno de las cajas de diálogo y botones. En este punto,
se documentan los requerimientos de la interfaz de usuario, no su implementación.
Los requerimientos de la interfaz tienden a ser muy vagos, los términos “user-friendly” y flexible son
muy empleados, pero significan diferente cosas para diferentes personas. Aquí es donde los
prototipos y las técnicas de storyboard pueden ser útiles. El desarrollador puede obtener el “look and
feel” que se desea del sistema y captar lo que significa amigable. Lo cual es entonces capturado
como la estructura y comportamiento de las clases frontera. Durante el diseño, estas clases se
refinan para tomar en consideración y elegir cómo se implementan los mecanismos de la interfaz de
usuario.
Las clases frontera se agregan, para facilitar la comunicación con otros sistemas. Durante el diseño,
estas clases se refinan para tomar en cuenta los protocolos de comunicación.
2.7.4. Clases Control

Las clases de control modelan la secuencia de comportamiento específico de uno o más casos de
uso. Las clases de control coordinan los eventos necesarios para realizar el comportamiento
específico de los casos de uso. Se puede pensar en las clases de control como “ejecutando” o
“corriendo” el caso de uso, estas representan la dinámica del caso de uso. Las clases de control se
agregan para cada par actor/caso de uso. La clase de control es responsable del flujo de eventos en
el caso de uso.
El uso de clases de control es muy subjetivo. Muchos autores sienten que tener clases de control
genera comportamiento separado de los datos. Esto puede suceder si la clase de control no se
selecciona cuidadosamente. Si una clase de control realiza más de una secuencia, entonces está
haciendo demasiado. La clase de control sabe cuándo se realiza una acción, mientras que las
otras clases saben cómo realizar la acción. Una clase de control errónea podría saber cuándo y
cómo realizar las acciones.
Agregar una clase de control por pareja de actor/caso de uso es sólo un principio, con forme el
análisis y diseño continúan, las clases de control pueden ser eliminadas, divididas o combinadas.
2.7.5. Métodos
Una clase encierra un conjunto de responsabilidades que definen el comportamiento de los objetos
de esa clase. Las responsabilidades se llevan a cabo por las operaciones definidas para la clase y
son llamadas métodos. Una operación debe realizar sólo una cosa y debe hacerla bien. Todas las
instancias de una clase serán capaces de ejecutar la operación identificadas de la clase.
Los mensajes en los diagramas de interacción generalmente se refieren a operaciones de la clase

que recibe el mensaje. Sin embargo, existen algunos casos especiales donde los mensajes no

generan una operación. Si la clase receptora es una clase frontera que contiene la interfaz gráfica de
usuario, el mensaje es una instrucción de los requerimientos de la GUI. Este tipo de mensajes
generalmente son implementados como algún tipo de control de la GUI, por ejemplo un botón, y no
son relacionados a operaciones ya que el comportamiento es llevado a cabo por el control de la GUI.
Los mensajes que envían y reciben los actores también reciben una consideración especial. Si el
mensaje es de o para un actor que representa una persona física, el mensaje es una instrucción de
un proceso humano y por lo tanto se incorpora en el manual de usuario, pero no como una
operación, ya que no tiene sentido crear operaciones para los humanos. Si el mensaje es de o para
un actor que representa un sistema externo, se crea una clase para manejar el protocolo que se use
para ejecutar la comunicación con el sistema externo. En este caso, el mensaje no se relaciona a
una operación de la clase.
Las operaciones deben ser nombradas en términos de la clase que ejecuta la operación, no de la
clase que solicita la funcionalidad a ser ejecutada. Adicionalmente, los nombres de las operaciones
no deben reflejar la implementación de la operación, ya que la implementación puede cambiar con el
tiempo.
Interrelaciones y sintaxis de métodos. La sintaxis de un método puede indicar una interrelación. Si

la clase para un argumento de un método o el retorno de un método es una clase fundamental como
String, la interrelación generalmente no se muestra en un diagrama. Para otras clases (no
fundamentales) la interrelación generalmente se despliega en uno o más diagramas de clases. Las
interrelaciones basadas en sintaxis de métodos inicialmente se modelan como asociaciones que
pueden ser refinadas en interrelaciones de dependencia con forme el diseño del sistema madura.
Las interrelaciones entre paquetes deben también reflejar las interrelaciones basadas en la sintaxis
de los métodos.
2.7.6. Atributos
La estructura de un objeto se describe por los atributos de la clase. Cada atributo es la definición de
un dato perteneciente a un objeto de la clase. Los objetos definidos a partir de la clase tienen un
valor para cada atributo de la clase. Los valores de los atributos no tienen que ser únicos para todos
los objetos.
Muchos de los atributos de una clase se encuentran en la declaración del problema, el conjunto de
requerimientos del sistema y la documentación del flujo de eventos. También pueden ser
descubiertos cuando se genera la definición de una clase. Finalmente, el experto del dominio
también es una fuente de atributos para la clase.
Los nombres de las clases inician con mayúsculas y los de los atributos y objetos se escriben de
manera estándar en minúsculas, capitalizando cada palabra de nombres compuestos por múltiples
palabras, esto mantiene una consistencia que facilita la lectura y mantenimiento de los modelos y
código.
Si los objetos en una clase no necesitan atributos u operaciones puede indicar que la clase está mal
definida y debe ser separada o unida a otra clase.
Una interrelación también puede tener una estructura y comportamiento. Esto es cierto cuando la
información trabaja con una liga entre dos objetos y no con un objeto por si mismo.
2.8. Herramientas de Diseño

Existen muchas metodologías para diseñadores y usuarios que pueden hacer más fácil el proceso de
diseño de la BD. Estas varían desde técnicas generales descritas en la literatura hasta productos
comerciales que ayudan a automatizar el proceso de diseño. Por ejemplo, las herramientas CASE
(Computer Aided Software Engineering) de diversos vendedores, que incluyen herramientas para el
análisis del sistema, administración de proyectos, diseño, y programación. Estos paquetes
proporcionan herramientas que pueden ser muy útiles en el proceso de diseño. Las herramientas son
clasificadas generalmente como:
 Upper-CASE. Herramientas usadas en la planeación para recolectar y analizar los datos,

diseñar el modelo de datos y diseñar aplicaciones.
 Lower-CASE. Herramientas usadas para implementar la BD, incluyendo prototipos,
conversión de datos, generar código de aplicación, generar reportes y pruebas.
 CASE integrado. Herramientas que cubren ambos niveles.
Un diccionario de datos orientado al usuario es un herramienta que puede desarrollarse con o sin
paquetes CASE. Los paquetes de administración de proyectos (Project Manager) son otro tipo de
herramienta que puede ser aplicada efectivamente al desarrollo de BD.
Tarea.
a. Leer al menos 2 fuentes adicionales sobre los temas vistos en esta unidad y hacer un resumen
de la unidad (máximo 1 cuartilla). No olvidar conclusiones y bibliografía.
b. Explicar cuáles son las diferencias entre el nivel externo, interno y lógico, entre una llave primaria,
secundaria, alterna y candidata, entre atributos compuestos y multivaluados, entre cardinalidad
máxima y mínima, entre la generalización y especialización, entre especialización parcial y total,
entre los subtipos y las entidades débiles, entre las clases frontera, control y entidad, entre
métodos y atributos de una clase, y entre upper, lower y case integrado.

Ejercicio1.
Usando la descripción siguiente, descubrir entidades. Para cada entidad, definir su alcance y
determinar la llave primaria, después documentarla.
Bueno, mi madre y yo y otros trescientos empleados trabajamos en esta pequeña tienda de comida
saludable sin usar computadoras, pero reconocemos que a veces sería mejor hacerlo de otra forma.
Por supuesto que se puede asignar un Número de Empleado si quiere…
De cualquier forma, necesitamos mantener información de todas estas diferentes clases de

productos, germen de trigo, vitamina E, chocolate cubierto de granola, que son muy vendidos. Es
preferible que mejor les de un número, porque tenemos tantas clases de productos que apenas
podemos con ellos. Y necesitamos saber qué productos se venden en qué tiendas, y cuáles no.
¿Perdón?, no, no tenemos números para las tiendas, pero puede dárselos si quiere, está bien para
mi madre y para mi.
¿Sabe que tenemos tiendas en tres diferentes estados? Y estamos pensando ampliarnos a otros dos
estados, Veracruz y Tamaulipas…
Ejercicio 2.
Parece que contrataremos más empleados. Casi 200 en la región N, la región norte, y cerca de 100
en la sur, región S. La región este E, es la más grande. Está bien si quiere numerar a los empleados.
Lo bueno es que el número de clientes también ha crecido. Catorce nuevos clientes tan sólo en la
región oeste. ¿También quiere numerar a los clientes? Bueno, ¿porqué no?
Sé que el director ha realizado un esquema de clasificación para saber qué clase de clientes
tenemos, y el tipo de experiencia tienen los empleados. Creo que les llama Códigos de Clase. Creo
que B es para Bancos, G para Oficinas de Gobierno, H para Hospitales, etc.
Ejercicio 3
Como sabe, yo soy quien tiene que organizar todas estas comidas, cada… bueno, todo el tiempo y
vaya que es mucho trabajo…Si, usted puede numerarlas pero la mejor parte es mantener
información de los platillos como S para bistec y Q para quiché y F para Pescado…algunas veces,
como cuando estoy muy cansado ya no sé como le hago pero como yo soy la persona responsable
debo llevar un registro de todas las invitaciones. Cada una debe ser numerada y debo mantener
información de qué invitados nos honran con su presencia y cuáles no. Supongo que también quiere
darles números a los invitados. Entonces qué, es esto interesante ¿o no?
Ejercicio 4
Desarrollar un modelo de datos para la siguiente situación. Primero modelar las entidades, una a la
vez, luego proceder a descubrir interrelaciones, definir su alcance, determinar su tipo y finalmente
documentarlas.
El usuario es administrador de un cementerio muy grande. Cada cliente tiene asignado por el
sistema un número de cliente único y a hasta que fallece una fosa. Las fosas son asignadas por
sistema con números únicos empezando con 1. De las 927 fosas en la institución, sólo el 20 % están
ocupadas. 312 clientes están actualmente en archivo.

Ejercicio 5
El usuario debe mantener información de los pedidos numerados de forma única por el sistema, que
son recibidos por varios vendedores, cada uno identificado con un número asignado por el usuario.
Un vendedor puede recibir varios pedidos, por supuesto, pero cada pedido está asociado sólo con un
vendedor.
Ejercicio 6
El usuario es responsable del registro de los estudiantes en pequeño colegio privado. Cada
estudiante es identificado con un número de estudiante asignado por sistema, cada curso tiene un
código de curso asignado por usuario. En cualquier momento, los estudiantes pueden estar
registrados a cero, uno o más cursos; y cada curso puede tener cero, uno o más alumnos inscritos.
Ejercicio 7
El siguiente ejercicio es una continuación de un ejercicio previo. Las entidades ya han sido
descubiertas, descubrir, definir el alcance, determinar en tipo de y modelar todas las interrelaciones
apropiadas para este sistema.
Bueno, mi madre y yo y otros trescientos empleados trabajamos en esta pequeña tienda de comida
saludable sin usar computadoras… Cada empleado, por supuesto sólo trabaja en una tienda, pero
una tienda puede tener varios empleados. Realmente no nos interesa saber dónde viven los
empleados.
Cada tipo de producto puede venderse en cualquier tienda, y la mayoría de las tiendas manejan la
mayoría de los productos. Existen algunas excepciones, creo…
No se olvide que estamos actualmente en tres estados. ¿Qué? Claro que no, todos saben que no se
puede tener una tienda en más de un estado…
Ejercicio 8
El usuario dice…
Casi 200 en la región norte, ¿recuerda? Y casi 100 en la sur. Si así es, cada empleado trabaja en
una sola región…
Ahora acerca de los clientes: cerca de catorce nuevos sólo en la región oeste…¿Que? No, si tienen
sucursales en más de una región los tratamos como clientes separados, diferentes números y todo…
Al jefe parecen gustarle sus nuevos códigos de clase. Ha terminado de clasificar a los clientes y la
próxima semana empezará con los empleados.
Ejercicio 9
El usuario dice…
Como le decía, una comida tiene muchos invitados y la mayoría de los invitados vienen a todas las
comidas con algunas excepciones, cada invitación es para un invitado pero un invitado puede recibir
varias invitaciones porque son para una sola comida y también sólo servimos un platillo en cada

comida pero el platillo se puede servir en diferentes comidas, no olvide que yo debo saber no sólo
quienes son los invitados sino quienes vinieron realmente.
Ejercicio 10
Y el usuario dice…
Debo poder obtener los nombres de los empleados, ya sabe, y el nombre y precio de los productos
también. Ah! Por supuesto. El precio de cada artículo es el mismo en cada tienda. También debo
poder saber qué cantidad de productos hay actualmente en cada tienda. Bien!
Sería bueno tener cada nombre de los estados en algún lugar, y para mi hijo Benjamín que se acaba
de graduar de la escuela y le gusta coleccionar números de tipo estadístico, mejor incluimos el
número de empleados por cada tienda, la cantidad de tiendas por estado, el número de estados que
tienen tiendas y el número total de empleados.
¿Cree que pueda manejar todo esto?
Ejercicio 11
El siguiente ejercicio es también una continuación de un ejercicio previo. Las entidades e

interrelaciones ya han sido modeladas. Descubrir, definir el alcance, determinar la llave para y
modelar todos los atributos apropiados.
El usuario dice…
El director probablemente quiera una llave única para cada uno de esos códigos de clase, y el
nombre del cliente y su número telefónico también. Los nombres de las regiones, como
probablemente sospecha, son todas diferentes. Necesitamos obtener la cantidad de empleados y
clientes para cada región todo el tiempo.
El director también quiere el nombre de cada empleado y mencionó que le gustaría poder ingresar
algún comentario de las habilidades de cada empleado. No, nada formal, sólo un comentario,
“bueno”, “muy bueno” o “no tan bueno”, cosas así.
Ejercicio 12
El siguiente ejercicio es también una continuación de un ejercicio previo. Las entidades e

interrelaciones ya han sido modeladas. Tomar las acciones necesarias faltantes.
Bueno, pues ya habíamos llegado a algo, pero, le tengo malas noticias…, he sido removido de mi
puesto quesque por no tener habilidad para expresarme claramente o algo así. Me parece totalmente
injusto, ¿no cree?, y bueno creo que no hemos terminado de definir el modelo o no sé si ya está,
bueno, usted me entiende, ¿no?
Ejercicio 13
El siguiente ejercicio es más interesante si se practica con varias personas y una lee el problema
asumiendo el papel de usuario, los otros no leen y asumen el papel de analistas. El objetivo es
generar un DER completo.

Se deben incluir sólo las entidades, interrelaciones y atributos mencionados en el texto, un modelo
que tiene demasiado puede estar tan incorrecto como un modelo que no incluye suficiente.
El usuario dice:
Bueno, me dijeron que usted me puede ayudar y eso espero porque este complejo de departamentos
se está saliendo de mis manos. 1400 unidades, ya sabe, son muchas unidades. ¿Qué dice? Por
supuesto que ya están numeradas de 1 a 1400, ¿qué mas?
Yo necesito saber quién paga la renta de cada uno. No, no me importa quién vive ahí, sólo quién es
el responsable de la renta. Si, les llamamos inquilinos, pero son realmente los que pagan la cuenta.
Sólo un inquilino por cada unidad. Necesito sus nombres, y poder obtener su número de credencial
de elector cuando quiera. ¿Un inquilino puede pagar más de una unidad? No veo porqué no.
Y necesito muchos datos de cada unidad. Número de recámaras, por ejemplo. Si tienen chimenea y
lava platos. Y qué lugares de estacionamiento tienen asignados. ¿Números? Seguro ya tienen
números, pero no corresponden con el número de la unidad, y no podemos hacer nada al respecto.
La unidad 103, por ejemplo, tiene los lugares de estacionamiento 1201 y 1202 asignados. ¿Está
usted loco? No puede asignar un lugar de estacionamiento a más de una unidad, habría peleas para
estacionarse todas las noches…
Ahora, algunas de estas unidades son llamadas de lujo, tipo L. Otras son tipo R para regulares y
existen un montón de unidades económicas también. Así es tipo E. ¿Cómo lo sabía? La cantidad de
renta depende del tipo de unidad, y no de las características.
Si, características, características adicionales. Las tenemos todas codificadas, pero siempre
pensamos en nuevas. ¿Como qué? Como VA para Vista a la Alberca y CT para cerca de las
canchas de tenis. Si quiero mantener información sobre esto. Quiero poder listar todas las
características y quiero poder encontrar en qué unidades se tienen qué características y cuáles no…
Ejercicio 14
El usuario dice:
Estamos en graves problemas aquí, He perdido el control sobre a quién pertenece esta TV y no sé a
quién pertenece aquel horno de microondas. De algún modo debemos poder mantener un mejor
control de qué cliente trajo qué aparato. Debemos obtener el nombre del cliente y su número
telefónico si se puede…
Y necesitamos un mejor sistema para mantener control de los técnicos. Sus nombre, por supuesto y
sobre qué aparato está trabajando y qué tiempo tarda en cada uno, las horas que se cobran, ya
sabe. Si, un técnico puede trabajar en más de un aparato y un aparato puede ser trabajado por más
de un técnico. No, no me importa saber quién lo tiene en este momento, pero me gustaría saber si
está o no reparado. ¿Un qué? ¿Una qué menor? No, no, sólo el código, SI significa que ya está
reparado y NO significa que no…
¿Cómo distinguimos un aparato de otro? El sistema los numerará y nosotros pondremos el número
correcto en el aparato, por supuesto. ¿Tipos de aparatos? Si, hemos tenido estos códigos por años.
TV significa Televisor, por supuesto, RA es para radio y MO es para horno de microondas. ¿Qué es
eso? No, cada aparato tiene sólo un tipo. También necesitamos una descripción para cada aparato.
Estos códigos no son suficientemente específicos…

También, vamos a requerir un mejor control del equipo de prueba. Este multiprobador HyperTech
costó $35000 una pieza, sabe. Tenemos nueve de ellos actualmente, numerados del 1001 al 1009.
Lo que quiero saber es qué técnico tiene qué pieza de equipo y en qué estación de trabajo se
encuentra. ¿Qué dice? Sólo una pieza de equipo por técnico, así es. Y sólo un técnico puede tener
una pieza a la vez. No, no me interesa quién la tuvo antes…
¿Las estaciones de trabajo? Bueno, como puede ver, son grandes, y hemos pintado números al final
de cada una. Cuatro o cinco técnicos en una estación y tenemos veinte estaciones. Cada técnico se
asigna siempre a una sola…
Ejercicio 15
Desarrollar dos modelos de la situación descrita a continuación. En el primer modelo no usar

subtipos y en el segundo emplear los subtipos. Una vez completados considerar las ventajas y
desventajas de cada uno.
El usuario dice:
Es mi responsabilidad mantener el control de todos los equipos de cómputo de esta organización.

Utilizo el término dispositivo, ya que existen diferentes tipos de equipo, y quiero que el sistema
proporcione un número único de dispositivo para cada pieza…
También tengo códigos para clasificar cada uno de estos dispositivos. PC es el código para
computadora personal, IM para impresora de matriz de punto, IL para impresora láser y MO para
modems. Cuatro tipos en total…
Ahora observemos las características de estos dispositivos: todos ellos tienen nombre. ¿Qué dice?
No, no tengo códigos para los nombres, y no los necesito. Si, ya sé que hay algunos nombres
duplicados, pero yo lo quiero así y, recordará que yo soy el que paga…
El ancho de banda debe registrarse para los modems y si soporta o no comandos Hayes, si o no
será suficiente en este caso. Para las impresoras de matriz de punto necesito saber el máximo de
caracteres por segundo (CPS) y el ancho en pulgadas. La resolución en puntos por pulgada es lo
que quiero mantener para cada impresora láser (DPI) y el número máximo de páginas por minuto
(PPM) también se requiere…
Para las PCs, necesito conocer el tipo, cantidad de memoria en megabytes, el tamaño de su disco
duro en gigabytes, el tamaño del monitor y la resolución en pixeles….
Ejercicio 16
Desarrollar dos modelos de la situación descrita a continuación, como en el ejercicio anterior. No

usar subtipos en el primero y usarlos en el segundo. Cuando ambos modelos estén completos,
considerar las ventajas y desventajas de cada uno.
El usuario dice:
Lo que hacemos aquí es probar la durabilidad y fuerza de los metales. Cada muestra es numerada
por el sistema, empezamos con la muestra 1 hace ya mucho tiempo, y tiene un nombre que puede o
no ser único. Las muestras son todas del mismo tamaño: tres pies de longitud, una pulgada de
diámetro…

Existen diferentes tipos de pruebas que realizar y cierta información es registrada para todas las
pruebas. El número de prueba generado por el sistema, por ejemplo, el número de muestra de la
muestra sobre la que se está trabajando, y el código de tipo de prueba. ¿Cómo? Si, todos tenemos
los códigos memorizados. PD significa prueba de Deflexión, PQ es el punto de quiebre, y PF es para
el punto de fundición…
Ahora, ¿dónde estaba?, Ah sí, una vez que se registra lo básico, la muestra se monta verticalmente
en un dispositivo y medimos la fuerza necesaria para doblarla en una cantidad específica hacia un
lado. Esta es la prueba de deflexión y la fuerza se registra en libras.
Se continúa aplicando presión hasta que la muestra se rompe. La fuerza nuevamente se registra en
libras, y la deflexión al momento de quebrarse se registra en pulgadas. No, esta no es la prueba de
deflexión, es la prueba de punto de quiebre…
Finalmente tomamos una pieza de la muestra rota – una pieza de tamaño estándar, por supuesto – y
la calentamos en el horno hasta que se funde. El resultado de esta prueba se registra en grados
centígrados. Puede registrarse algún comentario en este punto, describiendo cualquier separación
que ocurra durante el proceso, o si ardió en flama antes de fundirse, o cualquier cosa que el técnico
pueda decir…
¿Qué? Por supuesto que tenemos que tener un control de los técnicos, pero eso es fácil. Cada uno
tiene un número asignado por sistema y un nombre. Siempre se escribe el número de técnico en
cada prueba, ya sabe, con el número de muestra y el código de tipo de prueba. ¿Perdón? No, sólo
un técnico por prueba, pero las pruebas para una muestra dada pueden ser realizadas por diferentes
técnicos.
Eso es todo lo que tenemos que controlar, ¿y usted qué opina?
Ejercicio 15
Desarrollar el modelo de datos completo para la situación descrita a continuación.
El usuario dice:
Lo que hacemos aquí, es dividir el mundo en cuatro cuadrantes, cada uno consiste de una o más
áreas. Los cuadrantes tienen nombre y son numerados del 1 al 4, y las áreas tienen números únicos
en cada cuadrante. Las áreas en cada cuadrante son contiguas, por supuesto, y el cuadrante
coincide exactamente con los límites externos de las áreas. De todos modos, se mantiene un control
de los kilómetros cuadrados en cada área.
Ahora, las áreas se subdividen en dos o más zonas cada una. Las zonas tienen nombres y números
de zonas que son únicos en cada área…
Cada uno de nuestros agentes tiene un nombre y está asignado a una zona en particular. Los
agentes pueden moverse de una zona a otra, pero sólo nos interesa en su zona actual. Algunas
veces más de agente se asigna a la misma zona.
Ejercicio 15
Este es otro ejercicio involucrando dependencias. Desarrollar el modelo de datos completo para la
situación descrita a continuación.

El usuario dice:
Me parece muy complicado mantener el control de todas estas partes, ¿sabe? Quiero decir, cuando
alguien viene a la ventanilla y necesita un 47-22-C, necesito saber exactamente dónde encontrarlo…
Hace casi un año que le encargué al departamento de ingeniería que revisara que sus números de
arte coincidieran con la forma en que se mantienen en el almacén. ¡Qué batalla! Pero de cualquier
forma, gracias a eso ahora puedo decir exactamente dónde se encuentra la pieza 47-22-C porque el
47 significa pasillo 47, el 22 significa anaquel 22 y la C significa compartimiento C. ¡Buena idea! ¿No
cree?
El problema es que ahora tenemos que saber dónde se va a almacenar una parte antes de darle un
código, lo que significa que tenemos que saber cómo es y cuántas vamos a almacenar. Desearía no
tener que saber estas tonterías. Así que es muy complicado obtener el código de parte… algunas
veces almacenamos más piezas de las que originalmente se tenían planeadas y entonces la pieza
tiene dos números diferentes, y todo se vuelve un desastre…
Ahora los pasillos, anaqueles y compartimientos son fijos. Los hemos numerado y codificado hace
varios años y nunca cambian. Y Nunca ponemos más de un tipo de parte en un compartimiento, pero
como le decía, podemos tener la misma clase de parte en dos diferentes compartimientos…
¡Si! Olvidaba decirle. Este sistema no funciona si el que solicita la pieza sólo sabe el nombre de la
parte pero no su número.
¿Cree que pueda ayudarme?

Bases de Datos Unidad 2

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Bases de Datos Unidad 2

Caricato da

Copyright:

Formati disponibili

UNIVERSIDAD NACIONAL AUTÓNOMA DE

FACULTAD DE CONTADURÍA Y ADMINISTRACIÓN

AGOSTO - DICIEMBRE 2008

Unidad 2. Diseño de Bases de Datos Página 2

Unidad 2. Diseño de Bases de Datos Página 3

2.1.1. Aproximación Mediante Análisis de sistemas

Unidad 2. Diseño de Bases de Datos Página 4

 El modelo refleja adecuadamente las operaciones de la organización.

2.1.1.1. Análisis del ambiente del usuario

2.1.1.2. Desarrollo del modelo de datos conceptual

2.1.1.3. Elegir un DBMS

Unidad 2. Diseño de Bases de Datos Página 5

2.1.1.5. Desarrollo del modelo físico

2.1.1.6. Evaluación del modelo físico

2.1.1.7. Desarrollar la afinación si la evaluación lo indica

2.1.1.8. Implementar el modelo físico

2.2. Arquitectura de BD en Tres Niveles

 Los diferentes usuarios necesitan diferentes vistas de los mismos datos.

Unidad 2. Diseño de Bases de Datos Página 6

2.2.1. Modelo Externo

Unidad 2. Diseño de Bases de Datos Página 7

2.2.3. Modelo Físico

2.2.4. Independencia de Datos

 Independencia lógica. Se refiere a la inmunidad de los modelos externos a cambios en el

Unidad 2. Diseño de Bases de Datos Página 9

2.4. Modelo Entidad/Relación (MER)

Rectángulo Entidad Fuerte Alumno

Rectángulo Doble Entidad Débil Precio

Elipse u Óvalo Atributo Id_cuenta nombr

Diamante o Rombo Interrelación Estud

Símbolos Básicos para Diagramas Entidad/Relación

Unidad 2. Diseño de Bases de Datos Página 10

Todas las entidades deben cumplir las siguientes reglas:

Unidad 2. Diseño de Bases de Datos Página 11

Todas las entidades deben cumplir las siguientes reglas:

2.1.1.10. Valores Nulos

2.1.1.11. Atributos multivaluados

2.1.1.12. Atributos compuestos

2.1.1.13. Atributos derivados

Unidad 2. Diseño de Bases de Datos Página 12

2.1.1.14. Llave primaria

2.1.1.15. Llave candidata

2.1.1.16. Llave alterna

2.1.1.17. Llave secundaria

2.1.1.18. Llave compuesta

Unidad 2. Diseño de Bases de Datos Página 13

{(e1, e2, …, en) | e1 ∈ E1, e2 ∈ E2, …, en ∈ En }

2.1.1.20. Atributos e interrelaciones

2.1.1.21. Cardinalidad de una Interrelación (Cardinalidad máxima)

 Uno a Uno. Una interrelación R de X a Y es de uno a uno si cada instancia de la entidad X

Si las entidades A, B y C están relacionadas en una interrelación ternaria R, se puede determinar la

 Método 1, mostrar la cardinalidad poniendo 1, N o M sobre la línea que une la entidad a la

Universidad Impar Carrera

Unidad 2. Diseño de Bases de Datos Página 15

Universidad Impar Carrera

Universidad Impar Carrera

2.1.1.22. Restricciones de participación (Cardinalidad Mínima)

Unidad 2. Diseño de Bases de Datos Página 16

2.1.1.24. Interrelaciones dependientes y entidades débiles

2.5. Modelo Entidad/Relación Extendido

2.5.1. Generalización y Especialización (Sutipos)

Unidad 2. Diseño de Bases de Datos Página 17

El método de identificación de subtipos de entidades existentes llamado especialización,

2.1.1.27. Restricciones de Generalización