ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA

Modelado Conceptual

Esperanza Marcos

Modelo Conceptual

2

Contenido

GUÍA DE ESTUDIO......................................................................................................................................... 3

1. EL MODELADO CONCEPTUAL DE DATOS EN EL PROCESO DE DESARROLLO SOFTWARE .................. 4

2. CONCEPTO DE MODELO DE DATOS .................................................................................................... 5

3. EL MODELO ENTIDAD/INTERRELACIÓN EXTENDIDO (E/R) ................................................................ 8

3.1. ENTIDAD .............................................................................................................................................. 83.2. INTERRELACIÓN...................................................................................................................................... 9

3.2.1. Elementos de una Interrelación............................................................................................... 103.2.2. Cardinalidad de una Entidad en una Interrelación .................................................................. 11

3.3. DOMINIO Y VALOR................................................................................................................................ 123.4. ATRIBUTO........................................................................................................................................... 133.5. GENERALIZACIÓN/ESPECIALIZACIÓN......................................................................................................... 153.6. EJEMPLO ............................................................................................................................................ 18

4. ETAPAS DEL MODELADO CONCEPTUAL ............................................................................................ 19

4.1. ANÁLISIS DE REQUISITOS ........................................................................................................................ 194.2. ETAPA DE CONCEPTUALIZACIÓN............................................................................................................... 194.3. PASO DEL ESQUEMA PERCIBIDO AL ESQUEMA CONCEPTUAL ......................................................................... 21

5. EJERCICIOS DE AUTOCOMPROBACIÓN ............................................................................................. 24

5.1. ENUNCIADOS....................................................................................................................................... 24

6. BIBLIOGRAFÍA .................................................................................................................................... 27

6.1. BIBLIOGRAFÍA BÁSICA ........................................................................................................................... 276.2. BIBLIOGRAFÍA RECOMENDADA ................................................................................................................ 27

Modelo Conceptual

3

Guía de Estudio

Podemos decir que el núcleo de todo Sistema de Información (en adelante SI)orientado a la gestión está constituido por los datos del sistema, por lo que éstos son unelemento clave en el proceso de desarrollo software. Si además estamos hablando dedesarrollo estructurado de software nos encontramos con que los datos forman el eje apartir del cual se construye el sistema.

En esta unidad se abordará el problema del modelado conceptual de datos, dentro dela fase de análisis del proceso de desarrollo software. El objetivo que nos planteamos esque, al finalizar dicha asignatura, el alumno sea capaz de realizar el modelado conceptualde datos de un SI.

Para ello, en primer lugar, situaremos las actividad del modelado conceptual de datosen el lugar que les corresponde dentro del proceso de desarrollo, estableciendo lasrelaciones existentes entre ésta y otras actividades. Posteriormente, revisaremos elconcepto de modelo de datos, pasando a continuación a exponer el modeloEntidad/inteRrelación (en adelante E/R) como la técnica más aceptada de modelado dedatos en el desarrollo estructurado. Al final de la unidad se incluyen una serie de ejerciciosde autocomprobación con las soluciones propuestas. Es importante que el alumno tengaen cuenta que las soluciones propuestas, en general, no serán únicas, especialmente enlos ejercicios de modelado conceptual. Por tanto, el alumno puede llegar a otrassoluciones alternativas que no serán necesariamente iguales a las que nosotrosproponemos. Finalmente se detalla la bibliografía que se ha divido en dos apartados:bibliografía básica en la que nos hemos basado para desarrollar esta unidad y que, engeneral, el alumno debería conocer; y bibliografía recomendada, constituida por librosque también hemos consultado y que se recomienda a aquellos alumnos que deseenprofundizar o completar algún aspecto concreto de ésta unidad. La unidad contienetambién un control que permitirá evaluar los conocimientos adquiridos por el alumno alfinal de la misma.

A modo de recomendación, y siempre que sea posible, el alumno debería contrastarsus soluciones con las de otros alumnos. Esto permitirá discutir las distintas alternativasanalizando las ventajas e inconvenientes de cada una de ellas. Si esto no fuera posible, elalumno dispone de una dirección de correo electrónico (cuca@escet.urjc.es) a la quepodrá enviar sus comentarios, dudas o sugerencias.

Modelo Conceptual

4

1. El Modelado Conceptual de Datos en el Proceso de Desarrollo Software

El modelado conceptual permite describir, de un modo totalmente independiente de laimplementación, los datos que el usuario quiere recoger en el sistema. Dependiendo de lacantidad de información que se desee representar, tendremos aplicaciones más o menosorientadas a los datos. Así, por ejemplo, la gestión de una biblioteca es una aplicaciónpura de Bases de Datos (en adelante BD) ya que prácticamente toda la funcionalidad delsistema se centra en el mantenimiento de los datos (introducir un libro, prestar un libro,etc.). Existen, sin embargo, otras aplicaciones, como por ejemplo un sistema de control denavegación aérea, en las que los datos son algo secundario. Podemos decir que, engeneral, los datos son el núcleo de todo SI orientado a la gestión.

El desarrollo estructurado de software, a diferencia de lo que ocurre en el desarrolloorientado a objetos, mantiene una clara separación entre los datos y las funciones delsistema. Por ello, es necesario disponer, en cada una de las etapas del proceso dedesarrollo, de técnicas específicas para la especificación de los datos, que serán diferentesde las técnicas orientadas a la especificación de las funciones o procesos.

El modelado conceptual es una actividad que se realiza en la etapa de análisis,paralelamente al modelado de procesos o funciones. Su objetivo, como ya hemos dicho,es captar toda la información del mundo real que se desea representar en el mundoinformático. En este proceso es importante abstraer los detalles sin importancia yrepresentar tan sólo aquella información que sea relevante.

