• Author / Uploaded
• lolo1234

Citation preview

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

TEMA 1

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1- 1

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Tema 1 Modelo Entidad/Relación

1. Modelos de datos ..................................................................................................................... 2 2. Concepto de modelo de datos.................................................................................................. 4 3. Diseño de una base de datos ................................................................................................... 5 4. Modelo entidad/relación ........................................................................................................... 6 4.1 Estática del modelo E/R...................................................................................................... 6 4.1.1 Entidades ..................................................................................................................... 6 4.2 Relaciones....................................................................................................................... 8 4.3 Dominio ........................................................................................................................... 9 4.4 Atributos .......................................................................................................................... 9 5. Semántica de las relaciones en el modelo E/R ...................................................................... 10 5.1 Tipo de correspondencia................................................................................................... 11 5.2 Papel o rol ......................................................................................................................... 12 5.3 Cardinalidad de una entidad ............................................................................................. 12 5.4 Ejemplo de cardinalidades ............................................................................................ 13 6. Extensiones al modelo E/R..................................................................................................... 14 6.1 Dependencia en identificación .......................................................................................... 14 6.2 Jerarquía subconjunto....................................................................................................... 14 6.3 Generalización .................................................................................................................. 15 7. La fecha en el modelo de datos.............................................................................................. 16 7.2 Fecha en entidades........................................................................................................... 16 7.3 Fecha en relaciones ...................................................................................................... 17 8. Obtención del modelo relacional a partir del modelo E/R....................................................... 18 8.1 Reglas para la transformación del modelo E/R básico ..................................................... 18 8.2 Reglas para la transformación de las extensiones al modelo básico ............................... 22 Ejemplo práctico ......................................................................................................................... 23

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 1

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Tema 1 Modelo Entidad/Relación

1. Modelos de datos Los modelos de datos son herramientas de abstracción que permiten representar la realidad captando las restricciones semánticas que en ella se puedan dar. En primer lugar, y antes de pasar a analizar el modelo de datos Entidad/Relación, vamos a analizar lo que se entiende por modelo de datos en profundidad y analizaremos el papel que los modelos de datos tienen en el diseño de bases de datos. Cuando en el mundo real se da información de cualquier suceso u objeto siempre los datos suministrados van acompañados de una semántica o de un significado. De la misma manera estos datos están sujetos a unas restricciones y nosotros entendemos los datos suministrados solo si entendemos el dominio y las restricciones de significados que acompañan a la información. Sin embargo, cuando aparecen los ordenadores y las bases de datos se empiezan a informatizar ocurre que se tiende a almacenar datos separando a estos de su interpretación, esto es, de su semántica. Como consecuencia fue necesaria la aparición de los modelos de datos como una herramienta que ayudara a incorporar significado a los datos almacenados. De esta manera, los modelos de datos proporcionan mecanismos de abstracción que permiten la representación de la parte del mundo real que nos interesa registrar. Esta representación se concibe en dos niveles: el de las estructuras que hacen posible al representación de la información, y el de la información en sí misma. Esto nos lleva a diferenciar entre lo que se denomina el esquema de la base de datos y la colección de datos en sí misma que es lo que denominamos base de datos. Asociados a los modelos de datos están los lenguajes de datos que son los que van a permitir definir , consultar y actualizar la base de datos. Tal y como es conocido, modelo de referencia de ANSI/Sparc define 3 niveles de abstracción: Global Externo e Interno A grandes rasgos el nivel interno es el más cercano al almacenamiento físico, está relacionado con la forma de almacenar físicamente los datos. El nivel externo es el más cercano al usuario, está relacionado con la forma de ver los datos cada usuario de la base de datos, y por último, el nivel global es un nivel de indirección entre el nivel interno y externo, ocultando los detalles de implementación y almacenamiento al usuario. Este nivel contiene una representación del conjunto de los datos de la organización. Si el nivel externo está relacionado con los usuarios de la base de datos, cada uno de los cuales puede tener una visión diferente de la base de datos, el nivel conceptual tiene que ver con una visión completa de la base de datos abstrayendo la implementación de la misma y todos los aspectos relacionados con la máquina en la que está ejecutando el SGBD.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 2

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

Usuario A1

Gerencia de Informática Subdirección General de Informática

Usuario A2

Lenguaje máquina + DSL

Esquema externo A

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Lenguaje máquina + DSL

Usuario B1

Lenguaje máquina + DSL

Esquema externo B

Vista externa A

Mapping A conceptual/externo

Esquema conceptual

Usuario B2

Usuario B3

Lenguaje máquina + DSL

Lenguaje máquina + DSL

Vista externa B

...

...

Mapping B conceptual/externo

Vista conceptual

DBA

Sistema gestor de base de datos (SGBD)

Mapping conceptual/interno

Definición de la estructura de almacenamiento (Esquema interno)

Vista interna

En la figura se muestra con más detalle la arquitectura ANSI/SPARC de tres niveles Como consecuencia de esta arquitectura existen en una base de datos 3 clases de esquemas: el esquema global, los esquemas externos (uno por aplicación) y el esquema interno que aunque en un momento determinado es único, un mismo esquema global puede admitir distintos esquemas internos. De entre todos estos tipos de modelos, los que a continuación se van a describir son los modelos globales puesto que el modelo Entidad/Relación pertenece a este tipo de modelos. Dentro de los modelos globales a su vez podemos hacer otra distinción entre los que se denominan: Modelos conceptuales: son los modelos que facilitan la descripción global del conjunto de información al nivel más próximo al usuario. El modelo E/R es un modelo conceptual Los modelos convencionales que se encuentran soportados por los sistemas de gestión de bases de datos por lo que también se les denomina modelos lógicos o modelos de bases de datos. El modelo relacional es un modelo lógico.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 3

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

