0% encontró este documento útil (0 votos)

137 vistas31 páginas

Sistema de Gestion

Base de Datos

Cargado por

Sulmahryej

Derechos de autor

Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.

Formatos disponibles

Descarga como PDF, TXT o lee en línea desde Scribd

0% encontró este documento útil (0 votos)

137 vistas31 páginas

Sistema de Gestion

Base de Datos

Cargado por

Sulmahryej

Derechos de autor

Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.

Formatos disponibles

Descarga como PDF, TXT o lee en línea desde Scribd

Está en la página 1/ 31

20 Sistemas de gestión de bases de datos

1.9 USUARIOS DE LAS BASES DE DATOS

Existe una gran variedad de personas asociadas con la creación y el empleo de bases de datos.
Evidentemente, hay implementadores de bases de datos, que crean software de SGBD, y
usuarios finales, que desean guardar y utilizar datos de los SGBD. Los implementadores de
bases de datos trabajan para fabricantes como IBM u Oracle. Los usuarios finales vienen de un
número de campos diverso y creciente. A medida que los datos aumentan en complejidad y en
volumen, y se van reconociendo como un activo fundamental, la importancia de mantenerlos
en los SGBD se acepta cada vez más. Muchos usuarios finales se limitan a utilizar aplicaciones
escritas por programadores de aplicaciones de bases de datos (véase más abajo) y, por tanto,
no necesitan tener muchos conocimientos técnicos sobre el software de SGBD. Por supuesto,
los usuarios sofisticados que hacen un uso más amplio de los SGBD, como la escritura de sus
propias consultas, necesitan una comprensión más profunda de sus caracterı́sticas.
Además de los usuarios finales y de los implementadores, hay otras dos clases de usuarios
asociados con los SGBD: los programadores de aplicaciones y los administradores de bases de
datos.
Los programadores de aplicaciones de bases de datos desarrollan paquetes que
facilitan el acceso a los datos por parte de los usuarios finales, que generalmente no son
profesionales de la informática, mediante lenguajes anfitriones o de datos y herramientas
software que proporcionan los fabricantes de SGBD. (Entre esas herramientas figuran las
herramientas para la escritura de informes, las hojas de cálculo, los paquetes de estadı́stica y
similares.) Los programas de aplicación deberı́an tener acceso a los datos, en teorı́a, mediante
el esquema externo. Es posible escribir aplicaciones que tengan acceso a los datos en un nivel
inferior, pero esas aplicaciones pondrı́an en peligro la independencia con respecto a los datos.
Las bases de datos suelen estar mantenidas por la persona que las posee y las utiliza. Sin
embargo, las bases de datos corporativas suelen ser lo bastante importantes y complejas como
para que la tarea de diseñarlas y mantenerlas se confı́e a profesionales, denominados adminis-
tradores de bases de datos (database administrator, DBA). Los DBA son responsables
de muchas tareas crı́ticas:
Copyright © 2007. McGraw-Hill España. All rights reserved.

El diseño de los esquemas conceptual y fı́sico. El DBA es responsable de interactuar

con los usuarios del sistema para comprender los datos que se van a guardar en el SGBD
y la manera en que es más probable que se utilicen. Con ese conocimiento, el DBA debe
diseñar el esquema conceptual (decidir las relaciones que se van a guardar) y el fı́sico
(decidir la manera de guardarlas). Puede que el DBA también diseñe las partes más
utilizadas del esquema externo, aunque los usuarios hagan crecer este esquema mediante
la creación de vistas adicionales.
Seguridad y autorización. El DBA es responsable de garantizar que no se permita el
acceso sin autorización a los datos. En general, no todo el mundo debe poder tener acceso
a todos los datos. En los SGBD relacionales se puede conceder permiso a los usuarios para
el acceso tan sólo a determinadas vistas y relaciones. Por ejemplo, aunque puede que se
permita que los alumnos averigüen las matriculas de cada asignatura y quién las imparte,
no es probable que se desee que vean los sueldos de los profesores o la información sobre
las notas de los demás alumnos. El DBA puede aplicar esta polı́tica mediante la concesión
a los alumnos de permiso para leer tan sólo la vista Infoasignatura.
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción a los sistemas de bases de datos 21

Disponibilidad de los datos y recuperación en caso de fallo. El DBA debe tomar

medidas para garantizar que, en caso de fallo del sistema, los usuarios puedan seguir
teniendo acceso a tanta cantidad de datos que no se hayan deteriorado como sea posible.
El DBA también debe trabajar para devolver los datos a un estado consistente. Los
SGBD ofrecen soporte de software para estas funciones, pero el DBA es responsable de
la implementación de procedimientos para la realización periódica de copias de seguridad
y para el mantenimiento de los registros de la actividad del sistema (para facilitar la
recuperación en caso de fallo).
Ajuste de las bases de datos. Es probable que las necesidades de los usuarios evolu-
cionen con el tiempo. El DBA es responsable de modificar la base de datos, en especial
los esquemas conceptual y fı́sico, para garantizar un rendimiento adecuado a medida que
varı́en las exigencias.

1.10 PREGUNTAS DE REPASO

Las respuestas a las preguntas de repaso pueden hallarse en los apartados indicados.
¿Cuáles son las ventajas principales del empleo de SGBD para administrar los datos en
aplicaciones que impliquen un amplio acceso a los datos? (Apartados 1.1, 1.4)
¿Cuándo se deben guardar los datos en SGBD en lugar de hacerlo en los archivos del
sistema operativo y viceversa? (Apartado 1.3)
¿Qué son los modelos de datos? ¿Qué es el modelo de datos relacional? ¿Qué es la
independencia con respecto a los datos y cómo la soportan los SGBD? (Apartado 1.5)
Explı́quense las ventajas de emplear un lenguaje de consultas para procesar los datos en
lugar de los programas habituales. (Apartado 1.6)
¿Qué son las transacciones? ¿Qué garantı́as ofrecen los SGBD con respecto a las transac-
ciones? (Apartado 1.7)
Copyright © 2007. McGraw-Hill España. All rights reserved.

¿Qué son los bloqueos de los SGBD y por qué se emplean? ¿Qué es el registro previo
a la escritura y por qué se utiliza? ¿Qué son los puntos de control y por qué se usan?
(Apartado 1.7)
Identifı́quense los principales componentes de los SGBD y explı́quese brevemente lo que
hace cada uno de ellos. (Apartado 1.8)
Explı́quense los diferentes papeles de los administradores de bases de datos, los progra-
madores de aplicaciones y los usuarios finales de las bases de datos. ¿Quién necesita saber
más sobre los sistemas de bases de datos? (Apartado 1.9)

EJERCICIOS
Ejercicio 1.1 ¿Por qué elegir un sistema de bases de datos en lugar de limitarse a guardar los datos en los
archivos del sistema operativo? ¿Cuándo tendrı́a sentido no emplear un sistema de bases de datos?

Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
22 Sistemas de gestión de bases de datos

Ejercicio 1.2 ¿Qué es la independencia lógica con respecto a los datos y por qué es importante?

Ejercicio 1.3 Explı́quese la diferencia entre la independencia lógica con respecto a los datos y la fı́sica.

Ejercicio 1.4 Explı́quense las diferencias entre los esquemas externo, interno y conceptual. ¿Cómo están
relacionadas estas capas de esquemas con los conceptos de independencia lógica y fı́sica con respecto a los
datos?

Ejercicio 1.5 ¿Cuáles son las responsabilidades de los DBA? Si se supone que el DBA no está interesado en
ejecutar nunca sus propias consultas, ¿sigue necesitando comprender la optimización de las consultas? ¿Por
qué?

Ejercicio 1.6 Avaro Puñocerrado desea guardar la información (nombres, direcciones, descripciones de mo-
mentos embarazosos, etc.) sobre las muchas vı́ctimas de su lista. Como era de esperar, el volumen de datos
le impulsa a comprar un sistema de bases de datos. Para ahorrar dinero, desea comprar uno con las mı́nimas
caracterı́sticas posibles, y piensa ejecutarlo como aplicación independiente en su ordenador personal. Por su-
puesto, Avaro no piensa compartir esa lista con nadie. Indı́quese por cuáles de las siguientes caracterı́sticas de
los SGBD debe pagar Avaro; en cada caso, indı́quese también el motivo de que Avaro deba (o no) pagar por
esa caracterı́stica del sistema que va a comprar.
1. Un dispositivo de seguridad.
2. Control de la concurrencia.
3. Recuperación de fallos.
4. Un mecanismo de vistas.
5. Un lenguaje de consultas.

Ejercicio 1.7 ¿Cuál de los elementos siguientes desempeña un papel importante en la representación de la
información sobre el mundo real en las bases de datos? Explı́quese brevemente.
1. El lenguaje de definición de datos.
2. El lenguaje de manipulación de datos.
3. El gestor de la memoria intermedia.
4. El modelo de datos.
Copyright © 2007. McGraw-Hill España. All rights reserved.

Ejercicio 1.8 Descrı́base la estructura de un SGBD. Si se actualiza el sistema operativo para que soporte
alguna función nueva en los archivos del sistema operativo (por ejemplo, la posibilidad de obligar a que se
guarde en disco alguna secuencia de bytes), ¿qué capa(s) del SGBD habrı́a que volver a escribir para aprovechar
esas funciones nuevas?

Ejercicio 1.9 Respóndanse las preguntas siguientes:

1. ¿Qué son las transacciones?
2. ¿Por qué los SGBD intercalan las acciones de las diferentes transacciones en lugar de ejecutar una
transacción después de otra?
3. Qué deben garantizar los usuarios con respecto a las transacciones y a la consistencia de las bases de
datos? ¿Qué deben garantizar los SGBD con respecto a la ejecución concurrente de varias transacciones
y a la consistencia de las bases de datos?
4. Explı́quese el protocolo de bloqueo estricto de dos fases.
5. ¿Qué es la propiedad WAL y por qué es importante?

EJERCICIOS BASADOS EN PROYECTOS

Ejercicio 1.10 Empléese un navegador Web para examinar la documentación en HTML de Minibase. Inténte-
se captar la idea de su estructura global.