En este punto no nos interesa el cómo ni donde se va a implementar el sistema. Dehecho, dependiendo del tipo de sistema (más o menos orientado a los datos), del volumende información, de los requisitos de eficiencia, etc. se podrán utilizar distintosmecanismos de persistencia de los datos: Sistemas de Bases de Datos, Sistemas deFicheros, etc. De estos aspectos nos ocuparemos en la etapa de diseño (ver la unidaddedicada a diseño estructurado de datos). En esta etapa interesa recoger la máximacantidad de información posible, por lo necesitamos una técnica que cumpla los siguientesrequisitos:

Ser independiente de los modelos o lenguajes de implementación

Tener una capacidad semántica alta

Ser lo mas cercana posible al usuario

Aunque existen diversas técnicas, utilizaremos el modelo E/R porque además decumplir los requisitos anteriores es la técnica de modelado conceptual universalmenteaceptada para el desarrollo estructurado.

Modelo Conceptual

5

En la figura 1.1 se muestra la situación del modelado conceptual en el proceso dedesarrollo, así como la relación existente entre esta y otras actividades. La etapa deanálisis comprende, tanto el análisis de datos, modelado conceptual de datos, como el defunciones. La técnica más habitual para el modelado conceptual de datos es el modelo E/Ry para el modelado conceptual de procesos son los Diagramas de Flujo de Datos (enadelante DFD). Existen algunas técnicas, como el Diagrama de Historia de Vida de lasEntidades o la Matriz Entidad-Evento, que permiten integrar la visión de los datos y la delos procesos. Como se puede apreciar, la etapa de diseño también se compone del diseñode datos y del diseño de procesos.

Figura 1.1. Comparación entre el proceso de diseño de datos y el de procesos

2. Concepto de Modelo de Datos

Un modelo puede definirse como la construcción mental a partir de la realidad en laque se reproducen los principales componentes y relaciones del segmento de la realidadanalizada. Éste es, efectivamente, el significado de modelo en las ciencias empíricas en lasque, a fin de estudiar el comportamiento de una determinada parcela de la realidad, secrea un modelo de ésta. Dicho modelo habrá de ser isomórfico respecto a la realidad querepresenta y más simple que ésta, destacando sus principales características, o aquellasque son relevantes para un determinado interés de estudio. Sin embargo, ésta no es laúnica acepción del término modelo, al que podemos asignar dos significados:

DATOS

ANALISISREQUISITOS DE INFORMACIÓN

FUNCIONES

DISEÑO REQUISITOS DE LOS PROCESOS

Modelado Conceptual de Datos: E/RModelado Conceptual de Procesos: DFD

Diseño de Datos: Relacional Diseño de Procesos: DEC

Modelo Conceptual

6

Por un lado, el modelo entendido como una reproducción simplificada de larealidad; este es el caso, ya expuesto, de las ciencias empíricas, en las que sedefinen modelos de comportamiento simplificados de la parcela del mundo realque es objeto de estudio;

Y, por otro lado, el modelo entendido como la realidad propiamente dicha;piénsese, por ejemplo, en un pintor, quien reproduce en lienzo a sus modelos;en este segundo caso, el modelo no es la representación del mundo real, sinoque constituye el mundo real en sí mismo: es un modelo a copiar o a simular.

Esta segunda acepción de modelo es la que corresponde a la lógica matemática, dondela representación recibe el nombre de teoría y lo representado el de modelo, mientrasque la primera corresponde, como ya hemos visto, al concepto de modelo en las cienciasempíricas.

En algunos casos, como en el caso de los modelos de datos, el concepto de modeloresponde simultaneamente a estas dos acepciones. Quizá resulte esclarecedor el ejemplodel arquitecto, para quien una maqueta es un modelo a copiar para la construcción de unnuevo edificio. La maqueta sería, en un primer momento, la realidad puesto que el edificioaún no existe. El arquitecto obtiene un nuevo edifio tomando dicha maqueta comomodelo. A partir de este momento, el edificio constituye la realidad, mientras que lamaqueta puede considerarse una copia del mismo.

En el ámbito de la bases de datos es muy común la utilización del término modelo dedatos, y existen diferentes definiciones del mismo en la literatura. Así, por ejemplo,Dittrich define modelo de datos como "un conjunto de herramientas conceptuales paradescribir la representación de la información en términos de datos. Los modelos de datoscomprenden aspectos relacionados con: estructuras y tipos de datos, operaciones yrestricciones".

Un modelo de datos permite representar una parcela de información del mundo realde especial interés, lo que habitualmente se denomina universo del discurso o, entérminos, de Dittrich mini-mundo. La representación del universo del discurso se concibeen dos niveles: el de la información en sí misma y el de las estructuras que hacen posiblela representación de tal información. Estos dos niveles dan lugar, en el ámbito de las basesde datos, a la distinción entre esquema y base de datos, conceptos que Dittrich definecomo sigue: "La descripción específica de de un determinado mini-mundo en términos deun modelo de datos se denomina esquema (o esquema de datos) del mini-mundo. Lacolección de datos que represntan la información a cerca del mini-mundo constituya labase de datos".

Modelo Conceptual

7

Sin embargo, el término modelo, debido a las diferentes acepciones del mismo, puededar lugar a ambigüedad y es importante tener en cuenta que en otros ámbitos diferentesal de las bases de datos esta terminología puede variar. Así, por ejemplo, algunos autoreshablan de formalismos, en lugar de modelos, como marcos en los que definir esquemas, alos que ellos se refieren como modelos. De este modo, en muchas ocasiones se habla demodelos (modelos conceptuales, modelos de conocimiento, modelos lógicos, etc.) parareferirse indistintamente, tanto al modelo del universo del discurso (esquema) como alformalismo en el que éste es definido (modelo de datos).

