0

PROLOGO
El diseo de base de datos es una de las fases ms
importantes de una metodologa de desarrollo de
Software.
Para el diseador es un gran desafo resumir e integrar
todos los requerimientos del sistema en una vista
conceptual que todo el equipo y cliente puedan
entender.
Es por eso que es tan importante elegir las mejores
prcticas para expresar forma objetiva y adaptable la
realidad percibida.

Metodologa Para Disear Bases De Datos

El diseo de base de datos generalmente est compuesto por tres etapas
segmentadas por complejidad.
En primera instancia est el Diseo Conceptual, cuyo fin es representar modelos
mentales del negocio en su extensin ms general. En esta etapa se interpretan las
necesidades del proyecto y se transforman en un modelo de datos que sea
independiente de todo tipo de consideraciones fsicas (Modelo Entidad Relacin,
diccionario de datos, validacin de transacciones).
Luego sigue el Diseo Lgico, donde se transforma el modelo de datos conceptual
en un modelo de datos lgico (modelo de datos relacional), con el fin de acercar a
una definicin relacional que satisfaga las transacciones de la base de datos
(Normalizacin, restricciones de integridad, reglas del negocio, etc.).
La tercera etapa es el Diseo Fsico. Aqu se traduce todo el modelo lgico a una
versin preliminar a la implementacin de la base de datos en SQL,
independientemente del motor de base datos a usar. Normalmente se realizan
tareas como definir la estructura de archivos, la nomenclatura a usar, la
declaracin de las consultas ms importantes en papel, el manejo de ndices, etc.

Modelo Entidad-Relacin
El Modelo Entidad-Relacin (frecuentemente abreviado Modelo ER) es un
enfoque de abstraccin usado para la comprensin de la vista conceptual de un

proyecto. No importa si usas un ciclo de vida en cascada o una planeacin gil.

En ambos casos funciona.
Con el podemos identificar desde un alto nivel, aquellas entidades que participan
en el proceso que se desea comprender, analizando las caractersticas y relaciones
de cada una.
Para ello se usan diagramas y documentos que organicen las ideas para su
interpretacin global.
Precisamente en la primera parte veremos cmo usar el Diagrama EntidadRelacin para representar el modelo de datos con el fin de facilitar visualmente
el dominio del negocio o necesidades del usuario.
Aunque existen una gran variedad de notaciones para crear diagramas que
representen el modelo de datos, en este ebook usaremos la notacin UML (Unified
Modeling Language) o Lenguaje de Modelado Unificado, el cual nos permite acercar
la estructura de la base de datos a un enfoque orientado a objetos.
Esta notacin permitir generar un modelo conceptual y uno lgico sin tener que
crear diagramas diferentes.
No obstante tambin existen notaciones como la Crows Foot, la cual es muy
usada para proyectar el estado final del diseo lgico de una base de datos. Su
propsito es representar la base de datos transformada y lista para implementarla
al cdigo.

Puedes ver su notacin en el archivo Notacin Crows Foot.png

Otra notacin conocida es la Chen, cuyo propsito es el diseo conceptual, es

decir, puede ser implementado en la primera fase para levantar los datos
generales, pero se aleja un poco de la implementacin.

Puedes ver su notacin en el archivo Notacin CHEN.png

Plantillas Y Checklists
Para la aplicacin del contenido de este ebook he creado contenidos extras como
lo son plantillas, checklist y formatos donde puedes practicar el uso de las
instrucciones.
Revisa la carpeta Herramientas para acceder a estos recursos. A lo largo del
temario vers anotaciones que te indicarn el archivo a estudiar.

Errores
Para Hermosa Programacin es importante mejorar hasta el mximo los
contenidos que produce para sus seguidores. Por esa razn apreciara que me
contases sobre cualquier error, sugerencia de redaccin o anomala que
encuentres al leer.
Este ebook tuvo varios filtros de correccin, pero como sabes, somos humanos y
cualquier cosa se nos puede pasar por alto.
Enva tus comentarios correo jamesreveu@gmail.com. Gracias!

CONTENIDO
PARTE 1 EL MODELO ENTIDAD-RELACIN
CASO DE ESTUDIO ............................................................................................................... 13
Requerimientos del Software ......................................................................................... 15
Facultades ........................................................................................................................ 15
Instructores ..................................................................................................................... 15
Estudiantes....................................................................................................................... 15
Cursos ................................................................................................................................ 16
Consultas Identificadas .................................................................................................... 16
Visin general ..................................................................................................................... 16
1.

ENTIDADES..................................................................................................................... 19