NOTAS BIBLIOGRÁFICAS
La evolución de los sistemas de gestión de bases de datos se describe en [189]. El empleo de modelos de datos
para la descripción de los datos del mundo real se trata en [270], mientras que [271] contiene una taxonomı́a
de los modelos de datos. Los tres niveles de abstracción se introdujeron en [118, 432]. El modelo de datos en
red se describe en [118], mientras que [472] trata de varios sistemas comerciales basados en ese modelo. [438]
contiene un buen conjunto comentado de trabajos orientados a los sistemas sobre la gestión de las bases de
datos.
Entre los textos que tratan de los sistemas de gestión de bases de datos están [137, 157, 199, 220, 298,
347, 414, 455, 463]. En [136] se ofrece un estudio detallado del modelo relacional desde un punto de vista
conceptual y es destacable por su amplia bibliografı́a comentada. [346] presenta una perspectiva orientada al
rendimiento con referencias a varios sistemas comerciales. En [157] y [414] se ofrece una amplia cobertura de
los conceptos de los sistemas de bases de datos, incluido un estudio de los modelos de datos jerárquico y de
red. [220] pone el énfasis en la conexión entre los lenguajes de consultas para bases de datos y la programación
lógica. [463] se centra en los modelos de datos. De estos textos, [455] ofrece el tratamiento más detallado de
los aspectos teóricos. Entre los textos dedicados a los aspectos teóricos están [1, 29, 309]. El libro [452] incluye
un apartado sobre bases de datos que contiene artı́culos de investigación introductorios sobre diversos temas.
Copyright © 2007. McGraw-Hill España. All rights reserved.

¿Qué pasos se siguen en el diseño de bases de datos?

¿Por qué se utiliza el modelo ER para crear el diseño inicial?
¿Cuáles son los conceptos principales del modelo ER?
¿Cuáles son las directrices para un empleo eficaz del modelo ER?
¿Cómo encaja el diseño de bases de datos en el marco del diseño global de software
complejo en las grandes empresas?
¿Qué es UML y qué relación tiene con el modelo ER?
¾ Conceptos fundamentales: diseño de bases de datos, diseño conceptual, lógico y
fı́sico; modelo entidad-relación (ER), conjunto de entidades, conjunto de relaciones,
atributo, ejemplar, clave; restricciones de integridad, relaciones de una a varias y de
varias a varias, restricciones de participación; entidades débiles, jerarquı́as de clases,
agregación; UML, diagramas de clases, diagramas de bases de datos, diagramas de
componentes.
Copyright © 2007. McGraw-Hill España. All rights reserved.

Los grandes hombres de éxito del mundo han empleado su imaginación. Se adelantan en su
pensamiento, crean su propia imagen mental y luego trabajan para materializar esa imagen en todos
sus detalles, rellenando aquı́, añadiendo un poco allá, alterando esa pizca y aquélla, pero trabajando
sin pausa, construyendo sin pausa.

— Robert Collier

El modelo de datos entidad-relación (ER) permite describir los datos implicados en empresas
reales en términos de objetos y de sus relaciones, y se emplea mucho para desarrollar el
diseño preliminar de las bases de datos. Aporta conceptos útiles que permiten pasar de una
descripción informal de lo que los usuarios desean de su base de datos a otra más detallada
y precisa que se pueda implementar en un SGBD. En este capı́tulo se presenta el modelo ER
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
25
26 Sistemas de gestión de bases de datos

y se estudia el modo en que sus caracterı́sticas permiten modelar fielmente una amplia gama
de datos.
Se comenzará con una introducción al diseño de bases de datos en el Apartado 2.1 con
objeto de motivar el estudio del modelo ER. Dentro del contexto más general del proceso
global de diseño, el modelo ER se emplea en la fase denominada diseño conceptual de bases
de datos. Luego se introducirá el modelo ER en los apartados 2.2, 2.3 y 2.4. En el Apartado
2.5 se estudian aspectos del diseño de bases de datos que afectan al modelo ER. El diseño
conceptual de bases de datos para grandes empresas se trata brevemente en el Apartado 2.6.
En el Apartado 2.7 se presenta una visión general de UML, un enfoque de diseño y modelado
de ámbito más general que el modelo ER.
En el Apartado 2.8 se presenta el estudio de un caso que se emplea como ejemplo a lo
largo de todo el libro. El caso que se estudia es el diseño de principio a fin de una base de
datos para una tienda en Internet. Se ilustran los dos primeros pasos del diseño de bases de
datos (análisis de requisitos y diseño conceptual) en el Apartado 2.8. En capı́tulos posteriores
se amplı́a este caso de estudio para tratar el resto de pasos del proceso de diseño.
Es de destacar que se han utilizado muchas variaciones de los diagramas ER y que no
se ha impuesto ninguna norma generalmente aceptada. La presentación de este capı́tulo es
representativa de la familia de modelos ER e incluye una selección de las caracterı́sticas más
populares.

2.1 DISEÑO DE BASES DE DATOS Y DIAGRAMAS ER

Se comienza el estudio del diseño de bases de datos mediante la observación de que no suele
tratarse más que de una parte, aunque fundamental para las aplicaciones que hacen amplio
uso de los datos, del diseño de sistemas de software de mayor alcance. No obstante, el principal
centro de atención de este libro es el diseño de la base de datos, y sólo se tratarán por encima
otros aspectos del diseño de software. Este punto se vuelve a tratar en el Apartado 2.7.
El proceso de diseño de bases de datos puede dividirse en seis etapas. El modelo ER es
muy relevante para los tres primeros pasos.
Copyright © 2007. McGraw-Hill España. All rights reserved.

1. Análisis de requisitos. El primer paso del diseño de aplicaciones de bases de datos es

comprender los datos que se deben guardar en la base de datos, las aplicaciones que se
deben construir sobre ellos y las operaciones que son más frecuentes e imponen requisitos
de rendimiento. En otras palabras, hay que averiguar lo que los usuarios esperan de la
base de datos. Se trata normalmente de un proceso informal que supone discusiones con
grupos de usuarios, un estudio del entorno operativo en vigor y del modo en que se espera
que éste cambie, el análisis de toda la documentación disponible sobre las aplicaciones
existentes que se espera que la base de datos sustituya o complemente, etc. Se han
propuesto varias metodologı́as para la organización y presentación de la información
recogida en esta etapa, y se han desarrollado algunas herramientas automatizadas para
soportar el proceso.
2. Diseño conceptual de bases de datos. La información reunida en el análisis de
requisitos se emplea para desarrollar una descripción de alto nivel de los datos que se van a
guardar en la base de datos, junto con las restricciones que se sabe que se impondrán sobre
esos datos. Este paso se suele llevar a cabo empleando el modelo ER y se discute en el resto
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 27

Herramientas para el diseño de bases de datos. Los fabricantes de SGBDR y otros

fabricantes ofrecen herramientas de diseño. Por ejemplo, véase el siguiente enlace para
conocer más detalles sobre las herramientas de diseño y análisis de Sybase:
http://www.sybase.com/products/application tools
El siguiente ofrece detalles sobre las herramientas de Oracle:
http://www.oracle.com/tools

de este capı́tulo. El modelo ER es uno de los modelos de datos de alto nivel, o semánticos,
empleados en el diseño de bases de datos. El objetivo es crear una descripción sencilla
de los datos que se acerque mucho a lo que los usuarios y los desarrolladores piensan de
los datos (y de la gente y de los procesos que se van a representar con esos datos). Esto
facilita la discusión entre todas las personas implicadas en el proceso de diseño, aunque
no tengan formación técnica. Al mismo tiempo, el diseño inicial debe ser lo bastante
preciso como para permitir una traducción directa a un modelo de datos soportado por
algún sistema comercial de bases de datos (lo que, en la práctica, significa el modelo
relacional).
3. Diseño lógico de bases de datos. Hay que escoger un SGBD que implemente nuestro
diseño de la base de datos y transformar el diseño conceptual de la base de datos en un
esquema de base de datos del modelo de datos del SGBD elegido. Sólo se considerarán
SGBD relacionales y, por tanto, la tarea en la etapa de diseño lógico es convertir el
esquema ER en un esquema de base de datos relacional. Este paso se examinará con
detalle en el Capı́tulo 3; el resultado es un esquema conceptual, a veces denominado
esquema lógico, del modelo de datos relacional.

2.1.1 Más allá del diseño ER

El diagrama ER no es más que una descripción aproximada de los datos creada mediante la
evaluación subjetiva de la información reunida durante el análisis de requisitos. A menudo,
un análisis más detenido puede refinar el esquema lógico obtenido al final del Paso 3. Una
vez se dispone de un buen esquema lógico hay que tomar en consideración los criterios de
rendimiento y diseñar el esquema fı́sico. Finalmente, hay que abordar los aspectos de seguri-
dad y garantizar que los usuarios puedan tener acceso a los datos que necesiten, pero no a los
que se les desee ocultar. Las tres etapas restantes del diseño de bases de datos se describen
brevemente a continuación:
4. Refinamiento de los esquemas. El cuarto paso del diseño de bases de datos es el
análisis del conjunto de relaciones del esquema relacional de la base de datos para iden-
tificar posibles problemas y refinarlo. A diferencia de los pasos de análisis de requisitos
y de diseño conceptual, que son esencialmente subjetivos, el refinamiento del esquema se
puede guiar por una teorı́a elegante y potente. Esa teorı́a de normalización de relaciones
—reestructurarlas para garantizar propiedades deseables— se estudia en el Capı́tulo 12.

5. Diseño fı́sico de bases de datos. En este paso se toman en consideración las cargas
de trabajo tı́picas esperadas que deberá soportar la base de datos y se refinará aún más
el diseño de la base de datos para garantizar que cumple los criterios de rendimiento
deseados. Puede que este paso no implique más que la creación de ı́ndices para algunas
tablas y el agrupamiento de otras, o puede que suponga un rediseño sustancial de partes
del esquema de la base de datos obtenido de los pasos de diseño anteriores. El diseño
fı́sico y el ajuste de las bases de datos se estudia en el Capı́tulo 13.
6. Diseño de aplicaciones y de la seguridad. Cualquier proyecto de software que impli-
que a una base de datos debe tomar en consideración aspectos de su aplicación que van
más allá de la propia base de datos. Las metodologı́as de diseño como UML (Apartado
2.7) intentan abordar todo el ciclo de diseño y desarrollo del software. En resumen, hay
que identificar las entidades (por ejemplo, los usuarios, los grupos de usuarios, los de-
partamentos) y los procesos relacionados con la aplicación. Hay que describir el papel de
cada entidad en cada proceso que se refleje en una tarea de la aplicación, como parte del
flujo de trabajo completo de esa tarea. Para cada papel hay que identificar las partes de
la base de datos que debe tener accesibles y las que no debe tener accesibles, y adoptar
las medidas necesarias para que esas reglas de acceso se cumplan. Los SGBD ofrecen
varios mecanismos para ayudar en este paso, y se tratan en el Capı́tulo 14.
En la fase de implementación hay que codificar cada tarea en un lenguaje de programa-
ción (por ejemplo, Java) y emplear el SGBD para tener acceso a los datos. El desarrollo de
aplicaciones se estudia en los Capı́tulos 6 y 7.
En general, la división del proceso de diseños en varios pasos deberı́a verse como una
clasificación de los tipos de pasos relacionados con el diseño. De manera realista, aunque se
podrı́a comenzar con el proceso en seis etapas que se ha esbozado aquı́, el diseño completo
de una base de datos probablemente necesite una fase posterior de ajuste en la que los seis
tipos de etapas del diseño se entrelacen y se repitan hasta que el diseño sea satisfactorio.