El problema deriva, de la doble acepción del término modelo. Podemos decir que unesquema es un modelo (entendido como una copia simplificada de la realidad), y unmodelo (entendido como un original que se toma como referencia) si ese esquema seimplementa en un sistema informático. Por este motivo, podemos encontrar autores quehablan de modelos para referirse a lo que nosotros denominaremos esquemas, o que serefieran a los modelos como formalismos o técnicas. Por ejemplo, un DFD no es en símismo un modelo, sino que suelen ser denominados técnicas, mientras que se denominamodelo funcional, a la representación de la parte dinámica de un universo del discursoutlizando la técnica de los DFDs.

Teniendo presente que esta terminología puede variar y que empleamos ésta por ser lamás extendida en el mundo de los “datos” en el que se centra la presente unidad,definimos modelo de datos como un:

Y esquema se datos como la:

Conjunto de conceptos, reglas y convencionesque permiten describir y manipular los datosde la parcela del mundo real que constituyenuestro universo del discurso.

Representación de un determinado universodel discurso en términos de un modelo de

Modelo Conceptual

8

3. El modelo Entidad/inteRrelación extendido (E/R)

El modelo E/R fue propuesto por Peter P. Chen en dos artículos ya históricos publicadosen 1976 y 1977. Permite al diseñador concebir los datos del sistema a un nivel superior deabstracción, aislándolo de consideraciones relativas a la máquina y a los usuarios enparticular. El modelo, como su nombre indica, se apoya en dos conceptos: entidad einterrelación1. Para Chen, una entidad es “una cosa que se puede identificar claramente”y “una interrelación una vinculación entre entidades”.

Posteriormente otros muchos autores (ver a modo de ejemplo Elsmari et al. (1997)),han investigado y escrito sobre el modelo, proponiendo importantes extensiones.Realmente no se puede considerar que exista un único modelo E/R, sino más bien lo quepodríamos llamar una familia de modelos, por lo que hay importantes diferencias en lapresentación que del modelo hacen distintos autores. Nosotros nos basaremos en elmodelo expuesto en De Miguel et al. (1999) que incluye la mayoría de las extensiones quese han ido aportando a lo largo del tiempo, así como algunas consideraciones einterpretaciones propias.

En el modelo E/R, tal como fue propuesto por Chen, se distinguen los siguienteselementos: Entidad, Interrelación, Dominio y Atributo. De entre las diversas extensionespropuestas al modelo básico, consideraremos aquí la Generalización debido a suimportancia en el modelado conceptual debida, en parte, a que es un constructor básicoen el paradigma de la orientación a objetos.

3.1. Entidad

El mundo real se compone de una serie de objetos (reales o abstractos) acerca de loscuales queremos obtener y representar información. En general dichos objetos podránagruparse en conjuntos de acuerdo a unas características comunes a todos aquellos queforman parte de un mismo conjunto. Denominamos entidad a la abstracción que permiterepresentar aquellos objetos del mundo real que comparten una serie de característicascomunes. Cada uno de los objetos concretos que pertenecen a la entidad es un ejemplar uocurrencia de entidad. Así, por ejemplo, DEPARTAMENTO es una entidad que permiterepresentar el conjunto de departamentos de los que se compone una empresa.Ejemplares de la entidad DEPARTAMENTO podrían ser el departamento de ventas, de I+D,de personal, de formación, etc. El conjunto de ejemplares de una entidad en un momentodado será la extensión de ese tipo de entidad.

1 Hemos traducido por interrelación el término inglés “relationship” a fin de distinguirlo de la relación del modelo relacional que, en

inglés, se denomina “relation”. El término asociación lo utilizaremos para referirnos al caso general de conexión entre objetos, dejando

interrelación para expresar la asociación en el modelo E/R.

Modelo Conceptual

9

La representación gráfica de una entidad es un rectángulo etiquetado en cuyo interiorestá el nombre del tipo de entidad. La figura 3.1 muestra la representación de lasentidades DEPARTAMENTO y EMPLEADO.

Figura 3.1. Representación de entidades

Existen dos clases de entidades: regulares, que son aquellas cuyos ejemplares tienenexistencia por sí mismos (como DEPARTAMENTO y EMPLEADO), y débiles, en las cuales laexistencia de un ejemplar depende de que exista un cierto ejemplar de otro tipo deentidad. Por ejemplo, la entidad HIJO es una entidad débil que depende de EMPLEADO, yaque a la empresa tan sólo le interesa información de los hijos de sus empleados, del talmodo que la desaparición de un determinado empleado hace que desaparezcan tambiénlos hijos de éste. Las entidades débiles se representan con dos rectángulos concéntricoscon su nombre en el interior, como se ve en la figura 3.2.

Figura 3.2.- Representación de una entidad débil

3.2. Interrelación

Se entiende por interrelación una asociación, vinculación o correspondencia entreentidades. Cada asociación o vinculación que se establece entre ejemplares concretos delas entidades que intervienen en una interrelación se denomina ejemplar u ocurrencia deinterrelación. Por ejemplo, Pertenece es una interrelación que vincula las entidadesDEPARTAMENTO y EMPLEADO; un ejemplar de la interrelación Pertenece es la vinculaciónentre el departamento de “formación” y la empleada “B. Vela”.

Representaremos la interrelación mediante un rombo etiquetado con un nombre,unido mediante arcos a los tipos de entidad que asocia, como se ve en la figura 3.3, endonde establecemos la interrelación Pertenece entre DEPARTAMENTO y EMPLEADO.Entre dos entidades puede existir más de una interrelación.

DEPARTAMENTO EMPLEADO

HIJO

Modelo Conceptual

10

Figura 3.3.- Representación de la relación Imparte

3.2.1. Elementos de una Interrelación

En un tipo de interrelación se pueden distinguir los siguientes elementos:

a) Nombre: al igual que las entidades, los dominios y los atributos, cada interrelacióntiene un nombre que lo distingue unívocamente del resto, y mediante el cual ha deser referenciado.