2.

RELACIONES .................................................................................................................. 21
2.1 Grado de una Relacin ............................................................................................... 22
2.2 Cmo identificar si es pertinente usar una relacin compleja? ................... 23
2.3 Relaciones Recursivas ................................................................................................ 23
2.4 Ms de una Relacin entre dos Entidades ............................................................ 24

3.

ATRIBUTOS ..................................................................................................................... 26
3.1 Dominio de un Atributo ............................................................................................. 26
3.2 Atributos Atmicos y Compuestos .......................................................................... 26
3.3 Atributos Monovalorados y Multivariados........................................................... 27
3.4 Atributos Derivados .................................................................................................... 27
3.5 Llaves .............................................................................................................................. 28
3.5.1 Llave Candidata .................................................................................................... 28
3.5.2 Llave Primaria o Clave Primaria ...................................................................... 28
3.5.3 Llave compuesta ................................................................................................... 28
3.6 Representacin de atributos en UML ..................................................................... 29
3.7 Atributos en Relaciones ............................................................................................. 31

3.7.1 Notacin UML ........................................................................................................ 31

4.

ENTIDADES FUERTES Y DBILES ........................................................................... 33

5.

RESTRICCIONES ESTRUCTURALES ........................................................................ 35

5.1 Multiplicidad................................................................................................................. 35
5.2 Relaciones uno a uno (1:1) ........................................................................................ 35
5.2.1 Cmo determinar que la multiplicidad es 1:1?........................................... 36
5.2.2 Notacin UML de la multiplicidad 1:1 ............................................................ 37
5.3 Relacin uno a muchos (1:*) ..................................................................................... 37
5.3.1 Notacin UML de la Multiplicidad 1:* ............................................................. 38
5.4 Relacin muchos a muchos (*:*) .............................................................................. 39
5.5 Multiplicidad en Relaciones Complejas ................................................................. 40
5.5.1 Determinar la multiplicidad de una relacin n-aria................................... 41
5.6 Restricciones de Participacin y Cardinalidad .................................................... 45
5.6.1 Cmo identificar la participacin y cardinalidad? .................................... 46

6.

PROBLEMAS COMUNES DE MODELAMIENTO................................................... 48

6.1 La Trampa del Ventilador ......................................................................................... 48
SOLUCION ........................................................................................................................ 49
6.2 La trampa del Abismo ................................................................................................ 50
SOLUCIN ........................................................................................................................ 51
6.3 Mala eleccin de nombres ........................................................................................ 52
SOLUCIN ........................................................................................................................ 52
6.4 Pensar en tablas ........................................................................................................... 53
SOLUCIN ........................................................................................................................ 53

PARTE 2 MODELO ENTIDAD-RELACIN EXTENDIDO

7.

Generalizacin y Especializacin .......................................................................... 58

7.1 Relaciones Superclase/Subclase............................................................................... 58
7.2 Herencia de atributos ................................................................................................. 60

7.3 Proceso de Especializacin ....................................................................................... 60

7.4 Proceso de Generalizacin ........................................................................................ 60
7.5 Notacin UML de Especializacin y Generelizacin .......................................... 60
7.6 El problema del diamante ......................................................................................... 61
7.6 Restricciones de la Generalizacin y Especializacin........................................ 64
7.6.1 Restriccin de Participacin .............................................................................. 64
7.6.2 Restriccin de Disyuncin .................................................................................. 65
Notacin UML ................................................................................................................. 65
8.

AGREGACIN................................................................................................................. 67

9.

COMPOSICIN ............................................................................................................... 67

10. HERRAMIENTAS PARA CREAR DIAGRAMAS ER ................................................ 69

10.1 Lucidchart ................................................................................................................... 69
10.2 creately......................................................................................................................... 71
10.3 draw.io ......................................................................................................................... 73
10.4 Microsoft Visio Profesional ..................................................................................... 75
10.5 Otras Herramientas .................................................................................................. 76
10.6 Evaluando La Mejor Solucin ................................................................................ 77
PARTE 3 METODOLOGA
Paso 1 Identificar entidades ............................................................................................ 82
Tcnicas de bsqueda de entidades .............................................................................. 82
Aadir Entidades al Diccionario de Datos ................................................................... 83
Paso 2 Identificar Relaciones .......................................................................................... 85
Tarea 1. Hallar la Multiplicidad de las Relaciones .................................................... 86
Tarea 2. Verificar posibles fallas .................................................................................... 87
Tarea 3. Aadir al Diccionario de Datos ...................................................................... 87
Paso 3 Identificar Atributos de Cada Entidad y Relacin ..................................... 88
Cmo Obtener los Atributos de una Relacin?......................................................... 88