2. Concepto de modelo de datos Aunque como se ha visto, existen muchos modelos de datos, se puede extraer una serie de características de todos ellos y se puede dar la siguiente definición de modelo de datos [2]: Un modelo de datos es un conjunto de conceptos, reglas y convenciones bien definidos que permiten aplicar una serie de abstracciones a fin de describir y manipular los datos de un cierto mundo real que se desean almacenar en la base de datos. Los modelos de datos permiten crear categorías mediante la aplicación de los tipos de abstracción, lo que lleva a diferenciar dos tipos de modelos, al estilo de los lenguajes de programación: Modelos de datos fuertemente tipados Cada dato debe pertenecer a una categoría previamente definida en el esquema del modelo. Modelos de datos débilmente tipados No es obligatorio que los datos pertenezcan a una categoría determinada, pudiendo existir por si mismos. En este caso puede haber categorías, pero en caso de existir se tratan como datos individuales. En el mundo de bases de datos se utilizan modelos fuertemente tipados, también conocidos como modelos estrictamente tipados, puesto que a pesar de sus inconvenientes (falta de flexibilidad) tienen como ventaja que permiten el tratamiento de grandes volúmenes de datos al agruparlos en categorías o tipos. Un modelo de datos define las reglas mediante las cuales se han de estructurar los datos del mundo real. La representación de un mundo real mediante un determinado modelo da lugar a un esquema, el cual describe las categorías existentes. Sin embargo, la realidad contempla además de los aspectos estáticos, los aspectos dinámicos. Por tanto las propiedades del mundo real son de dos tipos: Estáticas Relativamente invariantes en el tiempo, que es lo que se suele conocer como estructuras. Este tipo de propiedades está compuesto por: Elementos permitidos como: los objetos (entidades, relaciones, registros, …), asociaciones entre objetos, propiedades o características de los objetos y asociaciones (atributos, elementos de datos, …), dominios, que son conjuntos de valores que pueden tomar las propiedades. Elementos no permitidos o restricciones, puesto que no todos los valores, cambios de valor o estructuras están permitidos en el mundo real. Además cada modelo tiene por sí mismo limitaciones en cuanto a las estructuras que permite: Las restricciones impuestas por el modelo se conocen como restricciones inherentes, y las restricciones que permiten captura la semántica del universo de discurso que se quiere modelar y verificar la corrección de los datos

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 4

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

almacenados en la base de datos. Estas últimas restricciones se conocen como restricciones de integridad o semánticas. Las restricciones de integridad son impuestas por el usuario, mientras que las restricciones inherentes al modelo son impuestas directamente por el modelo. Dinámicas Son las operaciones que se aplican a los datos o valores almacenados en las estructuras, los cuales varían a lo largo del tiempo al aplicarles dichas operaciones. La aplicación de cualquier operación sobre los valores de la base de datos debe dejar la base de datos en un estado válido, es decir los valores de los elementos deben pertenecer a alguna de las categorías definidas en el esquema y deben cumplir las restricciones de integridad. La componente estática de un modelo de datos se define a través del lenguaje de definición de datos (DDL) y la componente estática se define a través del lenguaje de manipulación de datos (DML), constituyendo ambas componentes el lenguaje de datos.

3. Diseño de una base de datos Se conoce como diseño de una base de datos al conjunto de pasos que son necesario realizar para pasar del mundo acerca del cual se quiere guardar información a la base de datos que lo representa. En este proceso son los modelos de datos los que juegan el papel más importante por suministrar las herramientas de abstracción necesarias. Los objetivos que se consiguen con los modelos de datos son: Por una parte, permite formalizar las estructuras permitidas y las restricciones Por otra parte, establece la metodología de diseño de bases de datos Los pasos, por tanto, que se aconsejan en el diseño de toda base de datos son los siguientes: 1. Definición del universo de discurso o parcela del mundo real que se quiere diseñar. De esta manera, por ejemplo, en un hospital se pueden definir distintos universos de discurso, como puede ser el universo concerniente a ingresos hospitalarios, otro diferente para la gestión del personal y podríamos distinguir otro universo diferente para por ejemplo la gestión de recursos del hospital. De esta manera podemos ver que el mundo real es solo uno pero hay que distinguir en cada caso cual es la parte de ese mundo real que queremos conceptuar 2. Una vez definido el universo de discurso, se procede a la estructuración y dentro de esta fase la primera parte es la definición del esquema conceptual de datos. Mientras se realiza el modelado conceptual se intenta describir el mundo real de acuerdo a un modelo conceptual que en nuestro caso será el modelo E/R. Se tratará en esta fase de capturar toda la semántica del mundo real que sea posible y hacer que el esquema resultante sea independiente del sistema de gestión de bases de datos que se utilice con posterioridad para la implementación de la base de datos. 3. Una vez realizado el esquema conceptual se pasará a su transformación a modelo convencional o lógico. En la metodología de diseño que aquí proponemos, el modelo lógico elegido es el modelo relacional por lo que se analizarán las reglas de transformación de modelo E/R en modelo relacional. 4. Se terminará el diseño con el esquema interno y, por último, la implementación de la base de datos física.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 5

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

4. Modelo entidad/relación Los modelos de datos convencionales como el modelo relacional, no ofrecen la suficiente capacidad de abstracción ni el poder expresivo para poder captar la semántica del mundo real. Esto dificulta en gran medida la comunicación del diseñador con el usuario. Como consecuencia, con posterioridad a la aparición del modelo relacional, surgen todas una serie de modelos para tratar de paliar las carencias del primero. De esta manera, en 1976 Chen propone el Modelo Entidad/Relación. Según el propio autor del modelo, “el modelo E/R puede ser usado como una base para una vista unificada de los datos, adoptando el enfoque más natural del mundo real que consiste en entidades y relaciones”. El modelo E/R permite al diseñador concebir la base de datos a un nivel superior (conceptual) de abstracción, aislándolo de consideraciones relativas a la máquina. El modelo, como su nombre indica se apoya en dos conceptos, el concepto de entidad y el concepto de relación. Este modelo de datos permite representar casi cualquier restricción del diseño de datos. El modelo E/R percibe el mundo real como una serie de objetos relacionados entre sí y pretende representarlos gráficamente mediante un mecanismo de abstracción. Este mecanismo de abstracción está basado en una serie de símbolos, reglas y métodos que permitirán representar los datos de interés del mundo real. Desde que el modelo de datos fue propuesto, se ha extendido por toda la comunidad de diseñadores de bases de datos siendo el modelo mas utilizado en diseño de bases de datos y el modelo mas extendido entre las herramientas CASE. Tendremos que distinguir cuando analicemos el modelo las estructuras del modelo E/R básico tal y como fue propuesto por Chen y todas las extensiones que desde su proposición se han realizado para conseguir captar la mayor semántica del mundo real. Tal y como veíamos en los apartados anteriores distinguiremos entre la estática del modelo y la dinámica del mismo.

4.1 Estática del modelo E/R Chen distingue en el modelo E/R los siguientes elementos: Entidad Relación Atributo Dominio