b) Grado: es el número de entidades que participan en una interrelación. Así, unainterrelación es de grado 2 (o binaria) cuando asocia dos entidad (ver, por ejemplo,figura 3.3). Un caso particular de interrelaciones de grado 2 son las interrelacionesreflexivas, las cuales asocian una entidad consigo misma; en la figura 3.4 se muestrala interrelación reflexiva Consta que asocia PROYECTO con PROYECTO, y que refleja laposibilidad de que un cierto proyecto (por ejemplo, gestión de un hospital) estécompuesto por (sub)proyectos (por ejemplo, gestión de personal, gestión dehistoriales clínicos, etc.). Pueden existir también interrelaciones que asocien más dedos entidades (interrelaciones n-arias). Las interrelaciones nárias, siendo n>2, másfrecuentes son las de grado 3 y reciben el nombre de interrelaciones ternárias.

Figura 3.4. Ejemplo de interrelación reflexiva

DEPARTAMENTO EMPLEADOImparte

Consta

PROYECTO

Modelo Conceptual

11

c) Tipo de correspondencia: es el número máximo de ejemplares de una entidad quepueden estar asociados, en una determinada interrelación, con un ejemplar deotra(s) entidad(es); para representarlo gráficamente, bien se pone una etiqueta con1:1, 1:N o N:M l lado de la interrelación, o bien se orienta el arco de unión en elsentido 1 a N mediante una punta de flecha, tal como aparece en la figura 3.5,donde se han incluido ambos tipos de representación en tres ejemplos de tipos deinterrelación.

d) Papel (“rol”): es la función que cada una de las entidades realiza en la interrelación;se representa poniendo el nombre del papel en el arco que une cada entidad coninterrelación (ver figura 3.5). Siempre que no exista ambigüedad se suele prescindirde representar el papel.

Figura 3.5. Ejemplos e interrelación uno a uno (1:1), uno a muchos (1:N), y muchos a muchos(N:N) y roles

3.2.2. Cardinalidad de una Entidad en una Interrelación

Se define como el número máximo y mínimo de ejemplares de una entidad que puedenestar interrelacionadas con un ejemplar de la otra, u otras entidades que participan en lainterrelación. Se representa gráficamente añadiendo una etiqueta del tipo (0,1), (1,1), (0,n)ó (1,n), según corresponda, al lado de las entidades asociados por la interrelación, tal comoaparece en la figura 3.6. Las cardinalidades máximas coinciden con el tipo decorrespondencia.

Es_realizado_por

Trabaja_en

PROYECTO

Dirige 1:1

EMPLEADO

DEPARTAMENTO

Pertenece 1:N

EMPLEADO

PROYECTO

Participa N:M

EMPLEADO

Está_adscrito_a

Se_compone_de

Es_cordinado_por

Coordina

Modelo Conceptual

12

Figura 3.6. Ejemplo de interrelación en la que aparecen las cardinalidades

En la figura 3.7 se muestran algunos ejemplares de la interrelación Pertenece entreDEPARTAMENTO y EMPLEADO, en la que se ha supuesto que pueden existir departamentosque (por estar recién creados) no tienen ningún empleado y que todo empleado tiene quepertenecer siempre a un único departamento.

Figura 3.7. Representación de ejemplares de la interrelación Pertenece

3.3. Dominio y valor

Las distintas propiedades o características de una entidad o de una interrelación tomanvalores para cada ejemplar de éstas. El conjunto de posibles valores que puede tomar unacierta característica se denomina dominio. Se define dominio como un conjunto devalores homogéneos con un nombre. Para saber si un valor pertenece a un dominiodeterminado, comprobaremos que cumple el predicado que el dominio lleva siempreasociado.

DEPARTAMENTO (1,1) EMPLEADO (0,n)

Pertenece (DEPARTAMENTO(1,1):EMPLEADO(0,n))

DEPARTAMENTO EMPLEADOPertenece(0,n)

1:N

(1,1)

Modelo Conceptual

13

Por ejemplo, el valor “formación” se toma del dominio Nombre_departamento, ycumple el predicado de ser uno de los departamentos posibles del conjunto {“ventas”,“I+D”, “personal”, “formación”, “desarrollo”}; el dominio Nombre_empleado es una tirade caracteres. Un dominio puede definirse por intensión, especificando el tipo de datos(por ejemplo, carácter (30) para el Nombre_empleado o fecha para la Fecha_alta); o porextensión, declarando el valor de cada elemento del dominio (como es el caso deNombre_departamento).

3.4. Atributo

Cada una de las propiedades o características que tiene una entidad o una interrelaciónse denomina atributo; los atributos toman valores de uno o varios dominios. Por tanto,podemos decir que el atributo le da una determinada interpretación al dominio (o a losdominios) en el contexto de un tipo de entidad o de un tipo de interrelación. El atributo serepresenta gráficamente con un círculo u óvalo etiquetado con su nombre (ver figura 3.8)y unido mediante un arco a la entidad o a la interrelación correspondiente.

Figura 3.8. Dos formas de representación de un atributo

Por simplicidad, en el esquema conceptual resultante del modelado sóloespecificaremos los atributos más significativos; en la figura 3.9. se representa lasentidades DEPARTAMENTO y EMPLEADO y la interrelación Pertenece con alguno de susatributos.

Figura 3.9. Representación de atributos de entidades y de interrelación

Nombre_departamento

Nombre_departamento

Codigo_dep

Nombre_depDEPARTAMENTO

EMPLEADO

Pertenece Fecha_alta

DNI

Nombre_emp

Fecha_nac

Modelo Conceptual

14

La existencia de un atributo está ligada a la de la correspondiente entidad. Así la fechade nacimiento de un empleado (Fecha_Nac) no tiene sentido si de nuestro esquemadesaparece el tipo de entidad EMPLEADO; sin embargo, el dominio Fechas puede existircon independencia de cualquier otra entidad.