Tarea 3.1. Diferenciar entre Atributos Simples y Compuestos .............................. 88

Tarea 3.2. Diferenciar entre Atributos Monovalorados y Multivalorados ......... 89
Tarea 3.3. Identificar atributos derivados ................................................................... 89
Tarea 3.4. Determinar el dominio de los atributos ................................................... 89
Reglas de Negocio........................................................................................................... 90
Tarea 3.5. Aadir al Diccionario de Datos ................................................................... 91
Paso 4 Definir llaves candidatas, la llave primaria y las llaves alternativas 93
Integridad............................................................................................................................. 93
Manejo .................................................................................................................................. 93
Simplicidad .......................................................................................................................... 94
Velocidad .............................................................................................................................. 94
Inmutabilidad ..................................................................................................................... 94
Tamao ................................................................................................................................. 94
Familiaridad ........................................................................................................................ 95
Llave suplente ..................................................................................................................... 95
Aadir Llave Primaria al Diccionario de Datos ......................................................... 96
Paso 5 Decidir si es conveniente usar el modelo EER............................................. 97
Casos donde No se debe Usar Herencia de Atributos ............................................... 97
Paso 6 Comprobar el cumplimiento de las transacciones del usuario ............ 99
Paso 7 Aadir Anotaciones Temporales al Esquema ............................................ 101
Instante, Intervalo y Periodo ........................................................................................ 101
Granularidad ..................................................................................................................... 102
Tarea 7.1. Identificar la Esperanza de Vida de Cada Entidad .............................. 102
Anotaciones Temporales ................................................................................................ 103
Tarea 7.2. Identificar el Tiempo Vlido para las Relaciones ................................ 104
Tarea 7.3. Identificar el Tiempo Vlido de los Atributos ....................................... 107
Anotaciones Temporales para Atributos ............................................................... 107
Tarea 7.4. Identificar la Temporalidad de las Transacciones .............................. 107

Anotaciones Temporales de Transacciones .............................................................. 108

Anotaciones Temporales en el Diseo Lgico .......................................................... 108
Paso 8 Revisar el modelo de datos con el Usuario ................................................. 110
CONCLUSIONES .................................................................................................................. 111

PARTE 1
EL MODELO
ENTIDAD-RELACION

11

INTRODUCCIN
Como se vena hablando, el modelo entidad relacin surge como el estudio formal
de las caractersticas de la informacin que debe ser almacenada en una base de
datos.
Este nos permite modelar de forma general con el fin de interpretar
correctamente la situacin que deseamos solucionar.
Para demostrar la construccin de un modelo de datos, se ha creado un caso de
estudio que nos permitir comprender el temario basndonos en una situacin
apegada a la realidad. El cual seguiremos a lo largo de todo el ebook con el fin de
ejemplificar todos los conceptos.
Luego de ello veremos en detalle cada uno de los componentes de un modelo
entidad-relacin y como son representados en el diagrama correspondiente con
la notacin UML.
Partiremos definiendo el propsito de las entidades, las cuales representan a cada
uno de los objetos que nos interesa estudiar en un negocio o situacin. En seguida
analizaremos como se relacionan con otras entidades y que atributos poseen.
Por ltimo se estudiar cmo afrontar la clasificacin de las entidades en
superclases y subclases, un concepto muy usado en la Programacin Orientada a
Objetos (POO). Veremos cmo este enfoque puede refinar nuestros modelos para
mejorar su organizacin.

12

CASO DE ESTUDIO
El Instituto Educativo San Judas es un centro de
educacin tcnica fundado en el ao 2000.
Inici con tan solo 40 estudiantes en sus
instalaciones y las facultades de Tecnologas de la
informacin y Mercadeo.
Desde entonces ha tenido un crecimiento enorme,
abriendo otras 8 facultades ms y contando con
aproximadamente 350 estudiantes activos.
Debido a este crecimiento, el personal administrativo y el cuerpo docente se ha
incrementado proporcionalmente. Con ello los procesos de gestin de la
informacin se han tornado en un flujo de papelera tediosa e innecesaria. Existen
formatos fsicos para diversas actividades, lo que hace retardar las actividades de
registro y apertura de cursos.
Su Director Administrativo Carlos Cifuentes, est preocupado por las
complicaciones que se estn generando con todos los trmites que se deben llevar
a cabo.
El cree que la solucin est en la implementacin de un sistema de informacin
basado en bases de datos, ya que ha escuchado los increbles resultados que han
obtenidos los institutos cercanos con este modelo de operacin.
Al contratar nuestro servicio, Carlos nos describe la forma en que funciona el
instituto San Judas y como fluye la informacin:
En primera instancia llega el estudiante con toda su
documentacin al rea de Registro y Control, donde se reciben sus
documentos y se le autoriza el pago del semestre actual,
entregndole un recibo de pago.
Luego de pagar se matricula financieramente y acadmicamente.
La matrcula acadmica se gestiona en la faculta a la que pertenece
el nuevo alumno, aqu se le entrega informacin detallada sobre los
horarios diurnos y nocturnos de los cursos que puede ver , adems

