Entidades y relaciones de datos

Comenzamos a disear bookbiz usando una versin un tanto simplificada del modelado
entidad-relacin. En el nivel ms bsico, modelado de entidad-relacin (tambin llamado
modelado de entidad) significa identificar

Las cosas-entidades-sobre las cuales la informacin ser almacenada en el sistema de

base de datos

Las propiedades de estas entidades

Las relaciones entre las entidades

Entidades: cosas con una existencia independiente

Comencemos por considerar algunas de las entidades de la base de datos bookbiz. Si
ignoramos por el momento la mayor parte de la informacin financiera que las pistas de
bookbiz, una lista preliminar de entidades podra verse as:

Los autores que han escrito libros publicados por la empresa

Los propios libros

Los editores que trabajan para la empresa

Las editoriales filiales propiedad de la empresa

Cada elemento de esta lista es una entidad con una existencia independiente en el mundo
considerado, es decir, el mundo de la base de datos bookbiz. Cada uno est representado en
la base de datos por una tabla. (Otros tipos de elementos de datos tambin estn
representados por tablas, pero eso est saltando adelante.)
Las entidades tienen ciertas propiedades que se van a registrar en la base de datos. Entre las
propiedades se encuentran:
Nombre del libro
Precio del libro
Fecha de publicacin del libro
Nombre del autor
Direccin del autor
Nmero de telfono del autor
Nombre del editor
Direccin del editor
Nmero de telfono del editor
Nombre del editor
Direccin del editor

Cada propiedad o atributo de la entidad en cuestin (el autor, libro, editor o filial de
publicacin) es una columna potencial en la base de datos. Los nombres de columnas deben
seleccionarse para mayor claridad, para describir los tipos de valores que contienen la
columna y la brevedad, para minimizar tanto la escritura como el ancho de las pantallas.
La lista de entidades y propiedades que hemos identificado puede ser vista como un primer
paso tentativo para decidir sobre las tablas y columnas que se incluirn en la base de datos.
Puede bosquejar estas decisiones de la siguiente manera:

Diagramacin de entidades y atributos

Otra forma de ver la informacin est en un diagrama entidad-relacin, como se muestra en
la Figura 2.1. La convencin usual es mostrar cada tabla como una caja con las columnas que
aparecen en el interior.

Este esbozo de cuatro tablas, cada una con varias columnas, es una primera pualada en la
estructura de la base de datos; Puede imaginar que las tablas contendrn varias filas de
datos. Cada fila de una tabla representa una ocurrencia (o instancia) de la entidad, es decir,
un solo libro, autor, editor o empresa editora.

Claves principales
Uno de los trabajos del diseo de la base de datos es proporcionar una manera de distinguir
entre las ocurrencias de entidades para que el sistema pueda recuperar una determinada fila.
Como se podra haber adivinado, las filas (que representan las ocurrencias de entidades) se
distinguen entre s por los valores de la clave principal de la tabla. De hecho, como hemos
dicho, la definicin (informal) de una clave primaria es la columna o combinacin de columnas
que identifica de manera nica la fila.
Cul es la clave principal para cada una de estas tablas? Considere la tabla de autores. De
las columnas identificadas hasta ahora, nombre es el candidato obvio para la clave primaria:
El nombre de un autor lo distingue de otros autores, pero la columna de nombre es
problemtica como clave principal por varias razones. En primer lugar, el valor en el nombre
est compuesto por el nombre y apellido del autor. La combinacin de nombres y apellidos en
una columna es una mala idea, aunque slo sea porque sera difcil (en muchos sistemas,
imposible) clasificar autores por orden alfabtico por apellido. As que el primer cambio
necesario es dividir la columna de nombre (tanto en autores como en editores) en dos
columnas (ver Figura 2.2).