El modelo E/R admite atributos compuestos, es decir, atributos definidos sobre más deun dominio; por ejemplo, el atributo Fecha_Nac de la entidad EMPLEADO puede estardefinido sobre los dominios Día, Mes, y Año. En la figura 3.10 se muestran dos formas derepresentar los atributos compuestos.

Figura 3.10. Dos formas de representar atributos compuestos

El modelo E/R permite también atributos multivaluados. En general un atributo toma,para cada ejemplar de entidad, un único valor de cada dominio (o dominios)subyacente(s) (un empleado tiene un único nombre, un único DNI, etc.), pero tambiénexisten atributos que pueden tomar más de un valor (por ejemplo, un empleado puedetener varios números de teléfono). Estos atributos, que pueden tomar varios valores,reciben el nombre de multivaluados frente a los univaluados que toman un solo valor. Enla figura 3.11 se muestra, mediante el ejemplo de los teléfonos, una forma de representarlos atributos multivaluados.

Año

MesEMPLEADO

Día

Fecha_nac

Año

MesEMPLEADO Día

Fecha_nac

Modelo Conceptual

15

Figura 3.12. Ejemplo de atributo multivaluado (Teléfono)

Entre todos los atributos de una entidad han de existir uno o varios (simples y/ocompuestos) que identifiquen unívocamente cada una de los ejemplares de esa entidad.Cada uno de estos conjuntos de atributos se denomina Identificador Candidato (IC).Cuando un IC es compuesto, el número de los atributos que lo componen debe sermínimo, en el sentido de que la eliminación de cualquiera de ellos le haría perder sucarácter identificador. Luego todo IC debe cumplir la condición de ser unívoco y mínimo.Entre los IC se elige uno como Identificador Principal (IP) y el resto serán IdentificadoresAlternativos (IA). El atributo IP se puede representar de cualquirea de los dos modos quese muestran en la figura 3.13. Los identificadores principales compuestos se puedenrepresentar de forma análoga a la de los atributos compuestos.

Figura 3.13. Representación gráfica de IP y IA

3.5. Generalización/Especialización

En el modelo E/R básico propuesto por Chen no se encontraba este tipo de abstracciónque fue introducido en posteriores extensiones del modelo. La jerarquía degeneralización/especialización, en el modelo E/R, se considera como un caso especial deasociación entre varias entidades (subtipos) y una entidad más general (supertipo) cuyas

Teléfono

EMPLEADO

DNI

Nombre_emp

Fecha_nac

DNIEMPLEADO

DNIEMPLEADO

Modelo Conceptual

16

características son comunes a todos los subtipos. La asociación que se establece entre lossubtipos y el supertipo corresponde a la noción de es_un (IS_A, en inglés).

Aunque existen distintas convenciones para representar estas jerarquías degeneralización/especialización, nosotros utilizamos un triángulo cuya base es paralela alrectángulo que representa la entidad del supertipo al cuál está conectado; triangulo quetambién se une a los subtipos, tal como se muestra en la figura 3.14.

Figura 3.14. Ejemplo de jerarquía de supertipo/subtipos

Esta clase de asociación tiene la característica de que todo ejemplar de un subtipo estambién un ejemplar del supertipo, aunque no sucede lo contrario, con lo que lascardinalidades serán siempre (1,1) en el supertipo y (0,1) en los subtipos.

La aparición de estas jerarquías, en el modelado de datos, puede surgir de dos formasdistintas:

a) Generalización. Se observa que dos o más entidades comparten varios atributos y/ointerrelaciones, de donde se deduce la existencia de una entidad de nivel superior(supertipo) que contiene los atributos y las interrelaciones comunes a todos lossubtipos.

b) Especialización. Se observa que una entidad tiene ciertos atributos y/ointerrelaciones que tienen sentido para unos ejemplares pero no para otros, por loque es conveniente definir uno o varios subtipos que contengan estos atributos y/ointerrelaciones específicos, dejando en el supertipo los que son comunes.

Por tanto, si nos movemos de los subtipos hacia el supertipo, se trata de unageneralización; mientras que si primero identificamos el supertipo y, a partir de él, llegamosa los subtipos, se trata de una especialización.

(1,1)Es_un

(0,1) (0,1)ANALISTA PROGRAMADOR

EMPLEADO SUPERTIPO

SUBTIPOS

Modelo Conceptual

17

Puede ocurrir que se formen, por generalización y/o especialización, jerarquías a más deun nivel donde un subtipo es, a su vez, supertipo de otros.

Otra característica muy importante de esta clase de asociación es la herencia, ya que,todo atributo, o interrelación, del supertipo pasa a ser un atributo, o interrelación, de lossubtipos; por ejemplo, en la jerarquía de la figura 3.14 tanto los analistas como losprogramadores son empleados, por lo que heredarán todos los atributos de la entidadEMPLEADO (DNI, Nombre, Dirección, etc.).

En este tipo de abstracción los atributos comunes a todos los subtipos (incluidos losidentificadores) se asignan al supertipo, mientras que los atributos específicos se asocian alsubtipo al cual pertenecen. Del mismo modo, las interrelaciones que afectan a todos lossubtipos se asocian al supertipo, dejándose para los subtipos las interrelaciones específicasen las que sólo participa el correspondiente subtipo.

La división en subtipos (especialización) puede venir determinada por una condiciónpredefinida (por ejemplo, en función de los valores de un atributo) en cuyo caso serepresentará la condición (o el atributo discriminante) asociada al triángulo que representala interrelación.

Atendiendo a si los subtipos se solapan o son disjuntos, y a si la unión de los subtiposrecubre o no al supertipo se pueden distinguir cuatro clases de generalización. Si un mismoejemplar del supertipo puede pertenecer a más de un subtipo habrá solapamiento y si sólopuede pertenecer a uno de los subtipos existirá exclusividad; por otro lado, si todo ejemplardel supertipo tiene que pertenecer a algún subtipo tendremos totalidad y si, por elcontrario, no tiene obligatoriamente que pertenecer a algún subtipo habrá parcialidad.

