Modelamiento de Base de Datos

PROGRAMA NACIONAL DE INFORMATICA
Modelamiento de Datos
y diseo de Base de datos
MANUAL DEL PARTICIPANTE
MP0901
Modelamiento de datos
y diseo de BD
Manual del participante
TABLA DE CONTENIDO
CAPITULO 1 Introduccin
Un poco de historia .................................................................................................................... 3
Sistema de procesamiento de archivos..................................................................................... 4
Sistema de procesamiento de base de datos............................................................................ 4
Historia de procesamiento de base de datos ............................................................................ 4
Conceptos Bsicos .................................................................................................................... 5
Campo: ................................................................................................................................... 5
Registro: ................................................................................................................................. 5
Archivo:................................................................................................................................... 5
Base de datos:........................................................................................................................ 5
Sistema Manejador de Base de Datos. (DBMS).................................................................... 5
Esquema de base de datos:................................................................................................... 5
Administrador de base de datos (DBA):................................................................................. 5
El Modelo Relacional ................................................................................................................. 6
Ventajas del Modelo Relacional ............................................................................................. 6
Resistencia al Modelo Relacional .......................................................................................... 7
Productos DBMS para microcomputadoras ........................................................................... 7
Aplicaciones de bases de datos cliente servidor ................................................................... 8
Procesamiento distribuido de bases de datos ....................................................................... 8
Los DBMS Orientados a Objetos (ODBMS)........................................................................... 9
Ciclo de vida de una base de datos........................................................................................... 9
Caracteristicas de una Base de Datos .................................................................................... 11
La metodologa de diseo de datos......................................................................................... 14
El Modelo lgico....................................................................................................................... 14
Restricciones de integridad...................................................................................................... 15
Preguntas de repaso................................................................................................................ 19
CAPITULO 2 El Modelo Entidad Relacin

Definicin del Modelo Entidad-Relacin .................................................................................. 21
Entidades.............................................................................................................................. 21
Atributos ............................................................................................................................... 22
Identificadores ...................................................................................................................... 22
Relaciones ............................................................................................................................... 23
Tipos de Relaciones Binarias .................................................................................................. 23
Diagramas Entidad-Relacion ................................................................................................... 24
Atributos en los diagramas Entidad-Relacin ...................................................................... 25
Entidades dbiles ................................................................................................................. 26
Entidades Subtipo ................................................................................................................ 26
Documentacin de reglas de negocios.................................................................................... 27
Programa Nacional de Informtica
Modelamiento de
datos y diseo de BD
El modelo entidad-relacin y las herramientas CASE............................................................. 27

CAPITULO 3 El Modelo Relacional y la Normalizacin

El Modelo Relacional ............................................................................................................... 31
Dependencias funcionales ................................................................................................... 32
Claves................................................................................................................................... 33
Dependencias funcionales, claves y unicidad...................................................................... 34
Normalizacin .......................................................................................................................... 34
Clases de afinidades ............................................................................................................ 34
Definicin de la clave............................................................................................................ 35
Primera forma normal (1NF)................................................................................................. 36
Segunda forma normal (2NF)............................................................................................... 37
Tercera forma normal (3NF)................................................................................................. 38
Cuarta forma normal (4NF) .................................................................................................. 39
Quinta forma normal............................................................................................................. 40
Forma Normal Dominio/Clave .............................................................................................. 40
Desnormalizacion .................................................................................................................... 41
CAPITULO 4 Diseo de Base de Datos empleando Modelo Entidad Relacin

Representacin de entidades con el modelo relacional .......................................................... 43
La funcin de la normalizacin............................................................................................. 43
Representacin de Entidades dbiles.................................................................................. 46
Representaciones de relaciones ............................................................................................. 46
Representacin de relaciones Uno-a-Uno .......................................................................... 46
Representacin de Relaciones Uno-a-Varios ...................................................................... 48
Representacin de Relaciones Varios-a-Varios .................................................................. 50
Representacin de relaciones recursivas ............................................................................ 51
Representacin de subtipos................................................................................................. 53
Ejemplo................................................................................................................................. 53
ANEXO
CASO: Cursos de Formacion de Empleados .......................................................................... 57
CASO: Enseanza de lecciones de Baile................................................................................ 60
Diagrama E-R final para le JK Dance Club .......................................................................... 63
Evaluacin del modelo de datos E-R ................................................................................... 63
CASOS PROPUESTOS .......................................................................................................... 65
CASO: Campeonato de Ajedrez .......................................................................................... 65
CASO: Energia Elctrica ...................................................................................................... 65
CASO: Conflictos Blicos ..................................................................................................... 66
CASO: Gestin de Nminas................................................................................................. 67
2
y diseo de BD
Captulo I
Introduccin
Objetivos:
Al finalizar este captulo, el participante tendr conocimientos sobre:
; Sistema de procesamiento de archivos.
; Sistema de procesamiento de base de datos
; Historia del procesamiento de base de datos
; El modelo relacional
; Procesamiento distribuido de base de datos
; Ciclo de vida de una base de datos
Un poco de historia
Desde tiempos remotos, los datos han sido registrados por el hombre en algn tipo de soporte
(piedra, papel, madera, etc.) a fin de que quedara constancia de un fenmeno o idea. Los datos
han de ser interpretados para que se conviertan en informacin til, esta interpretacin supone
un fenmeno de agrupacin y clasificacin.
En la era actual y con el auge de los medios informticos aparece el almacenamiento en
soporte electromagntico, ofreciendo mayores posibilidades de almacenaje, ocupando menos
espacio y ahorrando un tiempo considerable en la bsqueda y tratamiento de los datos. Es en
este momento donde surge el concepto de bases de datos y con ellas las diferentes
metodologas de diseo y tratamiento.
El objetivo bsico de toda base de datos es el almacenamiento de smbolos, nmeros y letras
carentes de un significado en s, que con un tratamiento adecuado se convierten en
informacin til. Un ejemplo podra ser el siguiente dato: 19941224, con el tratamiento correcto
podra convertirse en la siguiente informacin: "Fecha de nacimiento: 24 de diciembre de
1994".
Segn van evolucionando los tiempos, las necesidades de almacenamiento de datos van
creciendo y con ellas las necesidades de transformar los mismos datos en informacin de muy
diversa naturaleza. Esta informacin es utilizada diariamente como herramientas de trabajo y
como soporte para la toma de decisiones por un gran colectivo de profesionales que toman
dicha informacin como base de su negocio. Por este motivo el trabajo del diseador de bases
de datos es cada vez ms delicado, un error en el diseo o en la interpretacin de datos puede
dar lugar a informacin incorrecta y conducir al usuario a la toma de decisiones equivocadas.
Se hace necesaria la creacin de un sistema que ayude al diseador a crear estructuras
correctas y fiables, minimizando los tiempos de diseo y explotando todos los datos, nace as la
metodologa de diseo de bases de datos.
En un tiempo la frontera entre el programa de aplicacin y el DBMS (Sistema administrador de
base de datos) estaba bien definida. Las aplicaciones estaban escritas en lenguajes de tercera
generacin como COBOL, y se comunicaban con los DBMS para los servicios de organizacin
de datos. Esto todava se hace con ms frecuencia en base de datos en macrocomputadoras.
Las caractersticas y funciones de mltiples productos DBMS se han desarrollado tanto que
ahora el DBMS mismo puede procesar grandes partes de la aplicacin. La mayor parte de los
productos DBMS contienen escritores de informes y generadores de formularios que pueden
integrarse en una aplicacin.
Modelamiento de
datos y diseo de BD
Sistema de procesamiento de archivos

La mejor forma de entender la naturaleza y las caractersticas de las bases de datos actuales
es ver las particularidades de los sistemas que precedieron al uso de la tecnologa de base de
datos. Tales sistemas revelan los problemas que han resuelto la tecnologa de la base de
datos.
Los primeros sistemas de informacin comerciales almacenaban grupos de registros en
archivos separados y eran llamados sistemas de procesamiento de archivos.
Los sistemas de procesamiento de archivos tienen las siguientes limitaciones:
Los datos estn separados y aislados
Con frecuencia, los datos estn duplicados
Los programas de aplicacin dependen de los formatos de archivos
Con frecuencia, los archivos son incompatibles entre si
Es difcil representar los datos en el modo en que los usuarios lo ven
Sistema de procesamiento de base de datos

La tecnologa de las bases de datos se desarrollo para superar las limitaciones de los
sistemas de procesamiento de archivos. Los programas de procesamiento de archivos acceden
a los archivos de los datos almacenados. En contraste, los programas de procesamiento de
base de datos acuden al DBMS para acceder a los datos almacenados. Entre las
caractersticas de un sistema de procesamiento de base de datos tenemos:
Datos integrados
Menos duplicacin de datos
Independencia del programa y los datos
Fcil representacin de la vista de datos de los usuarios
Historia de procesamiento de base de datos

Las grandes corporaciones estaban produciendo datos a grandes velocidades en los sistemas
de procesamiento de archivos, pero los datos se volvan difciles de manejar y los nuevos
sistemas estaban siendo cada vez ms difciles de desarrollar. Adems la administracin
quera ser capaz de relacionar los datos de un sistema de archivo con los de otro.
Las limitaciones en le procesamiento de archivos evitaron la fcil integracin de los datos. Sin
embargo la tecnologa de base de datos ofreca la promesa de una solucin a tales problemas
y las compaas fuertes empezaron a desarrollar base de datos organizacionales. Las
compaas centralizaron sus datos operativos: pedidos, inventarios y datos de contabilidad en
estas bases de datos. Las aplicaciones fueron inicialmente sistemas de transaccin y
procesamiento a nivel de toda la organizacin.
Cuando la tecnologa era nueva, las aplicaciones de base de datos eran difciles de desarrollar
y haba distintas fallas. Incluso las que funcionaban eran lentas y poco confiables: el hardware
no poda manejar el volumen de transacciones con rapidez, la gente de desarrollo aun no haba
descubierto formas ms eficientes de almacenar y obtener datos. Los programadores no
conocan modos de acceso a las bases de datos. Algunas veces sus programas no trabajaban
correctamente.
Las compaas encontraron otra desventaja del procesamiento en base de datos: la
vulnerabilidad. Si un sistema de procesamiento de archivos falla, solo esa aplicacin particular
estar fuera de accin. Pero si una base de datos falla, todas las aplicaciones dependientes
quedaran inutilizadas.
De un modo gradual la situacin fue mejorando Los ingenieros de hardware y software
aprendieron a construir sistemas suficientemente poderosos para dar soporte a varios usuarios
a la vez y tan rpidos como parea mantener la carga de trabajo diaria de transacciones. Se
planearon nuevas formas de controlar, proteger y respaldar la base de datos. Evolucionaron los
procedimientos normales para el procesamiento de las base de datos y los programadores
4
y diseo de BD
aprendieron a escribir cdigos mas eficientes y actualizables. A mediados de los aos 70, las
bases de datos podan procesar muy bien las aplicaciones de una organizacin.
Los administradores aprendieron que de alguna forma todos los datos podan proporcionar
informacin para tomar decisiones tcticas de corto plazo y estratgicas de largo plazo. Sin
embargo, para hacer esto los usuarios deban acceder los datos ellos mismos, no podan
esperar semanas o meses para que los programadores obtuvieran la informacin de la
computadora.
Conceptos Bsicos
Campo:
Es un conjunto de datos del mismo tipo. Representa la caracterstica de un individuo u objeto.
Registro:
Es un conjunto de datos de un objeto u entidad.
Archivo:
Coleccin de registros almacenados siguiendo una estructura homognea.
Base de datos:
Es una coleccin de archivos interrelacionados, son creados con un DBMS. El contenido de
una base de datos abarca la informacin concerniente (almacenadas en archivos) de una
organizacin, de tal manera que los datos estn disponibles para los usuarios, una finalidad de
la base de datos es eliminar la redundancia o al menos minimizarla. Los tres componentes
principales de un sistema de base de datos son el hardware, el software DBMS y los datos a
manejar, as como el personal encargado del manejo del sistema.
Sistema Manejador de Base de Datos. (DBMS)

Un DBMS es una coleccin de numerosas rutinas de software interrelacionadas, cada una de
las cuales es responsable de una tarea especfica.
El objetivo primordial de un sistema manejador base de datos es proporcionar un entorno que
sea a la vez conveniente y eficiente para ser utilizado al extraer, almacenar y manipular
informacin de la base de datos. Todas las peticiones de acceso a la base, se manejan
centralizadamente por medio del DBMS, por lo que este software funciona como interfase entre
los usuarios y la base de datos.
Esquema de base de datos:

Es la estructura por la que esta formada la base de datos, se especifica por medio de un
conjunto de definiciones que se expresa mediante un lenguaje especial llamado lenguaje de
definicin de datos. (DDL)
Administrador de base de datos (DBA):

Es la persona o equipo de personas profesionales responsables del control y manejo del
sistema de base de datos, generalmente tienen experiencia en DBMS, diseo de bases de
datos, Sistemas operativos, comunicacin de datos, hardware y programacin
Los sistemas de base de datos se disean para manejar grandes cantidades de informacin, la
manipulacin de los datos involucra tanto la definicin de estructuras para el almacenamiento
de la informacin como la provisin de mecanismos para la manipulacin de la informacin,
adems un sistema de base de datos debe de tener implementados mecanismos de seguridad
que garanticen la integridad de la informacin, a pesar de cadas del sistema o intentos de
accesos no autorizados.
Un objetivo principal de un sistema de base de datos es proporcionar a los usuarios finales una
visin abstracta de los datos, esto se logra escondiendo ciertos detalles de como se almacenan
y mantienen los datos
Modelamiento de
datos y diseo de BD
El Modelo Relacional
En 1970, E. F. Codd public un artculo memorable en el que aplicaba los conceptos de una
rama de las matemticas llamada lgebra relacional, a los problemas de almacenar enormes
cantidades de datos que en muy pocos aos condujo a la definicin del modelo de las bases
de datos relacionales.
Ventajas del Modelo Relacional

La ventaja del modelo relacional es que los datos se almacenan, al menos conceptualmente,
de un modo en el que los usuarios entienden con ms facilidad. Los datos se almacenan como
tablas y las relaciones entre las filas y las tablas son visibles en los datos. A diferencia de los
anteriores modelos de las bases de datos este enfoque permite a los usuarios obtener
informacin de las bases de datos sin asistencia de sistemas profesionales de administracin
de informacin.
Recuerde usted que las bases de datos no slo se almacenan los datos, tambin las relaciones
entre ellos. Por ejemplo, considere la produccin de una boleta de un estudiante. La figura 1-1
muestra la informacin bsica requerida para construir una boleta de estudiante: datos que
conciernen a los estudiantes y a los cursos que los estudiantes han completado. Para construir
una boleta necesitamos tener los datos y las relaciones entre los valores de los datos, as como
las relaciones entre estudiante particular y los cursos.
Los productos DBMS varan en el modo en que representan tales relaciones de los datos. Los
anteriores productos DBMS almacenaban las relaciones en datos de sistemas, como son los
ndices, que escondan las relaciones de forma eficaz a cualquiera que no tuviera algn
conocimiento de las estructuras de los datos. Aunque los programadores y otros profesionales
aprendieron a usar tales estructuras para desplazarse por la base de datos, el tpico usuario
final no conoca qu eran ni tampoco quera saberlo. Los usuarios dependan de que los
profesionales de sistemas de informacin escribieran programas, para as obtener su
informacin, lo que requera tiempo y con frecuencia era frustrante.
El modo relacional cambi la situacin. Una de las partes fundamentales del modelo relacional
es almacenar las relaciones de los datos en un modo visible para el usuario. En la figura 1-1
las relaciones entre los estudiantes y los cursos se almacenan en el campo de identificacin del
estudiante que se encuentra en el registro del curso.
Es posible recuperar un registro de cursos y determinar cules estudiantes tomaron ese curso
examinando su contenido. Se pueden procesar los datos en otra direccin. Dado un nmero
de ID estudiante, un DBMS relacional puede determinar cules cursos ha completado tal
estudiante.
Cuando se usa el modelo relacional el usuario slo debe especificar cules registros quiere
procesar. Por ejemplo, todos los registros de cursos para el estudiante 100 o los nombres de
los estudiantes que complementaron el curso MA114. El DBMS calcular cmo desplazarse
por la base de datos.
Los sistemas de administracin de base de datos relacionales pueden usarse en la mayor parte
de las aplicaciones, incluyendo el procesamiento de transacciones de las bases de datos
organizacionales. Para cierto tipo de aplicacin, el modelo relacional ha resultado muy til: es el
sistema de apoyo a decisiones (DSS). Las aplicaciones con apoyo a decisiones se aplican a
problemas no estructurados e implican un procesamiento demasiado ad hoc o impredecible.
Como lo plantea un ejecutivo: s que estoy haciendo DSS cuando no conozco la segunda
pregunta por formular hasta que encuentro la respuesta a la primera pregunta. Casi siempre,
los usuarios DSS son gerentes de alto nivel o asistentes de tales personas que estn
dispuestos y son capaces de aprender el funcionamiento de los DBMS relacionales para
cumplir con sus objetivos. Por lo general, los productos basados en el modelo relacional son
fciles de usar, con frecuencia las bases de datos relacionales son el corazn de un DSS.
ID estudiante
100
200
300
6
Nombre estudiante
Carlos Bejarano
Roberto Fernandez
Angela Ramirez
Telfono
323-0098
232-9987
887-4484
y diseo de BD
ID Curso
MA114
MA214
MA314
MA414
FI115
FI215
FI315
DI100
Curso
Matemticas I
Matemticas II
Matemticas III
Matemticas IV
Fsica I
Fsica II
Fsica III
Diseo Mecnico
Ciclo
1
2
3
4
1
2
3
3
ID estudiante
100
200
200
300
300
100
100
300
Fig. 1-1 Datos de estudiantes y cursos
Resistencia al Modelo Relacional