2.2 ENTIDADES, ATRIBUTOS Y CONJUNTOS

DE ENTIDADES
Una entidad es un objeto del mundo real que puede distinguirse de otros objetos. Ejemplos
de entidades son: el juguete Dragón verde, el departamento de juguetes, el responsable del
departamento de juguetes o la dirección postal del responsable del departamento de juguetes.
Suele resultar útil identificar conjuntos de entidades similares. Un conjunto ası́ se denomina
conjunto de entidades. Obsérvese que no hace falta que los conjuntos de entidades sean
disjuntos; tanto el conjunto de empleados del departamento de juguetes como el conjunto de
empleados del departamento de electrodomésticos pueden contener al empleado Juanjo Dı́az
(que resulta que trabaja en los dos departamentos). También se podrı́a definir un conjunto
de entidades denominado Empleados que contuviera tanto al conjunto de empleados del
departamento de juguetes como al de los empleados del departamento de electrodomésticos.
Cada entidad se describe empleando un conjunto de atributos. Todas las entidades de
un conjunto de entidades dado tienen los mismos atributos; eso es lo que quiere decir similar.
(Esta afirmación es una simplificación excesiva, como se verá cuando se discutan las jerarquı́as
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 29

de herencia en el Apartado 2.4.4, pero resulta suficiente por ahora y hace destacar la idea
principal.) La selección de los atributos refleja el nivel de detalle con el que se desea representar
la información relativa a las entidades. Por ejemplo, el conjunto de entidades Empleados
podrı́a utilizar el nombre, el número del documento nacional de identidad (DNI) y el número
de la plaza de aparcamiento de cada empleado. Sin embargo, no se guardará, por ejemplo, la
dirección del empleado (ni su sexo ni su edad).
Para cada atributo asociado con un conjunto de entidades hay que identificar el dominio
de valores posibles. Por ejemplo, el dominio asociado con el atributo nombre de Empleados
podrı́a ser el conjunto de cadenas de caracteres de longitud veinte1 . Como ejemplo adicional, si
la empresa califica a sus empleados según una escala del uno al diez y guarda las calificaciones
en un campo denominado calificaciones, el dominio asociado consistirá en los enteros del uno
al diez. Además, para cada conjunto de entidades, se escoge una clave. Una clave es un
conjunto mı́nimo de atributos cuyos valores identifican de manera unı́voca a cada entidad del
conjunto. Puede haber más de una clave candidata; en ese caso, se escogerá una de ellas
como clave principal. Por ahora se supondrá que cada conjunto de entidades contiene, como
mı́nimo, un conjunto de atributos que identifica de manera unı́voca a cada entidad de ese
conjunto; es decir, que el conjunto de entidades contiene una clave. Este punto se volverá a
tratar en el Apartado 2.4.3.
El conjunto de entidades Empleados con los atributos dni, nombre y plaza se muestra en la
Figura 2.1. Cada conjunto de entidades se representa por un rectángulo, y cada atributo por
un óvalo. Los atributos de la clave principal están subrayados. Se podrı́a indicar la información
sobre el dominio junto con el nombre de cada atributo, pero se ha omitido para que las figuras
sean más concisas. La clave es dni.

nombre

dni plaza

Empleados
Copyright © 2007. McGraw-Hill España. All rights reserved.

Figura 2.1 El conjunto de entidades Empleados

2.3 LAS RELACIONES Y LOS CONJUNTOS

DE RELACIONES
Una relación es una asociación entre dos o más entidades. Por ejemplo, puede que se tenga
una relación en que Avelino trabaja en el departamento farmaceútico. Al igual que con las
entidades, puede que se desee reunir un conjunto de relaciones similares en un conjunto de
1 Paraevitar confusiones se da por supuesto que los nombres de los atributos no se repiten en los conjuntos de
entidades. Esto no supone una verdadera limitación, ya que siempre se puede utilizar el nombre del conjunto de entidades
para resolver las ambigüedades si el mismo nombre de atributo se utiliza en más de un conjunto de entidades.

entidades. Se puede considerar a los conjuntos de relaciones como conjuntos de n-tuplas:

{(e1 , . . . , en ) | e1 ∈ E1 , . . . , en ∈ En }

Cada n-tupla denota una relación que implica a n entidades, e1 a en , donde la entidad ei
se halla en el conjunto de entidades Ei . En la Figura 2.2 puede verse el conjunto de relaciones
Trabaja en, en la que cada relación indica un departamento en el que trabaja ese empleado.
Obsérvese que puede que varios conjuntos de relaciones impliquen a los mismos conjuntos de
entidades. Por ejemplo, también se podrı́a tener un conjunto de relaciones Dirige que implique
a Empleados y Departamentos.

desde
nombre nombred

dni plaza idd presupuesto

Empleados Trabaja_en Departamentos

Figura 2.2 El conjunto de relaciones Trabaja en

Las relaciones también pueden tener atributos descriptivos. Los atributos descriptivos
se emplean para registrar la información sobre la relación, más que sobre las entidades parti-
cipantes; por ejemplo, puede que se desee registrar que Avelino trabaja en el departamento
farmaceútico desde enero de 1991. Esta información se captura en la Figura 2.2 añadiendo
un atributo, desde, a Trabaja en. Cada relación debe identificarse de manera unı́voca por
sus entidades participantes, sin necesidad de referencia alguna a los atributos descriptivos.
En el conjunto de relaciones Trabaja en, por ejemplo, cada relación Trabaja en debe quedar
Copyright © 2007. McGraw-Hill España. All rights reserved.

identificada de manera unı́voca por la combinación de empleado dni y departamento idd.

Por tanto, para una pareja empleado-departamento dada, no se puede tener más de un valor
desde asociado.
Cada ejemplar de un conjunto de relaciones es un conjunto de relaciones. De manera
intuitiva se puede considerar cada ejemplar como una “instantánea” del conjunto de relaciones
en un momento temporal dado. Puede verse un ejemplar del conjunto de relaciones Trabaja en
en la Figura 2.3. Cada entidad Empleados se denota por su dni, y cada entidad Departamentos
se denota por su idd, en aras de la simplicidad. El valor desde se muestra junto a cada
relación. (Los comentarios “varias a varias” y “participación total” de la figura se explican
más adelante, cuando se estudian las restricciones de integridad.)
Como ejemplo adicional de diagrama ER, supóngase que cada departamento tiene ofici-
nas en varias ubicaciones y que se desea registrar las ubicaciones en las que trabaja cada
empleado. Esta relación es ternaria, ya que hay que registrar la asociación entre cada em-
pleado, el departamento y la ubicación. El diagrama ER de esta variante de Trabaja en, que
se denominará Trabaja en2, puede verse en la Figura 2.4.

1/1/91

123.223.666 3/3/93
51
231.315.368
2/2/92
56
131.243.650
3/1/92
60
223.326.316
3/1/92

EMPLEADOS TRABAJA_EN DEPARTAMENTOS

Participación total Varias a varias Participación total

Figura 2.3 Un ejemplar del conjunto de relaciones Trabaja en

desde
Copyright © 2007. McGraw-Hill España. All rights reserved.

nombre nombred

dni plaza idd presupuesto

Empleados Trabaja_en2 Departamentos

dirección Ubicaciones capacidad

Figura 2.4 Un conjunto de relaciones ternarias

No hace falta que los conjuntos de entidades que participan en un conjunto de relaciones
sean distintos; puede que a veces una relación implique a dos entidades del mismo conjunto
de entidades. Por ejemplo, considérese el conjunto de relaciones Informa a que puede verse
en la Figura 2.5. Como los empleados rinden cuentas a otros empleados, las relaciones de
Informa a son de la forma (emp1 , emp2 ), donde tanto emp1 como emp2 son entidades de
Empleados. Sin embargo, interpretan papeles diferentes: emp1 rinde cuentas al empleado
encargado emp2 , lo que se refleja en los indicadores de papeles supervisor y subordinado
en la Figura 2.5. Si un conjunto de entidades desempeña más de un papel, el indicador de
papeles concatenado con un nombre de atributo del conjunto de entidades da un nombre
único para cada atributo del conjunto de relaciones. Por ejemplo, el conjunto de relaciones
Informa a tiene los atributos correspondientes al dni del supervisor y al dni del subordinado,
y el nombre de esos atributos es dni supervisor y dni subordinado.

nombre

dni plaza

Empleados

supervisor subordinado

Informa_a

Figura 2.5 El conjunto de relaciones Informa a

2.4 OTRAS CARACTERÍSTICAS DEL MODELO ER

A continuación se examinarán algunas de las estructuras del modelo ER que permiten des-
cribir algunas propiedades sutiles de los datos. La expresividad del modelo ER es una razón
importante de su amplia utilización.

2.4.1 Restricciones de clave en relaciones

Considérese la relación Trabaja en de la Figura 2.2. Cada empleado puede trabajar en varios
departamentos, y cada departamento puede tener varios empleados, como puede verse en la
Figura 2.3. El empleado 231.315.368 ha trabajado en el Departamento 51 desde 3/3/93 y en
el Departamento 56 desde 2/2/92. El Departamento 51 tiene dos empleados.
Considérese ahora otro conjunto de relaciones denominado Dirige entre los conjuntos de
entidades Empleados y Departamentos tal que cada departamento tenga como máximo un en-
cargado, aunque se permite que cada empleado dirija más de un departamento. La restricción
de que cada departamento tenga como máximo un encargado es un ejemplo de restricción de
clave, e implica que cada entidad de departamentos aparezca como máximo en una relación
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 33

Dirige en cualquier ejemplar admisible de Dirige. Esta restricción se indica en el diagrama

ER de la Figura 2.6 mediante una flecha que va de Departamentos a Dirige. De manera intui-
tiva, la flecha indica que, dada una entidad Departamentos, se puede determinar de manera
unı́voca la relación Dirige en la que aparece.

desde
nombre nombred

dni plaza idd presupuesto

Empleados Dirige Departamentos

Figura 2.6 Restricción de clave en Dirige

En la Figura 2.7 se muestra un ejemplar del conjunto de relaciones Dirige. Aunque se

trate también de un posible ejemplar del conjunto de relaciones Trabaja en, el ejemplar de
Trabaja en que puede verse en la Figura 2.3 viola la restricción de clave en Dirige.

123.223.666 3/3/93

51
231.315.368
2/2/92
56
131.243.650

