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.................................................................................52.1.1.2. Desarrollo del modelo de datos conceptual..................................................................52.1.1.3. Elegir un DBMS............................................................................................................52.1.1.4. Desarrollo del modelo lógico........................................................................................62.1.1.5. Desarrollo del modelo físico.........................................................................................62.1.1.6. Evaluación del modelo físico........................................................................................62.1.1.7. Desarrollar la afinación si la evaluación lo indica.........................................................62.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....................................................................................................................122.1.1.10. Valores Nulos...........................................................................................................122.1.1.11. Atributos multivaluados............................................................................................122.1.1.12. Atributos compuestos...............................................................................................122.1.1.13. Atributos derivados...................................................................................................12

2.4.3. Llaves ............................................................................................................................. 12 2.1.1.14. Llave primaria...........................................................................................................132.1.1.15. Llave candidata........................................................................................................132.1.1.16. Llave alterna.............................................................................................................132.1.1.17. Llave secundaria......................................................................................................132.1.1.18. Llave compuesta......................................................................................................13

2.4.4. Interrelaciones .................................................................................................................. 13 2.1.1.19. Tipos de interrelaciones...........................................................................................142.1.1.20. Atributos e interrelaciones........................................................................................142.1.1.21. Cardinalidad de una Interrelación (Cardinalidad máxima)........................................142.1.1.22. Restricciones de participación (Cardinalidad Mínima)..............................................162.1.1.23. Roles........................................................................................................................172.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.........................................................................................................182.1.1.26. Generalización.........................................................................................................182.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...................................................................................................212.1.1.29. Entidades Menores..................................................................................................212.1.1.30. Descubrir una entidad..............................................................................................212.1.1.31. Definir el alcance de la entidad.................................................................................212.1.1.32. Determinar la llave primaria de la entidad................................................................222.1.1.33. Documentar la entidad.............................................................................................22

2.6.4. Paso 2- Modelar Interrelaciones ....................................................................................... 22 2.1.1.34. Descubrir una interrelación.......................................................................................232.1.1.35. Definir el alcance de la interrelación.........................................................................232.1.1.36. Determinar el tipo de la interrelación........................................................................232.1.1.37. Documentar la interrelación......................................................................................24

2.6.5. Paso 3- Modelar Atributos ................................................................................................ 24 2.1.1.38. Atributos reales de entidades...................................................................................242.1.1.39. Atributos reales de interrelaciones...........................................................................242.1.1.40. Datos derivados.......................................................................................................242.1.1.41. Descubrir un atributo................................................................................................252.1.1.42. Definir el alcance del atributo...................................................................................252.1.1.43. Determinar la llave del atributo.................................................................................252.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......................................................................................272.1.1.46. Paso 2 - Modelar Interrelaciones.............................................................................272.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..............................................................282.1.1.49. Paso 2 - Modelar Interrelaciones.............................................................................282.1.1.50. Paso 3 - Modelar Atributos......................................................................................29

2.6.8. Modelar Interrelaciones Recursivas ................................................................................ 29 2.1.1.51. Paso 1 - Modelar Entidades ...................................................................................292.1.1.52. Paso 2 - Modelar Interrelaciones Recursivas..........................................................292.1.1.53. Paso 3 - Modelar Atributos......................................................................................29

2.6.9. Modelar Interrelaciones Complejas (Agregaciones) ......................................................... 29 2.1.1.54. Paso 1 - Modelar Entidades ...................................................................................302.1.1.55. Paso 2 - Modelar Agregaciones .............................................................................302.1.1.56. Paso 3 - Modelar Atributos......................................................................................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 DATOSUNIDAD 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 ActividadesInvestigaciónPreliminar

Entrevistar usuarios, estudiar reportes, transacciones, software y documentación para identificar problemas en el sistema actual, y los objetivos del nuevo sistema.

Estudio de Factibilidad

Estudiar las alternativas, estimar costos, estudiar el calendario y beneficios, y hacer recomendaciones.

Diseño Preliminar

Trabajar con los usuarios para desarrollar el diseño del sistema general. Elegir el mejor diseño. Desarrollar el diagrama de flujo del sistema. Identificar las necesidades de hardware, software y personal. Revisar los estimados.

Diseño Detallado

Hacer el diseño técnico. Planear los módulos del sistema, algoritmos, archivos, base de datos, formularios de E/S. Revisar estimados.

Implementación del Sistema

Programar módulos, convertir archivos, probar sistema, escribir documentación, desarrollar procedimientos de operación, capacitar al personal, hacer corrida en paralelo, poner en funcionamiento el nuevo sistema.

Operación del Sistema

Evaluar el sistema. Monitorear y modificar el sistema de acuerdo a las 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ísicoUnidad 2. Diseño de Bases de Datos Página 8

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

Rectángulo Doble Entidad Débil

Elipse u Óvalo Atributo

Diamante o Rombo InterrelaciónLínea Liga:

Atributo a Entidad

Entidad a Interrelación

Atributo a Interrelación

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.


Alumno

Id_cuenta

Estud

Id_cuenta

Alumno

Alumno

Estud

Estud

Id_cuenta

Precio

nombr

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 E1, 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.

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.

Método 3, mostrar la cardinalidad con o sin flecha en la línea que une la entidad a la interrelación, dependiendo del número máximo de entidades asociadas.


M1Universidad CarreraImpar

te

11Director DepartamentoDirect

or-

NMAlumno Materia

Se ins-

Director DepartamentoDirector-

Universidad CarreraImparte

Alumno MateriaSe ins-

Método 4, mostrar la cardinalidad con o sin punto en la línea que une la entidad a la interrelación, dependiendo del número máximo de entidades asociadas.

Método 5, mostrar la cardinalidad con o sin patas de gallo en la línea que une la entidad a la interrelación, dependiendo del número máximo de entidades asociadas.

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.

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


Es un Es un

0,1 1,M

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.

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:


Empleado

idEmpleado nombre puesto

Monitorear hasta

Proyecto DeptoAsignado a

idProyecto idDeptodesde

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

Documents

Transcript of Bases de Datos Unidad 2