Universidad Nacional Autónoma de México

Facultad de Ingeniería
BASES DE DATOS
PRÁCTICA 05 - PREVIO
_________________________________________________________________________

1. DISEÑO BÁSICO DE MODELOS RELACIONALES

1. DISEÑO BÁSICO DE MODELOS RELACIONALES...........................................................................1

1.1. Antecedentes teóricos................................................................................................................................................3
1.1.1. Notaciones para diseño lógico de una base de datos................................................................3
1.1.2. Representación de entidades, atributos y llaves primarias................................................. 4
1.1.3. Tipos de llaves en el modelo relacional...............................................................................................4
1.1.4. Representación de atributos compuestos....................................................................................... 5
1.1.5. Representación de atributos multivalorados..................................................................................5
1.1.6. Representación de relaciones................................................................................................................... 6
1.1.6.1. Acerca de las cardinalidades............................................................................................................6
1.1.6.2. Relaciones identificativas y no identificativas.....................................................................7
Ejemplo................................................................................................................................................................ 7
Relaciones 1:1.................................................................................................................................................... 8
Relaciones unarias......................................................................................................................................10
Relaciones ternarias....................................................................................................................................11
1.1.6.3. Dependencia e independencia de existencia................................................................... 12
Ejemplo.............................................................................................................................................................. 12
Ejemplo.............................................................................................................................................................. 12
1.1.6.4. Participación de una entidad en una relación................................................................. 12
Ejemplo.............................................................................................................................................................. 12
Ejemplo.............................................................................................................................................................. 13
1.1.6.5. Dependencia de identificación................................................................................................... 13
1.1.7. Tipos de datos SQL.......................................................................................................................................... 14
1.2. Generación de modelos relacionales con ER/Studio..........................................................................15
1.2.1. Personalizar el editor......................................................................................................................................16
1.2.2. Creación de un nuevo modelo...............................................................................................................19
1.2.3. Agregando objetos al modelo lógico.................................................................................................19
1.2.4. Elementos del modelo lógico............................................................................................................... 20
1.2.4.1. Creación de entidades..................................................................................................................... 20
1.2.4.2. Atributos de una entidad............................................................................................................... 21
1.2.4.3. Documentación de entidades y atributos.........................................................................22
1.2.4.4. Asociación de entidades empleando relaciones..........................................................22
1.2.4.5. Opciones para relaciones.............................................................................................................. 23

Jorge A. Rodríguez C. [email protected] 1

Material de apoyo FI UNAM

1.2.4.6. Cambio del nombre a la FK.........................................................................................................24

Ejemplo:............................................................................................................................................................ 24
1.2.5. Generación de reportes..............................................................................................................................26
1.2.5.1. Exportando diagramas.....................................................................................................................28
1.2.6. Generando modelos físicos..................................................................................................................... 29
1.3. Ejercicios previos......................................................................................................................................................... 31
1.3.1. Ejercicio 1.................................................................................................................................................................31
1.3.2. Ejercicio 2..............................................................................................................................................................32

Jorge A. Rodríguez C. [email protected] 2

Material de apoyo FI UNAM

1.1. Antecedentes teóricos

Los siguientes conceptos son empleados en el desarrollo de esta práctica.
● Notaciones para modelo lógico de una base de datos.
○ Crow’s foot
○ IDEF1X
● Transformación de un modelo ER a un Modelo Relacional.

Entidades y atributos:
● Representación de atributos obligatorios y opcionales
● Representación de atributos simples y compuestos
● Representación de atributos multivalorados
● Representación de llaves primarias (natural, candidata, artificial o subrogada,
compuesta)

Relaciones entre entidades:

● Relaciones suaves/débiles/no identificativas
● Relaciones duras/fuertes/identificativas
● Cardinalidad
● Dependencia de existencia
● Participación de una entidad en una relación
● Dependencia de identificación
● Entidades débiles

Grado de una relación

● Relaciones unarias
● Relaciones binarias
● Relaciones ternarias.

Para mayores detalles, consultar el documento BD/apuntes/tema04.pdf