La combinación de estas posibilidades da lugar a cuatro tipos de jerarquías, donderepresentaremos por un arco el hecho de que los subtipos sean disjuntos y con un círculo lapresencia de una jerarquía total, como puede observarse en la figura 3.15, en la cual sepresenta una jerarquía total de subtipos disjuntos, ya que:

Tanto un analista como un programador son empleados (jerarquía degeneralización)

Los empleados con título de licenciado o ingeniero tienen categoría de analistasmientras que los diplomados o ingenieros técnicos tienen categoría deprogramadores. Un mismo empleado no puede ser a la vez analista yprogramador (exclusividad)

Todo empleado tiene que ser obligatoriamente un analista o un programador(totalidad)

Modelo Conceptual

18

Figura 3.15. Ejemplo de jerarquía total sin solapamiento

3.6. Ejemplo

A continuación, figura 3.16, representamos en el modelo E/R el esquema conceptualcompleto que hemos utilizado a lo largo de la explicación. En el se muestran dosinterrelaciones (una 1:N y otra N:M) con sus cardinalidades, los atributos identificadorespricipales (AIP) de cada una de las entidades así como los atributos de las interrelaciones.

Figura 3.16. Ejemplo de esquema conceptual en el modelo E/R

(1,1)

1:N

(0,n) N:M

(1,n) (0,n)

DEPARTAMENTO

1:N

EMPLEADO PROYECTO

Pertenece

Participaa

Codigo_dep

Fecha_alta

DNI

Codigo_proy

EMPLEADO

(1,1)

SUPERTIPO

SUBTIPOS

Es_un

(0,1) (0,1)

ANALISTA PROGRAMADOR

Título

Modelo Conceptual

19

4. Etapas del Modelado Conceptual

El modelado conceptual, también denominado diseño conceptual, puede subdividirseen dos etapas claramente diferenciadas:

4.1. Análisis de requisitos

Esta primera etapa, en general común para datos y procesos, es la etapa depercepción, identificación y descripción de los fenómenos del mundo real a analizar. En elanálisis de requisitos se ha de responder a la pregunta: “¿Qué representar?”.

Mediante el estudio de las reglas de una empresa (que proveen el marco para elanálisis del sistema) y de entrevistas a los usuarios de los diferentes niveles de laorganización (que proveen los detalles sobre los datos) se llega a elaborar un esquemadescriptivo de la realidad. Aunque son varias las propuestas existentes respecto a la formade expresar el esquema descriptivo, en general se utiliza el lenguaje natural para recogeresta primera información.

Uno de los problemas más importantes con los que nos enfrentamos en esta etapa esla dificultad de comunicación entre los usuarios y los analistas. Los problemas quepresenta esta primera especificación se irán solucionando a lo largo del resto de las etapasde diseño de modo que este primer esquema percibido se irá refinando hasta llegar a unesquema más correcto: el esquema conceptual.

4.2. Etapa de conceptualización

En la etapa de conceptualizción se transforma este primer esquema descriptivo,refinándolo y estructurándolo adecuadamente. Esta etapa responde a la pregunta:“¿Cómo representar?”. En la Figura 4.1 se recoge el proceso de modelado conceptual,distinguiéndose las dos etapas, así como los distintos procesos que hay que realizar parapasar del mundo real al esquema descriptivo, y de éste al esquema conceptual.

Modelo Conceptual

20

ESQUEMADESCRIPTIVO

ESQUEMACONCEPTUAL

MUNDOREAL

PERCEPCIONPERCEPCION

ANALISISANALISIS

DESCRIPCIONDESCRIPCION

TRANSFORMACIONTRANSFORMACION

REFINAMIENTOREFINAMIENTO

PROBLEMA ARESOLVER

¿Qué representar?

¿Cómo representar?

ETAPA:

ANALISIS DE LOSREQUISITOS

(DESCRIPCION DELMUNDO REAL)

CONCEPTUALIZACION(REPRESENTACION

NORMALIZADA DELESQUEMA DESCRIPTIVO)

Figura 4.1. Proceso de modelización conceptual

En esta etapa de conceptualización se habrá de buscar una representación normalizadaque se apoye en un modelo de datos que cumpla determinadas propiedades, a saber:coherencia, plenitud, no redundancia, simplicidad, fidelidad, etc., para llegar así aldenominado esquema conceptual. Un modelo de datos que cumple tales requisitos es elmodelo E/R. Una característica importante del esquema conceptual es que no debedescribir los aspectos ligados a la implementación, sino que debe permitir ver lainformación con todo su contenido semántico.

En el proceso de modelado conceptual se parte del análisis del universo del discurso (loque también podría denominarse realidad empresarial), analizando los listados, pantallas,normativas, etc. y realizando un conjunto de entrevistas a varios niveles de la empresa.Posteriormente se elabora un esquema percibido, expresado en lenguaje natural, que nosfacilita la obtención del esquema conceptual, esto es, delimita qué entidades, atributos,interrelaciones y restricciones semánticas vamos a considerar. Este proceso se realiza deforma iterativa hasta que se introducen y clasifican todos los objetos del universo deldiscurso de forma satisfactoria.

Modelo Conceptual

21

4.3. Paso del Esquema Percibido al Esquema Conceptual

Como hemos señalado, de la primera subfase de la etapa de modelado conceptual seobtiene un esquema percibido en lenguaje natural que representa los requisitos delsistema a diseñar. Posteriormente, este esquema se irá refinando sucesivamente ynormalizando hasta obtener un esquema en el modelo E/R. Será preciso, por tanto,interpretar las frases del lenguaje natural en el que está descrito el esquema percibido,convirtiéndolas en elementos del modelo E/R (entidades, atributos e interrelaciones).

