INDICE

INTRODUCCIÓN..................................................................................................... 2

1. LA BASE DE DATOS COMO UN COMPONENTE DE LOS SISTEMAS DE

INFORMACIÓN........................................................................................................3

1.1. DEFINICIÓN DE BASE DE DATOS..............................................................3

1.2 SISTEMAS DE GESTIÓN DE BASES DE DATOS.........................................4

1.3 ARQUITECTURA DE BD A TRES NIVELES..................................................6

1.4 LENGUAJES DE UN SGBD...........................................................................6

1.5 OTRAS HERRAMIENTAS DE LOS SGBD.....................................................7

1.6 ALGUNAS ARQUITECTURAS DE SISTEMAS DE BASES DE DATOS........7

2. METODOLOGÍAS DE DESARROLLO DE BASES DE DATOS...........................9

[Link]É ES UNA METODOLOGÍA Y PARA QUÉ SIRVE....................................9

2.2. MODELOS DE DATOS COMO INSTRUMENTOS DE DISEÑO DE BASES

DE DATOS..........................................................................................................11

2.3 UNA METODOLOGÍA DE DESARROLLO DE BASES DE DATOS.............12

3. FASE DE ANÁLISIS DE REQUISITOS: MODELO ENTIDAD INTERRELACIÓN

(E/R)....................................................................................................................... 14

3.1 ELEMENTOS BÁSICOS DEL MODELO E/R................................................14

3.2 EXTENSIONES DEL MODELO E/R.............................................................18

3.3 CASO PRÁCTICO........................................................................................ 22

CONCLUSION....................................................................................................... 37

BIBLIOGRAFIA...................................................................................................... 38

1
 INTRODUCCIÓN

En el entorno del mercado actual, la competitividad y la rapidez de maniobra de

una empresa son imprescindibles para su éxito. Para conseguirlo existe cada vez
una mayor demanda de datos y, por tanto, más necesidad de gestionarlos. Esta
demanda siempre ha estado patente en empresas y sociedades, pero en estos
años se ha disparado debido al acceso multitudinario a las redes integradas en
Internet y a la aparición de los dispositivos móviles que también requieren esa
información.

En informática se conoce como dato a cualquier elemento informativo que tenga

relevancia para un usuario. Desde su nacimiento, la informática se ha encargado
de proporcionar herramientas que faciliten la manipulación de los datos. Antes de
la aparición de las aplicaciones informáticas, las empresas tenían como únicas
herramientas de gestión de datos los ficheros con cajones, carpetas y fichas de
cartón. En este proceso manual, el tiempo requerido para manipular estos datos
era enorme. Pero la propia informática ha adaptado sus herramientas para que los
elementos que el usuario utiliza en cuanto a manejo de datos se parezcan a los
manuales. Por eso se sigue hablado de ficheros, formularios, carpetas,
directorios,.

La clientela fundamental del profesional informático es la empresa. La empresa se

puede entender como un sistema de información formado por diversos objetos: el
capital, los recursos humanos, los inmuebles, los servicios que presta, etc.

Los sistemas de información actuales se basan en bases de datos (BD) y sistemas

de bases de datos (SGBD) que se han convertido en elementos imprescindibles
de la vida cotidiana de la sociedad moderna.

2
 1. LA BASE DE DATOS COMO UN COMPONENTE DE LOS

SISTEMAS DE INFORMACIÓN

Desglosando en detalle los componentes de un SI nos encontramos con cinco

grandes componentes:

• El Contenido, es decir, los datos con su correspondiente descripción,

almacenados en un soporte de ordenador (por ejemplo, en unos grandes
almacenes se tendrían los datos de clientes, ventas, productos, etc.).

• Equipo físico (hardware) formado por la unidad central de proceso y los equipos
periféricos (discos, terminales, impresoras, redes, ...).

• Equipo lógico (software) compuesto por los programas, documentación,

lenguajes de programación, etc. que debe gestionar los datos (creación, consulta,
recuperación y mantenimiento) así como controlar las comunicaciones y dar
soporte a tratamientos específicos (por ejemplo, gestión de personal, facturación,
etc.).

• El Administrador, encargado de asegurar la calidad de los datos almacenados y

de permitir su uso correcto y permanente. El administrador o administradores debe
controlar la disponibilidad, la confidencialidad y la integridad de los datos. La
disponibilidad se refiere a que los datos deben estar accesibles en todo momento,
es decir, que ante cualquier tipo de catástrofe o fallo, se tengan los mecanismos
adecuados de recuperación para que el sistema siga funcionando; la
confidencialidad se encarga de no desvelar datos a usuarios no autorizados y la
integridad asegura que los datos no se falseen, es decir, que sean correctos,
válidos y precisos.

• Un conjunto de Usuarios formado por las personas que acceden al sistema de

información y que pueden ser de dos tipos: informáticos (analistas y
programadores encargados de desarrollar las aplicaciones, bases de datos, etc.) y
los usuarios finales con pocos conocimientos de informática que requieren
consultas y actualizar los datos mediante interfaces adecuados a sus
características.

1.1. DEFINICIÓN DE BASE DE DATOS

Cada día, la mayoría de nosotros nos encontramos con actividades que requieren
algún tipo de interacción con una base de datos (ingreso en un banco, reserva de
una entrada para el teatro, solicitud de una suscripción a una revista, compra de
productos,.). Estas interacciones son ejemplos de lo que se llama aplicaciones

3
tradicionales de bases de datos (básicamente información numérica o de texto),
aunque los avances tecnológicos han permitido que también existan: bases de
datos multimedia, sistemas de información geográfica (GIS), almacenes de datos,
sistemas de proceso analítico on-line,.

• Una base de datos se entenderá como una colección de datos relacionados

entre sí y que tienen un significado implícito.

• Por datos queremos decir hechos conocidos que pueden registrarse y que tienen
un significado implícito.

Ejemplo

Una agenda con los nombres y teléfonos de un conjunto de personas conocidas

es una base de datos, puesto que es una colección de datos relacionados con un
significado implícito.

La definición presentada anteriormente hace referencia a dos elementos para que

un conjunto de datos constituya una Base de Datos:

1. Relaciones entre datos, tema que se tratará en las secciones siguientes.

2. Significado implícito de los datos que se atribuye dependiendo del contexto en

que se utilizan los mismos. Por ejemplo, el dato fecha en una base de datos de
VENTAS puede referirse a la fecha de emisión de las facturas, mientras que si la
base de datos es de MÚSICA quizás corresponda a la fecha en que se grabó un
tema musical. Es decir, el significado de un dato, depende de la BD que lo
contenga.

Para manipular y gestionar las bases de datos surgieron herramientas software

denominadas: sistemas gestores de bases de datos (SGBD en lo sucesivo) sobre
los que se profundizará en las siguientes secciones.

1.2 SISTEMAS DE GESTIÓN DE BASES DE DATOS

"Un Sistema de Gestión de Bases de Datos (SGBD ) es un conjunto coordinado de

programas, procedimientos, lenguajes, herramientas, etc., que suministra, tanto a
los usuarios no informáticos como a los analistas, programadores o
administradores de una BD, los medios necesarios para describir y manipular los
datos integrados en la BD, manteniendo su integridad, confidencialidad y
disponibilidad", De Miguel et al. (1999).

4
Se denomina Sistema de Bases de Datos a la unión de una BD, un SGBD más las
aplicaciones que acceden a la BD. La Figura 1.1 muestra la arquitectura de un
sistema de BD; en ella se observa que el SGBD hace de interfaz entre los
usuarios que acceden a la BD mediante las aplicaciones y la Base de Datos que
contiene toda la información.

Ya hemos mencionado en la sección anterior que existen distintos tipos de