4.1.1 Entidades Una entidad es un objeto real o abstracto de interés en una organización y acerca del cual se puede y se quiere guardar determinada información en la base de datos. Ejemplos de entidades pueden ser personas, cosas o lugares. La estructura genérica que describe un conjunto de entidades aplicando la abstracción se denomina tipo de entidad, mientras que entidad se refiere a cada una de las ocurrencias o ejemplares de ese tipo de entidad. De esta manera, Hospital es un tipo de entidad mientras que “Gregorio Marañón” es una ocurrencia o ejemplar. Para poder distinguir o encontrar entidades en un problema de la vida real conviene resaltar las propiedades que ha de cumplir la entidad:

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 6

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Debe tener existencia propia (veremos que hay un tipo de entidades que en puro rigor no cumple esta restricción como son las entidades débiles) Cada ocurrencia de un tipo de entidad tiene que poder distinguirse de los demás Todas las ocurrencias de un mismo tipo de entidad deben tener las mismas propiedades Una entidad se representa gráficamente en el modelo E/R mediante un rectángulo y en el interior del mismo se escribe el nombre de la entidad. Nombre de la entidad Figura 1: Representación gráfica de una entidad en el modelo E/R

Así pues, asociado al concepto de entidad surge el concepto de ocurrencia de entidad. Una ocurrencia de entidad es una realización concreta de una entidad. Cuando por el contexto se sobreentiende que nos estamos refiriendo a un tipo de entidad hablaremos solo de entidad. A continuación se representa la entidad hospital. Hospital

Existen dos clases de entidades: Regulares: son las que sus ejemplares tienen existencia por sí mismos Débiles en las que la existencia de un ejemplar depende de que exista un cierto ejemplar de otro tipo de entidad. Esto conlleva que la desaparición de las ocurrencias de la entidad de la cual depende su existencia lleve a la desaparición de las ocurrencias de la entidad débil que dependan de ellas. La entidades débiles se representan gráficamente por dos rectángulos concéntricos y en el interior el nombre de la entidad. Nombre de la entidad Figura 2: Representación gráfica de una entidad débil en el modelo E/R

Como ejemplo de entidad débil asumamos que estamos representado la información de un videoclub y que tenemos que guardar la información de las películas que se alquilan. En este caso claramente tendremos que distinguir entre lo que es la información de la película que existe aunque no hay copias de esa película en el videoclub y lo que es la información de los ejemplares de películas. Es obvio ahora comprobar cómo al menos tendremos que distinguir entre dos entidades: 1. Entidad regular película 2. Entidad débil ejemplar de película

Película

Ejemplar de pelicula

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 7

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

4.2 Relaciones Una relación es una asociación entre entidades y se caracteriza por tener unas determinadas restricciones que determinarán las entidades que pueden o no pueden participar de dicha relación. Nuevamente debemos distinguir entre lo que se denomina el tipo de relación que es la estructura genérica que describe el conjunto de relaciones y lo que es la relación propiamente dicha o cada una de las ocurrencias del tipo de relación. De esta manera trabaja es la relación que hay entre un médico y un hospital mientras que una ocurrencia de este tipo de relación será que Carlos Ruiz trabaja en el hospital Gregorio Marañón. Gráficamente, en el modelo E/R la relación se representa por medio de un rombo y en el interior del mismo se escribe el nombre de la relación, y unido mediante líneas a las entidades correspondientes.

Médico

Hospital

trabaja Figura 3: Ejemplo de relación binaria

Es importante resaltar que entre dos tipos de entidad puede haber más de un tipo de relación. De esta manera, en una base de datos de cidudades y personas , asumiendo que tenemos una entidad ciudad y una entidad persona, podemos establecer entre estas dos entidades una relación para almacenar las personas empadronadas en una determinada ciudad, y otra relación diferente para mantener el registro de las personas que han nacido en cada ciudad. Las relaciones se caracterizan por dos propiedades: Grado: es el número de entidades sobre las que se realiza la asociación. Es decir, es el número de entidades que participan en la relación. En el caso de la relación trabaja el grado de dicha relación es dos, puesto que participan dos entidades (médico y hospital). Un caso especial de relaciones de grado dos o binarias es el caso de las relaciones reflexivas, las cuales relaciona una entidad consigo misma. Un ejemplo de este tipo de relaciones se puede ver en la Figura 4, donde se observa la relación de dependencia (por ejemplo en una empresa) entre el personal.

persona

depende

Profesor

imparte

Curso

Tema _________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 8

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Figura 4: Ejemplo de relación reflexiva

También pueden existir relaciones que asocien más de dos relaciones, por ejemplo de grado tres, cuatro, … aunque no son habituales. Un ejemplo de relación de grado tres se puede observar en la figura , en la que se establece una relación entre los profesores, los cursos y los temas. Cardinalidad o tipo de la relación: de esta manera se analiza en el apartado de semántica de las relaciones el tipo de correspondencia que se tiene. De esta manera, se pueden tener relaciones muchos a muchos o relaciones uno a muchos.

4.3 Dominio Las distintas propiedades o características de un tipo de entidad o relación, toman valores para cada ocurrencia de las mismas. El posible conjunto de valores que puede tomar cada propiedad se denomina dominio. Con lo que se puede decir que el dominio es un conjunto de valores homogéneos con un nombre. Gráficamente se representan los dominios como un ovalo con el nombre del dominio en su interior. Es importante resaltar en este punto que los dominios tienen existencia propia y es el que realmente captura una semántica del mundo real. Lo que ha ocurrido muy a menudo es que se tiende a confundir dominio con atributo.

4.4 Atributos Cada una de las propiedades o características de un tipo de entidad o tipo de relación se denomina atributo. Los atributos toman valor en un dominio por lo que un atributo es una determinada interpretación de un dominio y varios atributos pueden tomar valores en el mismo dominio. La representación gráfica de los atributos en el modelo E/R consiste en etiquetar con el nombre del atributo la línea que una entidad con un dominio. Lo que ocurre es que como decíamos con anterioridad a menudo atributo y dominio se confunden y en cierto modo los culpables de esta no distinción son los sistemas de gestión de bases de datos en lo cuales no queda clara la definición de los dominios y más se tiende a hablar de tipos de datos de atributos que en realidad no captan la semántica subyacente al dominio. Debido a este motivo a menudo se representan en el modelo E/R solo los atributos y se hace mediante la representación de un ovalo con el nombre del atributo en su interior (tal y como habíamos especificando para los dominios) uniendo el ovalo al tipo de entidad o relación que corresponda tal atributo tal y como se muestra en la figura.

Nombre del atributo

Nombre de la entidad

Figura 5: Representación gráfica de un atributo en el modelo E/R

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 9

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