Ahora, con respecto a la cuestin de identificar la clave primaria de la tabla de autores, podra
parecer que la combinacin de las columnas au_lname y au_fname es la eleccin correcta. De
hecho, esa combinacin funcionara bastante bien, hasta que la tabla creciera lo
suficientemente grande como para contener nombres duplicados. Una vez que hay dos Mary
Smiths, por ejemplo, la combinacin au_lname-au_fname ya no identificara de manera nica
a cada autor.
Otro problema con el uso de valores como nombres como identificadores nicos es la
frecuencia con la que se introducen incorrectamente. Es fcil deletrear nombres: Imagine que
un empleado de entrada de datos en el telfono ingrese un nuevo registro sobre Anne Ringer,
o es Ann Ringer? Otros tipos de nombres propios, como nombres de empresas u
organizaciones, son an peores. Cuntas variaciones en la entrada de datos podra haber en
un nombre de la empresa, por ejemplo: AT & T, A.T. Y T., Ma Bell, y as sucesivamente. A una
computadora, estos nombres diferentes son todas compaas diferentes.
Finalmente, considere la volatilidad. Es probable que los nombres personales cambien debido
al matrimonio o al divorcio. Los nombres de las empresas pueden sucumbir a la rebranding o
la adquisicin.

Por estas razones, suele ser una buena idea crear una columna separada explcitamente
diseada para servir como clave principal. Los ejemplos del mundo real de estos
identificadores nicos son comunes: nmeros de Seguro Social, nmeros de identificacin de
empleados, nmeros de matrculas, nmeros de orden de compra, nmeros de identificacin
de estudiantes, nmeros de vuelo de aerolneas, etc.
En las tablas de autores y editores, usaremos los nmeros de Seguro Social. Para las tablas de
ttulos y editores, asignaremos arbitrariamente algunos cdigos de identificacin. Como
convencin de registro, subrayaremos estas columnas para mostrar que son claves primarias
(ver Figura 2.3).

A pesar de la importancia de las claves primarias, las primeras versiones de SQL no tenan
sintaxis para designarlas. El estndar ANSI de 1992 para SQL, ahora adoptado por la mayora
de los proveedores, soporta la clusula PRIMARY KEY en la sentencia CREATE TABLE (consulte
el Captulo 3 para ms detalles). Los proveedores tambin han desarrollado sus propios
mtodos de implementacin especficos para tratar este importante concepto.

Relaciones de uno a varios

En este punto tenemos estructuras para cuatro tablas en la base de datos bookbiz: autores,
ttulos, editores y editores. Se han especificado algunas de las propiedades de cada una de
las entidades descritas en las tablas y se ha identificado una clave primaria para cada tabla.
Sin embargo, es posible que haya notado que ciertas relaciones importantes entre los datos
an no estn representadas en el diseo propuesto. Por ejemplo, no hay nada en estas cuatro
tablas que le diga acerca de la conexin entre un editor en particular y los libros que pone.
La relacin entre editores y libros se puede describir como uno-a-muchos: Cada libro tiene
solamente un editor, mientras que cada editor puede producir muchos libros. Las relaciones
uno-a-muchos entre los datos a menudo se escriben como 1-a-N o 1: N.

Representacin de la relacin
Cmo puede representar esta relacin uno-a-muchos? En la base de datos bookbiz, un
primer impulso podra ser agregar una columna para title_id en la tabla de editores, como se
muestra en la Figura 2.4.

La columna title_id de la tabla publishers es una clave externa. Puede usarlo para apuntar a
filas especficas en la tabla de ttulos y unir el ttulo y la informacin del editor.
Lamentablemente, esta solucin propuesta enva su diseo de base de datos en la direccin
equivocada. Recuerde la relacin de datos que estamos modelando -un editor, muchos librosy considere lo que sucede cuando se publica un nuevo libro. Agregar una nueva fila a los
ttulos, con nombre de libro, precio, etc.

Para cada fila de ttulos, tendr que agregar una fila a los editores. La fila de editores repetir
tres columnas de informacin existente (nmero de editor, nombre y direccin) y agregar
una columna de nueva informacin (title_id) para apuntar a la descripcin ms completa en la
tabla de ttulos.

Recuerde que uno de los objetivos del diseo de la base de datos es controlar la redundancia
porque la redundancia introduce oportunidades de error. Una solucin mejor es agregar una
clave extranjera de editores a la tabla de ttulos (consulte la Figura 2.5).

Cuando salga un nuevo libro, agregue una fila (con una columna pub_id) a la tabla de ttulos.
No es necesario hacer nada a la tabla de editores a menos que la empresa asuma una nueva
filial.

Con estos cambios empieza a surgir una estructura:

La tabla de editores tiene una fila para cada editor.

La tabla ttulos tiene una fila para cada libro.