El modelo relacional encontr mucha resistencia. Los sistemas de bases de datos relacionales
requieren ms recursos computacionales y, por lo tanto, al principio eran mucho ms lentos
que los sistemas basados en modelos anteriores de bases de datos. Aunque eran fciles de
usar, la respuesta era lenta y con frecuencia inaceptable. A tal grado que los productos DBMS
relacionales resultaron imprcticos hasta los aos 80, cuando se desarrollo un hardware ms
rpido para computadoras y la relacin precio-desempeo de las computadoras cay de un
modo dramtico.
El modelo relacional tambin le pareca extrao a varios programadores. Estaban
acostumbrados a escribir programas en los cuales procesaban los datos de un registro a la vez.
Pero los productos DBMS relacionales procesan datos con mayor naturalidad; una tabla entera
a la vez. Por ello los programadores deban aprender un nuevo modo de pensar acerca del
procesamiento de datos.
Por ltimo los sistemas relacionales estn diseados para permitir que una persona inexperta
procese una base de datos con asistencia limitada de un profesional. Aunque no hay duda de
que el procesamiento relacional se parece ms al mundo del usuario que el procesamiento de
las bases de los datos basado en otros modelos, los productos DBMS relacionales todava le
parecen extraos a distintos usuarios.
De modo tal que si bien el modelo relacional tiene varias ventajas, no gan verdadera
popularidad hasta que las computadoras se volvieron ms poderosas. A medida que las
microcomputadoras entraron a escena, ms y ms ciclos de CPU pudieron ser destinados a un
simple usuario. Tal potencia fue una bendicin para los productos DBMS relacionales y
dispuso la escena para el siguiente descubrimiento importante en las bases de datos.
Productos DBMS para microcomputadoras

En 1979 una pequea compaa llamada Ashton-Tate introdujo el producto de
microcomputadoras dBase II y lo denomin un DBMS relacional. En una tctica promocional
muy exitosa, Ashton-Tate distribuyo casi gratis ms de cien mil copias de su producto a
compradores de las nuevas microcomputadoras Osborne. Muchas de las personas que
compraron estas computadoras fueron pioneros en la industria de las microcomputadoras.
Empezaron a inventar aplicaciones de la microcomputadoras fueron pioneros en la industria de
las microcomputadoras. Empezaron a inventar aplicaciones de la microcomputadora usando
dBase y el nmero de aplicaciones de dBase creci con rapidez Ashton-Tate se volvi una de
las primeras grandes corporaciones en la industria de las microcomputadoras, despus fue
comprada por Borland, que ahora vende la lnea de productos dBase.
Sin embargo, el xito de este producto confundi y embroll el tema del procesamiento a travs
de bases de datos. El problema era el siguiente: de acuerdo con la definicin que prevaleca a
finales de los sesenta, dBase II no era ni DBMS ni relacional (aunque era comercializado como
si fuera ambos). De hecho era un lenguaje de programacin con capacidades generalizadas de
procesamiento de archivos (no de procesamiento de base de datos). Alrededor de un milln de
usuarios de dBase II crean que estaban usando un DBMS relacional cuando en realidad no
era as.
Modelamiento de
datos y diseo de BD
Los trminos sistemas de administracin de base de datos y base de datos relacional se

usaron de manera vaga en el inicio del auge de las microcomputadoras. La mayor parte las
personas que procesaban una base de datos en microcomputadoras lo que hacan era
trabajar con archivos y no aprovechaban el procesamiento de una base de datos, aunque no se
dieran cuenta.
Hoy la situacin ha cambiado, a medida que el mercado de las microcomputadoras se ha
vuelto ms maduro y sofisticado, dBase III Plus es un autntico DBMS y el dBase IV es
completamente un DBMS relacional.
Aunque dBase fue un pionero en la aplicacin de la tecnologa de las bases de datos en las
microcomputadoras, al mismo tiempo otros vendedores empezaron a trasladar sus productos
de las macrocomputadoras a las microcomputadoras. Oracle, Focus e Ingres son tres ejemplos
de productos DBMS que fueron llevados a las microcomputadoras. En realidad, son autnticos
DBMS y la mayora estara de acuerdo en que tambin son verdaderos relacionales. Otros
vendedores desarrollaron nuevos productos DBMS relacionados especialmente para micros.
Paradox, Revelation, Helix y varios otros productos caen en esta categora.
Un impacto de pasar la tecnologa de bases de datos a las micros fue la dramtica mejora en
la interfaces de los usuarios de DBMS. Por lo general, los usuarios de los sistemas de
microcomputadoras no son profesionales MIS y no toleran las desordenadas y burdas
interfaces para usuarios comunes en los productos DBMS de macrocomputadoras. A medida
que se proyectaban productos DBMS para las micros, las interfaces de usuarios se
simplificaron y se hicieron ms fciles de usar. Esto fue posible porque los productos DBMS
para micro operan en las computadoras para los que fueron desarrollados y porque las
computadoras contaban con mayor potencia para procesar la interfaz del usuario. Los
productos DBMS proporcionan interfaces grficas de usuario, agradables y precisas como es
Windows de Microsoft. Otros dos productos son Access de Microsoft y Paradox para Windows
de Borland.
Aplicaciones de bases de datos cliente servidor

De mediados a finales de los 80, los usuarios finales empezaron a conectar sus
microcomputadoras separadas usando un nuevo tipo de capacidad de comunicaciones en las
computadoras llamado red de rea local (LAN). Estas redes permitieron a las computadoras
enviar datos de una a otra a velocidades antes no imaginadas. Las primeras aplicaciones de
esta tecnologa compartieron perifricos, tales como discos rpidos de gran capacidad,
impresoras y trazadores, y facilitaron la comunicacin entre computadoras a travs del correo
electrnico. Con el tiempo los usuarios finales tambin quisieron compartir sus bases de datos,
lo que condujo al desarrollo de aplicaciones multiusuario de las bases de datos en las redes de
rea local.
La arquitectura multiusuario basada en LAN es muy distinta de la que se emplea en las bases
de datos de macrocomputadoras y minicomputadora. Con una macrocomputadora o
minicomputadora slo la CPU participa en el procesamiento de la aplicacin de bases de datos,
pero con los sistemas LAN pueden contribuir simultneamente varas CPU. Debido a que esta
situacin era ventajosa (mayor funcionalidad) y ms problemtica (coordinar las acciones de
las CPU independientes) ello condujo a un nuevo estilo de procesamiento en base de datos de
multiusuarios llamado arquitectura de base de datos cliente servidor.
Est arquitectura cliente servidor es la base para gran parte del procedimiento en las actuales
bases de datos de grupos de trabajo. Las minicomputadoras pueden usarse en un ambiente de
grupos de trabajo, aunque rara vez se hace por razones de costo.
Procesamiento distribuido de bases de datos

Las aplicaciones en base de datos organizacionales controlan los problemas de procesamiento
de archivos y permiten un procesamiento ms integrado de los datos de la organizacin. Los
sistemas de bases de datos personales y de grupos de trabajo acercan todava ms la
tecnologa de bases de datos en usuario, permitindole el acceso a bases de datos
administradas localmente. Las bases de datos distribuidas combinan estos tipos de
procedimiento de bases de datos, permitiendo que las bases de datos personales, de grupos
de trabajo y de organizaciones se combinen en sistemas integrados pero distribuidos. Como
8
y diseo de BD
tales, ofrecen un acceso de datos y un procesamiento todava ms flexibles, pero tiene varios
problemas an no resueltos.
La esencia de las bases de datos distribuidas es que todos los datos de la organizacin estn
dispersos en varias computadoras: micros, servidores LAN y macrocomputadoras, que se
comunican a medida que procesan la base de datos. Los objetivos de los sistemas distribuidos
de base de datos son hacer que cada usuario sienta que es el nico usuario de los datos de la
organizacin y proporcionan la misma consistencia, precisin y oportunidad que tendra si
nadie ms estuviera usando la base de datos distribuida.
Entre los problemas ms apremiantes con las bases de datos distribuidas se encuentran los de
seguridad y control. Son tareas complicadas permitir que muchos usuarios tengan acceso a la
base de datos (puede haber ciento de ellos a la vez) y controlar lo que ellos hacen en tal base
de datos.
Coordinar y sincronizar los datos puede ser difcil. Si un grupo introduce informacin y actualiza
parte de la base de datos y luego la regresa con los datos cambiados a la macrocomputadora,
Cmo puede el sistema evitar que, mientras tanto otro usuario pretenda usar la versin de los
datos que halle en la macrocomputadora? Imagine tal problema involucrando docenas de
archivos y cientos de usuarios que emplean varios equipos de computacin.
Supuestamente, una base de datos es un conjunto centralizado y controlado de datos y
relaciones. Si se fragmenta y se copia en varias computadoras diferentes, se altera el concepto
original de la base de datos.
Mientras que la transicin de organizacional a personal luego a grupos de trabajo del
procesamiento de bases de datos, fueron de algn modo fciles, las dificultades que enfrentan
los diseadores de bases de datos y los ingenieros de los DBMS distribuidos son
monumentales.
Los DBMS Orientados a Objetos (ODBMS)

A finales de los 80 empez a usarse un nuevo estilo de programacin llamado programacin
orientada a objetos (OOP) que tena una orientacin muy distinta a la programacin tradicional.
En resumen las estructuras de los datos procesadas con la OOP son mucho ms complejas
que las procesadas con lenguajes tradiciones. Tales estructuras de datos tambin son difciles
de almacenar en los productos DBMS relacionales en existencia. Como consecuencia est
evolucionando una nueva categora de productos DBMS denominados sistemas de bases de
datos orientados a objetos (OODBMS) para almacenar y procesar estructuras de datos de
OOP.
Por una serie de razones la OOP se emplea pocas veces en los sistemas de informacin y
negocios. Es difcil usar aplicaciones de OOP y muy costoso desarrollarlas. Adems la mayor
parte de las organizaciones tiene millones o billones de bytes de datos ya organizados en
bases de datos relacionales y no desean enfrentar el costo y el riesgo requerido para convertir
esas bases de datos a un formato OODBMS. Casi todos los OODBMS han sido desarrollados
para soportar aplicaciones de ingeniera de modo que no tienen caractersticas y funciones
apropiadas a las aplicaciones de los negocios de informacin.
En un futuro previsible es probable que los OODBMS ocupen un lugar menor en las
aplicaciones de los sistemas de informacin comerciales.
Ciclo de vida de una base de datos

El ciclo de vida de un desarrollo de una base de datos consta de seis pasos:
1. Anlisis de las necesidades
2. Estudio de viabilidad
3. Definicin de requisitos
4. Diseo conceptual / lgico
5. Implementacin
6. Evaluacin y Mantenimiento
Modelamiento de
datos y diseo de BD
1. - Anlisis de las necesidades

En reunin con el cliente se deben documentar los grupos de usuarios, las necesidades de
informacin de cada uno de ellos, as como los informes que cada uno necesita para su
actividad y el contenido de los mismos. Cuanta ms precisin exista en estos requisitos
iniciales ms preciso ser el desarrollo de la base de datos.
En esta reunin tambin deben quedar documentados los niveles de seguridad de los grupos
de usuarios, los derechos de cada uno de ellos sobre los datos, los requisitos de los sistemas
informticos del cliente sistema operativo, tipo de red, servidores, etc. y la ubicacin de los
usuarios.
No hay que olvidar que normalmente en las empresas existen ya sistemas de almacenamiento
de datos, por tanto es conveniente analizar los datos ya existentes y analizar las posibles
relaciones con la base de datos a desarrollar.
Un cuestionario muy sencillo pero muy til para el administrador es el siguiente:
Nombre
Cargo
rea de Responsabilidad
Obligaciones principales que requieren informacin de la base datos
De qu aplicaciones recibe informacin?
Con cunta frecuencia recibe informacin?
Qu hace con esta informacin?
Qu precauciones de seguridad debe tomar con respecto a la informacin?
Para que aplicacin proporciona datos?
Estn contemplados cambios para alguna de sus actividades actuales que

involucren alguna de las informaciones anteriores?
2. -Estudio de viabilidad
Un estudio de viabilidad implica la preparacin de un informe con las caractersticas siguientes:
Viabilidad tecnolgica.
Hay tecnologa suficiente para el desarrollo?
Viabilidad operacional.
Existen suficientes recursos humanos, presupuesto, experiencia y formacin para el
desarrollo?
Viabilidad econmica.
Se pueden identificar los beneficios?
Los beneficios costearan el desarrollo del sistema?
Se pueden medir los costes y los beneficios?
3. - Definicin de requisitos
Los requisitos de desarrollo involucran el software y hardware necesario para la
implementacin, los recursos humanos necesarios (tanto internos como externos), la formacin
al personal.
Aunque un poco al margen del tema es conveniente parar en este momento y planificar las
acciones a realizar elaborando un cronograma del proyecto y un organigrama con las
responsabilidades de cada miembro del equipo. Conviene sealar quienes van a ser los
interlocutores y fijar un calendario de reuniones de seguimiento del proyecto.
Hay que definir la figura del validador, esta persona ser la encargada de velar en cada
momento que no se est rebasando el alcance del proyecto, as como asegurar que la
implementacin est encaminada a subsanar las necesidades del cliente.
10
y diseo de BD
4. Diseo
En esta etapa se crea un esquema conceptual de la base de datos. Se desarrollan las
especificaciones hasta el punto en que puede comenzar la implementacin. Durante esta etapa
se crean modelos detallados de las vistas de usuario y sobre todo las relaciones entre cada
elemento del sistema, documentando los derechos de uso y manipulacin de los diferentes
grupos de usuarios.
Si parte de la informacin necesaria para crear algn elemento establecido ya se encuentra
implementado en otro sistema de almacenamiento hay que documentar que relacin existir y
detallar los sistemas que eviten la duplicidad o incoherencia de los datos.
El diseo consta, como se vio anteriormente, de tres fases: el diseo global o conceptual, el
diseo lgico y el modelo fsico.
5. Implementacin
Una vez totalmente detallado el modelo conceptual se comienza con la implementacin fsica
del modelo de datos, a medida que se va avanzando en el modelo el administrador del sistema
va asegurando la correccin del modelo y el validador la utilidad del mismo.
La implementacin consiste en el desarrollo de las tablas, los ndices de los mismos, las
condiciones de validacin de los datos, la relacin entre las diferentes tablas. Por otro lado, la
definicin de las consultas y los parmetros a utilizar por cada una de ellas.
Una vez finalizada la implementacin fsica, se asignan las correspondientes medidas de
seguridad y se ubica la base de datos en el lugar correspondiente.
6. - Evaluacin y Perfeccionamiento
En esta ltima etapa todos los usuarios del sistema acceden a la base de datos y deben
asegurarse el correcto funcionamiento de la misma, que sus derechos son los adecuados,
teniendo a su disposicin cuanta informacin necesiten. Tambin debern asegurarse que el
acceso a los datos es cmodo, prctico, seguro y que se han eliminado, en la medida de lo
posible, las posibilidades de error.
El administrador se asegura que todos los derechos y todas las restricciones han sido
implementadas correctamente y que se ha seguido en manual de estilo en la totalidad de la
implementacin.
El validador se asegurar que todas las necesidades del cliente han sido satisfechas.
Caracteristicas de una Base de Datos

Legibilidad
El diseo de una base de datos ha de estar redactado con la suficiente claridad para que
pueda ser entendido rpidamente. El lenguaje utilizado debe ser lo suficientemente claro,
conciso y detallado para que explique con total claridad el diseo del modelo, sus objetivos, sus
restricciones, en general todo aquello que afecte al sistema de forma directa o indirecta. En
este punto conviene aplicar el principio que una imagen vale ms que mil palabras, pero en
ocasiones son necesarias esas mil palabras y obviar la imagen.
Fiabilidad
Se trata de realizar un sistema de bases de datos lo suficientemente robusto para que sea
capaz de recuperarse frente a errores o usos inadecuados. Se deben utilizar gestores con las
herramientas necesarias para la reparacin de los posibles errores que las bases de datos
pueden sufrir, por ejemplo tras un corte inesperado de luz.
Portabilidad
El diseo deber permitir la implementacin del modelo fsico en diferentes gestores de bases
de datos.
11
Modelamiento de
datos y diseo de BD
Modificabilidad
Ningn sistema informtico es esttico, las necesidades de los usuarios varan con el tiempo y
por lo tanto las bases de datos se deben adaptar a las nuevas necesidades, por lo que se
precisa que un buen diseo facilite el mantenimiento, esto es, las modificaciones y
actualizaciones necesarias para adaptarlo a una nueva situacin.
Eficiencia
Se deben aprovechar al mximo los recursos de la computadora, minimizando la memoria
utilizada y el tiempo de proceso o ejecucin, siempre que no sea a costa de los requisitos
anteriores. En este punto se debe tener en cuenta los gestores cliente / servidor de bases de
datos. En muchas ocasiones es ms rentable cargar de trabajo al servidor y liberar recursos de
los clientes, pero no todos los gestores permiten este tipo de trabajo, por lo tanto se ha de tener
en cuenta estas dos circunstancias en el diseo de la base de datos.
Autodescripcin
En la documentacin generada debe estar todo el detalle del diseo, evitando referencias a
otros documentos que no estn incluidos dentro de la documentacin de la base de datos.
Trivialidad
Tanto el diseo como la implantacin se deben realizar utilizando los estndares fijados a priori,
estos estndares debern quedar reflejados al inicio del documento.
Claridad
Todos los documentos deben estar redactados de forma clara y fcil de entender, los nombres
utilizados para las tablas, los campos, ndices, etc. deben ser autodescriptivos y estar
perfectamente documentados.
Coherencia
Las anotaciones y terminologa utilizada deben ser uniformes, para ello se debe seguir algn
tipo de metodologa estndar, indicando cual se ha empleado, en los casos en que se utilice
alguna metodologa no estndar se debe adjuntar a la documentacin.
Completo
Todos los elementos constitutivos de la base de datos existen, no se han dejado partes
incompletas, sin documentar o sin implementar.
Concisin
No existen elementos intiles ni repetitivos. En este apartado hay que hacer un especial
hincapi en la repeticin de datos en diferentes tablas, hay que evitar a toda costa que el
mismo dato se repita en varias tablas para conseguir as una optimizacin del tamao de la
base de datos.
Facilidad de Aprendizaje
La documentacin de la base de datos se puede utilizar sin necesidad de otros conocimientos
informticos fuera del alcance del diseo e implementacin de la base de datos.
Facilidad de Uso
Los datos deben ser fciles de elaborar y los resultados fciles de entender.
Generalidad
La base de datos debe ser capaz de adaptarse a cualquier tipo de empresa y a cualquier
casustica.
Independencia de Usuario
La base de datos no debe estar ligada a la utilizacin en una nica instalacin, hay que tener
en cuenta que, aunque se trate de un desarrollo a medida, en un futuro se podra realizar la
instalacin en un cliente diferente al inicial.
Independencia de Sistema
Las prestaciones y diseo de la base de datos no estn vinculadas al entorno.
Independencia de Instalacin
La base de datos se puede transportar fcilmente de una instalacin a otra.
12
y diseo de BD
Modularidad
La base de datos puede ser descompuesta en elementos independientes. Si se trata de un
diseo grande, en donde hay un gran nmero de tablas, conviene realizar agrupaciones entre
ellas, creando mdulos funcionales que permitan la mejor compresin del diseo y de la
implementacin
Observable
La base de datos debe permitir observar los accesos a los datos. Siempre que se pueda hay
que dejar un rastro de la utilizacin de los datos por parte de los usuarios, esta informacin
ayuda al redimensionado de la base de datos y a conocer el nmero de accesos a los datos.
Precisin
Los clculos efectuados se deben realizar con la precisin requerida.
Proteccin
La base de datos debe permitir la proteccin de los datos frente a usos no debidos, para ello
hay que elaborar un sistema de accesos definiendo diferentes usuarios con diferentes claves y
especificar que autorizaciones tendr cada usuario sobre los diferentes datos.
Trazabilidad
Tomando como punto de partida la versin actual se puede remontar su diseo hasta las
especificaciones iniciales
13
Modelamiento de
datos y diseo de BD
La metodologa de diseo de datos