En función de las características del atributo respecto de la entidad se distinguen dos tipos de atributos: Atributo identificador o clave: distingue de manera única una ocurrencia de entidad del resto de ocurrencias de entidad. Normalmente, el atributo identificador es único, pero puede haber caso en los que haya varios atributos identificadores, incluso se puede dar el caso de que no exista un atributo identificador dentro de la entidad. Los atributos identificadores se distinguen del resto en los diagramas E/R porque su nombre aparece subrayado. Atributo descriptor: caracteriza una ocurrencia de entidad pero no la distingue del resto de ocurrencias de entidad. Una relación puede tener atributos al igual que las entidades. Un ejemplo de atributos en una relación se puede ver en la Figura 6, donde se representa que un cliente puede comprar el mismo producto varias veces, pero se distinguirá cada compra del mismo producto mediante la fecha en la cual se realiza la compra del mismo.

Cliente

compra

precio

Producto Figura 6: Ejemplo de atributos en las relaciones

5. Semántica de las relaciones en el modelo E/R Decíamos que el interés de los modelos de datos es captar tanta semántica como sea posible del mundo real. Con lo que hemos visto hasta el momento comprobamos que se permite establecen cualquier número de relaciones diferentes entre tipos de entidad pero no podemos establecer restricciones del tipo: Un médico solo trabaja en un hospital La base de datos solo almacenará información de individuos censados En un hospital trabajan n médicos Todos los socios del videoclub han alquilado al menos una película .... A continuación se analiza en detalle todos los aspectos de las relaciones que nos permitirán captar toda la semántica deseada.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 10

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

5.1 Tipo de correspondencia Se denomina tipo de correspondencia al tipo de asociación que se establece entre las entidades relacionadas. Concretamente, se puede definir el tipo de correspondencia como el número máximo de ocurrencias de una entidad asociada a una ocurrencia de otra o de la misma entidad a través de una relación. Para una relación binaria, es decir, de grado dos, entre las entidades X e Y, existen tres tipos posibles de correspondencias: Correspondencia 1:1 Una ocurrencia de la entidad X se asocia como máximo con una ocurrencia de la entidad Y y viceversa, como se puede observar en la

x1

y1

x2

y2

...

...

xn

yn

Entidad X

Entidad Y

Figura 7: Ejemplo de correspondencia 1:1

Un ejemplo de este tipo de correspondencia puede ser que un cliente tiene una única cuenta bancaria en una sucursal determinada y una cuenta determinada de una sucursal pertenece a un único cliente. •

Correspondencia 1:N Una ocurrencia de la entidad X se asocia con un número indeterminado de ocurrencias de la entidad Y, pero una ocurrencia de la entidad Y se asocia como máximo con una ocurrencia de la entidad X. Si fuera al revés la correspondencia sería N:1.

x1 x2 ... xn Entidad X

y1 y2 y3 ... yn Entidad Y

Figura 8: Ejemplo de correspondencia 1:N

Un ejemplo de este tipo de correspondencia puede ser que una persona vive en una ciudad y en una ciudad viven muchas personas-.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 11

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

•

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Correspondencia N:M Una ocurrencia de la entidad X se asocia con un número indeterminado de ocurrencias de la entidad Y y viceversa. Un ejemplo de este tipo de cardinalidad puede ser que un proveedor suministra varios productos y cada producto puede ser suministrado por varios proveedores.

x1

y1

x2

y2

...

...

xn

yn

Entidad X

Entidad Y

Persona

padre

hijo

Figura 9: Ejemplo de correspondencia N:M

5.2 Papel o rol Es la función que cada una de las entidades realiza en la relación. Gráficamente se representa indicando el nombre del rol en la línea que une las entidades con las relaciones como se muestra en la Figura. Los roles juegan un papel especialmente importante en relaciones reflexivas donde es necesario conocer los dos roles que el mismo tipo de entidad juega en una determinada relación.

5.3 Cardinalidad de una entidad Se define como el número máximo y mínimo de ocurrencias de una entidad que pueden estar relacionadas con ocurrencias de otra entidad. Se representa gráficamente mediante una etiqueta del tipo (0, 1), (1, 1), (0, N) ó (N, M), según corresponda, al lado de las entidades asociadas por la relación tal como se puede observar en la , donde el primer elemento de la tupla es la cardinalidad mínima, y el segundo elemento de la tupla es la cardinalidad máxima, que coincide con el tipo de correspondencia.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 12

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

La cardinalidad mínima permite establecer si todas las ocurrencias de una entidad participan o no en la relación establecida con otra entidad.

Autor

(0, 1)

escribe

(0, n)

Libro

1:N

Si toda ocurrencia de una entidad X debe estar asociada con al menos una ocurrencia de la entidad Y con la que tiene establecida una relación, la cardinalidad mínima es 1, pero si no tiene porque estar asociada con alguna ocurrencia de la entidad Y, la cardinalidad mínima es 0. Las etiquetas de las cardinalidades, según la notación propuesta por Chen, están intercambiadas, es decir la cardinalidad de una entidad aparece al lado de la otra entidad participante en la relación. Por ejemplo en la cardinalidad que aparece al lado de libro es la correspondiente a la entidad autor y la que aparece al lado de la entidad autor es la correspondiente a la entidad libro. Así la forma de leer la figura es la siguiente: un autor escribe o ninguno o muchos libros y un libro puede se escrito por ningún autor (anónimo) o por un único autor.

5.4 Ejemplo de cardinalidades En este apartado se va a detallar el diseño completo del diagrama E/R para un ejemplo muy sencillo, como puede ser una base de datos para almacenar los productos que suministra un determinado proveedor y en que cantidad y fecha los suministra.

Id_prov

Id_prod

direccion Proveedor

(1, N)

suministra

(0, N)

Producto

color

N:M

telefono cantidad

fecha

tamaño

nombre Figura 10: Ejemplo completo de un diagrama E/R

En la Figura 10 se puede observar como hay dos entidades proveedor y producto con sus atributos y claves correspondientes y una relación entre ambas suministra. El tipo de correspondencia de la relación es N:M y la relación tiene dos atributos que son cantidad de producto suministrado y fecha en la que se suministra el producto. Recordar que la cardinalidad correspondiente a la entidad proveedor es la que aparece al lado de la entidad producto (1, N), lo que quiere decir que todos los productos que aparezcan en la

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 13

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

tabla producto se relacionaran al menos con una ocurrencia de la entidad proveedor, y la cardinalidad de la entidad producto es la que aparece al lado de la entidad proveedor (0, N), lo que quiere decir que pueden existir ocurrencias de entidad de la entidad proveedor que no se relacionen con ninguna ocurrencia de entidad de la entidad producto.