Los nmeros de ID de editor se repiten en la tabla de ttulos porque hay muchos libros
para cada editor, pero eso es mucho menos redundante de lo que ocurrira con otras
opciones.

Puede utilizar la conexin lgica entre las columnas pub_id en ttulos y editores para unir las
dos tablas. En otras palabras, este diseo se planifica teniendo en cuenta la operacin de
combinacin para permitir a los usuarios recuperar informacin sobre editores y ttulos en una
consulta.
En la tabla publishers, pub_id es la clave principal. En la tabla titles, la columna pub_id es una
clave externa. El modelo relacional requiere que las relaciones uno-a-muchos sean
representadas por medio de emparejamientos de clave primaria / clave externa.
Llaves extranjeras
Al igual que el concepto de clave primaria, el concepto de clave extranjera es crucial en el
diseo de la base de datos. Informalmente, una clave externa es una columna (o combinacin
de columnas) en una tabla, cuyos valores coinciden con los de la clave principal en otra tabla.
Una consideracin de la relacin lgica entre la informacin en las columnas de clave primaria
y externa introduce algunas preguntas adicionales. Qu sucede en la columna pub_id de la
tabla de ttulos si la fila que describe el editor se elimina o se cambia en la tabla de editores?
Se debera permitir que la descripcin de un libro se refiera a un nmero de ID de editor si
ese editor ya no existe en la base de datos? No tiene sentido lgicamente y viola la definicin
de una clave extranjera, que requiere que el valor de una columna de clave externa coincida
con el valor de una columna de clave principal en algn lugar de la base de datos. Sin
embargo, esta no es una situacin inusual en la vida real. La forma de manejarlo depende de
las reglas de su negocio.
Un diseo de base de datos completo debe incluir la planificacin de la clave principal /
consistencia de clave externa (o integridad referencial). Por ejemplo,

Cuando el nmero de ID de un editor se actualiza o elimina de la tabla de editores, el

sistema debe reproducir automticamente el cambio en la tabla de ttulos, ya sea
actualizando todos los valores correspondientes en la columna de ttulos de la
publicacin pub_id o copiando en cascada (propagando) Filas de ttulos con pub_ids
coincidentes.

Cuando se agrega un nuevo ttulo, el sistema debe tener una forma de verificar que el
pub_id asociado es vlido, es decir, que existe en la tabla publishers.

En este punto, slo tome nota de estos problemas. El captulo siguiente ofrece sugerencias
sobre cmo manejar algunos problemas de clave principal / clave externa con las
restricciones REFERENCES en la instruccin CREATE TABLE. Los proveedores tambin han
introducido formas especficas de implementacin para controlar la integridad, como las
extensiones de SQL para el cdigo de procedimiento que se pueden ejecutar en la base de
datos, a menudo denominadas procedimientos o disparadores (discutidos en el Captulo 10).

Relaciones entre muchos y muchos

Despus de identificar todas las relaciones uno-a-muchos en la base de datos bookbiz y
asociarlas con emparejamientos de clave principal / clave externa, el siguiente paso es
considerar otros tipos de relaciones de datos. Por ejemplo, cmo estn relacionados los
autores y los libros?
Algunos libros estn escritos por ms de un autor, y algunos autores han escrito ms de un
libro. En otras palabras, los autores y los libros tienen una relacin de muchos a muchos (a
menudo escrito como N-a-N, o N: N, ya veces se llama una asociacin). Segn la teora
entidad-relacin, las asociaciones en bases de datos relacionales deben ser representadas
como tablas propias. En otras palabras, la base de datos bookbiz necesita una tabla para
autores, una tabla para ttulos y una tabla para representar la asociacin entre ellos, como se
muestra en la Figura 2.6.

La tabla titleauthors representa la relacin many-to-many entre autores y libros. Es una tabla
de base como ttulos y autores, pero es una asociacin ms que una entidad independiente.
Cuando un usuario de la base de datos bookbiz quiere informacin sobre quin escribi qu
libros, l o ella escribe una consulta de unin que utiliza la tabla titleauthors como una tabla
de conexin entre ttulos y autores.
Las tablas titleauthors y titles se unen en sus respectivas columnas title_id; Titleauthors y
autores se unen en la columna au_id de cada tabla. En otras palabras, title_id en titleauthors
es una clave extranjera cuya clave primaria coincidente es title_id en ttulos; Au_id en
titleauthors es la clave extranjera cuya clave primaria coincidente es au_id en los autores.