Se divide en:
1. Modelo Global: se trata de una representacin grfica legible por el usuario y que nos
aporta el flujo de informacin dentro de una organizacin. No existen reglas para su
construccin y se debe realizar siempre el esquema ms sencillo posible para la
comprensin por parte del usuario de la base de datos.
2. Modelo Lgico: se trata de una representacin grfica, mediante smbolos y signos
normalizados, de la base de datos. Su objetivo es representar la estructura de los datos
y las dependencias de los mismos, garantizando la consistencia y evitando la
duplicidad.
3. Modelo Fsico: se trata del almacn de los datos, es la base de datos en s misma, el
soporte donde se almacenan los datos y de donde se extraen para convertir los datos
en informacin. En funcin del gestor de bases de datos empleado las reglas de
almacenamiento varan.
El Modelo lgico
Antes de comenzar esta modelacin es necesario tener documentado las necesidades,
viabilidad y definicin de los requisitos, as como tener elaborado el modelo global o conceptual
del diseo.
El paso del modelo global o conceptual de datos al modelo lgico supone una abstraccin, un
mecanismo para la conversin del mundo real a un mundo formado por datos, a su agrupacin
y clasificacin. El proceso de abstraccin consiste en identificar los elementos conceptos
empleados en el modelo global y transformarlo en lo que denominamos entidades en el modelo
lgico. La abstraccin se puede realizar de las siguientes formas:
Clasificacin
Consiste en generar una nica entidad conceptos con caractersticas comunes, todos ellos
tendrn las mismas caractersticas y se diferencian unos de otros por los valores que toman
dichas caractersticas. Por ejemplo: los conceptos cursos de ingls, cursos de espaol y cursos
de francs se pueden agrupar en una nica entidad denominada "CURSOS" que agrupe y
diferencie cada uno de los diferentes cursos que se imparten.
Agregacin
Consiste en separar cada una de las partes de un concepto para generar distintas entidades,
por ejemplo el concepto auto lo podemos definir utilizando las entidades chasis, motor y llanta.
14
y diseo de BD
MOTOR
CHASIS
LLANTA
AUTO
Generalizacin
Consiste en ir generando entidades de diferentes niveles de tal forma que cada entidad de nivel
superior agrupe las de nivel inferior.
PERSONA
CLIENTE
EMPLEADO
NACIONAL
LIMA
EXTRANJERO
PROVEEDOR
MAYORISTA
MINORISTA
TRUJILLO
Asociacin
Consiste en la generalizacin de entidades a partir de entidades ya existentes.
ARTICULO
PEDIDO
FACTURA
Restricciones de integridad
En el mundo real existen ciertas restricciones que deben cumplir los elementos en l
existentes; por ejemplo, una persona slo puede tener un nmero de DNI y una nica direccin
oficial. Cuando se disea una base de datos se debe reflejar fielmente el universo del discurso
que estamos tratando, lo que es lo mismo, reflejar las restricciones existentes en el mundo real.
Los componentes de una restriccin son los siguientes:
La operacin de actualizacin (insercin, borrado o eliminacin) cuya ejecucin ha de dar lugar
a la comprobacin del cumplimiento de la restriccin.
La condicin que debe cumplirse, la cual es en general una proposicin lgica, definida sobre
uno o varios elementos del esquema, que puede tomar uno de los valores de verdad
(Verdadero o falso).
15
Modelamiento de
datos y diseo de BD
La accin que debe llevarse a cabo dependiendo del resultado de la condicin. En general, se
puede decir que existen tres tipos de integridad:
Integridad de dominio: restringimos los valores que puede tomar un atributo respecto a
su dominio, por ejemplo EDAD >= 18.
Integridad de entidad: la clave primaria de una entidad no puede tener valores nulos y
siempre deber ser nica, por ejemplo DNI.
Integridad referencial: las claves ajenas de una tabla hija se tienen que corresponder
con la clave primaria de la tabla padre con la que se relaciona. Por ejemplo, en la tabla
FAMILIARES de los empleados necesitaremos el DNI de empleado, que es la clave
externa de la tabla.
Las restricciones se clasifican en:

Inherentes
Estn impuestas por el modelo.
No tiene que ser definidas por el usuario, ya que se encuentran en el propio modelo
Se activan en el momento de la definicin del esquema cuando se produce un intento

de violacin.
Se rechaza todo esquema que no cumple estas restricciones.
Introducen rigidez al modelo.
Semnticas
Impuestas por el universo del discurso
Tienen que ser definidas por los diseadores
Se activan en el momento de la actualizacin de la base de datos
Se rechaza todo ejemplar que no cumpla estas restricciones (o se ponen en marcha

otros medios a fin de que no se produzca un estado de inconsistencia)
Ayudan a capturar la semntica de los datos y a conseguir su consistencia.
Ajenas
Se especifican en los programas de aplicacin
No estn almacenadas en el esquema de la base de datos
Pueden ser violadas por actualizaciones en las que no se haya programado la

restriccin.
El sistema de bases de datos no puede comprobar si son consistentes en s mismas.
El optimizador de BD no puede tomarlas en consideracin.
Proporcionan el mximo de flexibilidad.
Pueden ser programadas en un lenguaje de propsito general o en algn lenguaje

propio del sistema de bases de datos
Suponen una importante carga de programacin y mantenimiento.
Estn almacenadas en el esquema de la base de datos, No pueden ser violadas por

ninguna actualizacin.
Accin General
16
Es obligatorio especificar la condicin y la accin
Son a travs de procedimientos (al menos en parte, ya que la accin se especifica

siempre mediante un procedimiento)
Suponen carga de programacin
Es muy difcil (prcticamente imposible en la mayor parte de los casos) que el sistema
de bases de datos pueda comprobar su consistencia
El optimizador no puede tomarlas en consideracin

y diseo de BD
Hasta ahora no estn estandarizadas
Estn muy ligadas a los productos
Son muy flexibles
Tienen nombre y existencia propia dentro del programa.
Procedimientos almacenados
Es obligatorio especificar la condicin (adems de la accin)
Son totalmente a travs de procedimientos
Pueden ser tan complejas como imponga la semntica del mundo real (tanto en la
condicin como en la accin)
Son las ms flexibles dentro de las restricciones propias.
Disparadores
Combinan los enfoques declarativo (en la condicin) y a travs de procedimientos (en

la accin)
Pueden ser tan complejas como imponga la semntica del mundo real en cuanto a la
accin, y bastantes complejas en la condicin (todo lo que permite la proposicin lgica
mediante la que se expresa la condicin).
El cumplimiento de la condicin dispara la accin.
Son ms flexibles que las restricciones de accin especfica.
Accin Especfica
La accin est implcita en la misma restriccin, por lo que no hay que definirla
Son declarativas, puesto que no especifica la accin y la condicin, si se define, es

declarativa
El no cumplimiento de la condicin lleva a aplicar la accin
Podran ser definidas mediante un lenguaje de tipo general
El sistema de bases de datos puede comprobar si son consistentes en s mismas
El optimizador puede tomarlas en consideracin
No suponen carga de programacin, slo de definicin.
Condicin General
No se especifica la accin, que es siempre de rechazo (el no cumplimiento de la

condicin lleva consigo el rechazo de la actualizacin)
Es obligatorio declarar la condicin mediante una proposicin lgica que permite

condiciones de complejidad arbitraria
Adems de la condicin, se puede especificar algn otro componente
Son ms flexibles que las de condicin especfica
Es ms difcil optimizar su ejecucin que en el caso de las de condicin especfica.
Verificacin
No tienen existencia en s mismas
Su definicin forma parte de la definicin del elemento afectado por la restriccin
Se aplican a un nico elemento y aunque pueden afectar a otros, en este caso se

complica su definicin,
Pueden no tener nombre.
Asercin
Tienen existencia por s mismas
Se definen con independencia de cualquier elemento del esquema
Pueden afectar a ms de un elemento
17
Modelamiento de
datos y diseo de BD
Tienen nombre.
Condicin Especfica
18
Son opciones proporcionadas por el propio modelo
No se especifica ninguno de los componentes relativos a una restriccin (ni la

operacin, ni la condicin, ni la accin)
Son poco flexibles
El optimizador puede tomarlas en consideracin
Su ejecucin puede ser ms fcilmente optimizada que las de condicin general
y diseo de BD
Preguntas de repaso
1.
Por qu es importante el procesamiento de base de datos?
2.
Defina el termino Base de Datos
3.
Por qu una base de datos es un modelo?
4.
Cules fueron las principales debilidades de las primeras aplicaciones organizacionales

de base de datos?
5.
Cul es la principal ventaja del modelo relacional?
6.
Por qu en un principio, las personas se rehusaban a usar el modelo relacional?
7.
Explique la naturaleza general del procesamiento distribuido
8.
En que se distinguen la arquitectura Cliente/servidor y las arquitecturas de multiusuario

para macrocomputadoras o minicomputadoras?
9.
Entreviste personas que usen una aplicacin de base de datos. Qu funciones del
negocio son atendidas? Qu informacin se produce? Qu objetos estn
involucrados? Es esta una aplicacin personal, de grupos de trabajo o de una
organizacin?
10.
Entreviste a un Desarrollador de Aplicaciones. Pida informacin de sistemas de

administracin de base de datos para microcomputadoras. Comprenden la diferencia
entre sistemas de administracin de archivos y sistemas de administracin de base de
datos? Comprenden las distinciones entre productos DBMS relacionales y no
relacionales?
19
Modelamiento de
datos y diseo de BD
20
y diseo de BD
Captulo 2
El Modelo Entidad-Relacin
Objetivos:
; Definicin del Modelo Entidad Relacin.
; Definicin de Entidades y Atributos.
; Tipos de relaciones binarias.
; Diagramas Entidad-Relacin
Definicin del Modelo Entidad-Relacin

El modelo entidad-relacin (modelo E-R) fue introducido por Peter Chen en 1976. En su
informe, Chen estableci las bases del modelo, que a partir de entonces ha sido ampliado y
modificado por el mismo Chen y muchos otros. Adems, el modelo E-R se ha incorporado a
varias herramientas CASE, las cuales tambin lo han modificado en la actualidad no hay un
solo modelo estandarizado E-R. Por el contrario, hay un conjunto de estructuras comunes, a
partir de las cuales se conforman la mayora de las variantes E-R. Este captulo describe tales
estructuras comunes y muestra cmo se usan. Asimismo, los smbolos empleados para
expresar el modelo E-R difieren en forma significativa. Los que se usan aqu son tpicos y
populares, de ningn modo son los nicos smbolos aceptables en posibilidad de ser
empleados.
Entidades
Es un objeto en el mundo real con existencia independiente. Una entidad puede ser un objeto
fsico (una persona, un auto, una casa o un empleado) o un objeto conceptual (una compaa,
un puesto de trabajo o un curso). Una entidad es algo que puede identificarse en el ambiente
de trabajo de los usuarios, es algo que tiene importancia para los usuarios del sistema que se
requiere desarrollar.
Algunos ejemplos de entidades son:
EMPLEADO Juan Cubas
CLIENTE 12345
PEDIDO-DE-VENTAS 1000
VENDEDORA Leslie Medina
PRODUCTO A4200
Las entidades se agrupan en clases de entidades o conjuntos de entidades del mismo tipo. La
clase entidad se imprimen en letras maysculas. El nombre EMPLEADO representa entonces
una clase de entidad de empleados.
Usted necesita establecer la diferencia entre una clase de entidad y la ocurrencia de una
entidad: una clase de entidad es la forma general o descripcin de algo, pongamos un
CLIENTE, en tanto que una ocurrencia de una clase de entidad es la representacin de una
entidad particular tal como CLIENTE 12345.Con frecuencia los trminos entidad y clase de
entidad se usan de modo indistinto.
21
Modelamiento de
datos y diseo de BD
Atributos
Las entidades tienen atributos o propiedades que describen las caractersticas de una entidad.
Ejemplos de atributos de la entidad EMPLEADO son:
NombreDeEmpleado
FechaDeContratacin
CdigoDeCategoria.
Los atributos se imprimen en maysculas y minsculas. El modelo E-R supone que todas las
ocurrencias de cierta clase de entidad tienen los mismos atributos.
Como se defini en el modelo E-R original los atributos pueden ser de valor nico o mltiple, o
bien compuestos. En CLIENTE el atributo compuesto Direccin puede definirse como el grupo
Avenida, Distrito, Cdigo Postal, Departamento. Sin embargo, algunas implementaciones del
modelo E-R no permite atributos de valores mltiples o compuestos.
Identificadores
Las ocurrencias de una entidad tienen nombres que las identifican. Tenemos los siguientes
ejemplos:
EMPLEADO tienen NmeroDeSeguroSocial
CLIENTE tienen NmeroDeCliente o NombreDeCliente
PEDIDO-DE-VENTA tienen NmeroDePedido.
El identificador de una ocurrencia de entidad es uno o ms de sus atributos. Un identificador

puede ser nico o no serlo. Si es nico su valor identificar una y slo una ocurrencia de
entidad. Pero si no es nico el valor identificar un conjunto de ocurrencias. Si sucede esto
ltimo tal como el NombreDeCliente en CLIENTE, deben considerarse datos adicionales,
digamos una direccin o un nmero telefnico, para as encontrar una ocurrencia nica. La
figura 2-1 muestra una entidad y dos ocurrencias de ella.
CLIENTE
La entidad contiene:
NumeroDeCliente
NombreDeCliente
Direccin
Ciudad
NombresDeContacto
NumeroTelefonico
Dos ocurrencias de CLIENTE
12345
12399
Manufactura Atlas
Editorial Navarrete
Colonial 1245
Puno 245
Callao
Lima
Julio Martell
Pablo Carrizales
4253666
5621232
Fig. 2-1
22
y diseo de BD
Relaciones
Las entidades pueden asociarse una con otra en relaciones. El modelo E-R contiene clases de
relaciones y ocurrencias de relaciones. Las clases de relaciones son asociadas entre las clases
de entidades y las ocurrencias de relaciones son asociaciones entre las ocurrencias de
entidades. Las relaciones pueden tener mltiples atributos.
Como se defini en el modelo E-R original una relacin puede incluir muchas entidades; la
cantidad de entidades en una relacin es el grado de la relacin. En la figura 2-2 la relacin
VENDEDOR-PEDIDO es el grado 2, porque cada ocurrencia de la relacin implica dos
ocurrencias de entidades: una ocurrencia VENDEDOR y una PEDIDO. En la figura la relacin
PADRE es el grado 3, porque cada ocurrencia implica 3 entidades: MADRE, PADRE e HIJO.
Aunque el modelo E-R permite relaciones de cualquier grado, la mayora de las aplicaciones
del modelo slo considera relaciones de grado 2. Cuando son de tal tipo, se denominan
relaciones binarias.
VENDEDOR
MADRE
PEDIDO
PADRE
HIJO
Fig. 2-2 Ejemplo de relacin de grado 2 y de grado 3
Tipos de Relaciones Binarias
Relacin de Uno a Uno

En una relacin 1:1 (Uno-a-Uno), una ocurrencia de entidad nica de un tipo se
relaciona con una ocurrencia de entidad nica de otro tipo. En la figura 2-3 la relacin
AUTOMVIL-ASIGNACION asocia a un EMPLEADO nica con slo AUTOMVIL. De
acuerdo con este diagrama, ningn empleado posee ms de un automvil asignado y
ningn vehculo se asigna a ms de un trabajador.
1:1
EMPLEADO
AUTO
Fig. 2-3 Relacin AUTOMOVIL-ASIGNACION
Relacin de Uno a Varios

Denominada 1:N (Uno a varios). En la relacin DORMITORIO-OCUPANTE una
ocurrencia nica de DORMITORIO se relaciona con muchas ocurrencias de
ESTUDIANTE. De acuerdo a la Fig. 2-4, en un dormitorio hay muchos estudiantes,
pero un estudiante slo tiene un dormitorio.
Las posiciones del 1 y la N son significativas. El 1 est cerca de la lnea que se conecta
con DORMITORIO, lo que significa que el 1 se refiere al lado DORMITORIO de la
relacin y la N est cerca de la lnea que conecta con ESTUDIANTE, lo que significa
que la N se refiere al lado ESTUDIANTE de la relacin. Si el 1 y la N estuvieran
23
Modelamiento de
datos y diseo de BD
invertidos y la relacin se escribiera N:1, un DORMITORIO tendrn un ESTUDIANTE y

un ESTUDIANTE podra tener muchos DORMITORIOS.
1: N
DORMITORIO
ESTUDIANTE
Fig. 2-4 Relacin DORMITORIO-ESTUDIANTE
Relacin de Varios a Varios