13

de la cantidad de crditos que dispone para la configuracin de su

horario.
Luego se revisa el plan acadmico del estudiante para asegurarse
de que ha cumplido los prerrequisitos de cada curso incluido en su
matrcula acadmica.
Los horarios son creados de acuerdo a la disponibilidad de los
instructores que pertenecen a la facultad. Cada instructor tiene un
horario de trabajo registrado en los informes de actividades que
nos deben entregar.
En cuanto las evaluaciones, actualmente contamos con tres cortes
de evaluacin, cuya ponderacin se divide en 30, 30 y 40 por ciento
respectivamente.
Cada profesor carga una lista de estudiantes con sus notas
asociadas, la cual se entrega diligenciada al final de cada corte en
la facultad correspondiente.
Luego nos comenta sus objetivos con la implementacin del Software:
Necesito que el proceso completo de Registro de Estudiantes,
Matrcula Acadmica, Gestin de cursos y la configuracin de
horario de nuestros profesores sea implementada digitalmente.
Creo que esto agilizar los procesos institucionales y pondr en
segunda plano los aspectos que nos complican las operaciones
Luego de ello Carlos nos entrega diagramas de procesos, formatos de inscripcin,
planillas de cursos, reportes de estudiantes y toda la documentacin necesaria para
identificar lo que vamos a sistematizar.
Adicionalmente se realizan una serie de reuniones con el equipo desarrollador y
las personas interesadas, para determinar qu caractersticas debe tener el
software.
Al finalizar esta exploracin se obtienen los siguientes tems:

14

Requerimientos del Software

Facultades
El Instituto San Judas divide a su personal por saberes en facultades, por ejemplo
la facultad de Ingeniera. Se requiere administrar los datos de cada facultad como
lo son su identificador de facultad, su nombre, la oficina donde est ubicada en las
instalaciones, el nombre de la secretaria que brinda el servicio de registro y el
nmero para comunicarse va telefnica.
Instructores
Es necesario almacenar la informacin de todos los instructores para optimizar la
consulta de sus datos, averiguar su disponibilidad y la cantidad de cursos que
tienen asignados.
Los datos ms importantes de un instructor son: el identificador brindado por la
instituto, sus nombres, apellidos, direccin, un telfono principal para ubicarlo y
mximo 2 nmeros alternativos. Tambin se desea almacenar la oficina en que se
ubic y su salario.
Cabe destacar que de todos los instructores de una facultad, se elige uno para
coordinar las actividades de esta. Adicionalmente debe supervisar el trabajo de
sus compaeros.
Se debe considerar que a cada instructor se le pueden asignar varios cursos
dependiendo de su horario semanal.
El salario del instructor puede variar dependiendo de su desempeo, por lo que
se necesita realizar un seguimiento a su variacin.
Estudiantes
Para los estudiantes es necesario identificar a que cursos estn inscritos para
crear un historial acadmico de sus rendimientos.
Los datos de los estudiantes a almacenar son muy parecidos a los de los
instructores. Estos son: el identificador que se le asigna una vez haga parte de la
institucin, los datos de sus nombres, apellidos, un nmero telefnico principal
(como mximo 3 nmeros telefnicos) y la direccin de residencia.

15

Por cada curso en que se encuentre el estudiante, deben guardarse todas las
calificaciones que el profesor le asigne por su desempeo evaluado.
Cursos
Por cada curso se requiere almacenar el cdigo institucional asignado, el nombre
del curso, la descripcin del curso y los crditos que tiene. Adicionalmente se
necesita saber la fecha en la que dio inicio al curso, el semestre en que se present,
el horario que tuvo cuando se dict junto al saln donde se llev a cabo.
Debe notificarse tambin que cursos son prerrequisito de otros para evitar que
los estudiantes sigan un flujo incorrecto de su carrera. Tambin se debe saber si
un curso es presencial o es online, o si est creado para las dos modalidades.