Al final del documento se encuentran los ejercicios que deben resolverse previos a
realización de esta práctica

1.1.1. Notaciones para diseño lógico de una base de datos

Como se mencionó en la práctica anterior, el diseño lógico de una base de datos relacional
consiste en el desarrollo de un modelo relacional que se obtiene a partir del modelo ER
así como del enunciado y las reglas de negocio del caso de estudio.

Existen varias notaciones para realizar la construcción de un modelo relacional. Las 2

notaciones comúnmente empleadas en la industria del desarrollo de software son:

● Notación Crow’s foot

● Notación IDEF1X

Jorge A. Rodríguez C. [email protected] 3

Material de apoyo FI UNAM

Ambas notaciones son muy similares. En esta sección se muestran las características de
ambas haciendo énfasis en donde exista una diferencia entre ambas.

1.1.2.Representación de entidades, atributos y llaves primarias

Notación crow’s foot e IDEF1X

● Las entidades se representan por tablas. En el

rectángulo superior se indica la llave primaria.
● Tanto el nombre de la tabla como el de los
atributos se especifican en mayúsculas. Las
palabras compuestas se separan por guión bajo.
● A medida de lo posible omitir abreviaturas. Si se usan deben ser muy claras.
● Notar que se debe incluir el tipo de dato del atributo así como el constraint null o
not null.
● Para realizar borradores, diagramas en pizarrón o diagramas en exámenes, el tipo
de dato y el constraint anterior se pueden omitir del diagrama. Todos los atributos
se consideran como obligatorios por default, por lo que para un atributo opcional
se especifica con la palabra null.

1.1.3.Tipos de llaves en el modelo relacional

Clave principal en modelo ER TIpo de llave primaria en modelo relacional
clave principal llave primaria natural
clave artificial llave primaria artificial
clave candidata llave candidata
clave compuesta llave primaria compuesta

● En el modelo relacional se prefiere a medida de lo posible el uso de una PK

artificial principalmente por los beneficios que ofrece:
○ Mejor rendimiento. El índice que genera una llave primaria tiene un mejor
desempeño en valores numéricos de preferencia consecutivos.
○ Sin problemas de duplicidad
○ Sin probabilidad de cambio de valores
○ Al propagarse como FK, se mantiene la simplicidad. Imaginar propagar la
CURP que se emplea como PK en una tabla padre! La CURP aparecería en
múltiples tablas como FK lo que genera una mayor complejidad respecto a
manejar una columna simple de IDs.
● Por lo anterior, en prácticas que generan modelos relacionales hacer uso de una PK
artificial a menos que se indique lo contrario. La notación a emplear es
<nombre_tabla>_id. Por ejemplo, la PK para la tabla ESTUDIANTE será ESTUDIANTE_ID.

Jorge A. Rodríguez C. [email protected] 4

 Material de apoyo FI UNAM

● Para el caso de una PK compuesta, se debe tener cuidado con su selección. Una PK
compuesta implica la generación de combinaciones de valores de cada atributo lo
cual pudiera ser incorrecto para algunos escenarios.

1.1.4.Representación de atributos compuestos

Diseño conceptual Diseño lógico Crow’s Foot e IDEF1X

● En el diseño lógico, el atributo compuesto se omite, únicamente se incluyen los sub

atributos.

1.1.5. Representación de atributos multivalorados

Diseño conceptual Diseño lógico Crow’s Foot e IDEF1X

Atributo multivalor ● El modelo relacional no soporta de forma
directa la representación de un atributo
multivalorado. Por cada registro y columna
debe existir un solo valor.
● Para implementar este concepto se deberá
crear una nueva tabla. A nivel general, la PK
de la nueva tabla será una PK compuesta
formada por la PK de la tabla, en este caso
num_trabajador y por el atributo
multivalorado, en este caso, teléfono.

Jorge A. Rodríguez C. [email protected] 5

Material de apoyo FI UNAM

Diseño conceptual Diseño lógico Crow’s Foot e IDEF1X