El tercer tipo de relacin binaria, N:M (Varios a varios). Est relacin se llama
ESTUDIANTE-CLUB y relaciona las ocurrencias de ESTUDIANTE con las ocurrencias
de CLUB. Un estudiante puede inscribirse en ms de un club, y en club puede haber
como miembros muchos estudiantes.
Los nmeros dentro del diamante de la relacin detallan la cantidad mxima de
entidades que pueden ocurrir en un lado de ella. En ocasiones, tales limitaciones se
denominan la cardinalidad mxima de la relacin, digamos la relacin en la figura 2-4,
se dice que tienen una cardinalidad mxima de 1:N. Es posible que la cardinalidad
mxima sea distinta de 1 y N. Por ejemplo, la relacin entre EQUIPO DE
BSQUETBOL Y JUGADOR, pueden tener una cardinalidad mxima de 5.
N:M
ESTUDIANTE
CLUB
Fig. 2-5 Relacin ESTUDIANTE-CLUB
Las relaciones de los tipos mostrados en ocasiones se denominan relaciones TIENE UN. Este
trmino se usa porque la entidad tiene una relacin con la otra. Por ejemplo, un EMPLEADO
tiene un AUTO; un ESTUDIANTE tiene un DORMITORIO; y un CLUB tiene ESTUDIANTES.
Diagramas Entidad-Relacion
Los diagramas entidad-relacin o E-R estn estandarizados en forma muy abierta. De acuerdo
con este estndar, las clases de entidades se muestran con rectngulos; las relaciones
mediante diamantes y la cardinalidad mxima de la relacin con otra. Por ejemplo, un
EMPLEADO tiene un AUTO; un ESTUDIANTE tiene un DORMITORIO; y un CLUB tiene
ESTUDIANTES.
Aunque en algunos diagramas E-R el nombre de la relacin aparece dentro del diamante, esto
hace que la representacin se vea desproporcionada, ya que los diamantes tendran que ser
grandes para incluir el nombre de la relacin. Para evitar esto en ocasiones los nombres de
relaciones se escriben arriba del diamante; cuando el nombre se coloca dentro o en la parte
superior del diamante la cardinalidad de la relacin se detalla colocando patas de gallo en las
lneas que conectan a las entidades en el lado varios de la relacin. La representacin de las
relaciones DORMITORIO-OCUPANTE y ESTUDIANTE-CLUB con las mencionadas patas de
gallo.
DORMITORIO
1:N
ESTUDIANTE
ESTUDIANTE
N:M
CLUB
Fig. 2-6
24
y diseo de BD
La cardinalidad mxima indica a su vez la cantidad mxima de entidades que pueden participar
en una relacin. Los diagramas no indican la mnima. Por ejemplo la figura 2-4 muestra que un
estudiante se relaciona como mximo con un dormitorio, pero no es posible saber si un
estudiante debe relacionarse con una ocurrencia de dormitorio.
Se emplean varias formas para advertir la cardinalidad mnima. Una de ellas ilustrada en la
figura 2-7 es colocar un lnea perpendicular a la lnea de la relacin indicar que una entidad
debe existir en las relaciones, y colocar un valo perpendicular a la lnea de la relacin
sealando que pueda haber, o no una entidad en la relacin. La figura 2-7 nos dice que un
DORMITORIO debe tener una relacin con un ESTUDIANTE al menos, pero que no se
requiere que un ESTUDIANTE, tenga una relacin con un DORMITORIO. Las limitaciones
completas de la relacin son que un DORMITORIO posea una cardinalidad mnima de 1 y una
cardinalidad mxima de mltiples entidades ESTUDIANTE. Un ESTUDIANTE tiene una
cardinalidad mnima de cero y una cardinalidad mxima de una entidad DORMITORIO.
1:N
DORMITORIO
ESTUDIANTE
Puede existir una relacin entre entidades de la misma clase. Las relaciones entre entidades
de una sola clase se denominan relaciones recursivas.
Atributos en los diagramas Entidad-Relacin

En algunas versiones de los diagramas E-R, los atributos se muestran en valos que se
conectan con la entidad o relacin a la que pertenecen. La figura 2-8 muestra las entidades
DORMITORIO y ESTUDIANTE y la relacin DORMITORIO-OCUPANTE con los atributos. Se
muestra DORMITORIO tiene los atributos NombreDeDormitorio, Ubicacin y
CantidadDeHabitaciones y ESTUDIANTE tiene los atributos NumerodeEstudiante,
NombreDeEstudiante y AoDelEstudiante. La relacin DORMITORIO-OCUPANTE tiene el
atributo Renta el cual determina la cantidad de renta que paga un estudiante en el dormitorio
especfico.
Listar demasiados atributos en el diagrama E-R puede saturarlo y dificultar su interpretacin.
En estos casos los atributos de entidades se listan por separado, tal como se muestra en la
figura 2-9. Mltiples herramientas CASE exhiben tales atributos en ventanas GUI desplegables.
NombreDe
Dormitorio
NumeroDe
Estudiante
Ubicacin
1:N
DORMITORIO
CantidadDeHa
bitaciones
Renta
ESTUDIANTE
NombreDe
Estudiante
AoDeEstudiante
25
Modelamiento de
datos y diseo de BD
1:N
DORMITORIO
ESTUDIANTE
Dormitorio contiene:
Estudiante contiene:
NombredeDormitorio
NumerodeEstudiante
Ubicacin
NombredeEstudiante
CantidadDeHabitaciones
AodeEstudiante
Dormitorio-Ocupante contiene
Renta
Entidades dbiles
El modelo entidad-relacin define un tipo especial de entidad denominado entidad dbil. Tales
entidades son aquellas cuya presencia en la base de datos depende de la presencia de otra
entidad. Un ejemplo de tal relacin es la que hay en los empleados y sus dependientes. En la
figura 2-10 la entidad DEPENDIENTE depende de la presencia de otra entidad. Un ejemplo de
tal relacin es la que hay entre los empleados y sus dependientes. En la Figura 2-10 la entidad
DEPENDIENTE depende de la presencia de la entidad EMPLEADO.
Esto significa que los datos de DEPENDIENTE dependen de la presencia de la entidad
EMPLEADO. Esto significa que los datos de DEPENDIENTE slo pueden almacenarse en la
base de datos si el DEPENDIENTE posee una relacin con una entidad EMPLEADO.
Como se aprecia en esta figura, las entidades dbiles se representan redondeando las
esquinas del rectngulo de la entidad..
1:N
EMPLEADO
DEPENDIENTE
Fig. 2-10 Relacin EMPLEADO-DEPENDIENTE
Algunos diagramas E-R las entidades dbiles se dibujan empleando una doble lnea para el
rectngulo de la entidad dbil y diamantes dobles para la relacin de la que dependen.
Entidades Subtipo
Algunas entidades contienen grupos opcionales de atributos: Por ejemplo, considere CLIENTE,
con los atributos NmeroDeCliente, NombreDeCliente y CantidadAdeudada. Suponga que un
CLIENTE puede ser una persona, una sociedad o bien una empresa y que deben almacenarse
datos adicionales dependiendo del tipo. Digamos que estos datos adicionales son los
siguientes:
CLIENTE-PERSONA:
Direccin, NmeroDeSeguroSocial
CLIENTE-SOCIEDAD:
NombreDelSocioAdministrador, Direccin, NmeroDeIdentificacinFiscal.
CLIENTE-EMPRESA:
PersonaconQuienseHaceContacto, Telfono, NmeroDeldentificacinFiscal.
26
y diseo de BD
Una posibilidad de asignar es asignar tales atributos a la entidad CLIENTE, como se muestra
en la figura 2-11. En este caso; algunos de los atributos no son aplicables.
NombreDelSocioAdmnistrador no significa nada para un cliente persona o empresa y por lo
tanto no puede poseer un valor.
Un modelo ms preciso definir tres entidades subtipo, tal como se muestra en la figura 2-11.
Aqu las entidades CLIENTE-PERSONA, CLIENTE-SOCIEDAD y CLIENTE-EMPRESA se
muestran como subtipos de CLIENTE. A su vez, CLIENTE es un supertipo de las entidades
CLIENTE-PERSONA, CLIENTE-SOCIEDAD y CLIENTE-EMPRESA.
CLIENTE
CLIENTE
CLIENTE
CLIENTE
PERSONA
SOCIEDAD
EMPRESA
2-11 Subtipo CLIENTE
La junto a las lneas de relacin ndica que CLIENTE-PERSONA, CLIENTE-SOCIEDAD y

CLIENTE-EMPRESA son subtipos de CLIENTE. Cada entidad subtipo debe pertenecer al
supertipo CLIENTE
Documentacin de reglas de negocios

El modelo E-R se desarrolla a partir de los anlisis de requerimientos obtenidos de los
usuarios. Durante este anlisis surgen reglas de negocios y casi todos los analistas de
sistemas ponen atencin en investigarlas
Las reglas de negocios pueden ser impuestas por el DBMS o por el programa de aplicacin.
Muchas veces las reglas de negocios estn escritas en procedimientos manuales que deben
seguir los usuarios de la aplicacin de base de datos. En este punto no es importante la forma
como habrn de imponerse las reglas Lo que cuenta es documentarlas para que se
transformen en parte de los requerimientos del sistema.
El modelo entidad-relacin y las herramientas CASE

Desarrollar un modelo de datos usando el modelo entidad-relacin se ha vuelto ms fcil en
aos recientes, debido a que las herramientas para desarrollar diagramas E-R se incluyen en
mltiples productos CASE que son muy difundidos. Estos productos tambin integran las
entidades con las actividades de bases de datos que las representan lo que facilita la
administracin, control y mantenimiento de la base de datos.
27
Modelamiento de
datos y diseo de BD
Preguntas de repaso
1.
Defina entidad y proporcione un ejemplo
2.
Explique la diferencia entre una clase de Entidad y una ocurrencia de entidad
3.
Defina atributo y proporcione un ejemplo
4.
Explique que es un atributo compuesto
5.
Defina relacin y proporcione un ejemplo
6.
Defina grado de relacin
7.
Explique el trmino entidad dependiente
8.
Desarrolle un diagrama E-R para lo siguiente:

Una organizacin no lucrativa se dedica al desarrollo y mejoramiento de vivienda de bajo
costo. Esta opera en una rea metropolitana de unos 2.2 millones de personas en una
ciudad del Per.
La organizacin conserva datos sobre la ubicacin, disponibilidad y condiciones de
alojamiento de bajo costo en 11 zonas censadas diferentes del rea metropolitana.
Dentro de los lmites de estas zonas hay ms o menos 250 edificios que proporcionan
alojamiento de bajo costo. En promedio cada edificio contiene 25 departamentos u otras
unidades.
La organizacin conserva datos sobre cada zona censada, incluyendo lmites
geogrficos, ingresos medios de la poblacin, negocios principales, inversionistas que
representan los atributos en la zona y otros datos demogrficos y econmicos. Tambin
conserva una cantidad limitada de datos sobre criminalidad. Para cada edificio almacena
el nombre, direccin, tamao, nombre del propietario(s), nombre y direccin del poseedor
de la hipoteca, renovaciones, reparaciones y disponibilidad de instalaciones para
personas discapacitadas. La organizacin posee una lista de cada una de las unidades
dentro de cada edificio, incluyendo el tipo de unidad, tamao, cantidad de habitaciones,
cantidad de baos, instalaciones en la cocina y el comedor, ubicacin del edificio y otras
consideraciones especiales.
La organizacin funciona como un centro de distribucin de informacin y ofrece tres
servicios bsicos. Primero trabaja con grupos de polticos, congresistas y de abogados,
as apoya la legislacin que estimula el desarrollo de viviendas de bajo costo a travs de
estimulas fiscales, desarrollo de zonas preferenciales y otros incentivos en la legislacin.
28
y diseo de BD
Para lograrlo proporciona informacin sobre alojamiento de bajo costo a los gobiernos de
estado, municipal o regional. Adems mediante discursos, seminarios, publicidad en las
convenciones
y otras actividades de relaciones publicas, la organizacin
lucha por
aumentar la conciencia de la comunidad acerca de la necesidad de alojamiento de bajo

costo. Por ultimo la organizacin proporciona informacin sobre la disponibilidad de tal
tipo de habitacin a otras agencias que trabajan con la poblacin de bajos ingresos y sin
hogar.
29
Modelamiento de
datos y diseo de BD
30
y diseo de BD
Captulo 3
El Modelo Relacional y la Normalizacin
Objetivos:
; El Modelo relacional.
; Dependencias Funcionales.
; Normalizacin.
; Desnormalizacion
El Modelo Relacional
Una afinidad es una tabla de dos dimensiones donde cada hilera en la tabla tiene datos que
pertenecen a alguna cosa o a una parte de alguna cosa. Cada columna de la tabla contiene
datos referenciales a un atributo. Algunas hileras se denominan tuples y las columnas se
llaman atributos.
Los trminos afinidad, tuple y atributo surgen de las matemticas relacionales que son la fuente
terica de este modelo. Los profesionales en sistemas encuentran ms confortables los
trminos anlogos archivo, registro y campo pero la mayor parte de los usuarios encuentran
ms definidos los trminos tabla, hileras y columnas.
Para que una tabla sea una afinidad debe cumplir ciertas restricciones. Primero, las celdas de
la tabla deben ser de valor nico, no se permite repetir grupos ni tener arreglos como valores.
Todos los ingresos en cualquier columna (atributo) deben ser del mismo tipo. Si una columna
contiene nmeros de empleado debe haber nmeros de empleado para cada hilera de la tabla.
Cada columna posee un nombre nico y no es importante el orden de las columnas en la tabla.
La figura 3-2 es un ejemplo de una tabla. Observe que tiene siete hileras (tuples) constituidas
por cuatro columnas (atributos). Si se fuera a modificar el orden de las columnas colocando
NmeroDeEmpleado en el extremo izquierdo y tambin a reordenar las hileras quiz en
secuencia ascendiente de acuerdo a Edad se tendra una tabla equivalente.
La figura 3-2 muestra una ocurrencia de una tabla. El formato generalizado EMPLEADO
(Apellido, Edad, Sexo, NmeroDeEmpleado) se llama la estructura de la afinidad y es lo que la
mayor parte de la gente quiere decir cuando usa el trmino afinidad.
Para entender el modelo relacional y la normalizacin se deben comprender dos trminos:
dependencia funcional y clave. Estos conceptos aluden a las relaciones entre atributos en una
afinidad: ste es un buen ejemplo de por qu la terminologa en la tecnologa de las bases de
datos puede ser confusa. Una afinidad es una tabla. No confundirla con el trmino relacin que
es una asociacin entre cosas. Aunque las afinidades puedan expresar relaciones los dos
trminos hacen referencia a conceptos diferentes.
Modelo relacional
Programador
Usuario
Afinidad
Archivo
Tabla
Tuple (Fila)
Registro
Fila
Atributo
Campo
Columna
Fig. 3-1 Terminologa Relacional
31
Modelamiento de
datos y diseo de BD
Atributo 1
Atributo 2
Atributo 3
Atributo 4
Apellido
Edad
Sexo
NmeroDeEmpleado
Tuple 1
Ramirez
21
010110
Tuple 2
Alfaro
22
010100
Tuple 3
Bustamante
22
101000
Tuple 4
Altamirano
21
201100
Tuple 5
Juarez
19
111100
Tuple 6
Caceres
20
111101
Tuple 7
Solari
19
111111
Fig. 3-2 Afinidad EMPLEADO
Dependencias funcionales
Una dependencia funcional es una relacin entre uno o ms atributos. Suponga que si se da el
valor de un atributo se puede obtener o buscar el valor de otro. Si se conoce el valor de
NmeroDeCuentaDeCliente, se puede hallar el valor de EstadoDeCuentaCliente. Si esto es
cierto, se puede decir que EstadoDeCuentaDeCliente es funcionalmente dependiente de
NmeroDeCuentaDeCliente. En trminos ms generales, el atributo Y es dependiente del
atributo X si el valor de X determina el valor de Y. Dicho otro modo, si se conoce el valor de X,
se puede obtener el valor de Y.
Las ecuaciones pueden representar dependencias funcionales. Si se sabe el precio de un
artculo y la cantidad de artculos comprados, se puede calcular el precio total de esos artculos
como sigue:
PrecioTotal = PrecioDelArtculo x Cantidad
En este caso se podra decir que el PrecioTotal es dependiente del PrecioDelArtculo y
Cantidad.
Las dependencias funcionales entre atributos en una afinidad no involucran ecuaciones.
Suponga que los estudiantes tienen un nmero de identificacin nico IDEstudiante y que cada
alumno tiene una y slo una especialidad. Dado el valor de un IDEstudiante se puede encontrar
la especialidad del estudiante y as la Especialidad depende de IDEstudiante. Considere las
microcomputadoras en un laboratorio donde cada una tiene uno y solo un tamao de memoria
principal, por lo que TamaoDeMemoria depende de NmeroDeSerieDeComputadora.
A diferencia de una ecuacin, tales dependencias funcionales no pueden trabajarse usando
aritmtica; en vez de ello se listan en una base de datos. La expresin de las dependencias
funcionales es una de las razones para tener una base de datos.
Las dependencias funcionales se escriben usando la siguiente notacin:
IDEstudiante Especialidad
NmeroDeSerieDeComputadora TamaoDeMemoria
La primera expresin se lee como IDEstudiante determina funcionalmente Especialidad,
IDEstudiante determina Especialidad o Especialidad de IDEstudiante. Los atributos al lado
izquierdo de la flecha se llaman determinantes.
Una dependencia funcional es una relacin entre valores de atributos. Si IDEstudiante
determina Especialidad, un valor particular de IDEstudiante har pareja slo con un valor de
Especialidad. En sentido inverso un valor de Especialidad puede hacer pareja con uno o ms
valores diferentes de IDEstudiante.
IDEstudianteEspecialidad
Suponga que Contabilidad es la especialidad del estudiante cuyo IDEstudiante es 123. Cada
vez que IDEstudiante y Especialidad se encuentren juntos en una afinidad. El valor de
32
y diseo de BD
IDEstudiante para 123 siempre har pareja con el valor Contabilidad de Especialidad. Sin
embargo lo opuesto no es cierto, pues la Especialidad de Contabilidad puede hacer pareja con
varios valores de IDEstudiante (diversos estudiantes pueden tener especialidad en
Contabilidad). Se puede decir que la relacin de IDEstudiante con Especialidad es muchos a
uno (N:1). En general se puede decir que si A determina a B, la relacin de los valores de A a B
es N:1.
Las dependencias funcionales pueden involucrar grupos de atributos. Considere la afinidad
CALIFICACIONES (IDEstudiante, NombreDeClase, Calificacin). La combinacin de un
IDEstudiante y un NombreDeClase determina una calificacin, una dependencia funcional que
se escribe as:
(IDEstudiante, NombreDeClase) Calificacin.
Observe que tanto IDEstudiante como NombreDeClase son necesarios para determinar una
calificacin. No se puede subdividir la dependencia funcional porque IDEstudiante no determina
la calificacin por si mismo.
Claves
Una clave es un grupo de uno o ms atributos que identifican de modo nico a una hilera.
Considere la afinidad ACTIVIDAD de la figura 3-3, cuyos atributos son IDEstudiante, Actividad y
Cuota. El significado de una hilera es que un estudiante se apunta en la actividad designada
por una cuota especificada. Suponga que a un estudiante se le permite participar slo en una
actividad a la vez. Un valor de IDEstudiante determina una hilera nica de modo que es una
clave.
IDEstudiante
Actividad
Cuota
100
Tenis
200
150
Natacin
50
175
Voley
50
200
Natacin
50
Fig. 3-3 Afinidad con clave de un atributo
Las claves tambin pueden estar compuestas por un grupo de atributos tomados en conjunto.
Si a los estudiantes se les permitiera inscribirse en distintas actividades al mismo tiempo, sera
posible que un valor de IDEstudiante apareciera en dos o ms hileras de la tabla y por lo tanto,
IDEstudiante no identificara slo la hilera. Algunas combinaciones de atributos como
IDEstudiante, Actividad pueden ser requeridas
IDEstudiante
Actividad
Cuota
100
Tenis
200
100
Golf
65
150
Natacin
50
175
Voley
50
175
Natacin
50
200
Natacin
50
200
Golf
65
Fig. 3-4 Afinidad con una clave de dos atributos
33
Modelamiento de
datos y diseo de BD
Dependencias funcionales, claves y unicidad