6. Extensiones al modelo E/R Posteriormente a la aparición del modelo E/R se propusieron nuevas formas de notación adicionales al modelo E/R para poder capturar más semántica en los diagramas E/R. Las principales extensiones al modelo E/R fueron la dependencia en identificación, la jerarquía de subconjunto y la generalización o jerarquía de generalización.

6.1 Dependencia en identificación Surge este concepto porque hay veces que tenemos una entidad que no tiene el atributo adecuado para ser identificador principal. Entonces se tiene una entidad débil. Estas entidades únicamente tienen una atributo discriminador, que las diferencia del resto, y por tanto necesitan una clave, que provendrá de una entidad regular, con clave primaria. En este caso la clave principal se forma con la clave de la entidad fuerte más el atributo discriminador de la entidad débil. La representación gráfica de la dependencia en identificación se realiza mediante una línea en el rombo de la relación y una I para indicar que es en identificación. La entidad débil se representa mediante un rectángulo con doble línea, y el atributo discriminador se marca de alguna manera, en este caso, mediante un asterisco. En la figura se ve un ejemplo de dependencia en identificación, donde la entidad facturas no tiene un identificador claro, únicamente tiene un atributo discriminador, que es el número de factura. Está entidad depende de la entidad clientes, puesto que sino existe un cliente, tampoco existirá una factura.

Id_cli

nombre

Clientes

n_fact *

(1, 1)

I

tiene

(0, N)

Facturas

importe

1:N direccion

descuento

6.2 Jerarquía subconjunto El concepto de especialización establece que una entidad X es un subconjunto de otra entidad Y cuando toda ocurrencia de la primera es también una ocurrencia de la segunda, y lo contrario no tiene porque ser cierto.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 14

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Por tanto, se tiene una jerarquía subconjunto cuando cada ocurrencia de una entidad genérica pueda ser también una ocurrencia de otras entidades que potencialmente son subconjuntos no disjuntos. Es decir, en las entidades subconjunto pueden aparecer ocurrencias repetidas. Por ejemplo en la Figura 12 se aprecia una jerarquía subconjunto, donde la entidad genérica es profesor y las entidad subconjunto son profesores, alumnos y personal docente, pudiendo existir elementos repetidos en las entidades subconjunto, por ejemplo, puede haber personal docente que sea alumno. La entidad subconjunto puede tener atributos, además de tener los atributos de la entidad genérica, pero siempre las entidades subconjunto se encuentran identificadas por la clave de la entidad genérica. Además todos los atributos comunes de las entidades subconjunto deberían aparecer en la entidad genérica para evitar repetir los atributos en cada una de las entidades subconjunto. La forma de representar gráficamente la jerarquía subconjunto se puede ver en la Figura 11, y es un triangulo invertido, con la punta hacia las entidades subconjunto, y se conectan al triangulo invertido todas las entidades subconjunto así como la entidad genérica.

Apellidos Nombre

DNI

Personas

Profesores

Alumnos

Pesonal docente

Puesto

Año_mat

Figura 11: Ejemplo de jerarquía subconjunto

6.3 Generalización El concepto de jerarquía de generalización o generalización establece que una entidad genérica X es una generalización de otras entidades especializadas si cada ocurrencia de la primera es una ocurrencia y solamente una de las otras entidades. A veces este concepto se conoce también como jerarquía de especialización. Se tendrá una jerarquía de generalización cuando la entidad genérica se divida en una serie de entidades en función del valor que tome un determinado atributo de la entidad genérica. Como en el caso de las jerarquías subconjunto, las entidades especializadas pueden atributos propios además de los atributos de la entidad genérica.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 15

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

A diferencia con la jerarquía subconjunto, en la jerarquía generalización, en las entidades especializadas no puede haber elementos repetidos. La representación gráfica de la jerarquía de generalización se puede observar el la figura en la que se representa al igual que la jerarquía subconjunto pero con un arco para indicar que las entidades especializadas son disjuntas. Además unido al triangulo de la jerarquía, se indica el atributo diferenciador de cada una de las entidades de la jerarquía. En la siguiente figura se puede observar un ejemplo de este tipo de jerarquías de generalización, donde se tiene la entidad genérica automóviles con sus atributos, más el atributo diferenciador, que son comunes a todas las entidades especializadas motos, coches y autobuses que tienen sus atributos propios, aunque pueden no tenerlos. En este caso no puede haber ocurrencias de una entidad especializada que aparezcan como ocurrencias de otra de las entidades especializadas como ocurría con las jerarquías subconjunto.

Marca Modelo

Matricula

Automoviles

tipo

cilindrada

Motos

Coches

Autobuses

Nº asientos

color

7. La fecha en el modelo de datos El tratamiento de la fecha en las bases de datos es un tema complejo que requiere gran atención si se quiere modelar bien.

7.2 Fecha en entidades Almacenar fechas en las entidades generalmente no es un problema pues simplemente se almacena esta como un atributo más de la entidad. El primer problema aparece cuando sea necesario almacenar la evolución de una entidad a lo largo del tiempo. Si en esta evolución simplemente se tienen ciertos estados por los que puede pasar cada ocurrencia de la entidad, entonces bastará con añadir un atributo estado a la entidad. Una situación mas compleja es la que requiere almacenar no sólo estos posibles estados sino las fechas y posiblemente otras características asociadas al estado. En este último caso, la _________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 16

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

solución más aconsejable pasa por modelar una nueva entidad estado que tenga como atributos un identificador de estados así como tantos atributos como sea necesario almacenar de cada estado.