● El ejemplo anterior funciona correctamente. Sin embargo, la PK compuesta anterior no
es del todo eficiente al ser compuesta y formada por un identificador más un número
telefónico.
● Para resolver este detalle se puede especificar una PK artificial

1.1.6.Representación de relaciones
Las relaciones en el modelo relacional se representan a través de llaves foráneas. Para
este concepto si existe diferencia entre las notaciones Crow’s foot e IDEF1X.

Notación crow’s foot Notación IDEF1X

Las siguientes secciones explican los conceptos principales de las notaciones anteriores.

1.1.6.1.Acerca de las cardinalidades

● Notar el lado izquierdo de cada caso. Siempre se tienen valores de cardinalidades
(0,1) o (1,1). Esto se debe a que en el modelo relacional, una FK siempre se emplea

Jorge A. Rodríguez C. [email protected] 6

Material de apoyo FI UNAM

para representar relaciones 1:m o 1:1. Las relaciones m:m se deben descomponer en
2 relaciones 1:m
● Para el caso de la cardinalidad (0,1) del lado izquierdo notar que se emplea un
rombo como notación. Este rombo en conjunto con la cardinalidad (0,1) representan
a una FK opcional (null).
● Notar que el cuarto grupo de notaciones no existe, es decir, no existen relaciones
con cardinalidades (0,1) del lado izquierdo con una línea continua. Esto se debe a
que en una relación identificativa, la PK de la tabla padre se propaga a la tabla hija
tanto como FK como PK. Al propagarse como PK, el atributo debe ser not null.
Como se mencionó anteriormente, la cardinalidad (0,1) del lado de la tabla padre
indica una FK nula, lo cual no podría ser viable en este grupo. Por esta razón este
cuarto grupo no es factible. En la siguiente sección se explica a detalle el uso de las
relaciones identificativas.

1.1.6.2. Relaciones identificativas y no identificativas

Como se puede observar en el diagrama anterior, existe una diferencia importante entre el
uso de una línea punteada o continua
● Punteada: Relación no identificativa, suave o débil
● Continua: Relación identificativa, dura, o fuerte
● En una relación identificativa la PK de la tabla padre se propaga como PK y FK en la
tabla hija.
● En una relación no identificativa, la PK de la tabla hija se propaga únicamente como
FK en la tabla hija

¿Cuándo emplear una relación identificativa o una no identificativa?

● Las relaciones no identificativas se emplean principalmente para representar
relaciones 1:m, pero pueden ser empleadas para relaciones 1:1 o m:m, es decir, los 3
tipos de relaciones.
● Las relaciones identificativas se emplean para relaciones 1:1 y en algunos casos para
relaciones m:m, nunca para relaciones 1:m

Ejemplo
Curso y profesor 1:m
● Un profesor imparte varios cursos. 1:m
● Un curso es impartido por un profesor. 1:1

● Para una relación 1:m se emplea una relación no identificativa. Notar que la PK
profesor_id se propaga únicamente como FK hacia la tabla hija curso.

Jorge A. Rodríguez C. [email protected] 7

Material de apoyo FI UNAM

● La FK siempre se debe ubicar en la tabla que tiene la cardinalidad muchos o many

(m). En este ejemplo, corresponde con el valor * . Un profesor imparte varios cursos,
por lo tanto la FK deberá ubicarse en la tabla curso.

¿Qué sucedería si de forma errónea se emplea una relación identificativa?

Al ser identificativa (línea continua), la PK pasará como PK y FK en la tabla curso.

Notar que ahora la PK de la tabla curso es compuesta. La base de datos ahora permitirá
almacenar combinaciones de los 2 atributos. Para una relación 1:m las PKs compuestos
son incorrectas. Se pueden tener combinaciones que generan inconsistencias:

profesor_id curso_id Comentarios

10 100 Esta combinación es correcta. Un mismo profesor imparte los
10 101 cursos 100 y 101
11 141 Sin embargo, esta combinación es incorrecta. La BD permite
12 141 almacenar esta combinación, pero es inconsistente ya que indica
que el curso 141 podría ser impartido por 2 profesores