A menudo se confunden los conceptos de dependencia funcionales, claves y unicidad. Para
evitar esta posibilidad, considere lo siguiente un determinante de una dependencia funcional
puede o no ser nico para una afinidad. Si se sabe que A determina a B y que A y B estn en
la misma afinidad, todava no se sabe si A es nico en esta afinidad. Slo se sabe que A
determina a B.
A diferencia de los determinantes de las dependencias funcionales, las claves son siempre
nicas. Una clave determina la hilera completa. Si se duplicara el valor de la clave, se repetira
el tuple completo. Por definicin, esto no permite, porque las hileras en una afinidad deben ser
nicas. Cuando se dice un atributo (o combinacin) es una clave, se sabe que ser nica.
Normalizacin
No todas las afinidades son deseables. Una tabla que cumple la definicin mnima de una
afinidad tal vez no tenga una estructura efectiva o apropiada. Para algunas afinidades el
cambiar los datos puede tener consecuencias no deseables llamadas anomalas de
modificacin. Las anomalas pueden eliminarse volviendo a definir la afinidad en dos o ms
afinidades. En la mayor parte de las circunstancias se prefieren las afinidades redefinidas o
normalizadas.
Clases de afinidades
Las afinidades pueden clasificarse por los tipos de anomalas de modificacin a las cuales son
vulnerables. En los aos setenta los tericos relacionales investigaron estos tipos. Alguien
encontraba una anomala la clasificaba y pensaba en una forma de prevenirla. Cada vez que
esto ocurra, mejoraban los criterios para disear las afinidades. Estas clases de afinidades y
las tcnicas para prevenir las anomalas son llamadas formas normales. Dependiendo de su
estructura, una afinidad puede estar en una primera forma normal, segunda forma normal o
alguna otra.
En 1970, E. F. Codd. estableci la primera, segunda y tercera forma normal (1NF, 2NF, 3NF).
Continuo con la forma normal de Boyce-Codd (BCNF) y despus se definieron la cuarta y la
quinta formas normales. Como se aprecia en la figura, estas formas normales estn anidadas.
Esto es una afinidad en la segunda forma normal tambin est en la primera forma normal y
una afinidad en la 5NF (quinta forma normal), est tambin en 4NF, BCNF, 3NF, 2NF y 1NF.
Primera forma normal (1NF)
Segunda forma normal (2NF)
Tercera forma normal (3NF)
Forma normal de Boyce-Codd (BCNF)
Cuarta forma normal (4NF)
Quinta forma normal (5NF)
Fig. 3-5 Relacin de las formas normales
Estas formas normales fueron tiles, aunque tenan serias limitaciones. Ninguna teora
garantizaba que una de ellas eliminara todas las anomalas: cada forma slo eliminaba
algunas.
Est situacin cambio en 1981, cuando R. Fagin defini una nueva llamada forma normal
dominio/clave (DK/NF). En un importante artculo, Fagin mostr que una afinidad en la forma
normal dominio/clave est libre de todas las anomalas de modificacin, sin importar su tipo.
34
y diseo de BD
Tambin mostr que cualquier afinidad libre de anomalas de modificacin, tambin est en la
forma normal dominio/clave.
Hasta que se defini DK/NF, era necesario que los diseadores de bases de datos relacionales
busquen anomalas y ms formas normales. Sin embargo, la prueba de Fagin simplific la
situacin. Si se puede poner una afinidad en DK/NF, entonces se puede estar seguro de que
no tendr anomalas. El truco es saber cmo poner las afinidades en DK/NF.
El proceso de normalizacin es un estndar que consiste, bsicamente, en un proceso de
conversin de las relaciones entre las entidades, evitando:
La redundancia de los datos: repeticin de datos en un sistema.
Anomalas de actualizacin: inconsistencias de los datos como resultado de datos

redundantes y actualizaciones parciales.
Anomalas de borrado: prdidas no intencionadas de datos debido a que se han

borrado otros datos.
Anomalas de insercin: imposibilidad de adicionar datos en la base de datos debido a

la ausencia de otros datos.
Tomando como referencia la tabla siguiente:

AUTORES Y LIBROS
Nombre
Nacin
CodLibro
Titulo
Editor
Date
USA
999
IBD
AW
Ad.Mig.
ESP
888
CyD
RM
Ma.Piat.
ITA
777
CyD
RM
Date
USA
666
BdD
AW
Se plantean una serie de problemas:
Redundancia: cuando un autor tiene varios libros, se repite la nacionalidad.
Anomalas de modificacin: Si Ad.Mig. y Ma.Piat. desean cambiar de editor, se

modifica en los 2 lugares. A priori no podemos saber cuntos autores tiene un libro. Los
errores son frecuentes al olvidar la modificacin de un autor. Se pretende modificar en
un slo sitio.
Anomalas de insercin: Se desea dar de alta un autor sin libros, en un principio.

NOMBRE y CODLIBRO son campos clave, una clave no puede tomar valores nulos.
Asegurando:
Integridad entre los datos: consistencia de la informacin.
El proceso de normalizacin nos conduce hasta el modelo fsico de datos y consta de varias
fases denominadas formas normales, estas formas se detallan a continuacin.
Definicin de la clave
Antes de proceder a la normalizacin de la tabla lo primero que debemos de definir es una
clave, esta clave deber contener un valor nico para cada registro (no podrn existir dos
valores iguales en toda la tabla) y podr estar formado por un nico campo o por un grupo de
campos.
En la tabla de alumnos de un centro de estudios no podemos definir como campo clave el
nombre del alumno ya que pueden existir varios alumnos con el mismo nombre. Podramos
35
Modelamiento de
datos y diseo de BD
considerar la posibilidad de definir como clave los campos nombre y apellidos, pero estamos en
la misma situacin: podra darse el caso de alumnos que tuvieran los mismos apellidos y el
mismo nombre (Juan Fernndez Martn).
La solucin en este caso es asignar un cdigo de alumno a cada uno, un nmero que
identifique al alumno y que estemos seguros que es nico.
Una vez definida la clave podremos pasar a estudiar la primera forma normal.
Primera forma normal (1NF)

Se dice que una tabla se encuentra en primera forma normal (1NF) si y solo si cada uno de los
campos contiene un nico valor para un registro determinado. Supongamos que deseamos
realizar una tabla para guardar los cursos que estn realizando los alumnos de un determinado
centro de estudios, podramos considerar el siguiente diseo:
Cdigo
Nombre
Cursos
Marcos
Ingles
Lucas
Contabilidad, Informtica
Marta
Ingles, Contabilidad
Podemos observar que el registro de cdigo 1 si cumple la primera forma normal, cada campo
del registro contiene un nico dato, pero no ocurre as con los registros 2 y 3 ya que en el
campo cursos contiene ms de un dato cada uno. La solucin en este caso es crear dos tablas
del siguiente modo:
TABLA A
Cdigo
Nombre
Marcos
Lucas
Marta
TABLA B
Cdigo
Curso
Ingls
Contabilidad
Informtica
Ingls
Contabilidad
Como se puede comprobar ahora todos los registros de ambas tablas contienen valores nicos
en sus campos, por lo tanto ambas tablas cumplen la primera forma normal.
Una vez normalizada la tabla en 1NF, podemos pasar a la segunda forma normal.
36
y diseo de BD
Segunda forma normal (2NF)

La segunda forma normal compara todos y cada uno de los campos de la tabla con la clave
definida. Si todos los campos dependen directamente de la clave se dice que la tabla est es
segunda forma normal (2NF).
Supongamos que construimos una tabla con los aos que cada empleado ha estado
trabajando en cada departamento de una empresa:
Cdigo Empleado
Cdigo Dpto.
Nombre
Departamento Aos
Juan
Contabilidad
Pedro
Sistemas
Sonia
I+D
Vernica
Sistemas
10
Pedro
Contabilidad
Tomando como punto de partida que la clave de esta tabla est formada por los campos cdigo
de empleado y cdigo de departamento, podemos decir que la tabla se encuentra en primera
forma normal, por tanto vamos a estudiar la segunda:
El campo nombre no depende funcionalmente de toda la clave, slo depende del

cdigo del empleado.
El campo departamento no depende funcionalmente de toda la clave, slo del cdigo

del departamento.
El campo aos si que depende funcionalmente de la clave ya que depende del cdigo
del empleado y del cdigo del departamento (representa el nmero de aos que cada
empleado ha trabajado en cada departamento)
Por tanto, al no depender todos los campos de la totalidad de la clave la tabla no est en
segunda forma normal, la solucin es la siguiente:
TABLA A
Cdigo Empleado
Nombre
Juan
Pedro
Sonia
Vernica
TABLA B
Cdigo Departamento
Departamento
I+D
Sistemas
Contabilidad
37
Modelamiento de
datos y diseo de BD
TABLA C
Cdigo Empleado
Cdigo Departamento
Aos
10
Podemos observar que ahora si tenemos las tres tablas en segunda forma normal,
considerando que la tabla A tiene como ndice el campo Cdigo Empleado, la tabla B Cdigo
Departamento y la tabla C una clave compuesta por los campos Cdigo Empleado y Cdigo
Departamento.
Tercera forma normal (3NF)

Se dice que una tabla est en tercera forma normal si y solo si los campos de la tabla
dependen nicamente de la clave, dicho en otras palabras los campos de las tablas no
dependen unos de otros. Tomando como referencia el ejemplo anterior, supongamos que cada
alumno slo puede realizar un nico curso a la vez y que deseamos guardar en que aula se
imparte el curso. Podemos plantear la siguiente estructura:
Cdigo
Nombre
Curso
Aula
Marcos
Informtica
Aula A
Lucas
Ingles
Aula B
Marta
Contabilidad
Aula C
Estudiemos la dependencia de cada campo con respecto a la clave cdigo:
Nombre depende directamente del cdigo del alumno.
Curso depende de igual modo del cdigo del alumno.
El aula, aunque en parte tambin depende del alumno, est ms ligado al curso que el
alumno est realizando.
Por esta ltima razn se dice que la tabla no est en 3NF. La solucin sera la siguiente:
TABLA A
Cdigo
38
Nombre
Curso
Marcos
Informtica
Lucas
Ingles
Marta
Contabilidad
y diseo de BD
TABLA B
Curso
Aula
Informtica
Aula A
Ingles
Aula B
Contabilidad
Aula C
Una vez conseguida la tercera forma normal, se puede estudiar la cuarta forma normal.
Cuarta forma normal (4NF)

Una tabla est en cuarta forma normal si y slo si para cualquier combinacin clave - campo no
existen valores duplicados. Vemoslo con un ejemplo:
GEOMETRIA
Figura
Color
Tamao
Cuadrado
Rojo
Grande
Cuadrado
Azul
Grande
Cuadrado
Azul
Mediano
Circulo
Blanco
Mediano
Circulo
Azul
Pequeo
Circulo
Azul
Mediano
Comparemos ahora la clave con el atributo Tamao, podemos observar que Cuadrado Grande
est repetido; igual pasa con Crculo Azul, entre otras. Estas repeticiones son las que se deben
evitar para tener una tabla en 4NF.
La solucin en este caso sera la siguiente:
TAMAO
Figura
Tamao
Cuadrado
Grande
Cuadrado
Pequeo
Circulo
Mediano
Circulo
Pequeo
39
Modelamiento de
datos y diseo de BD
COLOR
Figura
Color
Cuadrado
Rojo
Cuadrado
Azul
Circulo
Blanco
Circulo
Azul
Ahora si tenemos nuestra base de datos en 4NF.
Quinta forma normal

La quinta forma normal se refiere a dependencias que son extraas. Tiene que ver con
afinidades que puedan dividirse en subafinidades como se ha venido haciendo, pero que no
pueden reconstruirse. La condicin bajo la cual surge esta situacin, no tiene un significado
intuitivo preciso. No se sabe cules son las consecuencias de tales dependencias, incluso si
tienen consecuencias prcticas.
Cada una de las formas normales que se han analizado, fueron identificadas por investigadores
que encontraron anomalas con algunas afinidades que estaban en una forma normal inferior:
la deteccin de anomalas de modificacin con afinidades en la segunda forma normal
condujeron a la definicin de la tercera forma normal. Aunque cada forma normal resolva
algunos de los problemas de identificadores con la forma normal anterior, nadie poda saber
cuales problemas todava no haban sido identificados. Con cada paso, se avanzaban a una
definicin estructurada de las bases de datos, nadie poda garantizar que no se encontraran
ms anomalas.
Forma Normal Dominio/Clave

El concepto DK/NF es muy simple: Una afinidad esta en DK/NF si cada restriccin en la
afinidad es una consecuencia lgica de la definicin de las claves y dominios. Considere los
trminos importantes en esta definicin: restriccin, clave y dominio.
La restriccin se define como cualquier regla que gobierna los valores estticos de atributos.
Las reglas para editar, las restricciones de intrarelacin e interrelacin, las dependencias
funcionales y las dependencias de valores mltiples son ejemplos de restricciones.
Una clave es el nico identificador de tuple
Se estableci que un dominio es una descripcin de los valores permitidos para un atributo.
Tiene una descripcin fsica y una descripcin semntica o lgica. La descripcin fsica es la
serie de valores que puede tener el atributo y la descripcin lgica es el significado del atributo.
No se conoce un algoritmo para convertir una afinidad a DK/NF ni siquiera se sabe cuales
afinidades pueden convertirse a DK/NF. Encontrar o disear las afinidades DK/NF es ms un
arte que una ciencia. A pesar de esto la DK/NF puede ser muy til para el diseo de las base
de datos: a decir verdad la DK/NF es un objetivo de diseo.
40
y diseo de BD
Desnormalizacion
Las afinidades normalizadas evitan anomalas de modificacin y se prefieren a las afinidades
no normalizadas. Valorada bajo otros criterios algunas veces la normalizacin no vale la pena.
Considere esta afinidad:
CLIENTE (NumeroCliente,
NumeroCliente es la clave.
NombreCliente,
Ciudad,
Estado,
CodigoPostal),
donde
Esta afinidad no esta en DK/NF por que contiene la dependencia funcional CodigoPostal
(Ciudad, Estado), la cual no esta implcita en la clave, NumeroCliente. Por lo tanto existe una
restriccin que no esta implcita en la definicin de claves.
Esta afinidad puede transformarse en las siguientes dos afinidades DK/NF:
CLIENTE (NumeroCliente, NombreCliente, CodigoPostal) donde la clave es NumeroCliente
CODIGOS (CodigoPostal, Ciudad, Estado) donde la clave es CodigoPostal
Estas dos tablas estn en la forma normal dominio/clave, pero es muy probable que no
representen mejor el diseo. Tal vez sea mejor la tabla no normalizada, ser ms fcil de
procesar y no son muy importantes las desventajas de duplicar los datos de ciudad y Estado.
Algunas veces las afinidades se dejan a propsito no normalizadas o estn normalizadas y
despus desnormalizadas. Esto se hace para mejorar el funcionamiento. Siempre que los datos
deben combinarse de dos tablas separadas, el DBMS debe efectuar un trabajo adicional. En la
mayora de los casos se requieren cuando menos dos lecturas en vez de una.
41
Modelamiento de
datos y diseo de BD
Preguntas de repaso
1.
Cules restricciones deben ponerse en una tabla para que se considere una afinidad?
2.
Defina los siguientes trminos: afinidad, tuple, atributo, archivo, registro, campo, tabla,
hilera, columna
3.
Defina Dependencia Funcional. Proporcione ejemplo de dos atributos que tengan

dependencia funcional y uno de dos atributos que no lo tengan
4.
Defina determinante y proporcione un ejemplo
5.
Defina clave y proporcione un ejemplo
6.
Qu es una anomala de eliminacin?
7.
Qu es la Normalizacin?
8.
Defina la segunda forma normal
9.
Qu es la desnormalizacion?
10.
Defina la forma normal dominio/clave
12.
Transforme la afinidad siguiente a DK/NF. Realice las suposiciones convenientes acerca

de las dependencias funcionales y los dominios.
EQUIPO
(Fabricante,
Modelo,
FechadeAdquisicion,
NombreComprador,
TelefonoComprador, UbicacionPlanta, Ciudad, CodigoPostal)

13.
Transforme la afinidad siguiente a DK/NF. Realice las suposiciones convenientes acerca

de las dependencias funcionales y los dominios
FACTURA (Numero, NombreCliente, NumeroCliente, DireccionCliente, NumeroArticulo,
PrecioArticulo, CantidadArticulo, NumeroVendedor, NombreVendedor, Subtotal,
Impuesto, TotalPagar)
42
y diseo de BD
Captulo 4
Diseo de bases de datos empleando
Modelo entidad-relacin
Objetivos:
; Representacin de entidades con el modelo relacional.
; Representacin de relaciones.
; Representacin de relaciones recursivas.
Representacin de entidades con el modelo relacional