usuarios con necesidades diferentes. Para poder dar soporte a estos usuarios el
SGBD debe proporcionar una serie de funciones que se describen a continuación:

1. Función de definición: permite a los diseñadores de la BD describir los

elementos de datos, su estructura y las relaciones que existen entre ellos; como
se estudiará en la sección 1.5, el SGBD proporciona un lenguaje para la definición
las tablas, los atributos que la componen, las restricciones semánticas así como
las características de tipo físico o almacenamiento.

2. Función de manipulación: permite a los usuarios de la BD añadir, suprimir o

modificar los datos de la misma siempre y cuando se respeten los aspectos de
seguridad que haya establecido el administrador de la BD.

3. Función de control: esta función aúna los interfaces que requieren los distintos
tipos de usuarios para comunicarse con la BD así como las herramientas
necesarias para el administrador para establecer los mecanismos de seguridad y
mantenimiento de la BD.

Para que el SGBD pueda llevar a cabo estas funciones se necesita un lenguaje
que permita especificar lo que cada tipo de usuario necesita en su comunicación

5
con la BD. En las BD relacionales se emplea el SQL (Standard Query Language)
sobre el que hablaremos en la sección

1.3 ARQUITECTURA DE BD A TRES NIVELES

A continuación, vamos a definir cuál es la arquitectura de una BD según la visión

que de ella tienen los distintos tipos de usuario. En una BD se identifican tres
capas de estructuración según tres niveles de abstracción. Así, se distingue un
nivel externo, un nivel lógico y un nivel físico.

• El nivel externo se corresponde con la visión de la BD que cada usuario tiene en

particular. Esto significa que no todos los usuarios necesitar conocer la BD
completa sino que únicamente necesitan una vista parcial de ella (la que le
permita llevar a cabo su trabajo); por ejemplo, un administrativo que trabaje
elaborando las nóminas de los empleados de una empresa no necesita conocer
los datos relativos a las ventas de productos de esa empresa.

• El nivel lógico se corresponde con la visión total de la empresa; esta vista global
se interpone entre el nivel externo y el nivel físico siendo independiente tanto del
equipo como de cada usuario en particular; por ejemplo, el administrador de la BD
si necesita tener una vista completa de la BD de la empresa para llevar a cabo su
trabajo.

• El nivel físico se corresponde con la vista del soporte físico informático en cuanto
a que se refiere a la forma en que se organizan los datos en el almacenamiento
físico (índices o punteros, longitud de los campos, caminos de acceso a los datos,
particionamientos de memoria, etc.).

La gestión de estos tres niveles debe estar soportada en cualquier SGBD.

1.4 LENGUAJES DE UN SGBD

De acuerdo a las funciones a las que debe dar soporte un SGBD estudiadas en la
sección 1.3 y a los distintos niveles de estructuración de una BD vistos en la
sección 1.4, los SGBD deben proporcionar un lenguaje para que los distintos tipos
de usuario puedan comunicarse con la BD. Así, en los SGBD relacionales se tiene
el lenguaje SQL que de acuerdo a su función se descompone en:

(a) Lenguaje de Definición de Datos (LDD): utilizado para definir la estructura

lógica de la BD (nivel lógico), la estructuras externas requeridas para el desarrollo

6
de las diferentes aplicaciones (nivel externo) así como la estructura interna (nivel
físico).

(b) Lenguaje de Manipulación de Datos (LMD): una vez se ha descrito la BD, ésta
ya está preparada para cargar los datos en las estructuras definidas y para su
utilización. Así, el LMD permite añadir, suprimir, modificar y buscar datos en la BD.
Es el SGBD el que se encarga de acceder al correspondiente soporte físico para
localizar los datos con los que se harán las operaciones especificadas.

(c) Lenguaje de Control: el administrador de la BD utiliza este lenguaje para

especificar los aspectos de seguridad física (copias de seguridad, rearranque de la
BD en caso de caída, etc.) así como de protección frente a accesos no permitidos
(autorizaciones y contraseñas, perfiles de usuarios, etc.). El lenguaje de control
también se requiere para definir los interfaces que necesitan los distintos usuarios
para comunicarse con la BD.

1.5 OTRAS HERRAMIENTAS DE LOS SGBD

Los SGBD proporcionan otro tipo de herramientas de gran utilidad en el desarrollo

de aplicaciones de Bases de Datos. Entre otras, existen:

• Herramientas de ayuda al desarrollo (CASE) en las fases de análisis, diseño e

implementación de BD que generalmente incluyen diagramadores para esquemas
conceptuales y lógicos de bases de datos, generadores de código SQL, etc.

• Generadores de informes y pantallas que facilitan la presentación de los datos

recuperados de la BD.

1.6 ALGUNAS ARQUITECTURAS DE SISTEMAS DE BASES DE DATOS

En este apartado revisaremos brevemente algunos conceptos relacionados con

las distintas arquitecturas de Sistemas de BD. En una arquitectura se reflejan
aspectos como la conexión en red, el paralelismo y la distribución:

• Red: permite que algunas tareas se ejecuten en un sistema servidor y que otras
se ejecuten en los clientes (son lo que se denominan sistemas de BD cliente-
servidor).

• Paralelismo: acelerar la ejecución de tareas (transacciones, etc.) de acuerdo al

sistema informático subyacente (sistemas de BD paralelos).

7
• Distribución: Datos situados donde se han generado o donde son más
necesarios pero accesibles desde todos los sitios (sistemas de BD distribuidos).

Según estos aspectos distinguimos sistemas centralizados, sistemas cliente-

servidor, sistemas paralelos y sistemas distribuidos.

En los sistemas centralizados existe un único sistema informático sin interacción

con otros ordenadores. En estos sistemas podemos diferenciar entre:

(a) Sistema monousuario formado por un ordenador personal o por una estación
de trabajo con una única CPU y un sistema operativo monousuario (no permite
que varios usuarios puedan acceder simultáneamente a la BD)

(b) Sistema multiusuario formado por varias CPU y con sistema operativo
multiusuario con terminales conectados al sistema servidor; estos terminales no
poseen ninguna funcionalidad propia aparte de la de visualizar el resultado de los
procesos que se ejecutan en el servidor.

En los sistemas cliente-servidor existe un reparto de funcionalidades, es decir, los

terminales se sustituyen por ordenadores personales que gestionan el interfaz de
usuario SQL, interfaz de formularios, diseñadores de informes e interfaz gráfica.
Los sistemas servidores satisfacen las peticiones generadas por los sistemas
clientes.

Se distinguen dos tipos de servidores:

(a) Servidores de transacciones (servidores de consultas) con un interfaz mediante

el que los clientes envían peticiones para realizar una acción que el servidor
ejecutará y cuyos resultados se devuelven al cliente.

(b) Servidores de datos (el servidor envía los datos a las máquinas clientes en las
que se realiza el procesamiento enviando después los datos de vuelta).

Respecto a los sistemas paralelos representan una solución al manejo de BD muy

grandes o con un gran volumen de transacciones por segundo. El objetivo es
realizar operaciones simultáneamente mediante el uso de varios procesadores y
varios discos en paralelo. Los modelos de arquitecturas para máquinas paralelas
son:

(a) Memoria compartida: Todos los procesadores comparten una memoria común.

(b) Disco compartido: Los procesadores comparten un disco común (cada

procesador con su memoria)

(c) Sin compartimiento: No hay compartición ni de disco ni de memoria

8
(d) Jerárquico: modelo híbrido de los anteriores.

Por último, en los sistemas distribuidos la BD se almacena en varios ordenadores

que no comparten ni memoria ni discos pero que se comunican mediante redes de
alta velocidad o líneas telefónicas. Estos ordenadores se encuentran en varios
lugares geográficos distintos. En un sistema distribuido se dan dos tipos de
transacciones:

1. Transacciones locales: Acceso a datos del ordenador en el que se inició la