Consultas Identificadas
1.
2.
3.
4.
5.

Obtener una lista todos los cursos vistos por un estudiante.

Generar el horario de clases para cada estudiante.
Generar el horario de los instructores.
Generar listado de todos los estudiantes en un curso y su cantidad total.
Generar una lista del historial de notas (historial acadmico) de un
estudiante.
6. Calcular la cantidad de crditos matriculados por un estudiante.
7. Calcular la cantidad de estudiantes por facultad.
8. Generar una lista de los instructores a cargo de un supervisor.
9. Listar los cursos menos aprobados por los estudiantes.
10. Calcular cuntos cursos online existen.
11. Listar los estudiantes que tienen que recuperar materias.

Visin general
El objetivo de este caso de estudio no es abordar temas de ingeniera de
requerimientos ni el anlisis de personas. Solo hemos usado un contexto simple
acomodado a la vida real para tener una gua ilustrativa y seguir una secuencia
clara para los temas que se desarrollarn a lo largo de todo el temario.
Como ves no se han usado formatos especiales de especificacin de
requerimientos o para la creacin de historias de usuario. Tampoco se ha definido

16

la arquitectura del sistema, ni la experiencia de usuario, o el sistema de roles, ni

se determinaron las vistas de usuario.
El fin de este ebook es especializarse simplemente en el diseo conceptual de
una base de datos y no dejar temas inconclusos.
El Modelo ER del Instituto San Judas diagramado
A continuacin puedes ver el modelo de datos representado con UML que resulta
del caso de estudio:

Si deseas verlo aisladamente busca el archivo Diagrama ER San Judas.png

Puedes consultarlo frecuentemente para contextualizar los temas que trataremos

en la primera parte.

17

0..1

Facultad

Coordina

1..1
1..1

CP

idFacultad

Pertenece

Contiene

1..1

Pertenece
EsPrerrequisito
1..*

1..*

Curso
CP

1..*

1..*

Estudiante
idCurso

CP

1..1
1..1

Instructor

idEstudiante

CP

0..*

Supervisa

idInstructor

1..1
0..1

1..1

1..*

1..1

Tiene
1..*

HoraTrabajoInstructor

Asiste
Dicta

nota [1..n]
/notaFinal
haAprovado

1..*

OfertaCurso

Genera

CP

idOfertaCurso

1..*

0..*
1..1
Tiene

1..*

DiaOfertaCurso

Figura 1 Diagrama E-R final del Instituto San Judas

18

1. ENTIDADES
La base de los modelos de datos es la entidad (Este concepto es anlogo a las
clases en POO). Una entidad es la representacin general de un conjunto de
objetos, ya sea fsicos o abstractos, que se caracterizan por tener los mismos
atributos y pertenecer a una misma familia.
Por lo general el cliente manifiesta qu entidades desea almacenar con facilidad
para tener un registro de estas. Sin embargo cuando entiendas los procesos de la
empresa encontrars entidades ocultas necesarias para la derivacin de
informacin.
A cada elemento nico perteneciente a la entidad se le llama instancia, es decir,
que el estudiante Francisco Maldonado es una instancia de la entidad Estudiante,
ya que se habla del objeto en particular como un sustantivo propio como se ve
en la Figura 1.

Figura 2 Ejemplo de instancias que componen la entidad Estudiante

En el caso del colegio San Judas se pueden identificar varios ejemplos, como
Estudiante, Instructor, Curso, Horario, etc. Pero tambin pueden ser entidades que
no tengan forma fsica, como Tarea, Evaluacin, Estadstica, Venta, etc.
19

Para representar una entidad en notacin UML se usa un rectngulo con el

nombre de la entidad en singular. La convencin para la escritura del nombre es
usar la primera letra en mayscula, y una letra capital por cada palabra que siga.
Veamos el ejemplo de la entidad Estudiante:

Estudiante

Figura 3 Notacin UML para la entidad Estudiante

20

2. RELACIONES
Una relacin es un conjunto de asociaciones entre dos o ms entidades. Por lo que
se entiende que las instancias de una entidad se relacionan con las instancias de
la otra. Este vnculo se puede basar en cualquier tipo de afeccin, clculo,
dependencia, etc. Es decir, todo lo que se refiera a un verbo.
Por ejemplo, a una facultad pertenecen uno o varios instructores. En este caso el
verbo pertenecer es identifica una relacin entre las entidades Facultad e
Instructor.
Al igual que con las entidades, una relacin tiene instancias para darle trato
particular a los elementos. Veamos una representacin en redes semnticas entre
las instancias de las facultades y los instructores:

Figura 4 Ejemplo de Redes Semnticas

Los elementos denominados con la letra i representan instancias de la entidad

Instructor, los elementos del tipo r representan una instancia de relacin y los
elementos f representan a las facultades.
Matemticamente podramos decir que una instancia de relacin para el caso
anterior se representa con el par r= { i , f }.
Generalmente se sigue la misma nomenclatura para el nombramiento que se us
con las entidades. Solo que usaremos como nombre un verbo en presente simple.
21

Opcionalmente puedes usar una flecha que indique la direccin desde donde se
inicia la relacin.
Veamos como representar la relacin anteriormente descrita:

Instructor

Facultad
Pertenece

Figura 5 Representacin UML de una Relacin

2.1 Grado de una Relacin

El grado de una relacin es el nmero de entidades que participan en la relacin.
Por ejemplo, la relacin anterior es de tipo binaria, ya que solo participan dos
entidades.
Si participasen tres entidades en la relacin, entonces sera una relacin ternaria,
si participan cuatro sera cuaternaria y si participan muchas ms se generaliza
con la notacin n-aria.
Las relaciones que tienen grado mayor a 2 son llamadas tambin relaciones
complejas. Un ejemplo podra ser la relacin: Un instructor dicta una de un curso
a un estudiante.
La notacin UML para representar las relaciones complejas se realiza con un
diamante conector, del cual desprenden lneas desde sus extremos hacia las
entidades que intervienen en la relacin. El nombre de la relacin se ubica en el
interior del diamante.
Veamos:

22

Instructor

OfertaCurso
Dicta

Estudiante

Figura 6 Relacin Compleja entre Instructor, OfertaCurso y Estudiante con UML

2.2 Cmo identificar si es pertinente usar una relacin

compleja?
Esta decisin depende de las vistas de los usuarios, los reportes que necesitan los
clientes y de si la informacin no es posible obtenerla desde una relacin binaria.
Por ejemplo, el diagrama anterior se observa que un instructor puede impartir
una oferta de un curso a un estudiante.
Si la Institucin San Judas expresa explcitamente que desea generar un listado de
los contactos presenciales que ha tenido un profesor con los estudiantes de un
curso, entonces la relacin ternaria tendra cabida en el modelo de datos.
De lo contrario el diseador de la base de datos puede asumir que en realidad no
existe una relacin directa entre un instructor y un estudiante, ya que ambos
interactan por medio de la entidad curso. Esto permite modelar solo relaciones
binarias entre Estudiante y Curso e Instructor y Curso.

2.3 Relaciones Recursivas

Una relacin recursiva (tambin llamada unaria) es aquella donde una entidad
participa consigo misma, es decir, sus instancia se relacionan entre s.
Por ejemplo, en el Instituto San Judas a los instructores se les asigna un
coordinador, el cual debe ser uno de sus mismos compaeros de facultad. Lo
quiere decir que existe un instructor especial ante las dems instancias.

23

Pero Cmo modelar dicha situacin?

Sencillo, se deben establecer dos roles que diferencien a las instancias de la
entidad. Uno para los coordinadores y otro para los que son coordinados.
Grficamente las relaciones recursivas se representan con una lnea de
asociacin, cuyos extremos estn conectados a la misma entidad. Adicionalmente
se debe ubicar el rol de la entidad dependiendo de la direccin de la relacin.

Coordina
Coordinador
Instructor

Coordinado
Figura 7 Ejemplo de una Relacin Recursiva en Instructor

Como ves en la ilustracin la relacin indica que Un instructor (Coordinador)

coordina/supervisa a otros instructores (Coordinados).

2.4 Ms de una Relacin entre dos Entidades

Los roles tambin pueden usarse cuando existen varias relaciones entre dos
entidades. Por ejemplo, el coordinador de los instructores no solo tiene la
responsabilidad de guiarlos si no tambin de asumir toda el rea administrativa
de la facultad.
Esto significa existe otra relacin de Instructor y Facultad que tiene como propsito
indicar el coordinador de la facultad.
Pero modelar esto es sencillo, simplemente usamos otra relacin pero
estableciendo roles de coordinador e instructor:

24

Coordina
Facultad
CP

Coordinador
Instructor

idFacultad

CP

idInstructor

Pertenece
Figura 8 Dos relaciones entre las Entidades Facultad y Coordinador

Ubicamos solo el rol de Coordinador, ya que los dems roles se mantienen igual.

25