La representacin de entidades mediante un modelo relacional es directa. Se empieza por
definir una afinidad para cada entidad. El nombre de la afinidad es el nombre de la entidad y los
atributos de la afinidad son los atributos de la entidad.
La entidad CLIENTE contiene:
NmeroDeCliente
NombreDeCliente
Direccin
Ciudad
CdigoPostal
PersonaConLaQueSeHaceContacto
Telfono
Fig. 4-1 La entidad CLIENTE
CLIENTE (NmeroDeCLiente,NombreDeCliente, Direccin, Ciudad, CdigoPostal,

PersonaConLaQueSeHaceContacto, Telfono)
Fig. 4-2 La afinidad que representa la entidad CLIENTE
La funcin de la normalizacin
Durante la fase de requerimientos, slo se estipula que una entidad es importante para el
usuario. No se intenta determinar si la entidad se acerca a los criterios de normalizacin, una
vez que se ha definido una afinidad para una entidad, debe examinarse de acuerdo con los
criterios de normalizacin.
Considere afinidad CLIENTE de la figura 4-3. Est en DK/NF? Para saberlo, es necesario
conocer las limitaciones de esta afinidad. Sin una descripcin completa de los requisitos
implcitos, no se conocen todas las limitaciones, ni todas las restricciones de dominio. Es
43
Modelamiento de
datos y diseo de BD
posible descubrir algunos requisitos analizando los nombres de los atributos y conociendo la
naturaleza del negocio.
NmeroDeCliente determina todos los otros atributos, ya que pueden determinarse los valores
nicos de NombreDeCliente, Direccin, Ciudad, Estado, PersonaConLaQueSeHaceContacto y
Telfono, a partir de cierto valor de NmeroDeCliente.
Hay otras limitaciones que surgen de otras dependencias funcionales. CdigoPostal determina
Ciudad y PersonaConLaQueSeHaceContacto determina Telfono. Para crear un conjunto de
afinidades en DK/NF, es necesario hacer de estas dependencias funcionales adicionales una
consecuencia lgica de los dominios y las claves. Eso se logra definiendo las tres afinidades
que aparecen en la figura 4-3. Observe que la clave de CLIENTE es NmeroDeCliente, la clave
de CDIGOPOSTAL-TABLA es cdigoPostal y la clave de CONTACTO es
PersonaConLaQueSeHaceContacto.
El diseo de la figura 4-3 est en DK/NF y no hay anomalas de modificacin. Se pueden incluir
cdigos postales y personas encargadas nuevas sin tener que agregar un cliente con el nuevo
cdigo o persona encargada. Adems cuando se elimina el ltimo cliente en cierto cdigo
postal no se pierden la ciudad y el estado de tal cdigo postal.
Puede ser predefinida la afinidad CLIENTE original. Aun cuando contiene anomalas de
modificacin, tal vez no sean muy importantes. Si un CLIENTE, es probable que no se requiera
conservar el telfono de las personas con las que se hace contacto que pasan a otra
compaa. Es decir no necesita saber que el telfono de Jurez es 555-1234 si la compaa
para la que trabaja Jurez no es un cliente.
CLIENTE (NmeroDeCliente, Direccin, CdigoPostal, PersonaConLaQueSeHaceContacto)
CDIGOPOSTAL-TABLA (CdigoPostal, Ciudad)
CONTACTO (PersonaConLaQueSeHaceContacto, Telfono)
Limitaciones de interrelacin.
CdigoPostal en CLIENTE debe existir en CdigoPostal en CODIGOPOSTAL-TABLA
PersonaConLaQueSeHaceContacto en CLIENTE debe ser igual a
PersonaConLaQueSeHaceContacto en CONTACTO.
Fig. 4-3 Representacin de la entidad Cliente con Afinidades en DK/NF
La entidad VENTAS-COMISION contiene:

NmeroDeVendedor
NombreDeVendedor
Telfono
NmeroDeCheque
PeriodoDeComisin
TotalDeVentaPorComisin
Comisin
CategoriaDelpresupuesto
Fig. 4-4 Entidad Ventas-Comisin
44
y diseo de BD
VENTAS-COMISION
(NmeroDeVendedor,
NombreDeVendedor,
Telfono,
NmeroDeCheque, FechaDeCheque, PeriodoDeComisin, TotalDeVentasPorComisin,
CategoraDelPresupuesto)
Dependencias funcionales:
NmeroDeCheque es clave
NmeroDeVendedor determina NombreDeVendedor, Telfono, CategoriaDelPresupuesto
(NmeroDeVendedor, PeriodoDeComisin) determina
totalDeVentaProComisin, Comisin
Fig. 4-5 Representacin de VENTAS-COMISION con una afinidad nica
VENDEDOR (NmeroDeVendedor, NombreDeVendedor, Telfono,

CategoriaDelpresupuesto).
VENTAS (NmeroDeVendedor, PeriodoDeComisin,
TotalDeVentasPorComisin, Comisin, CategoriaDePresupuesto)
COMISIN (NmeroDeCheque, FechaDeCheque, NmeroDeVendedor
PeriodoDeComisin)
Fig. 4-6 Representacin de VENTAS-COMISION con relaciones DK/NF
Considerar la entidad VENTAS-COMISION de la figura 4-4. Si intenta representar con una

afinidad, como se muestra en figura 4-5, el resultado es un confuso lo de atributos con
muchas anomalas de modificacin potenciales.
Es obvio que esta afinidad contiene ms del tema. Al examinarla se aprecia un tema de los
vendedores: uno acerca de las ventas durante cierto periodo y otro sobre los cheques de
comisin por ventas. Las afinidades en DK/NF que representa esta entidad se muestra en la
figura 4-6. Intuitivamente, este diseo parece mejor que la figura 4-6 es directa y se adapta
mejor.
Para resumir este anlisis en este punto, cuando se representa una entidad con el modelo
relacional, el primero paso es desarrollar una afinidad que posea todos los atributos de la
entidad como columnas. Despus se examina la afinidad contra los criterios de normalizacin.
En mltiples casos, el diseo puede mejorarse desarrollado conjuntos de actividades en
DK/NF.
No siempre se prefiere las afinidades DK/NF. Las afinidades son artificiales y es difcil trabajar
con ellas, pueden ser mejor un diseo que no sea DK/NF. El rendimiento tambin puede ser un
factor. Tener que acceder a dos o tres afinidades para obtener los datos necesarios sobre un
cliente, puede provocar un prohibitivo consumo de tiempo.
Al margen de la decisin de si es necesario normalizar, se debe cada afinidad(es) de entidad
en contra de los criterios de normalizacin. Si se va a hacer una trasgresin, debe realizar de
un modo informado y consciente. Tambin se identifican los tipos de anomalas de modificacin
que pueden afectar las afinidades.
45
Modelamiento de
datos y diseo de BD
Representacin de Entidades dbiles