60
223.326.316 3/1/92
Copyright © 2007. McGraw-Hill España. All rights reserved.

EMPLEADOS DIRIGE DEPARTAMENTOS

Participación parcial Una a varias Participación total

Figura 2.7 Ejemplar del conjunto de relaciones Dirige

Se dice a veces que los conjuntos de relaciones como Dirige son de una a varias, para
indicar que cada empleado se puede asociar con varios departamentos (en funciones de en-
cargado), mientras que cada departamento se puede asociar, como máximo, con un empleado
como encargado. Por el contrario, se dice que el conjunto de relaciones Trabaja en, en el que
se permite que cada empleado trabaje en varios departamentos y que cada departamento
tenga varios empleados, es de varias a varias.

Si se añade al conjunto de relaciones Dirige la restricción de que cada empleado pueda di-
rigir, como máximo, un departamento, lo que se indicarı́a añadiendo una flecha de Empleados
a Dirige en la Figura 2.6, se tendrá un conjunto de relaciones de una a una.

Restricciones de clave en relaciones ternarias

Se puede ampliar este convenio —y el concepto subyacente de restricción de clave— a los
conjuntos de relaciones que abarcan tres o más conjuntos de entidades: si el conjunto de
entidades E tiene una restricción de clave en el conjunto de relaciones R, cada entidad de
un ejemplar concreto de E aparecerá, como máximo, en una relación de (el ejemplar corres-
pondiente de) R. Para indicar una restricción de clave sobre el conjunto de entidades E del
conjunto de relaciones R, se traza una flecha de E a R.
En la Figura 2.8 se muestra una relación ternaria con una restricción de clave. Cada em-
pleado trabaja, como máximo, en un departamento y en una única ubicación. Puede verse un
ejemplar del conjunto de relaciones Trabaja en3 en la Figura 2.9. Téngase en cuenta que cada
departamento puede asociarse con varios empleados y ubicaciones y que cada ubicación puede
asociarse con varios departamentos y empleados; sin embargo, cada empleado está asociado
con un solo departamento y una única ubicación.

desde
nombre nombred

dni plaza idd presupuesto

Empleados Trabaja_en3 Departamentos

dirección Ubicaciones capacidad

Figura 2.8 Un conjunto de relaciones ternarias con restricción de clave

2.4.2 Restricciones de participación

La restricción de clave sobre Dirige indica que cada departamento tiene, como máximo,
un encargado. Una pregunta que resulta lógico formularse es si todos los departamentos
tienen encargado. Supongamos que se exige que cada departamento tenga un encargado.
Este requisito es un ejemplo de restricción de participación; se dice que la participación
del conjunto de entidades Departamentos en el conjunto de relaciones Dirige es total. Una
participación que no es total se dice de que es parcial. A modo de ejemplo, la participación
del conjunto de entidades Empleados en Dirige es parcial, ya que no todos los empleados
consiguen dirigir un departamento.
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 35

DEPARTAMENTOS

3/3/93 56

123.223.666
60
231.315.368 2/2/92

131.243.650
3/1/92

223.326.316 Roma
3/1/92

Delhi

EMPLEADOS TRABAJA_EN3 París

Restricción de clave
UBICACIONES

Figura 2.9 Un ejemplar de Trabaja en3

De vuelta al conjunto de relaciones Trabaja en, resulta natural esperar que cada empleado
trabaje, como mı́nimo, en un departamento y que cada departamento tenga, como mı́nimo, un
empleado. Esto significa que tanto la participación de Empleados como la de Departamentos
en Trabaja en es total. El diagrama ER de la Figura 2.10 muestra tanto al conjunto de
relaciones Dirige como al conjunto de relaciones Trabaja en y a todas las restricciones dadas.
Si la participación de un conjunto de entidades en un conjunto de relaciones es total, ambos
se conectan mediante una lı́nea gruesa; de manera independiente, la presencia de una flecha
indica una restricción de clave. Los ejemplares de Trabaja en y Dirige mostrados en las
Copyright © 2007. McGraw-Hill España. All rights reserved.

Figuras 2.3 y 2.7 satisfacen todas las restricciones de la Figura 2.10.

2.4.3 Entidades débiles

Hasta ahora se ha supuesto que entre los atributos asociados a un conjunto de entidades
se incluye una clave. Esta suposición no siempre se cumple. Por ejemplo, supóngase que los
empleados pueden suscribir pólizas de seguros que cubran a las personas que dependen de
ellos. Se desea registrar información sobre esas pólizas, incluyendo a las personas cubiertas
en cada póliza; pero esa información es, en realidad, lo único que interesa de las personas que
dependen de cada empleado. Si un empleado deja de serlo, las pólizas que hubiera suscrito
se cancelan, y se desea eliminar de la base de datos toda la información relevante sobre esas
pólizas y sobre las personas que dependen de ese antiguo empleado.
Se podrı́a decidir identificar en este caso a cada persona que depende de un empleado
únicamente por su nombre, ya que es razonable esperar que todas las personas que dependen
de un empleado tengan nombres diferentes. Por tanto, los atributos del conjunto de entidades
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
36 Sistemas de gestión de bases de datos

desde
nombre nombred

dni plaza idd presupuesto

Empleados Dirige Departamentos

Trabaja_en

desde

Figura 2.10 Dirige y Trabaja en

Beneficiarios podrı́an ser nombrep y edad. El atributo nombrep no identifica de manera unı́vo-
ca a cada persona que depende de un empleado. Recuérdese que la clave para Empleados es
dni; por tanto, se podrı́an tener dos empleados llamados Sánchez con un hijo llamado José.
Beneficiarios es un ejemplo de conjunto de entidades débiles. Cada entidad débil sólo se
puede identificar de manera unı́voca tomando en consideración alguno de sus atributos junto
con la clave principal de otra entidad, que se conoce como propietaria identificadora.
Se deben cumplir las restricciones siguientes:
El conjunto de entidades propietario y el conjunto de entidades débiles deben participar
Copyright © 2007. McGraw-Hill España. All rights reserved.

en un conjunto de relaciones de una a varias (cada entidad propietaria se asocia con una o
varias entidades débiles, pero cada entidad débil sólo tiene una propietaria). Este conjunto
de relaciones se denomina conjunto de relaciones identificadoras del conjunto de
entidades débiles.
El conjunto de entidades débiles debe tener participación total en el conjunto de relaciones
identificadoras.
Por ejemplo, cada entidad de Beneficiarios sólo se puede identificar de manera unı́voca si
se toma la clave de la entidad Empleados propietaria y nombrep de la entidad Beneficiarios.
El conjunto de atributos de un conjunto de entidades débiles que identifica de manera unı́voca
a una entidad débil para una entidad propietaria dada se denomina clave parcial del conjunto
de entidades débiles. En nuestro ejemplo, nombrep es una clave parcial de Beneficiarios.
El conjunto de entidades débiles Beneficiarios y su relación con Empleados se muestra
en la Figura 2.11. La participación total de Beneficiarios en Póliza se indica enlazándolos
mediante una lı́nea gruesa. La flecha que va de Beneficiarios a Póliza indica que cada entidad
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 37

de Beneficiarios aparece, como máximo, en una relación de Póliza (en realidad, exactamente
en una, debido a la restricción de participación). Para subrayar el hecho de que Beneficiarios es
una entidad débil y Póliza es su relación identificadora se dibujan las dos con lı́neas oscuras.
Para indicar que nombrep es una clave parcial de Beneficiarios, se subraya con una lı́nea
discontinua. Esto significa que puede haber perfectamente dos personas que dependan de
empleados y tengan el mismo valor de nombrep.

nombre
coste nombrep edad
dni plaza

Empleados Póliza Beneficiarios

Figura 2.11 Un conjunto de entidades débiles

2.4.4 Jerarquı́as de clases

A veces resulta natural clasificar las entidades en un conjunto de entidades en subclases. Por
ejemplo, puede que se desee hablar del conjunto de entidades Empleados temp y del conjunto
de entidades Empleados fijos para distinguir el modo en que se calcula su sueldo. Puede que
se hayan definido los atributos horas trabajadas y sueldo hora definidos para Empleados temp
y el atributo idcontrato para Empleados fijos.
Se desea que todas las entidades de cada uno de esos conjuntos sean también entidades
de Empleados y, como tales, deberán tener definidos todos los atributos de empleados. Por
tanto, los atributos definidos para una entidad Empleados temp dada son los atributos de
Empleados más los de Empleados temp. Se dice que los atributos del conjunto de entidades
Copyright © 2007. McGraw-Hill España. All rights reserved.

Empleados se heredan por el conjunto de entidades Empleados temp y que una entidad de
Empleados temp ES una entidad de Empleados. Además —y a diferencia de las jerarquı́as
de clases de los lenguajes de programación como C++— hay una restricción para las con-
sultas sobre los ejemplares de estos conjuntos de entidades: las consultas que pidan todas las
entidades Empleados también deben tomar en consideración las entidades Empleados temp
y Empleados fijos. La Figura 2.12 ilustra la jerarquı́a de clases.
El conjunto de entidades Empleados también se puede clasificar según un criterio diferente.
Por ejemplo, se puede identificar un subconjunto de empleados como Empleados veteranos.
Se puede modificar la Figura 2.12 para que refleje esta modificación añadiendo un segundo
nodo ES como hijo de Empleados y haciendo a Empleados veteranos hijo de ese nodo. Se
puede seguir clasificando cada uno de esos conjuntos de entidades y crear una jerarquı́a ES
multinivel.
Las jerarquı́as de clases se pueden considerar desde dos puntos de vista:
Empleados está especializada en subclases. La especialización es el proceso de identifi-
cación de subconjuntos de un conjunto de entidades dado (la superclase) que comparten
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
38 Sistemas de gestión de bases de datos

nombre

dni plaza

Empleado

ES
horas_trabajadas idcontrato

sueldo_hora
Empleados_temp Empleados_fijos

Figura 2.12 Jerarquı́a de clases

alguna caracterı́stica distintiva. Generalmente se define en primer lugar la superclase, a

continuación se definen las subclases y luego se añaden los atributos y los conjuntos de
relaciones especı́ficos de cada subclase.
Empleados temp y Empleados fijos se generalizan mediante Empleados. Como ejemplo
adicional, se pueden generalizar los conjuntos de entidades Motoras y Coches en el con-
junto de entidades Vehı́culos motorizados. La generalización consiste en identificar alguna
caracterı́stica común de un conjunto de conjuntos de entidades y crear un nuevo conjunto
de entidades que contenga entidades que posean esas caracterı́sticas comunes. General-
mente se definen en primer lugar las subclases, a continuación se define la superclase y
luego se definen los conjuntos de relaciones que implican a la superclase.
Se pueden especificar dos tipos de restricciones con respecto a las jerarquı́as ES: las restric-
Copyright © 2007. McGraw-Hill España. All rights reserved.