Si bien no existen reglas deterministas que nos digan qué elemento va a ser unaentidad o cuál otro una interrelación, sí podemos enunciar unos principios generales que,junto al buen criterio del diseñador, puedan ayudarnos a elaborar un primer esquemaconceptual, que será sometido después a un proceso de refinamientos sucesivos.

En el enfoque lingüístico Chen, se proponen un conjunto de heurísticas que tienen encuenta tanto la estructura de las oraciones como los atributos gramaticales de laspalabras. El objetivo de estas recomendaciones es depender menos de la intuición de losdiseñadores y más de métodos estructurados. Chen presenta 11 heurísticas (no reglas, yaque para cada una de ellas se pueden encontrar contra ejemplos). Destacamos las másrelavantes:

Un substantivo (nombre común) que actúa como sujeto o complemento directo enuna frase es, en general, una entidad, aunque podría ser un atributo. Por ejemplo,en la frase “Los departamentos solicitan empleados”, existen dos posiblesentidades: DEPARTAMENTO (substantivo que actúa como sujeto) y EMPLEADO(que actúa como complemento directo).

Los nombres propios nos suelen indicar ejemplares de una entidad; por ejemplo,“Vela, B.” indica un ejemplar de EMPLEADO.

Un verbo transitivo o una frase verbal es una interrelación; por ejemplo, en lafrase anterior “solicitar” indica una interrelación entre las dos entidades,DEPARTAMENTO y EMPLEADO.

Una preposición o frase preposicional entre dos nombres suele ser unainterrelación, o también puede establecer la asociación entre una entidad y susatributos. Por ejemplo, al decir, “el área del departamento”, podemos estarindicando la interrelación entre las entidades DEPARTAMENTO y AREA, o bienpodemos estar asociando el atributo área a la entidad DEPARTAMENTO.

Modelo Conceptual

22

El estudio de las frases que definen los requisitos del sistema permite ir clasificando losdistintos objetos. Existen dos verbos, muy comunes en la especificación de los requisitos,que presentan un especial interés: ser y tener.

1) “ES UN” nos permite, como ya hemos visto, crear jerarquías de entidades, ya quecorresponde al concepto de generalización. Por ejemplo, dada la frase: “...tanto unanalista como un programador son empleados...”, podemos establecer unageneralización como la que representamos en la figura 3.13.

2) “TIENE” es un verbo sobreutilizado en castellano ya que posee múltiplesinterpretaciones. Según la acepción del verbo en la correspondiente frase, puedecorresponder a:

a) Una interrelación general entre entidades: en cuyo caso el verbo se utilizacomo otro cualquiera, sin una acepción específica; por ejemplo, “...losempleados tiene un jefe...”, indica una interrelación entre las entidadesEMPLEADO y JEFE. En esta frase, tener actúa de forma totalmente análogaa cualquier verbo transitivo, y podría ser sustituido, por ejemplo, porasignar.

b) Una asociación de las entidades con sus atributos; por ejemplo, si decimosque “...los empleados tienen nombre y apellidos, un DNI, una dirección y unteléfono...”, estamos asociando a la entidad EMPLEADO una serie deatributos: nombre, apellidos, DNI, dirección, teléfono.

Existen otros aspectos a tener en cuenta, entre los que cabe destacar que, del númerode las entidades (singular/plural) puede deducirse ciertos tipos, cardinalidades y grados delas interrelaciones; así, si decimos “...un empleado participa en uno o varios proyectos... y...en un proyecto participan varios empleados...” podemos deducir que la interrelación esde tipo N:M, y de grado 2.

Dijimos al comienzo de este apartado lo difícil que puede resultar la categorización delos objetos del universo del discurso. Hemos visto, sin embargo, unos principios generalesque pueden servirnos como guía en este proceso, aunque siguen subsistiendo problemasy ambigüedades, como la distinción entre atributo y entidad, que no siempre resulta claradel análisis lexicográfico del esquema percibido. A continuación resumimos algunasconsideraciones que nos pueden ayudar a decidir si un determinado objeto de datos debeser representado como un atributo, o como entidad interrelacionada con la entidad de laque se supone que podría ser atributo.

Modelo Conceptual

23

Es preferible considerar el objeto de datos como entidad, en lugar de como atributo, enlos siguientes casos:

Si el objeto de datos tiene asociados otros atributos. Por ejemplo, si las áreas deun departamento (que considerábamos un atributo de DEPARTAMENTO) tiene asu vez otros atributos, como responsable de área, tareas asignadas al área, fechade creación, etc.), conviene crear la entidad AREA.

Si el objeto de datos estuviese relacionado con otras entidades. Por ejemplo, si elárea la hubiéramos considerado como un atributo de DEPARTAMENTO, nopodríamos reflejar las posibles interrelaciones existentes entre las áreas y losempleados (por ejemplo, no se podría especificar que empleados pertenecen a unárea concreta).

Un mismo atributo no puede aparecer en distintas entidades de datos y si estoocurriera debemos plantearnos la existencia de una interrelación no identificada entredichas entidades.

Estas reglas que acabamos de exponer pueden servirnos de ayuda en el paso delesquema percibido al conceptual. Sin embargo, no se debe olvidar que se trata de unproceso iterativo, y que sólo mediante refinamientos sucesivos, a lo que nos ayudará lacrítica constructiva de los usuarios, podremos llegar a un esquema conceptual que reflejelo más fielmente posible la estructura de la información de la empresa u organización.

Modelo Conceptual

24

5. Ejercicios de Autocomprobación

5.1. Enunciados

1. ¿En que etapa del proceso de desarrollo se encuentra el modelado conceptual dedatos?

2. ¿Qué es el universo del discurso?

3. Explique con sus palabras el concepto de modelo de datos, dentro del contexto delmodelado conceptual de datos.

4. ¿Qué entendemos por esquema conceptual de datos?

5. Brevemente, explique cuales son los objetivos del modelado conceptual de datos.