Antes de pasar a la representacin de las relaciones de un modelo E-R, considere la
representacin relacional de entidades dbiles. Para existir una entidad dbil depende de otra
entidad. Est dependencia necesita registrarse en el diseo relacional para que ninguna
aplicacin provoque una entidad dbil sin un padre (entidad de la cual depende la entidad dbil.
Necesita implementarse una limitacin de procesamiento para que cuando se elimine el padre,
tambin desaparezca la entidad dbil. Tales reglas deben describirse en el diseo relacional.
En la figura 4-7 ARTICULO-DE-LNEA es una entidad dbil dependiente. Es dbil porque su
existencia depende de FACTURA y depende de ID porque no tiene un nombre separado de
FACTURA.
1:N
FACTURA
ARTICULO-DE-LINEA
Fig. 4-7 Ejemplo de Entidad dbil
ARTICULO-DE-LINEA (NmeroDeLnea, Cant, NmeroDeArtculo, Descripcin, Precio,

Importe)
Fig. 4-8 Afinidad representando ARTICULO DE LINEA sin clave
ARTICULO-DE-LNEA (NmeroDeFactura, NmeroDeLnea, Cant, NmeroDeArtculo,

Descripcin, Precio, Importe)
Fig. 4-9 Afinidad ARTICULO DE LINEA con clave correcta
Para una entidad dbil dependiente es necesario agregar de la entidad padre a la afinidad de la
entidad dbil y este atributo incorporado se vuelve parte de la clave de la entidad dbil. En la
figura 4-9 se ha agregado NmeroDeFactura, la clave de FACTURA, a los atributos en
ARTICULO-DE-LINEA. La clave de ARTICULO-DE-LINEA es el objeto compuesto
(NmeroDeFactura, NmeroDeLnea).
Representaciones de relaciones
Se tienen las siguientes representaciones:
Representacin de relaciones Uno-a-Uno

La forma ms simple de las relaciones binarias es uno-a-uno (1:1), en la cual una entidad de un
tipo se relaciona con no ms de una entidad de otro tipo. El ejemplo de EMPLEADO y AUTO,
suponga que un automvil se asigna a un empleado y que un empleado se asigna a un
vehculo. En la figura 4-10 se muestra un diagrama E-R para esta relacin.
Representar una relacin 1:1 con un modelo relacional es directo. Cada entidad se representa
con una afinidad, y despus, la clave de una de las afinidades se coloca en la otra. En la figura
4-11,la clave de EMPLEADO se almacena en AUTO y en la figura 4-12 la clave de AUTO se
guarda en EMPLEADO.
Cuando la clave de una afinidad se almacena en la segunda se denomina una clave ajena o
clave fornea. En la figura 4-11 NmeroDeEmpleado es una clave ajena en AUTO y la
figura 4-12, NmeroDeLicencia es clave ajena de EMPLEADO. En las representaciones las
claves ajenas se muestran en cursivas, en ocasiones puede ver que se presentan con guiones
para subrayar. Todava hay otros casos en donde las claves ajenas no se denotan de ninguna
forma especial. Cuando existe el peligro de confusin, se muestra las claves ajenas en
cursivas, pero la mayor parte del tiempo no reciben ninguna notacin especial.
46
y diseo de BD
Para una relacin 1:1, la clave de una tabla se coloca como clave ajena en la otra. En la figura
4-11 la clave ajena NmeroDeEmpleado se coloca en AUTO. Con tal diseo, es posible pasar
EMPLEADO a AUTO o de AUTO a EMPLEADO. En el primer caso, tenemos un empleado y
deseamos el auto asignado a tal trabajador. Para obtener sus datos, usamos
NmeroDeEmpleado y as obtener la hilera del empleado en EMPLEADO. De est hilera,
tomamos el NmeroDeLicencia del auto asignado a tal empleado. Despus, se usa este
nombre para buscar los datos del automvil en AUTO.
Consideramos ahora la otra direccin. Suponga que se tiene un auto y deseamos conocer al
empleado asignado a tal vehculo. Usando el diseo de la figura 4-11 se accede la tabla
EMPLEADO y se busca la hilera que posee el nmero de licencia determinado. En tal hilera
aparecen los datos del empleado que se ha asignado a tal auto.
EMPLEADO
1:1
AUTO
Fig. 4-10 Ejemplo de relacion 1:1
Se realizan acciones similares para pasar en cualquier direccin para el diseo alternativo, en
el cual la clave ajena NmeroDeLicencia se coloca en EMPLEADO. Usando este diseo, para
ir de EMPLEADO a AUTO y se busca la hilera en AUTO que tiene cierto empleado como valor
de NmeroDeEmpleado. Para pasar de AUTO a EMPLEADO se busca la hilera en AUTO que
posee cierto NmeroDeLicencia. De esta hilera se toma el NmeroDeEmpleado y se usa para
acceder los datos de empleado en EMPLEADO. El uso del trmino buscar quiere decir
encontrar cierta hilera, dado un valor de una de sus columnas.
Aunque los dos diseos de las figuras 4-11 y 4-12 son equivalentes en lo conceptual, en su
funcionamiento son diferentes. Si una consulta es una direccin es ms comn que una
consulta en otra, es posible que se prefiera un diseo a otro. Asimismo, si el producto DBMS es
mucho ms rpido en bsquedas de claves primarias que en bsquedas de claves ajenas,
tambin se puede elegir un diseo sobre otro.
EMPLEADO (NumeroDeEmpleado, NombreDeEmpleado, Telfono,....)
AUTO(NumeroDeLicencia, NumeroDeSerie, Color, Marca, Modelo,.NumeroDeEmpleado)
Fig. 4-11 Colocacion de la clave de EMPLEADO en AUTO
EMPLEADO(NumeroDeEmpleado, NombreDeEmpleado, Telfono,...,NumeroLicencia)

AUTO (NumeroDeLicencia, NumeroDeSerie, Color, Marca, Modelo,.)
Fig. 4-12 Colocacion de la clave de AUTO en EMPLEADO
La figura 4-13 muestra otra relacin 1:1 en la cual cada EMPLEADO posee una EVALUACINDE-EMPLEO y cada EVALUACIN-DE-EMPLEO correspondiente a un empleado particular.
Por las marcas transversales se aprecia que la relacin es obligatoria en ambas direcciones. Es
probable que los registros describan aspectos diferentes de la misma entidad porque ambas
entidades tienen la misma clave. Cuando esto ocurre los registros deben combinarse en una
afinidad. Considere usted con muchas reservas tales relaciones obligatorias 1:1.
La separacin de una entidad en dos afinidades, en ocasiones puede justificarse. Una
justificacin se refiere al desempeo. Supongo que los datos de EVALUACIN-DE-EMPLEO
son extensos y se emplean con mucha menos frecuencia que el resto de la informacin sobre
empleados. En tales circunstancias, puede ser conveniente almacenar la informacin de
EVALUACIN-DE-EMPLEO en una tabla separada, de modo que se procesen con mayor
47
Modelamiento de
datos y diseo de BD
rapidez las solicitudes ms comunes de datos de empleados que no se refieren a

evaluaciones.
EMPLEADO
1:1
EVALUACION DE EMPLEO
Fig. 4-13 Relacion 1:1 sospechosa
Otra razn para dividir los dos registros es una mayor seguridad. Si el DBMS no da soporte la
seguridad a nivel de elementos de datos, puede ser necesario separar los datos de
EVALUACIN-DE-EMPLEO para evitar que los consulten usuarios no autorizados. Puede ser
conveniente colocar EVALUACIN-DE-EMPLEO en una tabla separada en un medio de disco
que se guarde en una seccin especial bajo clave.
Por este anlisis no se apresure a deducir que todas las relaciones 1:1 son inadecuadas; slo
son cuestionables aquellas que parecen describir distintos aspectos de la misma entidad. Es
muy conveniente la relacin 1:1 obligatoria entre EMPLEADO y AUTO, porque cada afinidad
describe una entidad diferente.
Representacin de Relaciones Uno-a-Varios

El segundo tipo de relacin binaria es uno-a-varios (1:N), en la cual entidad de un tipo puede
hacer referencia a mltiples entidades de otro tipo. La figura 4-14 es un diagrama E-R de una
relacin uno-a-varios entre profesores y estudiantes. En esta relacin, PROFESOR hace
referencia a los muchos ESTUDIANTES que asesora. El valo significa que la relacin entre
PROFESOR Y ESTUDIANTE es opcional; que un profesor no necesita tener alumnos a
quienes asesora. La lnea transversal en el otro extremo significa que una hilera de
ESTUDIANTE debe corresponder a una hilera de PROFESOR.
En ocasiones, en las relaciones 1:N se aplican los trminos padre e hijo a las afinidades. La
afinidad padre est en el lado uno de la relacin y la afinidad hijo est en el lado muchos.
La figura 4-15 muestra otras dos relaciones uno-a-varios. La figura muestra una entidad
DORMITORIO corresponde a muchas entidades ESTUDIANTE, pero una entidad
ESTUDIANTE corresponde a un DORMITORIO. Un dormitorio no tiene que tener estudiantes
asignados a l, ni se requiere que un estudiante viva en un dormitorio.
En la figura 4-16 un CLIENTE hace referencia a muchas entidades CITA, y una CITA particular
corresponde a slo un CLIENTE. Un CLIENTE puede o no tener una CITA, pero cada CITA
debe corresponder a un CLIENTE.
Representar relaciones 1:N es simple y directo. Cada entidad se representa a travs de una
afinidad. Despus, la clave de la afinidad que representa la entidad padre se coloca en la
afinidad que representa la entidad hija. Para representar la relacin de la figura 4-14, se coloca
la clave de PROFESOR, NombreDeProfesor en la afinidad ESTUDIANTE.
48
y diseo de BD
PROFESOR
ESTUDIANTE
1:1
Fig. 4-14 Relacion 1:N Opcional a Obligatoria
DORMITORIO
ESTUDIANTE
1:1
Fig. 4-15 Relacion 1:N Opcional a Opcional
DORMITORIO
1:1
ESTUDIANTE
Fig. 4-16 Relacion 1:N con entidad debil
PROFESOR
NombreDeProfesor
Telfono
Departamento.
ESTUDIANTE
NmeroDeEstudiante NombreDeEstudiante DireccinDeUniversidad NombreDeProfesor
Fig. 4-17 Representacin relacional de las entidades PROFESOR y ESTUDIANTE
La figura 4-17, la ramificacin en el extremo ESTUDIANTE de la lnea de relacin, implica que

pueden hacer mltiples hileras ESTUDIANTE de la lnea de relacin, implica que pueden haber
mltiples hileras ESTUDIANTE para cada PROFESOR. El que no aparezca una ramificacin en
el otro extremo, significa que cada ESTUDIANTE puede ser asesorado, como mximo, por un
PROFESOR. Al igual que con los diagramas E-R, se emplean lneas transversales para
representar relaciones obligatorias y valos para indicar las opcionales.
Observe que con NombreDeProfesor almacenado como una clave ajena en ESTUDIANTE, es
posible procesar la relacin en ambas direcciones. Dado un NmeroDeEstudiante, se puede
buscar la hilera apropiada en ESTUDIANTE y obtener el nombre de su asesor a partir de los
datos de la hilera. Para obtener el resto de los datos PROFESOR, se usa el nombre del
49
Modelamiento de
datos y diseo de BD
profesor obtenido de ESTUDIANTE para buscar la hilera apropiada en PROFESOR. Para

determinar todos los estudiantes asesorados por un miembro especfico del personal docente,
se buscan todas las hileras de ESTUDIANTE que tengan el nombre de profesor como valor
para NombreDelProfesor y despus se toman los datos de estudiantes de tales hileras.
Compare tal situacin con la que ocurre para representar relaciones 1:1. En ambos casos se
almacena la clave de una afinidad como clave ajena en la segunda. En una relacin 1:1 no
importa cul clave se mueva a la segunda afinidad pero si es importante en una relacin 1:N la
clave de una afinidad padre debe colocarse en la afinidad hija.
Para comprender mejor esta situacin, observe lo que sucedera si se intenta colocar la clave
de la hija en la afinidad padre. Como los atributos en una afinidad slo pueden tener un valor,
en cualquier registro de profesor, slo hay espacio para un estudiante. Tal ocurrencia no puede
usarse para representar el lado varios de la relacin 1:N. Una vez ms, para representar una
relacin 1:N, se debe poner la clave de la afinidad padre en la afinidad hija.
La figura 4-18 muestra la representacin de las entidades CLIENTE y CITA. Se representa aqu
cada entidad con una actividad. CITA es una entidad dbil dependiente de NumeroCliente, por
lo tanto, tiene una clave compuesta que consiste en la clave de la entidad de la que depende
su clave, ms un atributo de si mismo. La clave en este caso, es (NmeroDeCliente, Fecha,
Hora). Para representar la relacin 1:N normalmente se agregara la clave del padre a entidad
hija. La clave del padre (NmeroDeCliente) es parte de la hija y no es necesario agregarla la
relacin ya est representada.
CLIENTE
NmeroDeCliente NombreDeCliente Direccin Ciudad
Estado
CdigoPostal
CITA
NmeroDeCliente
Fecha
Hora
Costo
Fig. 4-18 Representacin relacional de la entidad dbil
Representacin de Relaciones Varios-a-Varios

El tercer y ltimo tipo de relacin binaria es varios-a-varios (M:N), en el cual una entidad de un
tipo correspondiente a muchas entidades del segundo tipo y una entidad del segundo tipo
correspondiente a muchas entidades del primer tipo.
La figura 4-19 presenta un diagrama E-R de la relacin muchos-a-muchos entre estudiantes y
claves. Una entidad ESTUDIANTE puede corresponder a mltiples entidades CLASE puede
corresponder a muchas entidades ESTUDIANTE. Observe usted que ambos participantes en la
relacin son opcionales: Un estudiante no necesita estar inscrito en una clase y clase no
necesita tener estudiantes.
Las relaciones varios-a-varios no pueden representarse mediante afinidades, como se hace
con las relaciones uno-a-uno y uno-a-varios. Para comprender por qu sucede as, intente usar
la misma estrategia que aplicamos con las relaciones 1:1 y 1:N: colocar la clave de una afinidad
como clave ajena en la otra. Defina una afinidad para cada una de las entidades; denomnelas
ESTUDIANTE y CLASE, Intente poner la clave de ESTUDIANTE (por ejemplo,
NmeroDeEstudiante) en CLASE. Debido a que no se permiten valores mltiples en las celdas
de una afinidad slo hay espacio para un NmeroDeEstudiante valores mltiples en las celdas
de un afinidad slo hay espacio para un NmeroDeEstudiante, por lo tanto, qu se hace con
el segundo estudiante inscrito en esa clase?
50
y diseo de BD
ESTUDIANTE
CLASE
M:N
Fig. 4-19 Diagrama E-R de la relacion ESTUDIANTE a CLASE
Ocurrir el mismo problema si se intenta poner la clave de CLASE (por ejemplo,

NmeroDeClase) en ESTUDIANTE. Es posible almacenar con facilidad el identificador de la
primera clase en la que se inscribe un estudiante, pero no hay espacio para almacenar el
identificador de la segunda y siguientes clases.
ESTUDIANTE (NmeroDeEstudiante, NombreDeEstudiante)
CLASE (NmeroDeClase, NombreDeClase)
ESTUDIANTE-CLASE (NmeroDeClase, NmeroDeEstudiante)
Fig. 4-20 Afinidades necesarias para representar la relacin ESTUDIANTE a CLASE
100
Arce, Leslie
100
10
10
Contabilidad
200
Palmer, Pablo
200
10
20
Finanzas
300
Milla, July
200
30
30
Mercadotecnia
300
30
40
Base de Datos
300
40
Fig. 4-21 Datos de ejemplo para la relacin ESTUDIANTE a CLASE
ESTUDIANTE
CLASE
NmeroDeEstudiante NombreDeEstudiante
NmeroDeClase
NmeroDeEStudiante
NombreDeClase
NumeroDeClase
Fig. 4-22 Diagrama de estructura de datos para la relacin ESTUDIANTE a CLASE.
Representacin de relaciones recursivas

Una relacin recursiva es aquella entre entidades de la misma clase. Las relaciones recursivas
no son diferentes de otras relaciones TIENE-UN y se representa usando las mismas tcnicas.
La nica complicacin es que, en las relaciones recursivas, las entidades tienen relaciones con
otras de su propia clase. Igual que con las relaciones no recursivas, las entidades tienen
relaciones con otras de su propia clase. Igual que con las relaciones no recursivas TIENE-UN,
hay tres tipos de relaciones recursivas: 1:1,1:N y N:M.
51
Modelamiento de
datos y diseo de BD
Considere usted primero la relacin PATROCINADOR de la figura 4-23, igual que con las
relaciones 1:1, una persona puede patrocinar a otra y cada persona es patrocinada por no ms
de una persona.
Para representar relaciones recursivas 1:1, se adopta un enfoque casi idntico al que se
emplea para relaciones regulares 1:1 es posible colocar la clave de la persona que se patrocina
en la hilera del patrocinador o poner la clave del patrocinador en la hilera de la persona que se
patrocina. La figura 4-24 muestra la primera alternativa, y la figura 4-25 incluye la segunda.
Ambas funcionan y la eleccin depende de aspectos tales como el rendimiento.
PATROCINADOR
1:1
PERSONA
Fig. 4-23 Relacin recursiva 1:1.
RECOMENDADO POR
1:N
CLIENTE
Fig. 4-24 Relacin recursiva 1:N.
TRATADO POR
N:M
DOCTOR
Fig. 4-25 Relacin recursiva N:M.
En esta tcnica es idntica a las que se emplea para relaciones no recursivas 1:1. Las hileras
hija y padre residen en la misma afinidad.
52
y diseo de BD
Representacin de subtipos
La estrategia para representar subtipos o relaciones ES-UN. Considere el ejemplo CLIENTE
con los atributos NmeroDeCliente, NombreDeCliente y CantidadAdeudada. Suponga que hay
tres subtipos de CLIENTE, por ejemplo, CLIENTE-PERSONA, CLIENTE-SOCIEDAD, y
CLIENTE-EMPRESA, con los siguientes atributos.
CLIENTE-PERSONA: Direccin, NmeroDeSeguroSocial.
CLIENTE-SOCIEDAD:NombreDelSocioAdministrador,Direccin, NmeroDeIdentificacinFiscal.
Para representar esta estructura por medio de afinidades, se define una afinidad para el
supertipo (CLIENTE) y otra para cada subtipo. Se coloca despus cada uno de los atributos del
supertipo en la afinidad que lo representan. En este punto, las afinidades subtipo no tienen una
clave. Para crearla se agrega la clave del supertipo o NmeroDeCliente a cada uno de los
subtipos. La lista final de afinidad es:
CLIENTE (NmeroDeCliente, NombreDeCliente, CantidadAdeudada)
CLIENTE-PERSONA (NmeroDeCliente, Direccin, NmeroDeSeguroSocial)
CLIENTE-SOCIEDAD
(NmeroDeCliente,
NmeroDelidentificacinFiscal)
CLIENTE-EMPRESA (NmeroDeCliente,
NmeroDelidentificacinFiscal)
NombreDelSocioAdministrador,
Direccin,
PersonaConQuienSeHaceContrato,
Telfono,
Observe usted que con esta estructura la relacin entre una hilera en CLIENTE y una hilera en
uno de los subtipos es 1:1. Ningn cliente tiene ms de una hilera en una afinidad subtipo y
cada subtipo corresponde slo a una hilera del supertipo. Dependiendo de las restricciones de
la aplicacin sera posible que una hilera en CLIENTE correspondiera con varias hileras, cada
una de un subtipo distinto. Pero ninguna hilera de CLIENTE puede corresponder a ms de una
hilera en la misma afinidad subtipo.
Es posible que uno o ms de los subtipos tengan una clave propia. La aplicacin puede
solicitar que NmeroDeClienteEmpresa sea distinto de NmeroDeCliente. En este caso, la
clave de CLIENTE-EMPRESA es NmeroDeClienteEmpresa. Dado que la relacin entre
CLIENTE y CLIENTE-EMPRESA es 1:1, puede establecer colocando la clave de una en la otra.
Con ms frecuencia y por cuestiones estticas, se prefiere colocar la clave de la afinidad
supertipo. En tal caso, la estructura de CLIENTE-EMPRESA es:
CLIENTE-EMPRESA (NmeroDeClienteEmpresa, NmeroDeCliente.
PersonaConQuienSeHaceContrato, Telfono, NmeroDeIdentificacinFiscal)
Ejemplo
El siguiente diagrama E-R contiene los elementos empleados en los diagramas E-R. Para
representar este diagrama mediante afinidades, se comienza por establecer una afinidad por
cada entidad. Se supone que las claves son las siguientes:
AFINIDAD
CLAVE
EMPLEADO
NumeroDeEmpleado
INGENIERO
NumeroDeEmpleado
CAMION
NumeroDeLicencia
SERVICIO
NumeroDeFactura
CLIENTE
NumeroDeCliente
INGENIERO-CERTIFICACION
(Empleado, NombreDeCertificacion)
CERTIFICACION
NombreDeCertificacion
53
Modelamiento de
datos y diseo de BD
EMPLEADO
CAMION-ASIGNACION
CAMION
INGENIERO
1:1
INGENIERO-HABILIDAD
SERVICIO-PROVEEDOR
1:N
1:N
SERVICIO
N:M
TARIFA
INGENIEROCERTIFICACION
CLIENTE-SERVICIO
N:1
CALIFICACIN-INGENIERO
CLIENTE
CERTIFICACION
1:N
RECOMENDADO POR
Fig. 4-26 Diagrama E-R
EMPLEADO (NmeroDeEmpleado, otros atributos de EMPLEADO que no son de clave....)

INGENIERO (NmeroDeEmpleado, otros atributos de INGENIERO que no son de clave....)
CAMION (NmeroDeLicencia,
NmeroDeEmpleado)
otros
atributos
de
CAMION
que
no
son
de
clave
SERVICIO (NmeroDeFactura, otros atributos de SERVICIO que no son de clave

NmeroDeEmpleado)
CLIENTE (NmeroDeCliente,
RecomendoPor)
otros
atributos
de
CLIENTE
que
no
son
de
clave,
SERVICIO-CLIENTE (NmeroDeFactura, NmeroDeCliente, Tarifa)

INGENIERO-CERTIFICACION (NmeroDeEmpleado, NombreDeCertificacin, otros atributos
que no son clave de INGENIERO-CERTIFICACION)
CERTIFICACIN (NombreDeCertificacin,
CERTIFICACION)
otros
atributos
que
no
son
clave
de
Fig. 4-27 Afinidades necesarias para representar Diagrama E-R
Debido a que INGENIERO-CERTIFICACION depende de la Identificacin de Ingeniero,

sabemos que NmeroDeEmpleado debe ser parte de su clave; la clave es compuesta de
NmeroDeEmpleado y NombreDeCertificacin. La relacin de dependencia es 1:N y se
realizar por medio de NmeroDeEmpleado. La relacin entre CERTIFICACIN y
INGENIERO-CERTIFICACION es 1:N y, normalmente, se agregara la clave de
CERTIFICACIN (el padre) a INGENIERO-CERTIFICACION.
54
y diseo de BD
Preguntas de repaso
1.
Cmo se transforman las entidades E-R en afinidades?
2.
Explique la representacin de entidades dbiles y fuertes
3.
Liste los tres tipos de relaciones binarias y proporcione un ejemplo de cada uno
4.
Defina clave externa y proporcione un ejemplo
5.
Muestre como representar la relacin 1:N
6.
Defina los trminos Padre e hijo y proporcione un ejemplo
7.
Para una relacin 1:N explique por que debe colocar la clave del padre en el hijo, en
lugar de incorporar la clave del hijo en el padre.
55
Modelamiento de
datos y diseo de BD
56
y diseo de BD
Anexo
Presentacin de casos prcticos
CASO: Cursos de Formacion de Empleados

Descripcin de la Empresa
El departamento de formacin de una empresa desea construir una base de datos
planificar y gestionar la formacin de sus empleados.
para
La empresa organiza cursos internos de formacin de los que se desea conocer el cdigo de
curso, el nombre, descripcin, el nmero de horas de duracin y el coste del curso.
Un curso puede tener como prerrequisito haber realizado otros previamente y a su vez la
realizacin de un curso puede ser prerrequisito de otros. Un curso que es un prerrequisito de
otro puede serlo de forma obligatoria o solo recomendable.
Un mismo curso tiene diferentes ediciones es decir se imparte en diferentes lugares, fechas y
con diferentes horarios (intensivos de maana o de tarde). En una misma fecha de inicio solo
puede impartirse una edicin de un curso.
Los cursos se imparten por personal de la propia empresa.
De los empleados se desea almacenar su cdigo de empleado, nombre y apellidos, direccin,
telfono, fecha de nacimiento, nacionalidad, sexo, firma y salario as como si esta capacitado
para impartir cursos.
Un mismo empleado puede ser docente en una edicin de un curso y alumno en otra edicin,
pero nunca puede ser ambas cosas a la vez (en una misma edicin de curso o lo imparte o lo
recibe)
Requerimientos
El departamento de formacin de la empresa desea construir una base de datos para

la planificacin y gestin de los cursos de formacin de los empleados
La Empresa organiza cursos de formacin en los que desea conocer el cdigo de

curso, nombre, descripcin, duracin y el coste del curso.
Se necesita almacenar el cdigo del empleado, nombre y apellidos, direccin, telfono,

fecha de nacimiento, nacionalidad, sexo, firma y salario as como si esta capacitado
para impartir cursos.
Reglas de Negocio
Un curso puede tener como prerrequisito haber realizado previamente otro.
Un curso tiene diferentes ediciones
Los cursos se imparten por personal de la propia empresa
Un mismo empleado puede ser expositor en una edicin y alumno en otra.
Modelo del Sistema

Entidades
Realizando la bsqueda de entidades
siguiente lista:
Curso
Edicin
Empleado
relacionados con el sistema podemos elaborar la
57
Modelamiento de
datos y diseo de BD
Capacitado
No Capacitado
Relaciones
N:M
CURSO
prerrequisito
CURSO
1:N
EDICION
EDICION
58
N:M
EMPLEADO
y diseo de BD
N:M
EDICION
N:1
EMPLEADO
CAPACITADO
NO CAPACITADO
Propuesta de Solucin
La propuesta de solucin se obtendra agrupando las soluciones parciales obtenidas:
Prerrequisito
N:M
CURSO
1:N
N:M
EDICION
N:1
EMPLEADO
CAPACITADO
NO CAPACITADO
59
Modelamiento de
datos y diseo de BD
CASO: Enseanza de lecciones de Baile

Descripcin del Negocio
El JK Dance Club ensea bailes de saln y ofrece a sus clientes lecciones privadas y de grupo.
La empresa cobra 45 dlares por hora a cada estudiante (o pareja) por una leccin privada y
de 6 dlares por hora, por una leccin en grupo. Se dan lecciones privadas todo el da, de las
12 AM a las 10:00 PM, seis das a la semana. Las lecciones por grupo se ofrecen en las
noches.
El club emplea dos tipos de instrucciones: de tiempo completo y por horas. Los instructores de
tiempo completo reciben una cantidad fija por semana y los maestros por horas cobran una
cantidad por una noche o por trabajar durante una clase particular.
Adems de las lecciones, el JK auspicia dos bailes a la semana con msica grabada. El costo
de admisin es de 5 dlares por persona. El baile de la noche del viernes es el ms popular y
promedia alrededor de 80 personas. El baile de la noche del sbado rene a treinta
participantes. El propsito de los bailes es dar a los estudiantes un lugar para que participen
sus habilidades. No se sirven alimentos ni bebidas.
Requerimientos
Al club le gustara desarrollar un sistema de informacin para registrar a los estudiantes

y las clases que han tomado.
Los administradores tambin desearan saber cuntos y cules tipos de lecciones ha

enseado cada maestro
Calcular el costo promedio por leccin con cada instructor.
Modelo del Sistema

Entidades
La mejor parte de iniciar un modelo entidad-relacin es determinar las entidades potenciales.
stas se representan con nombres de lugares, personas, conceptos, eventos, equipo, etc. en
los documentos o entrevistas. Una bsqueda de nombres importantes relacionados con el
sistema de informacin revela la lista siguiente:
Leccin privada.
Leccin en grupo.
Maestro.
Maestro de tiempo completo.
Maestro por horas.
Baile.
Cliente.
Es evidente que los nombres leccin privada en grupo denotan algo en comn, al igual que los
nombres maestro, maestro de tiempo completo y maestro por horas. Una solucin es definir
una entidad LECCIN, con subtipos LECCIN-PRIVADA y LECCIN-DE-GRUPO y otra
entidad MAESTRO, con subtipos MAESTRO-DE-TIEMPO-COMPLETO y MAESTRO-PORHORAS. Las entidades adicionales son BAILE y CLIENTE.
Relaciones
MAESTRO
tiene
dos
entidades
subtipo,
MAESTRO-DE-TIEMPO-COMPLETO
debe ser de uno o de otro; los subtipos son mutuamente excluyentes.
Despus se deben considerar las relaciones entre MAESTRO y LECCIN-PRIVADA y
LECCIN-EN-GRUPO. Un MAESTRO puede ensear mltiples LECCIONES-PRIVADAS y
una LECCIN-PRIVADA es impartida por un solo MAESTRO. Sin Embargo, un anlisis ms
detallado con los administradores del JK revela que, para los bailarines avanzados (en especial
los que se preparan para competencias), participan dos maestros en una leccin privada. La
60
y diseo de BD
leccin entre MAESTRO y LECCIN-PRIVADA debe ser muchos a muchos. Se supone que
slo un MAESTRO participa en una leccin de grupo.
LECCIN EN
GRUPO
LECCIN
PRIVADA
1:N
N:2
MAESTRO
MAESTRO DE
TIEMPO COMPLETO
MAESTRO
POR HORAS
Figura 1 Diagrama Entidad-Relacion inicial
Entre los CLIENTES, stos pueden tomar LECCIONES-PRIVADAS o LECCIONES-ENGRUPO. En ocasiones, una leccin la toma slo una persona y a veces una pareja. Esta
situacin puede modelarse en dos formas. Definirse como una entidad PAREJA, y tener una
relacin uno a dos con CLIENTE, o que CLIENTE o PAREJA tengan una relacin con
LECCIN-PRIVADA. Se supone que las parejas no toman lecciones en grupo y que, si lo
hacen, no es importante almacenar tal hecho en la base de datos.
La existencia de LECCIN-PRIVADA depende de cliente o pareja. Esto es, una leccin no
puede existir a menos que se proporcione a un CLIENTE o una PAREJA.
61
Modelamiento de
datos y diseo de BD
2:1
CLIENTE
1:N
PAREJA
N:1
LECCIN
PRIVADA
N:M
LECCIN
EN GRUPO
Figura 2a Diagrama E-R que muestra la entidad PAREJA
CLIENTE
2:N
LECCIN
PRIVADA
N:M
LECCIN
EN GRUPO
Figura 2b Diagrama E-R sin parejas
Otra alternativa es no representar parejas de eso, modelar la relacin entre CLIENTE y

LECCIN-PRIVADA como muchos a muchos y se muestra en figura 2 (b). Para ser ms
precisos, esta relacin es uno o dos a muchos. Aunque el modelo no es tan desarrollado como
el de la Figura 2 (a), puede servir muy bien para los propsitos del JK.
La ltima posibilidad de relacin entre BAILE y otras entidades. Tanto clientes como maestros
asisten a los bailes, y los analistas deben decidir si es importante almacenar tales relaciones.
En verdad la empresa necesita saber cules clientes asisten a los bailes? En verdad quieren
los administradores del club registrar la asistencia de clientes en un sistema de informacin
basado en computadora? Desean los clientes que se registre tal hecho? Es provocar que tal
relacin no necesite o deba almacenar BAILE y MAESTRO es distinta. A la empresa le gusta
que asistan maestros a cada baile. Para que este requerimiento sea equitativo, la
administracin ha programado la asistencia de los maestros a los bailes. Desarrollar y registrar
tal programa requiere que la base de datos contenga la relacin BAILE-MAESTRO, la cual es
muchos a muchos.
62
y diseo de BD
Diagrama E-R final para le JK Dance Club

En este diagrama no hemos mencionado las relaciones. Aunque hacerlo provocara que los
diagramas se apegaran ms a la forma, para nuestros datos nombrar las relaciones aportara
casi nada.
La existencia de LECCIN-PRIVADA depende del CLIENTE, pero LECCIN-EN-GRUPO no
depende, debido a que las lecciones en grupo se programan antes de que se registren los
clientes y se celebran incluso si estos no acuden. Sin embargo, esto no es cierto en las
lecciones privadas ya que slo se programan a solicitud del cliente. Observe tambin que este
modelo no representa a las parejas.
Una vez desarrollado un modelo debe verificarse su precisin e integridad en relacin con los
requerimientos. Esto se realiza con los usuarios.
CLIENTE
2:N
N:M
LECCIN
PRIVADA
LECCIN EN
GRUPO
1:N
MAESTRO
N:2
MAESTRO DE
TIEMPO
COMPLETO
N:M
BAILE
MAESTRO POR
HORAS
Figura 3 Diagrama E-Rfinal para JK Dance Club
Evaluacin del modelo de datos E-R

Es ms fcil y menos costoso corregir errores al principio del proceso de desarrollo de la base
de datos y no al final. Por ejemplo, cambiar la cardinalidad mxima de una relacin de 1:N a
N:M, en la etapa del modelado de datos, es slo cuestin de registrar el cambio en el diagrama
E-R. Una vez que se ha diseado y cargado la base de datos con informacin y programas de
aplicacin escritos para procesarla, realizar tal cambio requiere mucha reelaboracin, incluso
cientos de horas de trabajo. Es importante evaluar el modelo de datos antes de disearlo.
Una tcnica de evaluacin es considerar el modelo de datos E-R en el contexto de las
consultas que se podran plantear a la base de datos con la estructura que implica el modelo.
Observe usted el diagrama de la Figura 3 Cules preguntas podran contestarse con una
base de datos que implementara de acuerdo con este diseo?
A quienes se impartieron lecciones privadas?
63
Modelamiento de
datos y diseo de BD
Cules clientes han tomado una leccin privada con Carlos?
Quines son maestros de tiempo completo?
Cules maestros estn programados para asistir al baile el viernes?
Cundo se evala un modelo de datos E-R, se formulan tales preguntas y se muestran a los
usuarios para pedirles que hagan su propia lista de preguntas. Sus preguntas se prueban
contra el diseo para verificar si son apropiadas. Suponga usted que los usuarios preguntaron
cules clientes asistieron al baile del viernes en la noche de la semana anterior. Los
diseadores del modelo de datos de la figura 3 llegaran a la conclusin que su diseo no fue
correcto, debido a que no es posible responder a esta pregunta usando su modelo. Si es
necesaria una respuesta, entonces debe estructurarse una relacin entre CLIENTE y BAILE.
Resulta evidente que un proceso estructurado con tan escaso rigor no puede usarse para
comprobar que un diseo es correcto. Slo es una tcnica para verificar la exactitud potencial
de un diseo. Y es mejor que no hacer ninguna evaluacin.
64
y diseo de BD
CASOS PROPUESTOS
CASO: Campeonato de Ajedrez
Enunciado
La Federacin Peruana de ajedrez, ha sido encargada por la Federacin Internacional de
Ajedrez de la organizacin de los prximos campeonatos mundiales que se celebraran en la
ciudad de Lima. Por este motivo, desea llevar a una base de datos de toda la gestin relativa a
participantes, alojamiento y participantes, alojamiento y partidas. Teniendo en cuenta que:
En el campeonato participan jugadores y rbitros; de ambos se requiere conocer el nmero de
asociado, nombre, direccin, telfono de contacto y campeonatos en los que han participado
(como jugador o como rbitro). De los jugadores se precisa adems el nivel del juego en una
escala de 1 a 10.
Ningn rbitro puede participar como jugador.
Los pases envan al campeonato un conjunto de jugadores y rbitros, aunque ni todos los
pases envan participantes. Todo jugador y rbitro es enviado por un nico pas. Un pas
puede ser representado por otro pas.
Cada pas se identifica por un nmero correlativo segn su orden alfabtico e interesa conocer
adems de su nombre, el nmero de clubes de ajedrez existentes en el mismo.
Cada partida se identifica por un nmero correlativo (Cd_P), la juegan dos jugadores y la
arbitra un rbitro. Interesa registrar las partidas que juegan cada jugador y el color (blancas o
negras) con el que juega. Ha de tenerse en cuenta que un rbitro no puede arbitrar a jugadores
enviados por el mismo pas que le ha enviado a l.
Todo participante participa en al menos una partida:
Los jugadores como rbitros se alojan en uno de los hoteles en los que se desarrollan las
partidas, se desean conocer en qu hotel y en qu fecha se ha alojado cada uno de los
participantes. Los participantes pueden no permanecer en Lima durante todo el campeonato,
sino acudir cuando tienen que jugar alguna partida alojndose en el mismo o distinto hotel. De
cada hotel, se desea conocer el nombre, la direccin y el nmero de telfono.
El campeonato se desarrolla a lo largo de una serie de jornadas (Ao, mes, da) y cada partida
tiene lugar en una de las jornadas aunque no tengan lugar partidas todas las jornadas.
Cada partida se celebran en una de las salas de las que pueden disponer los hoteles, se desea
conocer el nmero de entradas vendidas en la sala para cada partida. De cada sala, se desea
conocer la capacidad y medios de que dispone (radio, televisin, vdeo...) para facilitar la
retransmisin de los encuentros. Una sala puede disponer de varios medios distintos.
De cada partida se pretende registrar todos los movimientos que la componen, la identificacin
de movimiento se establece en base a un nmero de orden dentro de cada partida: para cada
movimiento se guardan la jugada (5 posiciones) y un breve comentario realizado por un
experto.
CASO: Energia Elctrica

Enunciado
Se pretende levar a cabo un control sobre la energa elctrica que se produce y consume en un
determinado pas. Se parte de la siguiente hiptesis.
Existen productores bsicos de electricidad que se identifican por un nombre, de los cuales
interesa su produccin media, produccin, mxima y fecha de entrada en funcionamiento.
Estos productores bsicos lo son de una de las siguientes categoras: Hidroelctrica, Solar,
Nuclear o Trmica. De una central Hidroelctrica o presa nos interesa saber su ocupacin,
capacidad mxima y nmero de turbinas. De una central solar nos interesa saber la superficie
65
Modelamiento de
datos y diseo de BD
total de paneles solares, la media anual de horas de sol y tipo (fotovoltaica o termodinmica).
De una central nuclear, no interesa saber el nmero de reactores que posee, el volumen de
plutonio consumido y el de residuos nucleares que produce. De una central trmica, nos
interesa saber el nmero de hornos que posee, el volumen de carbn consumido y el volumen
de su emisin de gases.
Por motivos de seguridad nacional interesa controlar de que se provee una central nuclear,
este control se refiere a la cantidad de plutonio que compra a cada uno de sus posibles
suministradores, (nombre y pas), y que porta un determinado transportista (nombre y
matrcula), se ha de tenerse en cuneta que el mismo suministrador puede vender plutonio a
distintas centrales nucleares y que cada porte, (un nico porte por compra), puede realizarlo un
transportista diferente.
Cada da, los productores entregan la energa producida a una o varias estaciones primarias,
las cuales pueden recibir diariamente una cantidad distinta de energa de cada uno de estos
productores. Los productores entregan siempre el total de su produccin. Las estaciones
primarias se identifican por su nombre y tiene un nmero de transformadores de baja a alta
tensin y son cabecera de una o varias redes de distribucin.
Una rede de distribucin se identifica por un nmero de red y slo puede tener una estacin
primaria como cabecera. La propiedad de una red pude ser compartida por varias compaas
elctricas, a cada compaa elctrica se le identifica por su nombre.
La energa sobrante en una de las redes puede enviarse a otra red. Se registra el volumen de
energa intercambiada entre dos redes.
Una red esta compuesta por una serie de lneas, cada lnea se identifica por un nmero
secuencial dentro del nmero de red y tiene una determinada longitud. La menor de las lneas
posibles abastecer al menos a dos subestaciones.
Una subestacin es abastecida slo por una lnea y distribuye a una o varias zonas de
servicios, a tales efectos, las provincias (cdigo y nombre), se encuentran divididas en tales
zonas de servicio, aunque no puede haber zonas de servicio que pertenezcan a ms de una
provincia. Cada zona de servicio puede ser atendida por ms de una subestacin.
En cada zona de servicio se desea registrar el consumo medio y el nombre de consumidores
finales de cada una de las siguientes categoras particulares, empresas e instituciones.
CASO: Conflictos Blicos

Enunciado
Una organizacin internacional pretende realizar un seguimiento de los conflictos blicos que
se producen en todo el mundo. Para ello crear un BD que responder al siguiente anlisis:
Se entiende por conflicto cualquier lucha armada que afecte a uno o varios pases y en el cual
se produzcan muertos y/o heridos. Todo conflicto se identificar por un nombre que
habitualmente har referencia a la zona o causa que provoca el conflicto, aunque dado que
este nombre pude cambiar con el paso del tiempo, dentro de la BD cada conflicto se
identificar mediante un cdigo numrico sin significado alguno. Para cada conflicto se desea
recoger los pases a que afecta, as como el nmero de muertos y heridos contabilizados hasta
el momento.
Los conflictos pueden ser de distintos tipos segn la causa que lo ha originado, clasificndose,
a lo sumo, en cuatro grupos; territoriales, religiosos, econmicos o raciales, en cada uno de
estos grupos se recogern diversos datos. En los conflictos territoriales se recogern las
regiones afectadas, en los religiosos las religiones afectadas, en los econmicos las materias
primas disputadas y en los raciales las etnias enfrentadas.
En los conflictos intervienen diversos grupos armados (al menos dos) y diversas
organizaciones mediadoras (podra no haber ninguna). Los mismos grupos armados y
organizaciones mediadoras pueden intervenir en diferentes conflictos. Tanto los grupos
armados como las organizaciones mediadoras podran entrar y salir del conflicto, en ambos
66
y diseo de BD
casos se recoger tanto la fecha de incorporacin como la fecha de salida. Temporalmente,

tanto un grupo armado como una organizacin mediadora podran no intervenir en conflicto
alguno.
De cada grupo armado se recoge el cdigo que se le asigna y un nombre. Cada grupo armado
dispone de al menos una divisin y es liderado por la menos un lder poltico. Las divisiones de
que dispone un grupo armado se numeran consecutivamente y se registra el nmero de
barcos, tanques, aviones y hombres de que disponen, asimismo se recoge el nmero de bajas
que ha tenido. Para los grupos armados se recoge el nmero de bajas como suma de las bajas
producidas en todas sus divisiones.
Los traficantes de armas suministran diferentes tipos de arma a los grupos armados. De cada
tipo de armas se recoge un nombre y un identificador de su capacidad destructiva. DE cada
traficante se recoge un nombre, los diferentes tipos de arma que puede suministrar y cantidad
de armadas de cada uno de los tipos de arma que podra suministrar. Se mantiene le nmero
total de armas de cada uno de los diferentes tipos de armas suministrado por cada traficante a
cada grupo armado.
Los lderes polticos se identifican por su nombre y por su cdigo de grupo armado que lideran.
Adems se recoge una descripcin textual de los apoyos que ste posee.
Cada divisin le puede dirigir conjuntamente un mximo de tres jefes militares, aunque cada
jefe militar no dirige ms de una divisin. A cada jefe militar se le identifica por un cdigo,
adems se recoge el rango que ste posee, y dado que un jefe militar no acta por iniciativa
propia sino que siempre obedece las rdenes de un nico lder poltico de entre aquellos que
lideran al grupo armado al que el jefe pertenece, se registrar el lder poltico al que obedece.
De las organizaciones mediadoras se recoger su cdigo, su nombre, su tipo (gubernamental,
no gubernamental o internacional),la organizacin de que depende (una como mximo), el
nmero de personas que mantiene desplegadas en cada conflicto y el tipo de ayuda que presta
en cada conflicto que ser de uno y slo uno de los tres siguientes, mdica, diplomtica o
presencial).
Con diversos fines, los lderes polticos dialogan con las organizaciones; se desea recoger
explcitamente esta informacin. As para cada lder se recogern aquellas organizaciones con
que dialoga y viceversa.
CASO: Gestin de Nminas