ciones de solapamiento y de cobertura. Las restricciones de solapamiento determinan si se

permite que dos clases contengan la misma entidad. Por ejemplo, ¿puede Avelino ser una enti-
dad Empleados temp y una entidad Empleados fijos a la vez? De manera intuitiva, no. ¿Puede
ser a la vez una entidad Empleados fijos y una entidad Empleados veteranos? De manera in-
tuitiva, sı́. Esto se denota escribiendo “Empleados fijos SOLAPA A Empleados Veteranos”. En
ausencia de una afirmación de este tipo, se da por supuesto de manera predeterminada que
se restringe a los conjuntos de entidades a no solaparse.
Las restricciones de cobertura determinan si las entidades de las subclases incluyen de
manera colectiva a todas las entidades de la superclase. Por ejemplo, ¿tienen que pertenecer
todas las entidades Empleados a alguna de sus subclases? De manera intuitiva, no. ¿Tienen
que ser todas las entidades Vehı́culos motorizados una entidad Motoras o una entidad Coches?
De manera intuitiva, sı́; una propiedad caracterı́stica de las jerarquı́as de generalización es
que todos los ejemplares de una superclase son, a su vez, ejemplares de una subclase. Esto se
denota escribiendo “Motoras Y Coches CUBREN Vehı́culos motorizados”. En ausencia de una
afirmación de este tipo se supone de manera predeterminada que no hay ninguna restricción
de cobertura; se pueden tener vehı́culos de motor que no sean ni motoras ni coches.
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 39

Hay dos motivos básicos para identificar subclases (por especialización o por generaliza-
ción):
1. Puede que se desee añadir atributos descriptivos que sólo tengan sentido para las enti-
dades de una subclase dada. Por ejemplo, sueldo hora no tiene sentido para una entidad
Empleados fijos, cuya paga se determina mediante un contrato individual.
2. Puede que se desee identificar el conjunto de entidades que participan en una relación
dada. Por ejemplo, puede que se desee definir la relación Dirige de modo que los conjuntos
de entidades participantes sean Empleados veteranos y Departamentos, para garantizar
que sólo los empleados veteranos puedan ser encargados. Como ejemplo adicional, pue-
de que Motoras y Coches tengan atributos descriptivos diferentes (por ejemplo, tonelaje
y número de puertas) pero, como entidades de Vehı́culos motorizados, deben estar ma-
triculados. La información sobre la matrı́cula se puede capturar mediante una relación
Matriculado por entre Vehı́culos motorizados y un conjunto de entidades denominado
Propietarios.

2.4.5 Agregación
Como se ha definido hasta ahora, un conjunto de relaciones es una asociación entre conjuntos
de entidades. A veces hay que modelar las relaciones entre un conjunto de entidades y de
relaciones. Supóngase que se tiene un conjunto de entidades denominado Proyectos y que
cada entidad de Proyectos está patrocinada por uno o varios departamentos. El conjunto de
relaciones Patrocina captura esa información. El departamento que patrocina un proyecto
puede asignar empleados para que controlen el patrocinio. De manera intuitiva, Controla
deberı́a ser un conjunto de relaciones que asocie relaciones Patrocina (en vez de entidades
Proyectos o Departamentos) con entidades Empleados. Sin embargo, las relaciones que se han
definido asocian dos o más entidades, no relaciones.
Para definir un conjunto de relaciones como Controla se introduce una nueva caracterı́stica
del modelo ER, denominada agregación. La agregación permite indicar que un conjunto
Copyright © 2007. McGraw-Hill España. All rights reserved.

de relaciones (identificado mediante un cuadro discontinuo) participa en otro conjunto de

relaciones. Esto se ilustra en la Figura 2.13, con un cuadro discontinuo alrededor de Patrocina
(y sus conjuntos de entidades participantes) para denotar la agregación. Esto permite tratar
de manera efectiva Patrocina como un conjunto de entidades a los efectos de definir el conjunto
de relaciones Controla.
¿Cuándo se debe emplear la agregación? De manera intuitiva se emplea cuando hace falta
expresar una relación entre relaciones. ¿Pero no se pueden expresar relaciones que impliquen
a otras relaciones sin emplear la agregación? En el ejemplo anterior, ¿por qué no hacer de
Patrocina una relación ternaria? La respuesta es que realmente hay dos relaciones diferentes,
Patrocina y Controla, cada una de las cuales tendrá sus propios atributos. Por ejemplo, la
relación Controla tiene el atributo hasta que registra la fecha hasta la que un empleado ha
sido nombrado controlador del patrocinio. Compárese este atributo con el atributo desde de
Patrocina, que es la fecha en que el patrocinio entró en vigor. El empleo de la agregación
en lugar de una relación ternaria también puede deberse a determinadas restricciones de
integridad, como se explica en el Apartado 2.5.4.

nombre

dni plaza

Empleados

Controla hasta

desde
iniciado_el nombred

idp presupuestop idd presupuesto

Proyectos Patrocina Departamentos

Figura 2.13 Agregación

2.5 DISEÑO CONCEPTUAL DEL MODELO ER

El desarrollo de diagramas ER supone escoger entre varias opciones, como las siguientes:
¿Un concepto dado se debe modelar como entidad o como atributo?
¿Un determinado concepto se debe modelar como entidad o como relación?
¿Cuáles son los conjuntos de relaciones y sus correspondientes conjuntos de entidades
participantes? ¿Se deben emplear relaciones binarias o ternarias?
¿Se debe emplear la agregación?
Ahora se discutirán los problemas relacionados con la adopción de estas decisiones.

2.5.1 Entidades y atributos

Cuando se identifican los atributos de un conjunto de entidades no resulta a veces evidente
si una determinada propiedad se debe modelar como atributo o como conjunto de entidades
(y relacionarse con el primer conjunto de entidades mediante un conjunto de relaciones).
Por ejemplo, considérese añadir información sobre el domicilio al conjunto de entidades Em-
pleados. Una posibilidad es emplear el atributo domicilio. Esta opción resulta adecuada si
sólo hace falta registrar un domicilio por empleado y basta con pensar en el domicilio como
si fuera una cadena de caracteres. Una alternativa es crear un conjunto de entidades deno-
minado Domicilios y registrar las asociaciones entre empleados y domicilios mediante una
relación (por ejemplo, Tiene domicilio). Esta alternativa más compleja resulta necesaria en
dos situaciones:
Hay que registrar más de una dirección por empleado.
Se desea capturar la estructura de los domicilios en el diagrama ER. Por ejemplo, se
puede descomponer el domicilio en ciudad, provincia, paı́s y código postal, además de
Copyright © 2007. McGraw-Hill España. All rights reserved.

una cadena de caracteres para la información sobre la calle. Al representar el domicilio en

forma de entidad con esos atributos, se pueden soportar consultas como “Buscar todos
los empleados con domicilio en Madrid”.
Como ejemplo adicional de la conveniencia de modelar un concepto como conjunto de
entidades en vez de como atributo, considérese el conjunto de relaciones (denominado Tra-
baja en4) que puede verse en la Figura 2.14.
Sólo se diferencia del conjunto de relaciones Trabaja en de la Figura 2.2 en que tiene los
atributos desde y hasta, en lugar de sólo desde. De manera intuitiva, registra el intervalo
durante el que cada empleado trabaja para un departamento dado. Supóngase ahora que
cada empleado puede trabajar en un departamento dado en más de un periodo.
Esta posibilidad queda descartada por la semántica del diagrama ER, ya que cada relación
queda identificada de manera unı́voca por sus entidades participantes (recuérdese del Aparta-
do 2.3). El problema es que se desean registrar varios valores de los atributos descriptivos de
cada ejemplar de la relación Trabaja en4. (Esta situación es análoga a desear registrar varios
domicilios para cada empleado.) Se puede abordar este problema mediante la introducción
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
42 Sistemas de gestión de bases de datos

desde hasta
nombre nombred

dni plaza idd presupuesto

Empleados Trabaja_en4 Departamentos

Figura 2.14 El conjunto de relaciones Trabaja en4

de un conjunto de entidades denominado Permanencia, por ejemplo, con los atributos desde
y hasta, como puede verse en la Figura 2.15.

nombre nombred

dni plaza idd presupuesto

Empleados Trabaja_en4 Departamentos

desde Duración hasta

Figura 2.15 El conjunto de relaciones modificado Trabaja en4

valores. Dada esta caracterı́stica, se podrı́a hacer de Permanencia un atributo de Trabaja en4,
en vez de un conjunto de entidades; asociado con cada relación Trabaja en4 tendrı́amos un
conjunto de intervalos. Este enfoque es, quizás, más intuitivo que el modelado de Permanencia
como conjunto de entidades. Pese a todo, cuando esos atributos de tipo conjunto se trasladan
al modelo relacional, que no los soporta, el esquema relacional resultante es muy parecido a
lo que se obtiene considerando Permanencia como conjunto de entidades.

2.5.2 Entidades y relaciones

Considérese el conjunto de relaciones denominado Dirige de la Figura 2.6. Supóngase que se
concede a cada encargado de departamento el presupuesto discrecional (presupuestod), como
puede verse en la Figura 2.16, en la que también se ha renombrado el conjunto de relaciones
como Dirige2.

desde presupuestod
nombre nombred

dni plaza idd presupuesto

Empleados Dirige2 Departamentos

Figura 2.16 Entidades y relaciones

Dado un departamento, se conoce su encargado, su fecha de nombramiento y el presupuesto

de ese departamento. Este enfoque resulta natural si se da por supuesto que cada encargado
recibe un presupuesto discrecional diferente para cada departamento que dirige.
¿Pero qué ocurre si el presupuesto discrecional es una suma que abarca a todos los depar-
tamentos dirigidos por ese empleado? En ese caso, cada relación Dirige2 que implique a un
empleado dado tendrá el mismo valor del campo presupuestod, lo que lleva al almacenamiento
redundante de la misma información. Otro problema de este diseño es que induce a error;
sugiere que el presupuesto está asociado a la relación cuando, en realidad, está asociado al
encargado.
Estos problemas se pueden abordar mediante la introducción de un nuevo conjunto de
entidades denominado Encargados (que puede ubicarse por debajo de Empleados en la jerar-
quı́a ES, para mostrar que todos los encargados son también empleados). Los atributos desde
y presupuestod describen ahora a entidades encargado, como se pretendı́a. A modo de varia-
ción, aunque cada encargado tiene un presupuesto, cada uno de ellos puede tener una fecha
de nombramiento (como encargado) diferente para cada departamento. En ese caso, presu-
puestod es un atributo de Encargados, pero desde es un atributo del conjunto de relaciones
entre los encargados y los departamentos.
Copyright © 2007. McGraw-Hill España. All rights reserved.