Cul es la clave principal en titleauthors? Ni el ID del autor ni el ID del ttulo identifican de

forma exclusiva las filas en los autores de ttulo: Se repiten los ID de ttulos con ms de un
autor, as como los ID de autores que han escrito ms de un libro. Sin embargo, cada ID de
ttulo / combinacin de ID de autor es nica. La clave principal de titleauthors, entonces, es la
combinacin de title_id y au_id.
Las tablas de editores y ttulos tienen una relacin similar. Un editor puede trabajar en ms de
un libro, y un libro puede tener varios editores. Esta relacin de muchos a muchos tambin
requiere una mesa de conexin.

Relaciones uno-a-uno
Eche un vistazo final a las entidades. Si encuentra una relacin de uno a uno (1: 1) entre dos
tablas, es mejor que las colapse en una tabla. Sin embargo, mantener una relacin 1: 1 podra
mejorar la velocidad de respuesta en las consultas. Por ejemplo, si tiene informacin acerca
de los ttulos que utiliza pocas veces (notas sobre la informacin de copyright, listas de
pginas de cambio, por ejemplo), puede guardarla en una tabla aparte para que no tenga
acceso a la informacin cuando Ejecutando consultas comunes. En general, debe evitar las
estructuras 1: 1 cuando disea una base de datos, a menos que conozca sus datos muy bien.

El Enfoque Entidad-Relacin resumido

El modelo de la relacin entre las entidades es mucho ms amplio, ms preciso y ms
detallado que los procedimientos que hemos discutido tan brevemente aqu. Sin embargo, el
enfoque que acabamos de esbozar puede ayudarle a disear una buena base de datos que
compruebe la prxima metodologa de diseo a considerar, las reglas de normalizacin. Antes
de pasar a ese tema, he aqu una lista de revisin de los pasos bsicos discutidos hasta
ahora:
Representar a cada entidad independiente (libro, autor, editor, editor, empleado,
departamento, estudiante, curso, empresa, etc.) como una tabla base.
1. Representar a cada entidad independiente (libro, autor, editor, editor, empleado,
departamento, estudiante, curso, empresa, etc.) como una tabla base.
2. Representar cada propiedad de una entidad (direccin del autor, precio del libro, etc.)
como una columna de la tabla de la entidad.
3. Asegrese de que cada tabla tenga una clave primaria. La clave puede ser una
propiedad existente (un nombre) o artificial que agregue (un nmero de Seguro Social,
un nmero de pedido) o una combinacin de dos o ms propiedades. En cualquier caso,
debe describir de manera nica cada fila.
4. Busque las relaciones uno-a-muchos entre tablas. Compruebe que hay una o varias
columnas de clave externa en la tabla "muchos" que apuntan a las columnas de clave
principal en la tabla "una". Considere las restricciones de integridad referencial
asociadas con cada clave externa.
5. Representar cada relacin muchos-a-muchos (o asociacin) como una "tabla de
conexin" entre las dos tablas que participan en la asociacin. Incluya en esta tabla de
conexin claves forneas que apuntan a las tablas de entidades. La clave principal de
la tabla de conexin es a menudo la combinacin de esas claves forneas.
6. Collapse relaciones 1: 1 en una sola tabla, donde sea apropiado.
Despus de cada pase, revise sus necesidades de nuevo. Ha incorporado las reglas de
negocio? Puede obtener la informacin que necesita? Tal comprobacin contra los requisitos
del bookbiz revela algunas deficiencias: No hay manera de registrar la orden del autor o la
divisin de la realeza. Tampoco hay anotaciones para los contratos, y es necesario que
mantenga un registro de los avances. Las ventas son otro tema no cubierto en este diseo.
Con estos puntos en mente, puede modificar el diagrama E-R como se muestra en la Figura

2.7, agregando nuevos atributos y entidades y utilizando flechas para mostrar las relaciones
entre tablas. Si no est seguro de dnde va un atributo (como el orden de autor), no se
preocupe. Consgalo en la lista. Pasar por ms anlisis - atributos, entidades y relaciones antes de que se asiente en una forma final.