¿ Qué sucedería si erróneamente se establece la FK al revés ?

● En este diseño un curso puede ser impartido por varios profesores, pero un profesor
solo puede tener asignado un solo curso indicado a través de la FK. Definitivamente
esto no es correcto, no cumple con las reglas de negocio. Por lo tanto, se debe tener
cuidado con la asignación de la FK.

Relaciones 1:1
Las relaciones 1:1 se consideran las más complicadas para modelar ya que existen
diferentes técnicas. La solución final depende en buena medida de las reglas de negocio.
Los siguientes ejemplos muestran estas técnicas.

Estudiante y Credencial 1:1

A cada estudiante se le asigna su credencial 1:1
Una credencial se le asigna a un solo estudiante 1:1

Jorge A. Rodríguez C. [email protected] 8

Material de apoyo FI UNAM

● Al ser una relación 1:1 la PK de la tabla padre, en este caso estudiante, puede
propagarse como PK y FK a la tabla credencial: Un registro de estudiante se
asocia con un solo registro de credencial.
● La tabla credencial hereda la PK de estudiante, no requiere de su propia PK.
● Al ser una relación 1:1 la FK pudiera invertirse

● Ambas soluciones son factibles aunque cada una tiene sus ventajas y desventajas.
○ Resulta un poco más natural que la FK se encuentre en credencial. Primero
se crea al estudiante y después se registra su credencial.
○ En la segunda solución, primero se tendría que registrar la credencial del
estudiante y después se registran los datos del estudiante.
● Una desventaja de ambas soluciones es que la PK de la tabla hija, no es como tal
una PK propia de la tabla, es una PK heredada. En algunos casos esto pudiera
causar confusión. Por ejemplo, resulta un tanto extraño entender que la PK de la
tabla estudiante es credencial_id o que la PK de credencial es la PK del
estudiante.
● La solución a lo anterior, es asignar una PK artificial a cada tabla y hacer uso de una
relación no identificativa

○ En estricto sentido, cambiar a una relación no identificativa convierte a la

relación en 1:m por lo que no se estaría cumpliendo con la regla de negocio.
Sin embargo, si se agrega un constraint unique a la FK, la relación se vuelve
1:1 aunque se haga uso de una relación no identificativa.
○ ¿Qué sucede si la FK se invierte?

Jorge A. Rodríguez C. [email protected] 9

Material de apoyo FI UNAM

○ La solución funciona con algunos ajustes: La FK tiene que ser nula ya que
generalmente primero se debería crear al estudiante y posteriormente a su
credencial. Por esta razón se prefiere la solución anterior.

● Otra solución es realizar una fusión de tablas. Debido a que un solo registro de la
tabla credencial se asocia con un solo registro de estudiante, las columnas de
alguna de las tablas pudieran agregarse a la otra. En este caso, las columnas de la
credencial de un estudiante pudieran agregarse a la tabla estudiante.

○ Tener cuidado, no siempre fusionar tablas es factible, en especial cuando

ambas tablas se emplean para asociarse con otras entidades.

● Por último, ¿qué sucede si se emplea una relación identificativa y cada tabla tiene
su PK artificial ?

○ Definitivamente esta solución es errónea. La PK compuesta permite asociar

un estudiante con varias credenciales, así como una misma credencial podría
asociarse a varios estudiantes.

Relaciones unarias
El siguiente ejemplo muestra la representación de una relación unaria

Cada farmacia cuenta con su centro de distribución a partir del cual se le proporcionan sus
medicamentos. Un centro de distribución almacena grandes cantidades de

Jorge A. Rodríguez C. [email protected] 10

Material de apoyo FI UNAM

medicamentos para distribuir a otras farmacias. El centro de distribución también se

considera como farmacia ya que ahí mismo se atienden a los clientes.
De lo anterior:
● Una farmacia cuenta con su farmacia de distribución (centro de distribución) 1:1
● Una farmacia de distribución surte medicamentos a varias farmacias 1:m