transacción

2. Transacciones globales: Acceso a datos de un ordenador distinto o acceso a

datos de varios ordenadores distintos.

Las ventajas que proporcionan los sistemas distribuidos frente a los sistemas
centralizados son la compartición de datos (acceso a datos en distintos sitios), por
ejemplo, dos sucursales bancarias pueden compartir datos entre sí; la autonomía
en cuanto a que cada administrador controla su BD y, por último, la disponibilidad
de los datos pues si un ordenador falla, están los demás para poder seguir
trabajando, en particular, si hay duplicación de datos.

2. METODOLOGÍAS DE DESARROLLO DE BASES DE DATOS.

Una vez estudiados brevemente los principales aspectos relacionados con la

tecnología de las Bases de Datos en cuanto a terminología y conceptos básicos
(qué es una BD, Sistemas de Gestión de Bases de Datos, niveles de abstracción,
arquitecturas, etc.) en este capítulo se expondrán aquellos conceptos relacionados
con el diseño de BD que es el tema principal de este libro. Para ello, definiremos
en primer lugar qué es una metodología y para qué sirve; la sección 2.2 está
dedicada a los modelos de datos como instrumento necesario para diseñar BD y,
por último, la sección 2.3 expone la metodología de desarrollo de BD que se
seguirá en los siguientes capítulos de este libro.

[Link]É ES UNA METODOLOGÍA Y PARA QUÉ SIRVE.

"Una metodología es un conjunto de procedimientos, técnicas y ayudas a la

documentación para el desarrollo de un producto software", Amescua et al. (1995);
en el caso que nos ocupa en este libro, el producto software es una Base de Datos
. Una metodología nos indica las actividades a seguir en el desarrollo de principio
a fin de la Base de Datos, qué es lo que hay que realizar en cada actividad
indicando qué se necesita como entrada, qué se produce como salida e incluso
9
quién está involucrado. Por lo tanto, es como un libro de recetas de cocina en el
que se va indicando paso a paso todas las actividades a realizar para lograr la
Base de Datos deseada.

Una metodología se apoya en los siguientes elementos: técnicas, modelos y

soporte CASE. Veamos en qué consiste cada uno de estos elementos.

Las técnicas representan cómo llevar a cabo cada una de las actividades o pasos
de los que consta la metodología, es decir, proporcionan procedimientos para
llevar a cabo cada tarea; en ocasiones estas técnicas son procedimentales
(secuencia perfectamente definida de los pasos a realizar en una tarea como en
un algoritmo) y en otros casos son heurísticas (reglas, recomendaciones o
sugerencias a seguir que en ningún caso establecen el proceso exacto de
realización de una tarea; generalmente se utilizan en tareas con un alto
componente creativo).

Los modelos son los instrumentos que empleamos para representar una
determinada realidad (generalmente tienen una notación gráfica que facilita su
comprensión y validación); se utilizan en las técnicas para soportar la actividad
que llevan a cabo. En el siguiente apartado se estudiarán los modelos de datos
involucrados en el diseño de una BD

Por último, las herramientas CASE permiten dar soporte automatizado a la

aplicación de las técnicas de una metodología así como a los modelos que
incorporan. Los entornos CASE no solo deben automatizar las técnicas aisladas
correspondientes a una metodología sino también dar soporte a toda la
metodología de desarrollo mediante la incorporación de un conductor

10
metodológico que ayude al analista, diseñador o programador a desarrollar su
labor en cada actividad definida en la metodología.

Todos estos conceptos se estudiaran particularizados para una metodología de

BD en las siguientes secciones.

2.2. MODELOS DE DATOS COMO INSTRUMENTOS DE DISEÑO DE BASES

DE DATOS.

El diseño de BD consiste en describir la estructura de la BD de forma que se

represente fielmente la parcela del mundo real que se quiere almacenar. Ello se
realiza mediante un proceso de abstracción (que se denomina modelado) que se
apoya en un modelo de datos. Un modelo de datos es el instrumento que se
aplica a un UD para obtener una estructura de datos que se denomina esquema
de la BD.

Un modelo de datos proporciona un conjunto de conceptos, reglas y convenciones

que nos permiten especificar y manipular los datos que queremos almacenar en la
BD. Todo modelo de datos se compone de una parte estática y una parte dinámica
como se explica a continuación.

A. Estática: Conjunto de estructuras (también denominados constructores del

modelo) que permiten definir los datos y sus restricciones asociadas especificados
según un Lenguaje de Definición de Datos (apartado 1.5). Esta parte estática
consta de elementos permitidos y elementos no permitidos:

1. Elementos permitidos: son los objetos, asociaciones entre objetos,

propiedades, etc. que proporciona el modelo para representar una determinada
realidad (estos elementos varían de un modelo a otro según su riqueza
semántica).

11
2. Elementos no permitidos: Son las restricciones que representan las
limitaciones impuestas a la estructura del modelo o a los datos que invalidan
ciertos ejemplares de la BD. Las restricciones son de dos tipos:

• Restricciones inherentes: son las limitaciones impuestas a las estructuras

del modelo (reglas impuestas para la utilización y combinación de los distintos
constructores del modelo).

• Restricciones semánticas (o de usuario): son las restricciones que se