Enunciado
Una empresa decide informatizar su nmina. Del resultado del anlisis realizado se obtienen
las siguientes informaciones:
A cada empleado se le entrega mltiples justificantes de nmina a lo largo de su vida laboral en
la empresa y al menos uno mensualmente.
A cada empleado se le asigna un nmero de matrcula en el momento de su incorporacin a la
empresa, y ste es el nmero usado a efectos internos de identificacin. Adems, ser registran
el ID del empleado, nombre, nmero de hijos, porcentaje de retencin para Hacienda, datos de
cuenta corriente en la que se le ingresa el dinero (banco, sucursal y nmero de cuenta) y
departamentos en los que trabaja. Un empleado puede trabajar en varios departamentos y en
cada uno de ellos trabajar con una funcin distinta.
De un departamento se mantiene el nombre y cada una de sus posibles sedes.
Son datos propios de un justificante de nmina el ingreso total percibido por el empleado y el
descuento total aplicado. La distribucin entre dos justificantes de nmina se har adems de
mediante el nmero de matrcula del empleado, mediante el ejercicio fiscal y nmero de mes al
que pertenece y con un nmero de orden en el caso de varios justificantes de nmina recibidos
de nmina recibidos el mismo mes.
Cada justificante de nmina consta de varias lneas (al menos de una de ingresos) y cada lnea
se identifica por un nmero de lnea del correspondiente justificante. Una lnea puede
corresponder a un ingreso o a un descuento. En ambos casos, se recoge la cantidad que
corresponde a la lnea (en positivo si se trata de un ingreso o en negativo si se trata de un
67
Modelamiento de
datos y diseo de BD
descuento); en el caso de los descuentos, se recoge la base sobre la cual se aplica y el

porcentaje que se aplica para el clculo de stos.
Toda lnea de ingreso de un justificante de nmina responde a un nico concepto retribuido. En
un mismo justificante, puede haber varias lneas que respondan al mismo concepto retribuido.
De los conceptos retribuidos se mantienen un cdigo y una descripcin.
De cara a la contabilidad de la empresa, cada lnea de un justificante de nmina se imputa al
menos a un elemento de coste. Al mismo elemento de coste pueden imputrsele varias lneas.
Para cada elemento de coste, se recoge un cdigo, una descripcin y un saldo.
Entre los elementos de coste se establece una jerarqua, en el sentido de que un elemento de
coste puede contener a otros elementos de coste, pero un elemento de coste slo puede estar
contenido en, a lo sumo, otro elemento de coste.
En determinadas fechas, que se deben recoger, cada elemento de coste se liquida con cargo a
varios apuntes contables (cdigo y cantidad) y a cada una o varias transferencias bancarias,
de las que se recogen los datos de cuenta corriente (banco, sucursal y nmero de cuenta) y la
cantidad. Por cada apunte contable y transferencia bancaria se pueden liquidar varios
elementos de coste.
68
PROPIEDAD INTELECTUAL DEL SENATI

PROHIBIDA SU REPRODUCCIN Y VENTA
SIN LA AUTORIZACIN CORRESPONDIENTE
AO DE EDICIN 2003
CODIGO DEL MATERIAL MP0320
REGISTRO DE DERECHO DE AUTOR 1223-2004

Modelamiento de Base de Datos

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelamiento de Base de Datos

Uploaded by

Copyright:

Available Formats

PROGRAMA NACIONAL DE INFORMATICA

CAPITULO 2 El Modelo Entidad Relacin

El modelo entidad-relacin y las herramientas CASE............................................................. 27

CAPITULO 3 El Modelo Relacional y la Normalizacin

CAPITULO 4 Diseo de Base de Datos empleando Modelo Entidad Relacin

Programa Nacional de Informtica

Sistema de procesamiento de archivos

Los datos estn separados y aislados

Con frecuencia, los datos estn duplicados

Los programas de aplicacin dependen de los formatos de archivos

Con frecuencia, los archivos son incompatibles entre si

Es difcil representar los datos en el modo en que los usuarios lo ven

Sistema de procesamiento de base de datos

Menos duplicacin de datos

Independencia del programa y los datos

Fcil representacin de la vista de datos de los usuarios

Historia de procesamiento de base de datos

Programa Nacional de Informtica

Sistema Manejador de Base de Datos. (DBMS)

Esquema de base de datos:

Administrador de base de datos (DBA):

Ventajas del Modelo Relacional

Fig. 1-1 Datos de estudiantes y cursos

Resistencia al Modelo Relacional

Productos DBMS para microcomputadoras

Los trminos sistemas de administracin de base de datos y base de datos relacional se

Aplicaciones de bases de datos cliente servidor

Procesamiento distribuido de bases de datos

Programa Nacional de Informtica

Los DBMS Orientados a Objetos (ODBMS)

Ciclo de vida de una base de datos

Programa Nacional de Informtica

1. - Anlisis de las necesidades

Obligaciones principales que requieren informacin de la base datos

De qu aplicaciones recibe informacin?

Con cunta frecuencia recibe informacin?

Qu hace con esta informacin?

Qu precauciones de seguridad debe tomar con respecto a la informacin?

Para que aplicacin proporciona datos?

Estn contemplados cambios para alguna de sus actividades actuales que

Programa Nacional de Informtica

Caracteristicas de una Base de Datos

Programa Nacional de Informtica

Programa Nacional de Informtica

Programa Nacional de Informtica

La metodologa de diseo de datos

Programa Nacional de Informtica

Las restricciones se clasifican en:

Estn impuestas por el modelo.

Se activan en el momento de la definicin del esquema cuando se produce un intento

Se rechaza todo esquema que no cumple estas restricciones.

Introducen rigidez al modelo.

Impuestas por el universo del discurso

Tienen que ser definidas por los diseadores

Se activan en el momento de la actualizacin de la base de datos

Se rechaza todo ejemplar que no cumpla estas restricciones (o se ponen en marcha

Ayudan a capturar la semntica de los datos y a conseguir su consistencia.

Se especifican en los programas de aplicacin

No estn almacenadas en el esquema de la base de datos

Pueden ser violadas por actualizaciones en las que no se haya programado la

El sistema de bases de datos no puede comprobar si son consistentes en s mismas.

El optimizador de BD no puede tomarlas en consideracin.

Proporcionan el mximo de flexibilidad.

Pueden ser programadas en un lenguaje de propsito general o en algn lenguaje