● En este ejemplo la tabla farmacia representa a la entidad hija, y la farmacia de

distribución que es en sí una farmacia representa a la tabla padre.
● La cardinalidad (0,1) indica que no todas las farmacias están asociadas a una
farmacia de distribución. Las reglas anteriores indican lo contrario, pero existe un
caso de excepción: Las farmacias de distribución por ser consideradas como tal no
cuentan a su vez con una farmacia de distribución. Para todas ellas, el valor de la FK
deberá ser nula.
● A nivel general, una FK que proviene de la misma tabla siempre deberá ser marcada
como null.

Relaciones ternarias
Ocurren al participar 3 entidades para representar una relación. Este escenario ocurre con
relaciones m:m. En modelo relacional no soporta de forma directa relaciones m:m. Se
requiere descomponer la relación en 2 relaciones 1:m haciendo uso de una tabla
intermedia.

Partido, Jugador m:m

● En un partido participan de 5 a 7 jugadores 1:m
● Un jugador participa en varios partidos 1:m

En una relación m:m la PK de la tabla intermedia es compuesta. Esto permite relacionar

ambas tablas. Las combinaciones de la PK compuesta generan la relación m:m, es decir,

Jorge A. Rodríguez C. [email protected] 11

Material de apoyo FI UNAM

un mismo partido puede asociarse con varios jugadores, y un mismo jugador puede
asociarse con varios partidos.
Los atributos que se asignan a la tabla intermedia tienen sentido únicamente con la
combinación de los valores de la PK. En el ejemplo, el número de anotaciones depende de
ambas cosas, del jugador que las realizó en un partido en específico.
1.1.6.3. Dependencia e independencia de existencia
Retomando estos 2 conceptos revisados en la práctica anterior, los siguientes ejemplos
ilustran ambos conceptos los cuales se aprecian mejor en el diseño lógico.

Ejemplo
● Un profesor, si lo desea, puede ser asesor de hasta 3 alumnos.
● Un alumno debe contar con su asesor y es uno solo durante su estancia en la
escuela.

● En este ejemplo, la tabla hija alumno es dependiente de existencia. Esto se puede

observar en el diagrama anterior:
○ El primer dígito del lado izquierdo debe ser 1 (Un alumno debe contar con su
asesor)
○ La cardinalidad anterior implica que la FK sea obligatoria.
○ A nivel general, una FK no nula implica que la tabla hija sea dependiente de
existencia.

Ejemplo

● En este ejemplo se tiene una independencia de existencia. Ahora, el primer dígito

del lado izquierdo es cero (un curso puede o no tener asignado a su profesor). Esto
significa que es factible registrar o crear un curso sin su profesor. El curso no
depende de la existencia de un profesor para registrar al curso.
● Notar que ahora la FK es nula, y del lado de la tabla profesor, se tiene un rombo.

1.1.6.4.Participación de una entidad en una relación

Retomando los 2 ejemplos anteriores, se puede de forma similar verificar la participación
del lado de la tabla padre

Jorge A. Rodríguez C. [email protected] 12

Material de apoyo FI UNAM

Ejemplo

● En este ejemplo la tabla padre asesor tiene una participación opcional. Lo anterior
se puede verificar ahora con el primer dígito (cero) del lado derecho. Este valor
significa que un asesor si lo desea (opcionalmente ) puede asesorar hasta 3
alumnos, es decir, las instancias de la tabla asesor no están obligadas a relacionarse
con las instancias de alumno.

Ejemplo

● En este ejemplo la tabla padre profesor tiene una participación obligatoria. El

primer dígito del lado derecho (1 ) indica que el profesor debe impartir al menos 1
curso, es decir, cada instancia de profesor está obligada o debe relacionarse con al
menos una instancia de curso.

1.1.6.5. Dependencia de identificación

Retomando el ejemplo de la práctica anterior, se tiene el siguiente modelo relacional.

Jorge A. Rodríguez C. [email protected] 13

Material de apoyo FI UNAM