La naturaleza imprecisa del modelado ER puede, por tanto, dificultar el reconocimiento de

las entidades subyacentes, y puede que se asocien atributos con relaciones en lugar de con las
entidades correspondientes. En general, esos errores llevan al almacenamiento redundante de
la misma información y pueden provocar muchos problemas. La redundancia y sus problemas
asociados se discuten en el Capı́tulo 12, y se presenta una técnica denominada normalización
para eliminar las redundancias de las tablas.

2.5.3 Relaciones binarias y ternarias

Considérese el diagrama ER de la Figura 2.17. Modela una situación en la que cada empleado
puede tener varias pólizas, cada póliza puede ser propiedad de varios empleados y cada
beneficiario puede estar cubierto por varias pólizas.
Supóngase que se tienen los requisitos adicionales siguientes:
Dos o más empleados no pueden poseer conjuntamente una póliza.

nombre

dni plaza nombrep edad

Empleados Cubre Dependen

Pólizas

idpóliza coste

Figura 2.17 Las pólizas como conjunto de entidades

Cada póliza debe ser propiedad de algún empleado.

Dependientes es un conjunto de entidades débiles, y cada entidad dependiente queda
identificada de manera unı́voca empleando nombrep junto con idpóliza de una entidad
póliza (que, de manera intuitiva, cubre a ese beneficiario).
El primer requisito sugiere que se ha impuesto una restricción de clave a Pólizas con
respecto a Cubre, pero esa restricción tiene el efecto secundario no deseado de que cada
póliza sólo pueda cubrir a un beneficiario. El segundo requisito sugiere que se ha impuesto
una restricción de participación total sobre Pólizas. Esta solución resulta aceptable si cada
póliza cubre, por lo menos, a un beneficiario. El tercer requisito nos obliga a introducir una
Copyright © 2007. McGraw-Hill España. All rights reserved.

relación identificadora que sea binaria (en esta versión de los diagramas ER, aunque hay
versiones en las que no es ése el caso).
Aun ignorando el tercer requisito, la mejor manera de modelar esta situación es emplear
dos relaciones binarias, como puede verse en la Figura 2.18.
Este ejemplo tiene realmente dos relaciones que implican a Pólizas, e intentar emplear una
sola relación ternaria (Figura 2.17) resulta inadecuado. Hay situaciones, no obstante, en las
que una relación asocia de manera inherente a más de dos entidades. Se ha visto un ejemplo
de ello en las Figuras 2.4 y 2.15.
Como ejemplo tı́pico de relación ternaria, considérense los conjuntos de entidades Repues-
tos, Proveedores y Departamentos, y el conjunto de relaciones Contratos (con el atributo
descriptivo cant) que los implica a todos ellos. Un contrato dado especifica que un determina-
do proveedor suministrará (una determinada cantidad de) un repuesto concreto a un cierto
departamento. Esta relación no puede capturarse de manera adecuada mediante un conjunto
de relaciones binarias (sin el empleo de la agregación). Con las relaciones binarias se puede
denotar que un proveedor “puede suministrar” determinados repuestos, que un departamento
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 45

nombre

dni plaza nombrep edad

Empleados Beneficiarios

Suscriptor Beneficiario

Pólizas

idpóliza coste

Figura 2.18 Las pólizas de nuevo

“necesita” ciertos repuestos o que un departamento “trata con” un proveedor dado. Ninguna
combinación de estas relaciones expresa de manera adecuada el significado de un contrato, al
menos por dos razones:
El hecho de que el proveedor P pueda suministrar el repuesto R, de que el departamento
D necesite el repuesto R y de que D compre a P no implica necesariamente que el
departamento D compre realmente el repuesto R al proveedor P.
No se puede representar adecuadamente el atributo cant de los contratos.

2.5.4 Agregación y relaciones ternarias

ternaria viene determinada principalmente por la existencia de una relación que vincule un
conjunto de relaciones con un conjunto de entidades (o un segundo conjunto de relaciones).
Puede que la decisión también se guı́e por determinadas restricciones de integridad que se
deseen expresar. Por ejemplo, considérese el diagrama ER mostrado en la Figura 2.13. De
acuerdo con ese diagrama, cada proyecto puede ser patrocinado por varios departamentos,
cada departamento puede patrocinar uno o varios proyectos y cada patrocinio está controlado
por uno o varios empleados. Si no hace falta registrar el atributo hasta de Controla, puede
resultar razonable emplear una relación ternaria como, por ejemplo, Patrocina2, como puede
verse en la Figura 2.19.
Considérese la restricción de que cada patrocinio (de un proyecto por un departamento)
esté controlado, como máximo, por un empleado. No se puede expresar esa restricción en
términos del conjunto de relaciones Patrocina2. Por otro lado, esa restricción se puede expre-
sar fácilmente trazando una flecha desde la relación agregada Patrocina a la relación Controla
de la Figura 2.13. Por tanto, la presencia de una restricción ası́ es un motivo más para el
empleo de la agregación en lugar de un conjunto de relaciones ternarias.
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
46 Sistemas de gestión de bases de datos

nombre

dni plaza

Empleados

iniciado_el nombred

idp presupuestop idd presupuesto

Proyectos Patrocina2 Departamentos

Figura 2.19 Empleo de una relación ternaria en lugar de la agregación

2.6 DISEÑO CONCEPTUAL PARA GRANDES

EMPRESAS
Hasta ahora nos hemos concentrado en las estructuras disponibles en el modelo ER para
la descripción de diversos conceptos y relaciones de las aplicaciones. El proceso de diseño
conceptual consiste en algo más que la mera descripción de pequeños fragmentos de la apli-
cación en términos del diagrama ER. Para las grandes empresas puede que el diseño exija
el esfuerzo de más de un diseñador y abarque datos y código de aplicaciones empleado por
varios grupos de usuarios. El empleo de un modelo de datos semántico de alto nivel, como los
diagramas ER, para el diseño conceptual en un entorno de este tipo ofrece la ventaja adicional
Copyright © 2007. McGraw-Hill España. All rights reserved.

de que el diseño de alto nivel se puede representar mediante diagramas y lo puede comprender
fácilmente la gran cantidad de personas que deben ofrecer aportaciones al proceso de diseño.
Un aspecto importante del proceso de diseño es la metodologı́a empleada para estructurar
el desarrollo del diseño global y garantizar que tenga en cuenta todos los requisitos de usuario
y sea consistente. El enfoque habitual es que se tomen en consideración los requisitos de
diversos grupos de usuarios, se resuelvan de algún modo los que entren en conflicto y se
genere un conjunto único de requisitos globales al final de la fase de análisis de requisitos. La
generación de un conjunto único de requisitos globales es una labor difı́cil, pero permite que
la fase de diseño conceptual se continúe con el desarrollo de un esquema lógico que abarque
todos los datos y a todas las aplicaciones de la empresa.
Un enfoque alternativo es el desarrollo de esquemas conceptuales independientes para
los diferentes grupos de usuarios y su posterior integración. Para integrar varios esquemas
conceptuales hay que establecer correspondencias entre las entidades, las relaciones y los
atributos, y hay que resolver numerosos tipos de conflictos (por ejemplo, de denominaciones,
incoherencias de dominios, diferencias en las unidades de medida, etcétera). Esta tarea es

intrı́nsecamente difı́cil. En algunas situaciones la integración de los esquemas no se puede

evitar; por ejemplo, cuando una organización se fusiona con otra, puede que haya que integrar
las bases de datos existentes. La integración de esquemas también aumenta de importancia a
medida que los usuarios van exigiendo el acceso a orı́genes de datos heterogéneos, a menudo
mantenidos por organizaciones diferentes.

2.7 EL LENGUAJE UNIFICADO DE MODELADO

Hay muchos enfoques del diseño integral de software, que abarcan todas las etapas desde la
identificación de los requisitos empresariales a las especificaciones finales para una aplicación
completa, incluidos el flujo de trabajo, las interfaces de usuario y muchos aspectos de los
sistemas de software que superan ampliamente las bases de datos y los datos que se guardan
en ellas. En este apartado se tratará brevemente un enfoque que está ganando popularidad,
denominado enfoque del lenguaje unificado de modelado (unified modeling language,
UML).
UML, al igual que el modelo ER, presenta la atractiva caracterı́stica de que sus estructuras
se pueden dibujar en forma de diagrama. Abarca un espectro del proceso de diseño de software
más amplio que el modelo ER:
Modelado de la empresa. En esta fase el objetivo es describir los procesos empresa-
riales implicados en la aplicación de software que se está desarrollando.
Modelado del sistema. La comprensión de los procesos empresariales se emplea para
identificar los requisitos de la aplicación de software. Una parte de esos requisitos son los
de la base de datos.
Modelado conceptual de la base de datos. Esta etapa corresponde a la creación
del diseño ER para la base de datos. Con ese objetivo, UML ofrece muchas estructuras
análogas a las del modelo ER.
Modelado fı́sico de la base de datos. UML ofrece también representaciones gráficas
Copyright © 2007. McGraw-Hill España. All rights reserved.

de las opciones de diseño fı́sico de la base de datos, como la creación de espacios de tablas
y de ı́ndices. (El diseño fı́sico de la base de datos se discute en capı́tulos posteriores, pero
no ası́ las estructuras de UML correspondientes.)
Modelado del sistema de hardware. Los diagramas UML se pueden emplear para
describir la configuración de hardware empleada para la aplicación.
Hay muchas clases de diagramas UML. Los diagramas de casos de uso describen las
acciones llevadas a cabo por el sistema en respuesta a las solicitudes de los usuarios, y las
personas implicadas en esas acciones. Estos diagramas especifican la funcionalidad externa
que se espera que soporte el sistema.
Los diagramas de actividad muestran el flujo de acciones en los procesos comerciales.
Los diagramas de estado describen las interacciones dinámicas entre los diferentes objetos
del sistema. Estos diagramas, empleados en el modelado de la empresa y en el del sistema,
describen el modo en que se va a implementar la funcionalidad externa, de manera consistente
con las reglas del negocio y con los procesos de la empresa.
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
48 Sistemas de gestión de bases de datos