7.3 Fecha en relaciones Un caso diferente lo tenemos cuando lo que tenemos que almacenar es la fecha en la que ocurre un hecho, cosa que generalmente estará modelizada en la relación. En este caso tenemos que distinguir entre si será necesario almacenar un histórico o no. En el caso en el que sólo se quiere guardar la fecha en la que un evento ocurre pero no se quiere histórico. Es decir, tan sólo interesa el momento actual, entonces bastará con agregar un atributo fecha a la relación. Si ocurre que es necesario almacenar la fecha de comienzo y la de finalización del evento entonces se almacenarán dos atributos cada uno para reflejar la respectiva situación. Ahora bien, a menudo es necesario no solo almacenar el momento sino almacenar un histórico del evento en cuestión. En esta situación hay que realizarse solo una pregunta. Si las ocurrencias de las entidades que participan en la relación no pueden relacionarse en momentos diferentes entonces un atributo fecha en la relación soluciona el problema. Sin embargo, si ocurre que las mismas ocurrencias pueden relacionarse en momentos de tiempo diferenciados y esto es necesario reflejarlo en la base de datos entonces téngase en cuenta que la fecha es atributo que diferencia cada posible relación de estas entidades. Por ejemplo, piénsese en la situación del préstamo bibliotecario en el que hubieramos modelizado las entidades libro, bibliotecario y usuario y el préstamo como la relación entre ellos. En este caso claramente el mismo bibliotecario puede prestar el mismo libro al mismo usuario en fechas diferentes. De este modo si quisiéramos guardar el histórico del préstamo, con un atributo en la relación no quedaría solventado pues cada vez que el mismo usuario sacase el mismo libro y se lo prestara el mismo bibliotecario, estaríamos perdiendo la última vez que ese evento ocurrió. En estos casos ocurre que sería necesario que la fecha fuera atributo identificador en la relación con lo cual el problema estaría solventado y todas las ocurrencias se podrían almacenar en la base de datos sin ningún problema.

usuario

libro bibliotecario

presta

fecha

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 17

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

8. Obtención del modelo relacional a partir del modelo E/R 8.1 Reglas para la transformación del modelo E/R básico Una de las ventajas que ofrece el modelo relacional, es que a partir de un diseño conceptual como es el modelo E/R se puede obtener un diseño relacional casi automáticamente, y a partir de ahí su implementación en un sistema gestor de bases de datos es casi inmediato. El obtener el modelo relacional a partir del modelo E/R se conoce como paso a tablas. Las reglas para realizar el paso a tablas de un modelo E/R son las siguientes: •

Entidades: Toda entidad que aparece en un modelo E/R genera una tabla cuyo nombre es el nombre de la entidad, y tiene como atributos los atributos pertenecientes a la entidad a partir de la cual se genera dicha tabla. Además, la clave de la entidad en el modelo E/R también es clave en la tabla del modelo relacional. Si se toma por ejemplo el modelo E/R que aparece en la Figura 10, se generaran dos tablas correspondientes a las entidades proveedor y producto de la siguiente manera. PROVEEDOR(Id_prov, dirección, telefono, nombre) PRODUCTO(Id_prod, color, tamaño) Las relaciones que aparecen en el diagrama E/R se convierten dependiendo del tipo de correspondencia de la relación.

•

Relaciones N:M Siempre generan tabla. El nombre de la tabla es el nombre de la relación y los atributos son los propios de la relación si es que los tiene más los atributos claves principales de las entidades que participan en la relación. La clave principal de una tabla que provienen de una relación N:M es la formada por concatenación de los atributos que son claves principales de la entidades participantes en la relación. Como ejemplo se va a ver el paso a tablas de la relación que analizábamos en el ejemplo entre proveedores y productos. Además como consecuencia de la transformación de relaciones n:m surge una duplicidad en el modelo que es la provocada por la propagación de las claves de las entidades participantes en la relación. Como consecuencia y para evitar inconsistencias se generan tantas claves ajenas como entidades participen en la relación. De esta manera, si la relación es binaria, esto es dos entidades participantes, entonces nos encontraremos con 2 claves ajenas la primera hará referencia a la clave primaria de la primera entidad participante y la segunda hará referencia a la segunda entidad participante. De la misma manera se establecería si en lugar de binaria la relación fuera ternaria. En el caso que nos ocupábamos de la figura 10, se genera la tabla: SUMINISTRA(Id_prov, Id_prod, cantidad, fecha) Además en este caso, como puede observarse, la clave primaria es Id_prov, Id_prod y a su vez tenemos dos restricciones de clave ajena: por un lado Id_prod es clave ajena que hace referencia a la clave primaria de la entidad Producto y por otra parte la clave ajena Id_prov que hace referencia a la calve primaria de la tabla de Proveedores.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 18

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Téngase en cuenta además que habría que establecer la política de borrados y de modificaciones caso que se modificaran o borraran las claves primarias a las que referencian. Esta política se establecería de acuerdo a la semántica del problema en cada caso pero es importante tener en cuenta que en el caso de relaciones n:m la única política que no se podrá establecer es la de “Puesta a nulos “ puesto que esto supondría una violación de la restricción de entidad puesto que si cualquier componente de la clave primaria se queda a NULL esto hace nula a la clave primaria. Tal y como acabamos de establecer el elegir la política de borrados (actualizaciones ) en cascada o restringidos dependerá de la semántica de la aplicación. Por otra parte, es necesario hablar en este punto también de cómo se plasman en el modelo relacional las cardinalidades mínimas puesto que estas llevan asociadas cierta semántica del mundo real. En este caso sin embargo, no hay una manera directa de plasmar estas restricciones en el modelo relacional. Ya decíamos al principio que los modelos de datos tratan de capturar el máximo de semántica pero no siempre lo consiguen. En cuanto a las cardinalidades mínimas entonces nos ocurre que en el modelo relacional no se pueden plasmar con lo uqe tales restricciones si las hubiera se dejarán documentadas y luego se buscará la mejor manera de implementarlas dependiendo del gestor que se utilice. Es muy importante recordar que las restricciones se deberán dejar documentadas y siempre tratar de implementarlas puesto que ellas van cargadas de semántica, semántica que caso de no implementarlas se perdería con el consiguiente pérdida de información e incluso de consistencia que ello podría provocar •

Relaciones 1:N Este podría pensarse que es un caso particular de una relación n:m. No obstante, ocurre que en este caso es importante recordar que hay una entidad cuyas ocurrencias o no participan o si lo hacen lo hacen solo una vez. Como consecuencia, podemos tomar partido de esta propiedad para no tener que generar la tabla de la relación. De esta manera, en este caso no se genera una tabla en el modelo relacional, lo que se hace es que la clave principal de la entidad que participa con cardinalidad máxima N se pasa como atributo a la tabla de la entidad cuya cardinalidad máxima es 1. Como ejemplo se va a tomar el diagrama E/R que en la que se tenía que un autor escribe muchos libros pero un libro es escrito en este caso por un único autor. En este caso entonces téngase en cuenta que por cada tupla de autor no se podrían almacenar los libros que ha escrito puesto que son muchos. Sin embargo, ocurre que en el problema que estamos modelizando un libro es escrito por un único autor como consecuencia en la tupla correspondiente a cada libro es posible almacenar la información del código del autor del libro manteniendo en todo caso la información del autor en la tabla de autores. A este mecanismo de poner la clave de una entidad en la otra entidad se lo denomina propagación de clave extranjera. Es importante además resaltar que el atributo que se propaga no pasa a formar parte de la clave de la entidad es solamente un atributo más de la tabla que tendrá asociada una restricción de calve ajena puesto que tal y como hemos visto, este atributo proviene de otra entidad con lo que habrá que mantener la consistencia de la duplicidad que se acaba de generar. En el ejemplo entonces del libro y los autores se tendría el siguiente paso a tablas:

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 19

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