3. ATRIBUTOS
Los atributos son propiedades de las entidades. Un
ejemplo claro seran el nombres, apellidos, fecha de
nacimiento y telfono de un estudiante. Cada uno de
estos datos es considerado un atributo, los cuales son
el insumo necesario para realizar anlisis y gestionar
ocurrencias en los sistemas de informacin.

3.1 Dominio de un Atributo

Crees que es permitido agregar nmeros al nombre de un estudiante? Obviamente
no es bien visto un modelo que permita este tipo de situaciones irregulares, sin
embargo los diseadores y programadores pueden dar sorpresas.
Para prevenir estas anomalas, es necesario hacer nfasis en el dominio de los
atributos que tendrn las entidades de tu base de datos.
El dominio comprende el conjunto de aquellos valores que son permitidos en un
atributo. Si recuerdas cuando veas conjuntos o funciones matemticas, ya sabrs
a que me refiero.
Por ejemplo, el atributo sexo de la entidad Estudiante, tiene un dominio al cual
solo pertenecen los valores F (Femenino) y M (Masculino), as que debe
restringirse al atributo para que acate esa indicacin.
Incluso podemos expresar el dominio a travs de la teora de conjuntos. La
siguiente notacin por extensin establece que el atributo salario de un instructor
debe ser mayor a 2000USD:
= { | 2000 }
El anterior dominio se describe como todos los valores de salario que pertenezcan
a los nmeros naturales y sean mayor o igual a 2000.

3.2 Atributos Atmicos y Compuestos

Un atributo atmico o simple es aquel que no puede ser divisible en ms
atributos y su existencia es independiente de toda restriccin. Como por ejemplo
el email y telfono de la entidad Estudiante.

26

Un atributo compuesto, por el contario, es la composicin de dos o ms atributos

atmicos. Un buen ejemplo sera la composicin del nombre de una persona por
su primer nombre, segundo nombre, apellido paterno y apellido materno.
La seleccin de la complejidad del atributo depende de los requerimientos del
usuario.

3.3 Atributos Monovalorados y Multivariados

Los atributos monovalorados o de un solo valor son aquellos que solo tienen
asignados un solo valor por cada instancia de la entidad. Por ejemplo, existe un
solo valor para el atributo creditos de Curso, ya que no aplican variaciones.
Ahora, un atributo multivariado es aquel que puede recibir varios valores por
cada instancia. Puedes detectarlos fcilmente al percibir que un atributo contiene
una lista de varios valores.
Normalmente se encuentran en un rango considerado entre un valor mnimo y
mximo. Un atributo multivariado muy popular es el nmero telefnico, por
ejemplo, el instructor IA04 se le puede contactar al nmero 3451234 y al
4562213.
Aunque este instructor tiene dos nmeros, recuerda que en la definicin del caso
de estudio se determin que debe existir como mnimo un telfono principal y
mximo 3.

3.4 Atributos Derivados

Un atributo derivado es aquel que su valor se genera con respecto al valor de
otros atributos. Esto significa que se el valor se puede originar de un clculo
matemtico o una asignacin condicionada de valores de otros atributos de la
entidad u otras entidades.
Por ejemplo, la notaFinal de un estudiante es calculada a partir de las notas de los
distintos cortes evaluados.
Tambin se puede considerar un atributo derivado la cantidad de instancias que
tiene la entidad Facultad. O por ejemplo la cantidad total en ventas de un
vendedor.

27

3.5 Llaves
3.5.1 Llave Candidata
Una llave candidata es un atributo que puede llegar a comportarse como un
identificador nico de cada instancia de una entidad.
Por ejemplo, el atributo idEstudiante asignado por el instituto es una buena opcin
para diferenciar a las instancias de Estudiante, por lo que es una llave candidata.
Adems cada estudiante como ciudadano de un pas tiene asignada una
identificacin personal, por lo que este posible atributo tambin es una llave
candidata.
3.5.2 Llave Primaria o Clave Primaria
Como ves, en una entidad pueden existir varias llaves candidatas, sin embargo
debe elegirse una como la llave primaria o principal.
El objetivo es asegurar que cada instancia de una entidad se diferencie de las
dems. Esta caracterstica permite que las relaciones entre entidades se
representen con claridad, evitando la informalidad.
Puede que por el momento existan entidades que no tengan definida su llave
primaria completamente debido a que son entidades dbiles (veremos este
trmino en el siguiente apartado), as que no te preocupes por esa circunstancia.
3.5.3 Llave compuesta
No siempre una llave primaria est compuesta de un solo atributo. En ocasiones
una sola llave primaria no es suficiente para asegurar la unicidad entre las
instancias de una entidad.
En esos casos se implementa una llave compuesta, la cual se configura a partir
de dos o ms atributos llamados tambin llaves primarias parciales.
Cabe destacar que una llave compuesta puede generarse partir de llaves
candidatas, atributos que no sean llaves candidatas o una combinacin de ambos.
Un excelente ejemplo de llave compuesta se da en la entidad HoraTrabajoInstructor,
la cual representa los horarios de trabajo de cada instructor.