Los diagramas de clases son parecidos a los diagramas ER, aunque son más generales
en el sentido de que se pretende que modelen entidades de aplicación (de manera intuitiva,
componentes importantes del programa) y sus relaciones lógicas, además de las entidades de
datos y sus relaciones.
Tanto los conjuntos de entidades como los de relaciones pueden representarse en UML
como clases, junto con las restricciones de las claves, las entidades débiles y las jerarquı́as
de clase. El término relación se emplea en UML de manera ligeramente diferente, y las
relaciones de UML son binarias. Esto conduce a veces a confusión sobre si los conjuntos de
relaciones de los diagramas ER que implican a tres o más conjuntos de entidades se pueden
representar directamente en UML. La confusión desaparece una vez que se comprende que
todos los conjuntos de relaciones (en el sentido de ER) se representan en UML como clases;
las “relaciones” binarias de UML son, en esencia, precisamente los enlaces mostrados en los
diagramas ER entre los conjuntos de entidades y los de relaciones.
Los conjuntos de relaciones con restricciones de las claves se suelen omitir de los diagramas
UML, y la relación se indica enlazando directamente los conjuntos de entidades implicados.
Por ejemplo, considérese la Figura 2.6. La representación UML de ese diagrama ER tendrı́a
una clase para Empleados y otra para Departamentos, y la relación Dirige se mostrarı́a
mediante un enlace entre ambas clases. El enlace se puede etiquetar con un nombre y la
correspondiente información de cardinalidad para mostrar que cada departamento sólo puede
tener un encargado.
Como se verá en el Capı́tulo 3, los diagramas ER se traducen en el modelo relacional me-
diante la transformación de cada conjunto de entidades o de relaciones en una tabla. Además,
como se verá en el Apartado 3.5.3, las tablas correspondientes a los conjuntos de relaciones
de una a varias suelen omitirse mediante la inclusión de alguna información adicional sobre
cada una de esas relaciones en la tabla correspondiente a alguno de los conjuntos de entida-
des implicados en las mismas. Por tanto, los diagramas de clases en UML se corresponden
estrechamente con las tablas creadas mediante la transformación de los diagramas ER.
En realidad, cada clase de los diagramas UML se transforma en una tabla del diagrama
UML de la base de datos correspondiente. Los diagramas de bases de datos en UML
Copyright © 2007. McGraw-Hill España. All rights reserved.

muestran el modo en que se representan las clases en la base de datos y contienen detalles
adicionales sobre la estructura de la base de datos, como las restricciones de integridad y
los ı́ndices. Los enlaces (“relaciones” de UML) entre las clases de UML conducen a diversas
restricciones de integridad entre las tablas correspondientes. Muchos detalles especı́ficos del
modelo relacional (por ejemplo, las vistas, las claves externas, los campos que pueden tener
valores nulos) y que reflejan opciones del diseño fı́sico (por ejemplo, los campos indexados)
se pueden modelar en los diagramas de bases de datos en UML.
Los diagramas de componentes en UML describen los aspectos de almacenamiento de las
bases de datos, como los espacios de tablas y las particiones de las bases de datos, ası́ como las
interfaces con las aplicaciones que tienen acceso a la base de datos. Finalmente, los diagramas
de implantación muestran los aspectos hardware del sistema.
El objetivo de este libro es concentrarse en los datos almacenados en las bases de datos y
en los aspectos de diseño relacionados. Para ello se adoptará una visión simplificada de las
otras etapas del diseño y desarrollo del software. Más allá de la discusión concreta de UML,
se pretende que el material de este apartado sitúe los aspectos de diseño que se tratan en el
contexto más amplio del diseño de software. Los autores esperan que esto ayude a los lectores
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
Introducción al diseño de bases de datos 49

interesados en una discusión más general del diseño de software a complementar este estudio
mediante referencias a otros materiales de su enfoque preferido al diseño global de sistemas.

2.8 ESTUDIO DE UN CASO: LA TIENDA

EN INTERNET
Como ilustración se introducirá ahora el estudio de un caso de diseño desde su comienzo
hasta su fin que se empleará como ejemplo permanente a lo largo del libro. TiposBD S.A.,
una conocida empresa de consultorı́a de bases de datos, ha sido requerida para ayudar a Benito
y Norberto (B&N) con el diseño y la implementación de su base de datos. B&N es una gran
librerı́a especializada en los libros sobre carreras de caballos, y ha decidido abrirse a Internet.
TiposBD comprueba primero que B&N desee y pueda pagar sus elevados honorarios y luego
convoca una comida de trabajo —que, naturalmente, se facturará a B&N— para realizar el
análisis de requisitos.

2.8.1 Análisis de requisitos

El propietario de B&N, a diferencia de muchas de las personas que necesitan una base de
datos, ha meditado ampliamente lo que desea y ofrece un resumen conciso:
“Me gustarı́a que los clientes pudieran examinar el catálogo de libros y realizar pedidos por
Internet. Actualmente acepto pedidos por teléfono. Tengo, sobre todo, clientes corporativos
que me llaman y me dan el código ISBN del libro y la cantidad que desean comprar; a menudo
pagan con tarjeta de crédito. Luego preparo el envı́o, que contiene los libros pedidos. Si no
dispongo de suficientes copias en el almacén, encargo copias adicionales y retraso el envı́o
hasta que llegan; prefiero enviar todo el pedido de cada cliente de una sola vez. Mi catálogo
incluye todos los libros que vendo. Para cada libro, el catálogo incluye su código ISBN, tı́tulo,
autor, precio de adquisición, precio de venta y año de publicación. La mayor parte de mis
clientes son habituales, y dispongo de un registro con su nombre y dirección. Los clientes
nuevos tienen que llamarme primero y abrir una cuenta antes de poder utilizar mi Web.
Copyright © 2007. McGraw-Hill España. All rights reserved.

En la nueva Web los clientes se deberı́an identificar antes de nada por su número de
identificación de cliente, que debe ser único. Luego deberı́an poder examinar el catálogo y
formular pedidos en lı́nea.”
Los consultores de TiposBD están un poco sorprendidos por la rapidez con que se ha
completado la fase de requisitos —suelen hacer falta semanas de discusiones (y muchas comi-
das y muchas cenas) llevarla a buen puerto— pero vuelven a su oficina para analizar esta
información.

2.8.2 Diseño conceptual

En la etapa de diseño conceptual, TiposBD desarrolla una descripción de alto nivel de los
datos en términos del modelo ER. El diseño inicial se puede ver en la Figura 2.20. Los libros
y los clientes se modelan como entidades y se relacionan mediante los pedidos que formulan
los clientes. Pide es un conjunto de relaciones que conecta los conjuntos de entidades Libros y
Clientes. Para cada pedido se almacenan los atributos siguientes: cantidad, fecha del pedido
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.
50 Sistemas de gestión de bases de datos

fecha_pedido tarjeta

autor stock cantidad fecha_envío

nombrec
título precio

idc dirección
isbn año_publicación

Libros Pedidos Clientes

Figura 2.20 Diagrama ER del diseño inicial

y fecha de envı́o. En cuanto se envı́a un pedido, se establece la fecha de envı́o; hasta entonces,
la fecha de envı́o se define como nula, lo que indica que ese pedido no se ha enviado todavı́a.
TiposBD tiene en este momento una reunión interna para la revisión del diseño, y se
suscitan varias dudas. Para proteger sus identidades, nos referiremos al jefe del equipo de
diseño como Tipo 1 y al revisor del diseño como Tipo 2.
Tipo 2: ¿Qué ocurre si un cliente realiza dos pedidos del mismo libro el mismo dı́a?
Tipo 1: Se trata el primer pedido mediante la creación de una relación Pide y el segundo
mediante la actualización del valor del atributo cantidad de esa relación.
Tipo 2: ¿Qué ocurre si un cliente realiza dos pedidos para libros diferentes el mismo dı́a?
Tipo 1: No hay problema. Cada ejemplar del conjunto de relaciones Pide relaciona al cliente
con un libro diferente.
Tipo 2: Ah, ¿pero qué ocurre si un cliente realiza dos pedidos del mismo libro en dı́as dife-
rentes?
Tipo 1: Se puede emplear el atributo fecha de pedido de la relación Pide para distinguir los
Copyright © 2007. McGraw-Hill España. All rights reserved.

dos pedidos.
Tipo 2: Oh, no, no se puede. Los atributos de Clientes y de Libros deben contener una clave
de Pide conjuntamente. Por tanto, este diseño no permite que un cliente realice pedidos del
mismo libro en dı́as diferentes.
Tipo 1: Pues vaya, tienes razón. Oh, bueno, probablemente no le importe a B&N; ya veremos.
TiposBd decide pasar a la fase siguiente, el diseño lógico de la base de datos; volveremos
a verlos en el Apartado 3.8.

2.9 PREGUNTAS DE REPASO

Las respuestas a las preguntas de repaso pueden encontrarse en los apartados indicados.
Indı́quense las principales etapas del diseño de bases de datos. ¿Cuál es el objetivo de
cada etapa? ¿En qué etapa se emplea principalmente el modelo ER? (Apartado 2.1)
Defı́nanse estos términos: entidad, conjunto de entidades, atributo, clave. (Apartado 2.2)
Ramakrishnan, Raghu, and Johannes Gehrke. Sistemas de gestión de bases de datos (3a. ed.), McGraw-Hill España, 2007. ProQuest Ebook Central,
http://ebookcentral.proquest.com/lib/unadsp/detail.action?docID=3195347.
Created from unadsp on 2018-08-27 19:50:08.

También podría gustarte