6. Describa las características deseables para un modelo conceptual de datos.

7. Enumere los elementos básicos del modelo E/R.

8. ¿Qué es un atributo identificador principal (AIP)?. Cite un ejemplo.

9. Defina los conceptos de entidad regular y entidad débil.

10. ¿Qué etapas pueden distinguirse en el modelado conceptual de datos? Describabrevemente en qué consiste cada una de ellas.

Supuestos

Para cada uno de los siguientes supuestos, se pide realizar el modelado conceptual dedatos utilizando el modelo E/R extendido. Suponemos que las entrevistas con los usuariosya han sido realizadas y por tanto estamos ya en la etapa de conceptualización. De laetapa de análisis de requisitos se han obtenido las siguientes especificaciones de usuario:

S1. Basándose en el ejemplo de la figura 3.16, represente, en el modelo E/R, elesquema resultante de aplicar las siguientes especificaciones de usuario:

Un empleado puede ser, bien analista bien programador, pero nunca ambascosas a la vez.

Todo proyecto tiene un único jefe, que deberá ser analista, y uno o variosprogramadores asignados.

Un analista puede ser jefe de un solo proyecto. Un programador puedeparticipar en varios proyectos simultáneamente.

Modelo Conceptual

25

S2. La empresa de formación X, desea llevar un control informatizado de los cursos queimparte así como de lo profesores que participan en dichos cursos. Para ello, nos handado las siguientes especificaciones:

Cada curso, del que se desea conocer el título, el número de horas y el tema olos temas que trata, se identifica por un código de cuso.

Cada curso puede tener una serie de cursos cuyo realización previa esobligatoria (prerrequisito) o recomendada.

Cada curso se puede impartir una o varias veces, en diferentes fechas y en cadaedición del mismo pueden participar diferentes empleados.

Los empleados, de los que se desea conocer su código de empleado, nombre,DNI y fecha de antiguedad en la empresa, pueden impartir y recibir cursos perocon la restricción de que en una mismo edición de un curso no puedenparticipar como profesores y como alumnos.

S3. La cadena de Video-Clubs Glob-Gusters ha decidido, para mejorar su servicio,emplear una base de datos para almacenar la información referente a las películas queofrece en alquiler. Esta información es la siguiente:

Una película se caracteriza por su título, nacionalidad, productora y fecha (p.e.,“Quo Vadis”, “Estados Unidos”, “M.G.M.”, 1955).

En una película pueden participar varios actores (nombre, nacionalidad, sexo)algunos de ellos como actores principales.

Una película está dirigida por un director (nombre, nacionalidad).

De cada película se dispone de uno o varios ejemplares diferenciados por unnúmero de ejemplar y caracterizados por su estado de conservación.

Un ejemplar se puede encontrar alquilado a algún cliente (nombre, dirección,teléfono). Se desea almacenar la fecha de comienzo del alquiler y la dedevolución.

Cada socio puede alquilar como máximo 4 ejemplares.

Un socio tiene que ser avalado por otro socio, que responda de él en caso detener problemas en el alquiler.

S4. La empresa Personal Quality desea incorporar en su política de contratacióncriterios de calidad del personal basados en la medición de sus habilidades ocompetencias personales.

Modelo Conceptual

26

La empresa desea medir las competencias intelectuales de todos susempleados y además desea conocer las competencias emocionales de susdirectivos (por ejemplo, la capacidad de trabajo en grupo, la motivación,capacidad de liderazgo, etc.). De todas ellas se desea conocer: su código deidentificación, su nombre y su descripción. Además, para cada competenciaemocional se desea conocer, lo que se ha denominado el umbral; es decir, elvalor mínimo de cada competencia por debajo del cual ningún empleado podráser directivo.

Para llevar a cabo este estudio, Personal Quality ha contactado con elEmotional Skill Center quien le ha proporcionado una batería de Test. Cadacompetencia está asociada a un conjunto de test que permiten medirla. Un testpuede medir una única competencia. Cada Test se identifica por un nombre ydebe tener asociado un conjunto de preguntas, una plantilla para su correcciónasí como el modo en que se deberán interpretar los resultados.

Cada empleado se identifica por un código interno. Además se quiere conocerel nombre, la dirección y un teléfono de contacto de cada empleado.

Modelo Conceptual

27

6. Bibliografía

6.1. Bibliografía Básica

Piattini, M., Marcos, E., Calero, C., Vela. B. Tecnología y Diseño de Bases de Datos. Ed.Ra-ma, Madrid 2006.

Es el libro en el que nos hemos basado para la elaboración de esta documentación, porlo que es un excelente complemento de la misma. Presenta, de un modo claro ypreciso, el modelo E/R así como las diferentes aproximaciones al modelado conceptualde datos. Contiene además una colección de ejercicios de modelado conceptual,algunos de ellos con soluciones, por lo que es también recomendable para aquellosalumnos que deseen practicar más.

6.2. Bibliografía Recomendada

Batini, C., Ceri, S., Navathe, S. Diseño Conceptual de Bases de Datos. Un enfoque deentidades-interrelaciones. Addison Wesley Iberoamericana, 1994.

Aunque no se trata de un libro reciente (la versión original es de 1992), es uno de losprimeros libros en abordar el tema de diseño conceptual de datos. El enfoque deBatini, Ceri y Navathe ha sido seguido por numerosos autores, por lo que se considerauna obra básica para el modelado conceptual utilizando el modelo E/R.

Elsmari, R. y Navathe, S. B. Fundamentos de Sistemas de Bases de Datos. Addison-Wesley Iberoamericana,5ª Ed. 2007.

Se trata de un libro de referencia obligado en el tema de bases de datos. Aunque no esespecífico para diseño conceptual, también trata esta parte de un modo claro yriguroso, siguiendo el enfoque E/R. Además, es un excelente complemento para elalumno que quiera profundizar en la tecnología de BD