AUTOR(nombre, …) LIBRO(titulo, n_paginas, …, nombre)

Como se puede ver en la la entidad que participa con N en la relación es autor, y la que participa con 1 es libro. En este caso se añade en la tabla libro el atributo que es identificador principal de la tabla autor y este atributo es una clave ajena. En cuanto a las políticas de borrado y modificación se establecerán en este caso nuevamente de acuerdo a la semántica del problema teniendo en cuenta que en principio en este caso no hay restricción sobre el tipo de política que se puede establecer (cascadas, set null o restringida). En cuanto a las restricciones por cardinalidades mínimas, en este caso si se tiene que la entidad que participa con cardinalidad máxima 1 lo hace también con cardinalidad mínima 1 entonces adicionalmente a la propagación de clave ajena habrá que establecer que el atributo propagado no puede tomar valores Nulos en la tabla en la que está como clave ajena. Supongamos por claridad de nuevo el ejemplo del libro y el autor y supongase que se tuviera que un libro lo escribe uno y solo un autor esto es, que la cardinalidad de libro en la relación es (1,1) en este caso lo que se está diciendo es que no puede haber libros en la base de datos de los que no se conozca su autor, como consecuencia cuando el código del autor (en este caso el nombre) se propague a la tabla de libro entonces habrá que obligar a la entrada de datos es en este campo o lo que es lo mismop habrá que imponerle la restricción de NOT NULL. En el caso en que la restricción del 1 mínimo estuviera en la entidad que participa con la n máxima (en este caso el autor), entonces no hay manera de establecerlo ni en el paso a tablas ni con una restricción de not null. En este caso y como ocurriera con las relaciones n:m habrá que dejarlo establecido en la documentación para que dependiendo del gestor en el que finalmente se implemente se realice la restricción de una u otra manera. •

Relaciones 1:1 Es el mismo caso que las relaciones 1:N pero no está definido a qué entidad se le atribuye el atributo identificador de la otra. Se suele hacer por sentido común y haciendo un estudio de la eficiencia. No obstante dependiendo del caso aunque el sentido común nos lo establece vamos a estudiar aquí cual es la mejor transformación. Es muy importante en este caso recordar que independientemente de cual sea la propagación siempre el atributo que se propaga ha de establecerse que tiene restricción de ser UNIQUE en la tabla a la que se ha propagado pues es la única manera de establecer la restricción de uno máximo por ambos lados. Analizamos en detalle los casos que se pueden dar. Caso1. Supóngase el caso de la siguiente figura:

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 20

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

(0,1)

(0,1)

A

R

B

a

b

En este caso como se tiene que las dos cardinalidades mínimas son 0 ocurre que se podría propagar la clave de a a la entidad de B o al revés indistintamente. En este caso solo dependería de motivos de eficiencia. De esta manera si muchos de los accesos a la base de datos que piden datos de A también requieren información de la clave de B entonces podríamos plantearnos el propagar la clave de B a A con lo que estaríamos evitando hacer joins en estos tipos de consultas. De esta manera las dos posibilidades de transformación en este caso son: A(a, …b) B(b, …) Recuérdese que además se ha de establecer que b ha de ser UNIQUE en A puesto que B solo se puede relacionar con un A y de no establecer la restricción de UNIQUE se podría estar permitiendo que la misma ocurrencia de b ocurriera mas de una vez con diferentes A. ó: A(a, …) B(b, …a) Estableciendo ahora en este caso que a ha de ser UNIQUE en B Caso 2:

A

(0,1)

(1,1)

R

a

B

b

En el caso en el que tengamos un uno mínimo y solo uno entonces para no perder la restricción del 1 mínimo la mejor propagación es la que respeta este uno mínimo. En el caso de la figura ocurre que B se relaciona con uno y solo un A como consecuencia la mejor propagación será: A(a, …) B(b, …,a)

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 21

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

En la que al atributo a en la tabla de B se le establecerá la restricción de que ha de ser UNIQUE (valores no repetidos) puesto que A solo se puede relacionar con un B y además se establecerá que ha de ser NOT NULL puesto que B además de relacionarse con como máximo 1 A lo hace obligatoriamente con un A lo que establece que a no puede ser vació en B. Caso 3: En este caso ocurre que al tener unos mínimos por ambos lados, hay un 1 mínimo que se va a perder y que la única manera que tendremos de conservarlo será documentarlo para que dependiendo del gestor se implemente de la mejor manera. Como comentábamos en este caso podemos propagar indistintamente para un lado o para el otro y será nuevamente como en el caso 1 la eficiencia de la aplicación la que nos marcará la mejor propagación. De esta manera las dos posibilidades serían:

A

(1,1)

(1,1)

R

a

B

b

A(a, …) B(b, …,a) El atributo a en la tabla de B se le establecerá la restricción de que ha de ser UNIQUE (valores no repetidos) puesto que A solo se puede relacionar con un B y además se establecerá que ha de ser NOT NULL puesto que B además de relacionarse con como máximo 1 A lo hace obligatoriamente con un A lo que establece que a no puede ser vació en B. Además en este caso hay que documentar que es necesario añadir una restricción que obligue a que todo A además ha de estar relacionado con algún B, esto es, que no puede haber ocurrencias en la base de datos de A que no estén relacionadas con ningún B La otra posibilidad sería propagando b a A y estableciendo la restricción de NOT NULL y UNIQUE en este caso para el atributo a que se acaba de propagar y además añadiendo la restricción de que todo B se ha de relacionar con algún B.

8.2 Reglas para la transformación de las extensiones al modelo básico Dependencia en identificación Toda dependencia en identificación es una relación 1:n y como tal podemos aplicar los criterios que hemos venido aplicando en el epígrafe anterior. No obstante en este tipo de dependencias tenemos una peculiaridad y es que la entidad débil necesita de la clave de la entidad regular de la cual depende para poder identificar a sus ocurrencias. Como consecuencia lo que va a ocurrir es que vamos a propagar la clave como si de una relación 1: normal se tratara pero además vamos a hacer que la clave de la entidad débil (a la cual se le está propagando el atributo), sea su atributo identificador concatenado con la clave ajena que se acaba de propagar. Resumiendo, el paso a

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 22

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