1bases de Datos Introduccion y Modelo ER
Aún no hay calificaciones
1bases de Datos Introduccion y Modelo ER
61 páginas
Base de Datos Privativos y Libres
Aún no hay calificaciones
Base de Datos Privativos y Libres
16 páginas
Introducción a SGBD y sus Objetivos
Aún no hay calificaciones
Introducción a SGBD y sus Objetivos
14 páginas
Capítulo 1-Sistemas de Gestion de Base de Datos
Aún no hay calificaciones
Capítulo 1-Sistemas de Gestion de Base de Datos
24 páginas
Sistemas de Gestión de Bases de Datos, Relacionales, No Relacionales y Orientadas A Objetos
Aún no hay calificaciones
Sistemas de Gestión de Bases de Datos, Relacionales, No Relacionales y Orientadas A Objetos
52 páginas
A1.1 Mat. de Apoyo. Sistema Gestor de Base de Datos
Aún no hay calificaciones
A1.1 Mat. de Apoyo. Sistema Gestor de Base de Datos
30 páginas
Usuarios y Administradores de La Base de Datos
Aún no hay calificaciones
Usuarios y Administradores de La Base de Datos
2 páginas
Fundamentos de Bases de Datos
Aún no hay calificaciones
Fundamentos de Bases de Datos
30 páginas
Tema 1 Introducción A Los Sistemas Gestores de Bases de Datos (SGBD)
Aún no hay calificaciones
Tema 1 Introducción A Los Sistemas Gestores de Bases de Datos (SGBD)
13 páginas
Semana 1 BD Utel
Aún no hay calificaciones
Semana 1 BD Utel
15 páginas
Base de Datos
Aún no hay calificaciones
Base de Datos
12 páginas
2.2a SGBD e Instalación
Aún no hay calificaciones
2.2a SGBD e Instalación
66 páginas
Bda - Unidad 1 Resumen
Aún no hay calificaciones
Bda - Unidad 1 Resumen
6 páginas
Conceptos de Bases de Datos
Aún no hay calificaciones
Conceptos de Bases de Datos
53 páginas
Actividad 1
Aún no hay calificaciones
Actividad 1
10 páginas
David y Irvin
Aún no hay calificaciones
David y Irvin
2 páginas
Clase1-Conceptos Fundametnales Base de Datos
Aún no hay calificaciones
Clase1-Conceptos Fundametnales Base de Datos
5 páginas
Introducción a SGBD y DDL
Aún no hay calificaciones
Introducción a SGBD y DDL
17 páginas
Bases de Datos Relacionales
Aún no hay calificaciones
Bases de Datos Relacionales
122 páginas
Base de Datos (Manejadores)
Aún no hay calificaciones
Base de Datos (Manejadores)
19 páginas
Semana 1
Aún no hay calificaciones
Semana 1
40 páginas
Conceptos Introductorios de Base de Datos
Aún no hay calificaciones
Conceptos Introductorios de Base de Datos
17 páginas
Capítulo 1 BD-1
Aún no hay calificaciones
Capítulo 1 BD-1
42 páginas
BDSM Desarrollo
100% (1)
BDSM Desarrollo
21 páginas
Introduccion A Las Bases de Datos.
Aún no hay calificaciones
Introduccion A Las Bases de Datos.
28 páginas
Solucion Guía Base de Datos
Aún no hay calificaciones
Solucion Guía Base de Datos
11 páginas
Base de Datos
100% (1)
Base de Datos
14 páginas
Tipos de BDD y SGBD
Aún no hay calificaciones
Tipos de BDD y SGBD
12 páginas
Introducción y Resumen TDI
Aún no hay calificaciones
Introducción y Resumen TDI
4 páginas
Open Class, Semana 1, Base de Datos
Aún no hay calificaciones
Open Class, Semana 1, Base de Datos
28 páginas
Semana 1 - Introduccion A Los SGBD
Aún no hay calificaciones
Semana 1 - Introduccion A Los SGBD
41 páginas
Capitulo I
Aún no hay calificaciones
Capitulo I
10 páginas
Tipos de Gestores de Bases de Datos
Aún no hay calificaciones
Tipos de Gestores de Bases de Datos
4 páginas
Apuntes BD
Aún no hay calificaciones
Apuntes BD
10 páginas
Sistemas de Bases de Datos I
Aún no hay calificaciones
Sistemas de Bases de Datos I
12 páginas
Clase 1
Aún no hay calificaciones
Clase 1
5 páginas
Tema 9 Bases de Datos
Aún no hay calificaciones
Tema 9 Bases de Datos
12 páginas
Introduccion BD
Aún no hay calificaciones
Introduccion BD
110 páginas
Introducción A Las Bases de Datos
Aún no hay calificaciones
Introducción A Las Bases de Datos
44 páginas
Introduccion BD
Aún no hay calificaciones
Introduccion BD
85 páginas
Apuntes de Clases - Base de Datos
Aún no hay calificaciones
Apuntes de Clases - Base de Datos
9 páginas
Taller 2
Aún no hay calificaciones
Taller 2
8 páginas
Base de Datos Presentacion01
Aún no hay calificaciones
Base de Datos Presentacion01
23 páginas
Objetivos de Un SGBD
Aún no hay calificaciones
Objetivos de Un SGBD
3 páginas
Introducción a los SGBD
Aún no hay calificaciones
Introducción a los SGBD
41 páginas
Introducción a Bases de Datos Relacionales
Aún no hay calificaciones
Introducción a Bases de Datos Relacionales
34 páginas
Ejercicio Word - Bases de Datos
Aún no hay calificaciones
Ejercicio Word - Bases de Datos
23 páginas
SGBD: Clave en la Gestión de Datos
Aún no hay calificaciones
SGBD: Clave en la Gestión de Datos
6 páginas
Sistemas Gestores de Base de Datos
0% (1)
Sistemas Gestores de Base de Datos
138 páginas
FORO SEMANA 1 Y 2 - Foro Base Datos
Aún no hay calificaciones
FORO SEMANA 1 Y 2 - Foro Base Datos
4 páginas
Actividad 1.1 Introduccion A La Base de Datos.
Aún no hay calificaciones
Actividad 1.1 Introduccion A La Base de Datos.
13 páginas
Introducción a Bases de Datos
Aún no hay calificaciones
Introducción a Bases de Datos
32 páginas
TP1 Bases de Datos
Aún no hay calificaciones
TP1 Bases de Datos
7 páginas
Presentacion I Parcial (Base de Datos I)
Aún no hay calificaciones
Presentacion I Parcial (Base de Datos I)
57 páginas
Sistemas Gestores de Bases de Datos-Analisis de Caracteristicas PDF
Aún no hay calificaciones
Sistemas Gestores de Bases de Datos-Analisis de Caracteristicas PDF
13 páginas
Introducción a Bases de Datos Relacionales
Aún no hay calificaciones
Introducción a Bases de Datos Relacionales
14 páginas
Introduccion BD
Aún no hay calificaciones
Introduccion BD
86 páginas
Introducción a Bases de Datos I
Aún no hay calificaciones
Introducción a Bases de Datos I
22 páginas
Bases de Datos Relacionales-2
Aún no hay calificaciones
Bases de Datos Relacionales-2
129 páginas
Aporte1 Trabajo Colaborativo 2
Aún no hay calificaciones
Aporte1 Trabajo Colaborativo 2
6 páginas
1 Taller Fisica 10 de 2021
Aún no hay calificaciones
1 Taller Fisica 10 de 2021
5 páginas
Guía - Fase 5 - Desarrollar Aplicaciones Con Autómatas
Aún no hay calificaciones
Guía - Fase 5 - Desarrollar Aplicaciones Con Autómatas
11 páginas
Guía Fase 4 - Operación y Gestión de Redes Telemáticas
Aún no hay calificaciones
Guía Fase 4 - Operación y Gestión de Redes Telemáticas
14 páginas
Compiladores y Procesadores de Lenguajes - (PG 42 - 78)
Aún no hay calificaciones
Compiladores y Procesadores de Lenguajes - (PG 42 - 78)
37 páginas
Practica 2
Aún no hay calificaciones
Practica 2
12 páginas
Variograma en El Modelamiento Geológico
Aún no hay calificaciones
Variograma en El Modelamiento Geológico
4 páginas
Ejemplo - Especificación de Los Requerimientos Funcionales y No Funcionales Del Software. GA1-220501092-AA4-EV01
Aún no hay calificaciones
Ejemplo - Especificación de Los Requerimientos Funcionales y No Funcionales Del Software. GA1-220501092-AA4-EV01
6 páginas
PD708 User
Aún no hay calificaciones
PD708 User
24 páginas
Directorio IPN
Aún no hay calificaciones
Directorio IPN
385 páginas
Visagismo - Original
Aún no hay calificaciones
Visagismo - Original
31 páginas
Curriculum Vitae - Velasquez Viviano - Actualizado
Aún no hay calificaciones
Curriculum Vitae - Velasquez Viviano - Actualizado
4 páginas
PRACT. IV - Estudiantes Grupos A y B
Aún no hay calificaciones
PRACT. IV - Estudiantes Grupos A y B
1 página
Co 01 S - 3 18 - (74077)
Aún no hay calificaciones
Co 01 S - 3 18 - (74077)
71 páginas
Ciberseguridad y Ciberdefensa - 02
Aún no hay calificaciones
Ciberseguridad y Ciberdefensa - 02
36 páginas
Diseño de Red LAN en Plásticos Bosco
Aún no hay calificaciones
Diseño de Red LAN en Plásticos Bosco
117 páginas
PNO Surtido CAC 2021
Aún no hay calificaciones
PNO Surtido CAC 2021
19 páginas
G31, Comprensión Lectora, Educación Física e Informática, 1B, JIP
Aún no hay calificaciones
G31, Comprensión Lectora, Educación Física e Informática, 1B, JIP
4 páginas
Uso de Tiras de LEDs para Reemplazar Lámparas CCFL en TV LCD
Aún no hay calificaciones
Uso de Tiras de LEDs para Reemplazar Lámparas CCFL en TV LCD
5 páginas
Diseño Del Trabajo
100% (4)
Diseño Del Trabajo
50 páginas
Tarea Virtual - 2 Gamificación Grupo 8
100% (1)
Tarea Virtual - 2 Gamificación Grupo 8
12 páginas
Clase Metodologica Moraima Chiliquinga
100% (3)
Clase Metodologica Moraima Chiliquinga
30 páginas
Manual Basico de WIFISLAX y Sus Herramientas de Auditoria PDF
100% (2)
Manual Basico de WIFISLAX y Sus Herramientas de Auditoria PDF
32 páginas
Ethical Hacking
Aún no hay calificaciones
Ethical Hacking
5 páginas
Taller de Investigación de Operaciones
Aún no hay calificaciones
Taller de Investigación de Operaciones
2 páginas
? (AC-S08) Semana 08 - Tema 01 Tarea - Práctica Calificada 1 (REDACCION 2 - TERMINADO)
Aún no hay calificaciones
? (AC-S08) Semana 08 - Tema 01 Tarea - Práctica Calificada 1 (REDACCION 2 - TERMINADO)
18 páginas
Generadores Congruenciales Lineales
Aún no hay calificaciones
Generadores Congruenciales Lineales
2 páginas
Guía para Registro de Construbase o PU Nube
Aún no hay calificaciones
Guía para Registro de Construbase o PU Nube
4 páginas
Instrucciones de Microcontroladores
Aún no hay calificaciones
Instrucciones de Microcontroladores
21 páginas
Guía Rápida de Microsoft Word
Aún no hay calificaciones
Guía Rápida de Microsoft Word
2 páginas
Curp Pade610614mvzlms09
Aún no hay calificaciones
Curp Pade610614mvzlms09
1 página
Tres Niveles de Abstracción... Chomsky
Aún no hay calificaciones
Tres Niveles de Abstracción... Chomsky
0 páginas
Examen Segunda Unidad
Aún no hay calificaciones
Examen Segunda Unidad
5 páginas
Barra de Herramientas de PowerPoint
Aún no hay calificaciones
Barra de Herramientas de PowerPoint
3 páginas
Plan de Ejecución Módulo EDICION 10
Aún no hay calificaciones
Plan de Ejecución Módulo EDICION 10
4 páginas
Documento Unitario
Aún no hay calificaciones
Documento Unitario
4 páginas