deducen de los supuestos semánticos explícitos o implícitos o derivados de
nuestro conocimiento del mundo real que se quiere reflejar en la BD (por ejemplo,
"todo empleado debe pertenecer a un departamento", "el sueldo de un
determinado empleado siempre será inferior al sueldo de su jefe", etc.).

B. Dinámica: Formada por un conjunto de operadores que permiten manipular los

datos y que están reflejados en el Lenguaje de Manipulación de Datos (apartado
1.5). Como se estudiará después, esta parte dinámica no tiene sentido para todos
los modelos de datos.

Además, cada modelo de datos tiene una representación gráfica que suele ser en
forma de grafos o tablas.

A lo largo del desarrollo de una BD se utilizan varios modelos de datos que nos
permiten representar la realidad según las distintas fases de una metodología y
según distintos niveles de abstracción. Aunque los siguientes capítulos se
dedicarán al estudio pormenorizado de cada uno de los modelos, la Tabla 1
muestra la parte estática y dinámica del Modelo Entidad/Interpelación (E/R) para
modelado conceptual y el Modelo Relacional para diseño lógico de BD.

2.3 UNA METODOLOGÍA DE DESARROLLO DE BASES DE DATOS

Aunque existen distintas metodologías para el desarrollo de BD, Elsmari y

Navathe (1997), en este libro se seguirá la propuesta en De Miguel et al. (1999)
que cubre las fases de diseño conceptual, diseño lógico estándar y diseño lógico
específico. La figura 4 muestra las fases de esta metodología con los modelos que
se aplican en cada una de ellas. Aunque el uso de esquemas conceptuales facilita
el diseño de BD no siempre la fase de modelado conceptual se lleva a cabo. La
parte derecha de la Figura muestra la metodología completa de diseño de BD
mientras que la parte izquierda muestra el diseño de BD partiendo del diseño
relacional de una BD.

12
Veamos a continuación en qué consiste cada una de estas fases:

1. Modelado Conceptual: consiste en la representación del UD (parte del mundo

real que se quiere almacenar en la BD) en esquemas conceptuales E/R. Mediante
los constructores del modelo E/R se recoge toda la semántica que puede
obtenerse mediante la observación del UD o bien a partir de unas especificaciones
textuales (esquemas descriptivos) que describan la información que debe contener
la BD. En este libro se construirán esquemas conceptuales de BD a partir de
esquemas descriptivos.

Esta primera fase de análisis tiene como objetivo poder validar con el usuario
(persona o conjunto de personas que nos encargan una BD para cubrir sus
necesidades de negocio) la información que contendrá la BD. Por ello, los
esquemas E/R son los de mayor nivel de abstracción (capacidad para ocultar los
detalles y fijarse en lo esencial), con constructores muy naturales (estructuras muy
cercanas al usuario y fácilmente comprensibles por personas no informáticas).
Nótese que los esquemas conceptuales no son directamente implementables en
un ordenador; por ello, no tienen ninguna connotación física y pueden traducirse a
cualquier modelo lógico . El esquema E/R viene a ser para una BD como los
planos de un arquitecto son imprescindibles para una casa: algo necesario a priori
en la construcción de una BD. Sin estos planos es imposible conocer cuáles son
los requisitos que deberán contemplarse en la BD.

La construcción de esquemas E/R es una labor creativa que se realiza en

sucesivos pasos de refinamiento; consecuentemente, no todos los analistas
obtendrán el mismo esquema E/R cuando modelan una determinada realidad

13
pues dependerá de la labor intelectual que lleve a cabo cada uno en su visión del
UD. Sin embargo, si es posible seguir una serie de heurísticas o recomendaciones
de gran utilidad cuando se modela una BD. En el capítulo dedicado al modelo E/R
se estudiarán estas heurísticas en detalle.

2. Transformación de esquemas conceptuales E/R a esquemas relacionales: Una

vez se ha validado con el usuario el esquema E/R correspondiente a la BD ya es
posible realizar la transformación a un esquema lógico, en nuestro caso, a un
esquema relacional. Para este paso si que existe un procedimiento exhaustivo a
seguir con el fin de traducir todos los constructores del modelo E/R a constructores
del modelo Relacional. En un primer paso, se hace una transformación al modelo
relacional estándar (SQL-92). El modelo relacional estándar no es directamente
implementable en un SGBD relacional pues cada SGBD implementa de manera
libre un subconjunto de este estándar. Es en la fase de transformación a un
modelo lógico específico (es decir, el propio de cada SGBD comercial ) cuando ya
se habla de BD directamente trasladables a un producto comercial.

3. Diseño físico: En esta fase se tienen en cuenta aspectos relacionados con la

carga de la BD, la optimización de consultas y otros aspectos relacionados con la
eficiencia en el almacenamiento y funcionamiento de la BD y que son realizadas
por el administrador de la BD a través de las utilidades que proporciona el SGBD
que se vaya a utilizar.

3. FASE DE ANÁLISIS DE REQUISITOS: MODELO ENTIDAD

INTERRELACIÓN (E/R)

3.1 ELEMENTOS BÁSICOS DEL MODELO E/R

Los elementos u objetos básicos del modelo E/R son cuatro: entidades,
interrelaciones, atributos y dominios. A continuación se explican cada uno de
ellos. Entidades

Las entidades, también llamadas tipos de entidad, representan conjuntos de

elementos con existencia propia y que se caracterizan por las mismas
propiedades. Generalmente son personas, cosas, lugares,..., es decir, conceptos
sobre los que necesitamos guardar información y distinguibles de los demás
objetos. Su representación gráfica se hace por medio de un rectángulo dentro del

14
cual se escribe el nombre de la entidad en mayúsculas (generalmente un
sustantivo).

Por ejemplo, si queremos diseñar una base de datos para gestionar todos los
alumnos de los cursos Mentor, entre los tipos de entidad que deberíamos definir
estarían ALUMNO y CURSO. El primero representaría el conjunto de todos los
alumnos que se inscriben en los diferentes cursos, el segundo recogería todos los
cursos ofertados por el aula Mentor.

Atributos

Todo tipo de entidad tiene unas características o cualidades propias que

queremos recoger dentro de nuestro diseño. El modelo E/R define estas
cualidades como atributos, así por ejemplo el nombre del alumno, el teléfono, etc.,
describen propiedades de cada uno de los miembros que pertenecen al tipo de
entidad ALUMNO. Estas propiedades no tienen existencia propia, es decir, sólo
tienen sentido en el esquema de la Base de Datos en tanto en cuanto aparecen
formando parte de una entidad o, como veremos más adelante, de otro de los
elementos del modelo E/R, de una interrelación.

Supongamos que de cada alumno queremos la información referente a su D.N.I.,

Nombre, Dirección, Teléfono y Nacionalidad.

Los ejemplares, también denominados ejemplares o elementos, de un tipo de

entidad se definen como los valores correspondientes a los atributos que hemos
definido para ella.

Por ejemplo dos ejemplares del tipo de entidad ALUMNO serían:

15
• (DNI, 7515958), (Nombre, Juan), (Dirección, C/ Irún, nº 9 Madrid),
(Teléfono, 91-675-65-

65), (Nacionalidad, Española)

• (DNI, 7077777), (Nombre, Ana),(Dirección, C/ Bailén, nº 9, Madrid),

(Teléfono, 91-678-9899), (Nacionalidad, Española)

Por lo tanto los valores de los atributos constituyen una parte importante de los
datos que almacenaremos posteriormente en la Base de Datos. Es importante
destacar que un mismo concepto no tiene por qué representarse siempre de la
misma forma (por ejemplo, como una entidad o como un atributo). Así, si
estuviéramos modelando una Base de Datos para una tienda de ropa,
probablemente tendríamos una entidad denominada PRENDA y uno de sus
atributos podría ser Color (roja, negra, etc.). Sin embargo, si estuviéramos
hablando de una Base de Datos para gestionar la información de un taller de
vehículos dedicado a trabajos de chapa y pintura, el concepto de color puede
tener tal importancia que pase a ser una entidad COLOR, pues tiene existencia
propia y un conjunto de propiedades (código de color, textura, tipo de mezcla,
etc.).

Tipos de atributos

Como se puede observar en la figura 2.2 no todos los atributos se representan de

la misma forma; ello significa que existen diversas formas de recoger restricciones
semánticas sobre los atributos de una entidad o de una interrelación. En el
ejemplo aparece el atributo D.N.I. con un círculo negro, este tipo de atributo se
denomina identificador principal (IP) y lo que indica es que el atributo o propiedad
DNI es único para cada ejemplar del tipo entidad ALUMNO.

Para poder distinguir una ejemplar de otra, dentro de un mismo tipo de entidad, el
modelo E/R obliga a que cada vez que definimos un tipo de entidad se defina un
atributo que identifique cada ejemplar, es decir, un IP. Por lo tanto en todos los
tipos de entidad tiene que aparecer de forma obligatoria una característica que
identifique de forma única cada uno de los ejemplares.

Esta es la representación que nos proporciona el modelo E/R para distinguir este
tipo de atributo del resto de atributos que componen el tipo de entidad. En un tipo
de entidad sólo puede aparecer un identificador principal, pero pueden existir
distintos atributos que también identifiquen los ejemplares de esta; este tipo de
atributos se denominan Identificadores Alternativos (IA).

16
Veamos un ejemplo, supongamos que queremos añadir para el tipo de entidad
ALUMNO, la dirección de correo electrónico que este posee, sabiendo que es
única para cada uno de los alumnos.

En el ejemplo de la figura anterior, el atributo Teléfono aparece representado con

una línea de puntos lo que significa que estamos ante un Atributo Opcional que
nos informa de que existen alumnos que puede que no tengan número de teléfono
o que al fin y al cabo es un atributo cuyo valor no es demasiado importante y por
eso no lo ponemos como obligatorio. Por tanto, cuando los valores de un atributo
van a ser desconocidos o por alguna otra causa no van a tener valor se
denominan Atributos Opcionales.

Supongamos que para el tipo de entidad CURSO es importante recoger las

siguientes propiedades: nombre, libro de consulta y dirección Web. De estas tres
características de CURSO elegiremos como identificador principal el nombre, ya
que cada curso tiene un nombre distinto, la dirección Web sería un identificador
alternativo porque toma valores únicos para cada curso y libro de consulta sería
un atributo opcional ya que permitimos que haya cursos que no tengan o que
desconozcamos su libro de referencia. La entidad CURSO con sus atributos
queda representada en la siguiente figura.

Existen otras formas de recoger restricciones semánticas sobre los atributos que
se estudiarán en el capítulo siguiente, en donde ampliaremos estos conceptos.

17
Dominios

Supongamos que el atributo nacionalidad, sólo puede tomar los valores “española”
o “extranjera”. Para los conjuntos de valores sobre los que se definen los atributos
utilizaremos un objeto del modelo E/R denominado Dominio. Un dominio se define
por un nombre y un conjunto de valores. En nuestro ejemplo véase la definición
del dominio Nacionalidad en la figura resaltado en color azul.

En general los dominios no se suelen representar en el modelo por problemas de

espacio, pero para tener constancia de los valores que puede tomar un atributo se
suele anotar después de la representación gráfica una representación textual.

3.2 EXTENSIONES DEL MODELO E/R

Posteriormente al modelo E/R propuesto por Chen se realizaron algunas

extensiones para darle más riqueza semántica. Esto significa que se le han
añadido nuevos conceptos para que el modelo se adapte mejor a la realidad que
queremos modelar, es decir, recoja mayor semántica.

Vamos a introducir algunos de estos nuevos conceptos retomando el ejemplo visto

en el apartado anterior sobre una empresa en el que habíamos representado la
relación que existía entre los empleados y los departamentos de la empresa.

18
Supongamos que la empresa es un consorcio de distintas librerías especializadas
en libros y revistas informáticas llamada INTERFAZ. Sabemos que los empleados
de INTERFAZ están asignados a un departamento y que la relación entre
EMPLEADO y DEPARTAMENTO se representa como se indica en la figura.

Entidades

En el apartado 2 se estudió que las entidades en un esquema E/R son los objetos
principales sobre los que debe recogerse información y generalmente denotan
personas, lugares, cosas o eventos de interés. En esta sección vamos a estudiar
cómo las entidades pueden clasificarse por la fuerza de sus atributos
identificadores.

Las entidades fuertes o regulares tienen existencia propia, es decir, poseen

identificadores internos que determinan de manera única la existencia de sus
ejemplares. Las entidades débiles son dependientes de otras entidades y pueden
serlo por dos motivos: bien porque la existencia de sus ejemplares en la base de
datos depende de una entidad fuerte bien porque sus ejemplares requieran para
su identificación de los atributos identificadores (algunas veces llamados atributos
externos) de otra entidad.

Por ejemplo, los ejemplares correspondientes a los alumnos del MENTOR no

dependen de ninguna otra entidad para existir en la base de datos; por ello la
entidad ALUMNO es una entidad fuerte. Sin embargo, en el caso de una base de
datos de una cadena hotelera podríamos tener el tipo de entidad HABITACIÓN
dependiente del tipo de entidad HOTEL ya que para que existan ejemplares de
HABITACIÓN es necesario que existan ejemplares de HOTEL. Una ejemplar de
HABITACIÓN no tiene existencia por si misma porque siempre estará asociada a
una ejemplar de HOTEL. Además, si se elimina un determinado ejemplar de la
entidad HOTEL de la base de datos también deberán desaparecer los ejemplares
de la entidad HABITACIÓN asociadas a él. La representación de una entidad débil
difiere de la de una entidad regular pues el rectángulo de la entidad débil es de
doble recuadro como se muestra en la figura.

19
Interrelaciones binarias

La clasificación anterior entre entidades fuertes y débiles da lugar a dos tipos de

interrelaciones según los tipos de entidades que asocian.

Las interrelaciones regulares relacionan tipos de entidades regulares o fuertes.

Las interrelaciones débiles relacionan un tipo de entidad regular y un tipo de
entidad débil. Además, en las interrelaciones débiles podemos distinguir:

Dependencia en existencia. Este tipo de interrelación refleja que los ejemplares

del tipo de entidad débil que se relacionan con un determinado ejemplar del tipo
de entidad regular dependen de él y, si éste desaparece, ellos también. Veamos
un ejemplo que clarifique esta definición:

Supongamos que la empresa INTERFAZ necesita conocer los datos de los

familiares que están a cargo de cada empleado de la empresa (cónyuge, hijos,
etc.) para de esta manera apoyar a aquellos cuya carga familiar sea numerosa.

Para saber los familiares que dependen de cada empleado debemos crear un
nuevo tipo de entidad, que denominaremos FAMILIAR, cuyos atributos podrían ser
el DNI (como IP), el nombre completo y parentesco con el empleado. Como se
puede observar, la existencia de un miembro de la familia depende plenamente de
que ese miembro tenga a una persona de su familia trabajando en la empresa, o
lo que es lo mismo que exista un ejemplar de EMPLEADO que este relacionado
con él; es decir, los familiares sólo existen en la base de datos si existe un
empleado con el que se relacionen y si un determinado EMPLEADO se va de la
empresa, entonces se eliminarán todas los ejemplares de FAMILIAR que
dependan de él. Así, tenemos una interrelación de dependencia en existencia
entre EMPLEADO y FAMILIAR representada como muestra la figura

20
Dependencia en Identificación: Este tipo de interrelación complementa a la anterior
en que, además de que los ejemplares del tipo de entidad débil dependen de la
existencia de un ejemplar de la entidad regular, también necesitan para su
identificación el IP de la entidad regular. Así, veíamos anteriormente que la entidad
HABITACIÓN era débil respecto al HOTEL al que pertenece. Si construimos las
interrelación existente entre ambas entidades debemos pensar si el atributo “Nº de
Habitación” de la entidad HABITACIÓN es suficiente para identificar cada ejemplar
de esta.

Como se muestra en la figura el IP, es decir, el número de habitación se repite

para distintos hoteles (la habitación número 1 existe en el hotel “Mar” y en el hotel
“Sol”). Para solucionar este problema, existen dos soluciones:

(a) La primera consiste en cambiar el IP, por ejemplo, poner el nombre de la

habitación como IP; esto significa que los nombres de la habitación no pueden
repetirse en los distintos hoteles y esto no es posible asegurarlo.

(b) La segunda, y más razonable, consiste en crear una interrelación débil de

dependencia en identificación, es decir, los ejemplares de la entidad débil
requieren para su identificación de los atributos identificadores de la entidad fuerte.
Así, cada ejemplar de HABITACIÓN está identificada por la concatenación de su
número y del nombre del hotel en que se encuentra. Por ejemplo, la habitación 1
“Sol”, habitación 1 “Mar”, etc. Su representación es la que se muestra en la figura.

21
 3.3 CASO PRÁCTICO

Para este caso práctico se ha pensado en una continuación del ejemplo que se ha
ido desarrollando a lo largo de este capítulo sobre el diseño de una Base de Datos
que recoja información acerca del proyecto llevado a cabo por el Ministerio de
Educación denominado MENTOR. Hay que tener en cuenta que los supuestos
semánticos de este ejemplo son hipotéticos. A continuación se expondrán los
requisitos que se van considerar en este apartado para llevar a cabo el diseño de
la base de datos. Dicho proyecto se encarga de ofertar cursos por Internet para
alumnos del territorio nacional.
• La información que se desea almacenar en la Base de Datos se refiere a
los alumnos matriculados en cada curso, teniendo en cuenta la fecha de inicio
y la fecha de finalización de cada alumno en un determinado curso y sabiendo
que un alumno se ha podido matricular de uno o varios cursos y que un curso
tiene como mínimo un alumno.
• De los alumnos se desea saber el DNI, nombre completo, dirección,
teléfono, nacionalidad, pero sólo interesa saber si la nacionalidad es española
o no, y la dirección de correo

electrónico. La dirección de correo electrónico es imprescindible para poder

realizar los cursos y además es única para cada alumno.
La información referente a los cursos consta del nombre, título del libro de
consulta que se utiliza (aunque existen cursos que no lo poseen) y dirección de
Internet donde se encuentra todo el material que se puede utilizar durante el
curso.

22
 • Cada curso tiene asociado un grupo de personas expertas, llamadas
tutores, que son las encargadas de resolver las dudas propuestas por los
alumnos, la evaluación de los mismos e incluso el hombro para que estos se
desahoguen. Dentro de los tutores de un mismo curso existe una figura
importante que es la de coordinador que se encarga de realizar labores de
unificación y planificación. No hay que olvidar que una persona experta puede
ser tutora de varios cursos y que además un coordinador de curso es un tutor.
La información que se quiere almacenar en la BD acerca de los tutores es la
siguiente: DNI, nombre completo y dirección de correo electrónico.
• El proyecto MENTOR, además, tiene en cuenta que ha de facilitar a los
alumnos el acceso a Internet y por lo tanto ha instalado aulas con todos los
servicios necesarios para el pleno desarrollo de los cursos.
• Cada alumno pertenece a un aula y el mantenimiento tanto de los
ordenadores como de los programas se lleva a cabo por los administradores
de aula.
• Cada aula tiene asignado un código único, un nombre y una dirección.
• La información que se necesita de cada administrador es su DNI, nombre
completo, dirección de correo electrónico.

Diseño propuesto
Para realizar el diseño conceptual de la BD en el modelo E/R seguiremos una
serie de pasos que nos ayudarán a identificar los elementos básicos del modelo.
Estos pasos son iterativos, es decir, un esquema E/R se construye según distintas
fases de refinamiento. Además, las soluciones no son únicas, cada diseñador
puede ver el mundo real de distinta forma, dando lugar a distintos esquema E/R
válidos. Sin embargo, si se puede estudiar si un determinado esquema E/R refleja
mejor que otro los supuestos semánticos del enunciado. No hay que olvidar que
en el esquema E/R de una base de datos hay que recoger la mayor semántica
posible y no dejar para las siguientes fases de desarrollo (diseño lógico e
implementación) ningún supuesto semántico, siempre que sea posible.

23
1er paso: Identificar y enumerar las posibles entidades teniendo en cuenta la
siguiente heurística: en general, un tipo de entidad es un sustantivo dentro de una
oración con una serie de propiedades o características. Por ejemplo, DNI del
alumno, nombre del curso, etc...

En el texto presentamos en negrita y subrayado los tipos de entidad que hemos

detectado.

• La información que se desea almacenar en la Base de datos se refiere a los

alumnos matriculados en cada curso. Teniendo en cuenta la fecha de inicio de
cada alumno en un determinado curso así como su fecha de finalización y
sabiendo que un alumno se ha podido matricular de uno o varios cursos y que
un curso tiene como mínimo un alumno.
• De los alumnos se desea saber el DNI, nombre completo, dirección,
teléfono, nacionalidad, pero sólo interesa saber si la nacionalidad es española
o no, y la dirección de correo electrónico. La dirección de correo electrónico es
imprescindible para poder realizar los cursos y además única para cada
alumno.
• La información referente a los cursos consta de nombre de este, título del
libro de consulta que utiliza (aunque existen cursos que no lo poseen) y
dirección de Internet donde se encuentra todo el material del que consta.
• Cada curso tiene asociado un grupo de personas expertas, llamadas
tutores, que son las encargadas de resolver los problemas propuestos por los
alumnos, la evaluación de los mismos e incluso el hombro para que estos se
desahoguen. Dentro de los tutores de un mismo curso existe una figura
importante que es la de coordinador que se encarga de realizar labores de
unificación. No hay que olvidar que una persona experta puede ser tutora de
varios cursos y que además un coordinador de curso es un tutor. La
información que se quiere almacenar en la BD acerca de los tutores es la
siguiente: DNI, nombre completo y dirección de correo electrónico.
• El proyecto MENTOR, además, tiene en cuenta que ha de facilitar a los
alumnos el acceso a Internet y por lo tanto a instalado aulas con todos los
servicios necesarios para el pleno desarrollo de los cursos.
• Cada alumno pertenece a un aula y el mantenimiento tanto de los
ordenadores como de los programas se lleva a cabo por los administradores
de aula.
• Cada aula tiene asignado un código único, un nombre y una dirección.
• La información que se necesita de cada administrador es su DNI, nombre
completo, dirección de correo electrónico.
Los tipos de entidades que hemos localizado son: ALUMNO, CURSO, TUTOR,
AULA y ADMINISTRADOR. Del enunciado se podría deducir que
COORDINADOR es también un tipo de entidad; dejamos para más adelante la

24
discusión sobre si este concepto puede representarse como una entidad, un
atributo o una interrelación.

2º paso: Identificar y enumerar las posibles interrelaciones, teniendo en cuenta la

siguiente heurística: en general, una interrelación viene reflejada por un verbo
dentro de una oración que relaciona dos objetos.

En el texto aparece un número correlativo como superíndice en los verbos que

indican la posible existencia de una interrelación.
• La información que se desea almacenar en la Base de datos se refiere a los
alumnos matriculados1 en cada curso. Teniendo en cuenta la fecha de inicio de
cada alumno en un determinado curso así como su fecha de finalización y
sabiendo que un alumno se ha podido matricular de uno o varios cursos y que
un curso tiene como mínimo un alumno.
• De los alumnos se desea saber el DNI, nombre completo, dirección,
teléfono, nacionalidad, pero sólo interesa saber si la nacionalidad es española
o no, y la dirección de correo electrónico. La dirección de correo electrónico es
imprescindible para poder realizar los cursos y además única para cada
alumno.
• La información referente a los cursos consta de nombre de este, título del
libro de consulta que utiliza (aunque existen cursos que no lo poseen) y
dirección de Internet donde se encuentra todo el material del que consta.
• Cada curso tiene asociado2 un grupo de personas expertas, llamadas
tutores, que son las encargadas de resolver los problemas propuestos por los
alumnos, la evaluación de los mismos e incluso el hombro para que estos se
desahoguen. Dentro de los tutores de un mismo curso existe una figura
importante que es la de coordinador que se encarga de realizar labores de
unificación. No hay que olvidar que una persona experta puede ser tutora de
varios cursos y que además un coordinador de curso es un tutor. La
información que se quiere almacenar en la BD acerca de los tutores es la
siguiente: DNI, nombre completo y dirección de correo electrónico.
• El proyecto MENTOR, además, tiene en cuenta que ha de facilitar a los
alumnos el acceso a Internet y por lo tanto a instalado aulas con todos los
servicios necesarios para el pleno desarrollo de los cursos.
• Cada alumno pertenece3 a un aula y el mantenimiento4 tanto de los
ordenadores como de los programas se lleva a cabo por los administradores
de aula.
• Cada aula tiene asignado un código único, un nombre y una dirección.
• La información que se necesita de cada administrador es su DNI, nombre
completo, dirección de correo electrónico.

25
Para que nos sea más sencillo saber qué tipos de entidades están relacionadas
vamos a construir una matriz donde en la primera fila y la primera columna se
enuncian los tipos de entidad anteriormente enumerados y se señalará en el cruce
de filas y columnas aquellas interrelaciones que hemos detectado. De esta forma
se facilita también la identificación de posibles interrelaciones que no aparecen
explícitamente expresadas en los supuestos semánticos del enunciado pero que
son, bien de sentido común, bien deducidas del enunciado; estas interrelaciones
también tienen que aparecer en el esquema E/R de la base de datos.

Interrelaciones ALUMNO CURSO TUTOR AULA ADMINISTRADOR

ALUMNO Matricular 1 Pertenecer 3

CURSO Asociar 2
¿Coordinar?

TUTOR
AULA Mantener 4

ADMINISTRADOR

En la tabla se muestra el nombre de las interrelaciones y una numeración que

indica el orden en el que han ido apareciendo en el texto; se muestran
sombreadas las celdas que representan interrelaciones simétricas a las definidas
en el resto de las celdas. Además de las interrelaciones extraídas del texto hay
que estudiar si en las celdas vacías deberían aparecer nuevas interrelaciones.
Así, podría existir la interrelación Coordinar entre TUTOR y CURSO; dejaremos
esta interrelación entre interrogaciones con el fin de estudiar posteriormente si
debe reflejarse de esta forma.
3er Paso: Dibujar las interrelaciones (estudiando el tipo de correspondencia y las
cardinalidades) y los tipos de entidad con los atributos correspondientes.

Interrelación Matricular
Tanto los atributos de CURSO como de ALUMNO se presentaron a lo largo del
capítulo, pero recordamos que el IP (identificador principal) de CURSO es Nombre
y el de ALUMNO es DNI. Tanto el atributo WWW como el e-mail son
26
identificadores alternativos, es decir, los valores que toman para cada elemento
del tipo de entidad CURSO o ALUMNO son únicos; Los atributos Libro y Teléfono
son opcionales. La figura 2.27 muestra el esquema E/R correspondiente a la
interrelación Matricular.
D.N.I. Nombre Dirección Nombre Libro WWW
e-mail
Teléfono

ALUMNO Matricul CURSO

Nacionalidad

El estudio del tipo de correspondencia y las cardinalidades máximas y mínimas

también se realizó durante el desarrollo del capítulo pero recordaremos que la
correspondencia es de muchos a muchos (N:M) ya que un alumno puede
matricularse de uno o varios cursos, cardinalidad (1,n), y en un curso se
matriculan uno o varios alumnos, cardinalidad (1,n). Además, para saber las
fechas en las que un alumno inició y finalizó un curso se introducen dos atributos
que pertenecen a la interrelación Matricular (figura 2.28)

D.N.I. Nombre Dirección Nombre Libro WWW

e-mail F_Comienzo
F_Finalización
Teléfono
M:N
(1,n) (1,n)
ALUMNO CURSO
Matricul
Nacionalidad

Interrelación Asociar

Antes de analizar las propiedades de la interrelación Asociar veamos los atributos

del tipo de entidad TUTOR.

Según se muestra en el enunciado, la información que se requiere para los tutores

es: DNI, nombre completo y dirección de correo. De estos tres atributos tenemos
que elegir cual de ellos puede ser el IP. Elegiremos el DNI aunque bien podría ser
la dirección de correo si esta es única.
27
Por lo que el e-mail será un atributo alternativo y el nombre completo un atributo
obligatorio.

El tipo entidad y sus atributos quedan representados como muestra la figura 2.29.
Nombre
completo
DNI e-mail

TUTOR

La interrelación Asociar relaciona las entidades TUTOR y CURSO (véase la tabla

del paso 2 y Figura 2.30); tenemos que estudiar el tipo de correspondencia y las
cardinalidades máximas y mínimas para completar las propiedades de la
interrelación.

Si leemos detenidamente las especificaciones del texto tenemos que un tutor

puede realizar sus labores en varios cursos y que en un curso puede ser tutorado
por varias personas expertas (tutores) por lo tanto la correspondencia es N:M o
muchos a muchos.

D NI Ncompleto ombre e-mail Nombre Libro

WWW
N:M

TUTOR Asociar CURSO

Veamos ahora las cardinalidades máximas y mínimas del tipo de entidad TUTOR
en la interrelación Asociar; para ello, tenemos que mirar al tipo de entidad
TUTOR y preguntarnos:

• ¿A cuántos cursos está asociado como mínimo un TUTOR? La respuesta

podría ser 0 si consideramos que podemos tener tutores que en un momento
dado no estén tutorando ningún curso, o, por el contrario, podríamos poner un 1

28
 con lo que supondríamos que todos los tutores que tenemos en nuestra base
de datos siempre estarán ocupados con algún curso. Nos quedamos con la
primera alternativa para poder dejar descanso a los tutores. De esta forma la
cardinalidad mínima es 0.

• ¿A cuántos cursos está asociado como máximo un TUTOR? En este caso,

como en las especificaciones no se restringe el número de cursos que un tutor
puede impartir, la cardinalidad máxima será N.

Gráficamente, las cardinalidades de la entidad TUTOR se representan al lado

contrario de esta, es decir, junto al tipo de entidad CURSO.

Nombre
DNI completo e-mail Nombre Libro WWW
N:M

(0,n)
TUTOR Asociar CURSO

De forma análoga se razonaría para el caso de las cardinalidades asociadas a

CURSO. Un curso como mínimo ha de ser tutorado por un TUTOR (cardinalidad
mínima 1) y como máximo por N (cardinalidad máxima N).

Nombre
DNI completo e-mail Nombre Libro WWW
N:M

(1 ,n) (0,n)
TUTOR Asociar CURSO

29
En los pasos 1 y 2 dejamos sin estudiar el concepto de coordinador de los cursos.
Volviendo a releer el texto nos preguntamos ¿qué pasa con la figura del
coordinador?, ¿cuál sería su representación?

Como bien se indica en los supuestos semánticos del enunciado, el coordinador

es también un tutor y, además, puede desarrollar una función añadida de
planificación en determinados cursos. Esto significa que un tutor en determinados
cursos (pero solamente en aquellos donde participa) puede realizar dos labores:
tutor y coordinador. Por lo que una solución puede ser considerar, dentro de la
interrelación Asocia un atributo, Coordinador, definido dentro del dominio Verdad
que toma los valores (SI, NO), y el cual nos indicará con el valor SI que un
determinado tutor desarrolla la función de coordinador en un curso con el que se
relaciona.

Nombre
DNI completo e-mail Nombre Libro WWW
N:M

(1 ,n) (0,n)
TUTOR Asociar CURSO

Coordinador

Analicemos como se interpreta el atributo Coordinador en la interrelación Asocia.

El atributo Coordinador toma un valor para cada ejemplar de la interrelación
Asociar; esto significa que como un determinado curso puede tener más de un
tutor y el atributo Coordinador podría tomar el valor de SI en esas ejemplares de
la interrelación Asocia, entonces estamos permitiendo en el esquema E/R que un
curso tenga más de un coordinador. Esto significa que no respetamos uno de los
supuestos semánticos del enunciado.

30
 3446721

7423412

4567433 TUTOR Asociar CURSO

SI
TUTOR Asociar CURSO
TUTOR Asociar CURSO
Diseño de BD
SI
NO Diseño de BD
Diseño de BD

Veámoslo con los ejemplos de ejemplares de la interrelación mostrados en la

figura; el curso “Diseño de BD” tiene tres tutores cuyos DNI son 3446721,
7423412, 4567433. El tutor con DNI 4567433 no es coordinador y los tutores con
DNI 3446721 y 7423412 están definidos con coordinadores. Si no queremos violar
la restricción semántica de que un curso no tenga más de un coordinador,
entonces en el diseño lógico de la BD se debería definir algún mecanismo que
cuando se haya definido un coordinador para un curso, entonces no se permita
introducir ninguno más. Sin embargo, la solución de la figura si contempla la
restricción semántica consistente en que los coordinadores de los cursos deben
ser tutores de los mismos, es decir, no es posible definir un coordinador de un
curso que no sea tutor del mismo.

Nombre
DNI completo e-mail Nombre Libro
WWW
N:M

(1, n) (0, n)
TUTOR Asociar CURSO

1:N
(1, 1) (0, n)

Coordinar

Otra posible solución para representar la semántica de la figura de coordinador de

un curso consiste en utilizar otra interrelación denominada Coordinar entre

31
TUTOR y CURSO con las cardinalidades mostradas en la figura. La interrelación
Coordinar representa que un determinado TUTOR puede ser coordinador de más
de un CURSO y que un CURSO tiene uno y solo un TUTOR que lo coordina. Si
bien esta propuesta de solución recoge a la perfección la restricción de que un
curso sólo tiene un coordinador, sin embargo, no recoge que el coordinador de un
curso tenga que ser obligatoriamente un tutor de ese curso (ver figura 2.36). Para
controlar esta última restricción habría que incluir un mecanismo en el diseño
lógico que obligara a que el coordinador de un curso debe ser un tutor del mismo.

3446721

7423412

4567433 TUTOR Asociar CURSO

TUTOR Asociar CURSO

TUTOR Asociar CURSO

Diseño de BD

2223456 Diseño de BD
Diseño de BD

Coordinar CURSO
TUTOR

Diseño de BD

Aunque existen otras formas de representar la figura del coordinador de un curso,

no vamos a presentarlas aquí con el fin de no complicar el ejercicio. Se han
mostrado las dos más significativas. Para este caso práctico se ha seleccionado la
primera propuesta de solución (considerar el atributo Coordinador en la
interrelación Asocia). De esta forma, el esquema E/R definido hasta el momento
se muestra en la figura:

32
 Nombre
DNI completo e-mail Nombre lLibro WWW
N:M

(1, n) (0, n)
TUTOR Asociar CURSO

F_Comienzo (1, n)
Coordinador
F_Finalización
Matricular N:M

nacionalidad = (española, no_española)

(1, n) Teléfono
coordinador = (SI, NO)
ALUMNO Nacionalidad

e-mail
DNI Nombre Dirección

Interrelación Pertenecer

Esta interrelación asocia las entidades ALUMNO y AULA. En primer lugar se

representarán los atributos del tipo de entidad AULA que (código_aula, nombre y
dirección). El código_aula será el IP, y el resto de atributos serán obligatorios.

Teléfono
1:N

AULA Pertenecer ALUMNO

e-mail
Nacionalidad
DNI
Código_aula Nombre Dirección Nombre Dirección

Para la interrelación Pertenecer tenemos un tipo de correspondencia de uno a

muchos porque según el enunciado cada ALUMNO pertenece a un AULA
(suponemos que un alumno no puede estar asociado a más de un aula); además,
un AULA puede tener asociados varios ALUMNOS. Las cardinalidad mínima y
máxima de ALUMNO es (1,1) ya que el alumno está asignado a una y solo un

33
AULA. Las asociadas a AULA serían (1,n) ya que no tendría mucho sentido
mantener un aula sin alumnos.

1:N Teléfono
(1,1) (1,n)
AULA Pertenecer ALUMNO

e-mail
Nacionalidad
DNI
Código_aula Nombre Dirección Nombre Dirección

El esquema E/R obtenido hasta el momento es el mostrado en la figura.

Nombre
DNI completo e-mail Nombre Libro WWW
N:M

(1, n) (0, n)
TUTOR Asociar CURSO

F_Comienzo (1, n)
Coordinador
F_Finalización

nacionalidad = (española, no_española) Matricular N:M

administrador = (SI, NO)

1:N (1, n) Teléfono
(1,1) (1,n) Nacionalidad
AULA Pertenecer ALUMNO

e-mail
DNI Nombre Dirección
Código_aula Nombre Dirección

Interrelación Mantener

La interrelación Mantener se da entre las entidades ADMINISTRADOR y AULA.

Los atributos del tipo de entidad ADMISTRADOR son DNI, nombre completo y e-
mail y representan el IP, un atributo obligatorio y otro alternativo, respectivamente.

34
El tipo de correspondencia es de uno a muchos (1:N) ya que un
ADMINISTRADOR solamente puede estar asignado a un AULA y sin embargo un
AULA puede ser mantenida por más de un ADMINISTRADOR lo que nos indica
también las cardinalidades: (1,n) para el tipo de entidad AULA y (1,1) para el tipo
de entidad ADMINISTRADOR.

35
 1:N

Observando el esquema E/R final, las entidades TUTOR y ADMINISTRADOR

tienen atributos comunes. Podremos identificar generalizaciones si encontramos
una serie de atributos comunes a un conjunto de entidades; estos atributos
comunes describirán al supertipo y los atributos particulares permanecerán en los
subtipos. Puede ocurrir que los subtipos no tengan atributos propios, como es el
caso que nos ocupa; en ese caso, sólo existirán subtipos si éstos van a participar
en interrelaciones (aparte de las interrelaciones en las que participe el supertipo).
Así, podemos tener, como muestra la figura. el supertipo PERSONA con los
atributos DNI, nombre y e-mail y los subtipos TUTOR y ADMINISTRADOR que no
tienen ningún atributo propio. Los subtipos TUTOR y ADMINISTRADOR siguen
participando en las mismas interrelaciones que en la figura. Sin embargo, el
supertipo PERSONA no participaría en ninguna interrelación; por ello, se ha
optado por eliminar la generalización de la solución propuesta.

Nombre
DNI completo e-mail

PERSON

TUTOR ADMINISTRADOR

36
 CONCLUSION

La finalidad de este trabajo, es dar una inducción en el tema de Diseño de Bases

de Datos, a personas ajenas al tema. De manera que por ello los temas se
presentan de una manera sencilla y sin tanta terminología.

Nos muestra la gran importancia que para cualquier entidad, ya sea una empresa
grande o chica, para el gobierno, hasta para la vida cotidiana de una persona
(como se muestra en el ejemplo de los CD’s), tienen las bases de datos. Todo gira
alrededor de ellas, todos los procesos del mundo están registrados en ellas, de ahí
la importancia de llevar a cabo un diseño eficiente y libre de errores de las
mismas.

Siempre que una persona escucha hablar de bases de datos y de toda la

terminología que las acompaña piensa que es un tema excesivamente
complicado, y no es así, todo tiene un porque y lógica, es cosa de familiarizarse un
poco con ellas (bases de datos).

Cuando se ven en realidad todas las ventajas que tienen, es mas sencillo el
proceso de aprendizaje, ya que siente que el aprender a manejarlas se vera
recompensado.

Además de los sencillas que son, es muy fácil acceder a información, manuales y
cursos relacionados a ellas, todo esta a la mano, con la facilidad de poner este
tema en un buscador de la red y aparecerán infinidad de temas, unos mas

37
complejos que otros, pero siempre uno que se adecue a las capacidades de
aprendizaje de cada persona.

Otro punto muy importante es que la mayoría son gratis.

BIBLIOGRAFIA

 CAMPBELl, Mary. base IV Guía de Autoenseñanza. España. Editorial

McGraw Hill – Interamericana. 1990. pp110/111,121/122,161,169, 179-
191/192.
 HARWRYSZKIEWYCZ, I T. Análisis y diseño de base de datos. Editorial
Megabyte. Noriega Editores. México. 1994. pp29/31
 LAUDON, Kenneth C. Administración de los sistemas de información. 3ra.
Edición. México. 1996. pp 271/295
 Aprende computación. Editorial océano. España. Pp36/39
 Búsquedas en Internet:
 [Link]/trabajos5/tipbases/[Link]
 [Link]/trabajos5/basede/[Link]
 [Link]/trabajos5/desor/[Link]
 [Link]/cpi/bancopub/libfree/lib607/[Link]
 [Link]/[Link]
 [Link]/spanish/glossary/[Link]
 [Link]/sie/

38
 MATERIA:
INFORMATICA
II

DOCENTE:
JORGE
VENTURA
AZAMAR

39
TEMA:
DISEÑO Y