● Notar que en el modelo relacional, la entidad débil tiene una PK compuesta

formada por la PK natural de la entidad débil y la llave primaria de la tabla padre. Es
posible asignar una PK artificial a la tabla boleto para evitar la PK compuesta,
aunque se puede conservar la PK compuesta para representar de forma más clara
el concepto de dependencia de identificación.
● Notar el uso de una relación identificativa para poder propagar la PK de la tabla
padre también como PK.

1.1.7. Tipos de datos SQL

La siguiente tabla muestra los principales tipos de datos que se emplean para realizar la
construcción de modelos relacionales. El estándar SQL define una lista de tipos de datos.
No todos los tipos de datos son implementados al 100% por los manejadores. Existen
algunas diferencias.

Tipo de dato Tipo de dato Comentarios

estándar SQL equivalente en Oracle

char[(n)] char[(n)] Caracteres de longitud fija. El valor n indica la

longitud máxima de la cadena. Por ejemplo,
char(5) acepta cadenas de hasta 5
caracteres. Si se almacena una cadena de
menor longitud, se rellena con ceros.

varchar(n) varchar2(n) Caracteres de longitud variable. Oracle

recomienda varchar2 que representa una
mejora sobre el tipo de dato char y varchar

numeric [(p,[s])] numeric [(p,[s])] Empleado para almacenar valores

numéricos.
● P = precisión, indica el número total
de dígitos incluyendo la parte decimal.
● S = escala, indica el número de dígitos
que forman a la parte decimal.
● De lo anterior, el número de dígitos
que forman a la parte entera se
obtiene restando el valor de la
precisión con la escala (p - s)
Ejemplo:
numeric(5,2) indica que el número máximo
que se puede almacenar es 999.99

date, time date En Oracle este tipo de dato almacena fechas

hasta nivel segundos (año, mes, día, hora,
minuto y segundos).

timestamp timestamp En Oracle este tipo de dato se emplea

cuando se requiere almacenar fechas con
una precisión más allá del segundo, por

Jorge A. Rodríguez C. [email protected] 14

Material de apoyo FI UNAM

Tipo de dato Tipo de dato Comentarios

estándar SQL equivalente en Oracle

ejemplo, fechas a nivel nanosegundo.

clob clob Empleado para almacenar grandes

cantidades de caracteres en un solo registro,
más allá de 32767.

blob blob Tipo de dato empleado para almacenar

secuencias de bytes, por ejemplo, para
almacenar fotos, audio, video, en general
cualquier archivo binario.
Nota: en ER Studio se puede especificar el
tipo de dato varbinary/blob(max).

● La sintaxis contenida dentro de corchetes es opcional. Por ejemplo, un tipo de dato

char sin su longitud significa una cadena de caracteres fija formada por un solo
carácter.

1.2. Generación de modelos relacionales con ERWin

Revisar el documento manual-instalacion-erwin.pdf ubicado en la carpeta compartida
COMUN. Realizar la instalación y configuración de la herramienta para realizar los modelos
relacionales de esta práctica.

1.3. Ejercicios previos

Estos ejercicios son obligatorios únicamente para alumnos del laboratorio. Se deberán
entregar previo a la realización de la práctica.

Total de puntos: ______ /50

1.3.1.Ejercicio 1
Considerando el caso de estudio de la embajada del documento previo de la práctica
anterior:
A. Realizar el diseño lógico a través de un modelo relacional. Emplear la herramienta
CASE configurada anteriormente. Emplear notación Crow 's foot, no olvidar indicar
cardinalidades. (25P)

1.3.2. Ejercicio 2
Considerando el caso de estudio de los videojuegos del documento previo de la práctica
anterior:

Jorge A. Rodríguez C. [email protected] 15

Material de apoyo FI UNAM

A. Realizar el diseño lógico a través de un modelo relacional. Emplear la herramienta

CASE configurada anteriormente. Emplear notación Crow 's foot, no olvidar indicar
cardinalidades. (25P)

Jorge A. Rodríguez C. [email protected] 16