28

Tiene los atributos diaSemana, horaInicio y horaFin. Pero individualmente ninguno

es una llave candidata. Incluso, los tres juntos tampoco representaran una llave
candidata.
Cuando veas el Modelo Relacional (Diseo lgico), vers que esta entidad recibe
una copia de la llave primaria de Instructor como llave fornea y que su llave
primaria es una llave compuesta entre idInstructor, diaSemana, horaInicio y
horaFin.
Esta se representara como el siguiente conjunto:
CP = {idInstructor, diaSemana, horaInicio, horaFin}

3.6 Representacin de atributos en UML

Para diagramar los atributos relacionados a las entidades, dividiremos el
rectngulo en dos partes. En la parte superior incluimos el nombre de la entidad
y en la parte inferior la lista de atributos.
Dependiendo del tipo de atributo que sea usaremos las siguientes notaciones:

Tipo de Atributo

Notacin

Llave Primaria

{PK} {CP}

Llave Primaria Parcial

Atributo Compuesto

{PPK} {CPP}
Una tabulacin a la derecha

Atributo Multivalorado

Incluir rango entre llaves [minmax]

Atributo Derivado

Anteceder una barra inclinada '/'

Tabla 1 Notacin UML para atributos

Veamos cmo hacerlo para la relacin entre Instructor y Facultad:

29

Facultad

Instructor
CP

CP

idInstructor

idFacultad

Pertenece
nombre

nombre
nombres

oficina

apellidos

telefono

secretaria

direccion
oficina
telefono [1..3]
salario
Figura 9 Representacin de Atributos de una Entidad

Como ves, idInstructor e idFacultad usan la abreviacin CP (clave primaria) para

identificarse como llaves primarias de ambas entidades. La abreviacin PK
significa Primary Key, cuya traduccin es llave primaria.
Tambin se observa que el atributo nombre de Instructor es compuesto, por esto
se aade una tabulacin a los componentes nombres y apellidos.
En el caso de telefono que es multivariado, se incluy su rango de elementos,
expresando que mnimo debe existir un telfono y mximo tres.
Las anteriores entidades tienen pocos atributos por lo que es muy cmodo
ubicarlos visualmente. Pero si tus entidades tienen muchos atributos, no es
recomendable tomarse un tiempo de transcripcin en el diagrama para ponerlos
todos.
Puedes solo ubicar las llaves primarias para realizar anlisis rpidos como
haremos frecuentemente a lo largo del ebook. Todo depende de ti y los
requerimientos de modelaje que tu caso necesite.

30

3.7 Atributos en Relaciones

Conceptualmente los atributos tambin pueden usarse para describir las
instancias de una relacin. Esta preferencia nos permite aislar las caractersticas
relacionadas a las diferentes relaciones existentes.
Estudiemos el ejemplo entre las entidades Estudiante y OfertaDeCurso. Es
necesario aclarar que Curso es la declaracin estructural de un curso genrico y
OfertaDeCurso es el curso fsico como tal.
Entrando en materia, sabemos que un Estudiante se encuentra en una oferta de
curso, pero necesitamos saber que nota final obtendr y si aprob el curso o no.
Si Estudiante no existiera no habra a quin asignarle notas del curso, y si Curso
no existiera no habra nada que calificar. Por deduccin las notas individuales
(notas) y la notaFinal es el resultado de la interaccin entre ambas entidades por
lo que debe pertenecer a relacin Asiste.
3.7.1 Notacin UML
Para representar estos atributos de la relacin aadiremos una lnea punteada,
cuyo origen es el centro de la relacin y su orientacin es perpendicular a esta.
El contenido estar dentro de un rectngulo subdivido al igual que las entidades,
pero en este caso la subdivisin superior no tendr nombre.
Veamos:

31

nota [1..n]

/notaFinal
haAprovado

Estudiante

OfertaCurso
1..*

CP

idEstudiante

Asiste

1..*
CP

idOfertaCurso

Figura 10 Ejemplo de Atributos en una Relacin

32