tablas de una dependencia en identificación se realiza añadiendo como atributo de la entidad débil, la clave de la entidad fuerte, y este atributo formará junto con el atributo discriminador de la entidad débil, la clave principal de la entidad débil. Si se toma como ejemplo el diagrama E/R de la figura del ejemplo entre clientes y facturas el paso a tablas queda: CLIENTES(Id_cli, nombre, dirección) FACTURAS(Id_cli, n_fact, importe, descuento) Además hay que recordar que se genera la restricción de clave ajena que habrá que definir. Nótese que en este caso no es necesario imponer la restricción de NOT NULL puesto que el atributo forma parte de la clave lo que hace que nunca vaya a poder ser nulo. Jerarquías El paso a tablas de las jerarquías se realiza construyendo una tabla por la entidad genérica y una tabla por cada entidad hija de la jerarquía. La entidad genérica tiene como atributos los suyos propios con su calve principal, y si es una jerarquía de especialización además lleva también como atributo el atributo diferenciador. Las entidades hijas tienen como atributos los propios y además llevan como la clave de la entidad genérica, siendo clave principal también en las entidades hijas. Si se toma como ejemplo el diagrama E/R que aparece en la que se veía con anterioridad, las tablas que se generan son las siguientes: AUTOMÓVILES(matricula, marca, modelo, tipo) MOTOS(matricula, cilindrada) COCHES(matricula, color) AUTOBUSES(matricula, nºasientos) Se puede observar como la clave primaria de la entidad genérica, que en este caso es automóviles, aparece como atributo en cada una de las entidades hijas, y además forma su clave principal. Esta clave además es clave ajena en las tablas hijas de la jerarquía. Si en lugar de una jerarquía de especialización, hubiera sido una jerarquía subconjunto, la diferencia hubiera sido que en la entidad genérica no aparecería el atributo discriminador, en este caso el atributo tipo.

Ejemplo práctico A continuación se presenta un ejemplo práctico que permite ilustrar los conceptos fundamentales que se han analizado en el presente tema. Supóngase que se quiere modelar la base de datos de soporte a las transacciones realizadas en comercio que dispone de página web. Tan sólo estaremos interesados en realizar el diseño de la base de datos de soporte a las operaciones realizadas a través de dicha página web. Para el comercio es interesante no sólo almacenar la información de compradores sino la de los navegantes. Toda persona que quiere entrar en la página web ha de registrase la primera vez que entra suministrándole un login y una clave de acceso que podrá ser utilizada en futuros accesos al sitio web.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 23

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Los navegantes se convierten en clientes del comercio la primera vez que realizan una compra y en ese momento se le solicitará al navegante al menos su nombre completo, dirección, teléfono de contacto y fecha de nacimiento. Los clientes al realizar una compra han de suministrar la tarjeta de crédito contra la que se realiza el pago de la compra. Un cliente puede tener dada de alta mas de una tarjeta de crédito pero para cada compra sólo se especifica una tarjeta. De todas las tarjetas es necesario conocer además del titular, el número de la tarjeta y la fechas de caducidad de la misma. De las compras además es necesario almacenar la fecha de la compra el importe total de la compra y lo s productos que incluya la compra. De todos los productos se almacena en la base de datos su código, nombre, descripción, marca y el precio. Para finalizar la base de datos almacenará información relativa a los accesos de los navegantes. De esta manera, cada vez que un navegante entre en la página web se almacenará la fecha de tal acceso y la duración total de la visita. Se pretende realizar el diagrama entidad/relación que mejor modele las características de la base de datos que se acaba de exponer y el paso a modelo relacional

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 24

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

El diagrama entidad relación en el ejemplo propuesto es el siguiente:

Navegante

Clientes

(0,1

Código

(1,1

E

(0,n

(1,1

ó

Accesos

Hace c

(1,1

Id acceso

(0,n

Fecha

Tiene

duración

Compra (0,n Tarjeta

hac e

Password

Nombre Apellidos

(1,1

Login

(0,n)

(1,1 asoc

Id_compra Fecha

Número Fecha de caducidad

(0,n

involucra

(0,n) Productos Id_producto Nombre Descripción Precio

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 25

MINISTERIO DE TRABAJO Y ASUNTOS SOCIALES

TESORERÍA GENERAL DE LA SEGURIDAD SOCIAL

Gerencia de Informática Subdirección General de Informática

Recordando brevemente las reglas del paso a tablas del modelo básico tenemos: Toda entidad genera una tabla. Toda relación n:m genera una tabla Las relaciones 1:n se transforman por el mecanismo de propagación de clave extranjera. Como consecuencia se tiene: Navegante(login, passwd) Acceso(id_acceso, fecha_comienzo, fecha_fin, navegante) En este caso navegante es una clave extranjera que referencia a la clave de la tabla de navegantes Productos(código, descripción, nombre, precio ) Cliente (código, nombre, apellidos, dirección, navegante ) Navegante es una clave ajena que referencia a la clave de la tabla de navegantes Compras(Id_compra, id_tarjeta, id_cliente, cuantía) Id_ tarjeta es clave ajena que referencia a la lave de la tabla de tarjetas. ID_cliente es clave ajena que referencia a la clave de la tabla de cliente Involucra(Id_compra, Id_producto) Id_compra es clave ajena que referencia a la clave de la tabla de compras e Id_producto es clave ajena que hace referencia a la clave de la tabla de productos .

Bibliografía “Una introducción a los sistemas de base de datos”. Date C. J. .Addison Wesley 2000. “Diseño de bases de datos relacionales” Adoración de Miguel, Mario Piattini, Esperanza Marcos. Editorial RA-MA, 1999 “Un primer curso es sistemas de bases de datos”. Jeffrey D. Ullman, Jennifer Widom. Editorial Prentice Hall, 2000 “Implementación de los sistemas de base de datos”. Hector Garcia-Molina, Jeffrey Ullman, Jennifer Widom. Editorial Prentice Hall, 2000 “Procesamiento de bases de datos. Fundamentos, diseño e instrumentación”. David M. Kroenke. Editorial Prentice Hall “Diseño e implementación de bases de datos”. Gary W. Hansen. James V. Hansen. Segunda edición. 1997. Editorial Prentice Hall.

_________________________________________________________________________________________________________ Escala de Programadores de Informática de la Administración de la Seguridad Social Tema 1 - 26