modelo relacional

1. Bases de datos
Unidad 4 – Modelo
Relacional
Sesión 1
Mónica María Rojas Rincón
mmrojas@elpoli.edu.co
Oficina: P19-142

2. Competencias
• Proponer problemas para resolverlos mediante el modelo
Relacional
• Elaborar el diseño lógico de la base de datos
• Aplicar los conceptos de normalización de la información a un
problema concreto
2

3. Ejes temáticos
• Transformación de diagramas E–R a esquemas relacionales.
• Lenguajes de consulta formales
• Álgebra Relacional.
• Cálculo Relacional.
• Normalización.
• Lenguajes de consulta comerciales.
3

4. MODELO RELACIONAL
Características Generales
Ventajas y desventajas del modelo
Elementos del modelo
4

5. Modelo Relacional
• Desarrollado por Edgar F. Cood de IBM en 1970. “A Relational
Model of Data for Large Shared Data Bank”. Communication of
the ACM. 13. num 6, pp. 377-387.
• Representa la base de datos como una colección de
relaciones.[1]
• Basado en teoría de conjuntos
• Gran avance respecto a los modelos de red y jerárquico (que
son difíciles de administrar, de ejecución compleja, con
carencia de independencia estructural, etc.)
• Evita el uso de punteros
• Operaciones sobre conjuntos de datos
5
[1] Fundamentos de Sistemas de Bases de Datos. ELMASRI. 2007

6. Ventajas
• Separación clara del nivel lógico y el físico
• Sencillo y fácil de modificar. La representación
en forma de tabla es intuitiva.
• Operadores con gran poder de manipulación de
datos
• Fundamentación teórica sólida
• Compatibilidad y estandarización
• Confiabilidad y estabilidad
6

7. Desventajas
• No incluye comportamiento de los datos a
diferencia del objetual y objeto relacional por
ejemplo
• No se puede representar conocimiento en forma de
reglas ¿Cómo cuáles?
• No se puede manejar herencia*
• Descompone los elementos de interés en varias
tablas**
• Presenta dificultades para el manejo de datos no
atómicos
* Aunque la herencia puede ser simulada de forma incómoda
** Esto implica la recomposición del elemento
7

8. Representación
• Datos en tablas bidimensionales.
• Se basa en el concepto de relación. Cada fila de la tabla
representa una relación entre un conjunto de valores. Dado
que cada tabla es un conjunto de dichas relaciones, hay una
fuerte correspondencia entre el concepto de tabla y el
concepto matemático de relación, del que toma su nombre el
modelo de datos relacional. [2]
• Informalmente en el modelo relacional:
relación  tabla
• Se apoya en el álgebra y el cálculo de relaciones
• Generó los RDBMS (SGBD Relacionales)
8
[2] Silberschatz. Fundamentos de Bases de datos

9. Elementos del modelo
cédula Salario nombre
256888 3400000 López
3456890’0 2000000 Gutiérrez
556754434 800000 Fernández
3578006 500000 Jaramillo
9
EMPLEADO
Nombre de la
RELACION
ATRIBUTOS
TUPLAS
El DOMINIO del atributo cédula y
Salario = ENTEROS
Dominio de Nombre = TEXTO

10. Elementos del modelo: Relación o
tabla
• Concepto abstracto de estructura bidimensional: filas y columnas
• Se pueden definir por comprensión y por extensión:
• Ej. por comprensión: R={x|x (identificación, nombre, salario) es
empleado de la Universidad}
• Por extensión implica que hay que listar uno por uno los elementos de la
relación
• Una relación es un conjunto de filas, entonces por definición éstas no tienen
orden
• Cada instancia o fila de una relación se le denomina tupla.
• En una relación no hay filas (tuplas) repetidas
• Las columnas de una relación reciben el nombre de atributos, tienen un
nombre único dentro de la tabla
• Cada tabla debe tener un atributo o una combinación de ellos que
identifique de manera única a cada fila.
• Para cada atributo hay un conjunto de valores permitidos, llamado dominio
de ese atributo
• Cada celda es atómica o UNIVALUADA
• El orden de las filas de las columnas no es relevante para el DBMS
• La relación es el único elemento utilizado para representar tanto entidades
como asociaciones entre ellas.
10

11. Notación para la Relación
El esquema de una relación R se denota R(A1,A2, …An)
donde R es el nombre de la relación y A1,A2, …An son los
atributos de R
Ejemplo:
EMPLEADO(cédula,nombre,dirección,salario)
11

12. Notación para la Relación
• Esquema: lista de atributos y sus correspondientes dominios; la
notación para ello sería:
Esquema_Producto= (cod_prd: string, nom_prd: string, valor:
numérico)
• La definición precisa del dominio de cada atributo, se puede realizar
en el momento de la implementación. Por tanto la notación puede
ser:
Esquema_Producto= (cod_prd, nom_prd, valor)
• El esquema de la BD en este modelo, es el conjunto de definiciones
de sus esquemas.
Ej.: Para una empresa productora de partes, supondremos el
siguiente conjunto de esquemas de relaciones:
Esquema_Parte= (nro_pte, nom_pte, color, peso, ciudad)
Esquema_Proveedor= (nro_prv, nom_prv, ciudad_prv)
Esquema_Suministro= ( nro_prv,nro_pte,cantidad_sum)
12

13. Elementos del modelo: Tupla
• Un conjunto de tuplas es una relación
• Cada instancia o fila o registro de una relación es una tupla
• Una tupla puede representar tanto instancias de entidades
como instancias de “asociaciones” (modelo conceptual)
• Número de tuplas: cardinalidad o extensión de la relación
13

14. Notación para una tupla
• t = <D1,Comercialización,10M>DEPARTAMENTO
Para un subconjunto de tuplas:
t[nombre, presupuesto] = <D1,10M>
14

15. Elementos del modelo:
Atributo
• Cada campo o columna de una relación es un atributo
• El número de atributos se denomina grado o aridad de la
relación
• El conjunto de atributos forman la cabecera de la relación
• Cada atributo está valuado o basado sobre un único dominio
 Ver siguiente
15

16. Elementos del modelo:
Dominio
• Es el conjunto de los posibles valores que puede tomar
un atributo
• No es más que un tipo de datos. Ej: Booleano, Entero,
cadena de caracteres, etc.
• Puede servir para valuar a varios atributos
• Se puede restringir para velar por la integridad de la base
de datos
16

17. Notación Dominio
17
• Dominio: el dominio del atributo A se denota dom(A)
Relación es todas las posibles combinaciones
Subconjunto de
R(A1, A2, …An)  ( dom(A1) x dom(A2) x … dom(An) )
R es el subconjunto del producto cartesiano de los dominios de
A1, A2, …, An
R(A1, A2, …An)  ( dom(A1) x dom(A2) x … dom(An) )
• Una definición formal de relación:
• Restricción del dominio: t[A] = <x> x  dom(A)
Ej: en algunos casos NULL  dom(A), lo cual significa que el atributo
A acepta valores nulos

18. Elementos del modelo: Claves
DEPTNO NOMDEPT PRESUPUESTO
D1 Comercializació
n
10M
D2 Ventas 20M
D3 Investigación 5M
18
EMPNO CÉDULA NOMBRE SALARIO DEPTNO
E1 256888 López 3400000 D1
E3 34568900 Gutiérrez 2000000 D2
E2 55675443
4
Fernández 800000 D1
E4 3578006 Jaramillo 500000 D3
Clave primaria
Clave Foranea
DEPARTAMENTO
EMPLEADO
Clave Secundaria

19. Elementos del modelo: Claves
TIPO DE CLAVE DEFINICIÓN
Superclave Un atributo (o conjunto de atributos) que identifica de
manera única a cada instancia en la tabla
Clave candidato Una superclave mínima. Una superclave que no contiene un
subconjunto de atributos que por sí mismo es una clave.
Clave primaria Una clave candidato seleccionada para identificar de manera
única a todas los demás valores de atributo en cualquier fila.
No puede contener entradas nulas.
Clave secundaria Un atributo (o conjunto de atributos) utilizado estrictamente
para propósitos de recuperación de datos.
Clave foránea Un atributo (o conjunto de atributos) en una tabla cuyos
valores deben igualar a la clave primaria en otra tabla, o ser
nulos. 19
[*] Tomado de Sistemas de Bases de Datos. Peter Rob / Carlos Coronel.

20. Elementos del modelo: Claves
• Llave candidata, es el atributo o atributos que identifican una
tupla.
• Deben cumplir unicidad y minimalidad (irreducibilidad)
• Unicidad: debe ser única
• Minimalidad (irreductibilidad) ser mínima, en el sentido de
que en su composición no intervengan más que los atributos
estrictamente requeridos para identificar las tuplas de forma
única.
20

21. Elementos del modelo: Claves
• Las llaves o claves sirven para identificar las
tuplas de una relación. Se utiliza una colección
mínima de atributos como identificador único
del modelo Relacional llamado Llave primaria.
• Elegida a partir de las claves candidatas de la
relación.
Las demás quedan como claves alternativas o
secundarias (si las hay)
• Es el equivalente al identificador único del
Modelo Entidad/Asociación (#)
21

22. Regla de integridad: Clave
primaria
• Toda relación debe poseer una clave primaria.
Atributo tomado del conjunto de atributos que
son claves candidatas.
“Ningún componente de la clave primaria
acepta nulos ni repitencias”.
22

23. Elementos del modelo: Claves
• Clave foránea, es un atributo que es llave primaria en otra
relación o tabla, mediante ella se especifica la relación entre
dos tablas.
• Atributo (puede ser compuesto) de una relación R1 que es clave
primaria en una relación R2 (R1 y R2 no necesariamente
diferentes)
• Especifica de forma explícita la forma en que dos tablas se
relacionan
• Mecanismo para asegurar la integridad
23

24. Regla de integridad referencial
“Ningún componente de una clave foránea puede contener
valores que no están presentes en la clave primaria
(alternativa) a la que referencia”
• ¿Puede una clave foránea admitir nulos?
• ¿Cómo es el dominio de una clave foránea frente al dominio
de la clave primaria a la que referencia?
Nota:
Si la clave foránea es compuesta, sus valores
deben ser completamente nulos ó no, ninguno
puede ser nulo. 24

25. Regla de integridad referencial
• ¿Qué pasa si la referencia (“Padre”) de una clave foránea
intenta ser borrada?
• Posibles cursos de acción:
• CASCADA : Especifica que si se intenta eliminar una fila con
una clave a la que hacen referencia claves externas de filas
existentes en otras tablas, todas las filas que contienen
dichas claves externas también se eliminan.
• RESTRINGIDO: No lo permite.
• NULIFICACION: Especifica que si se intenta eliminar una fila
con una clave a la que hacen referencia las claves externas
de las filas existentes de otras tablas, todos los valores que
conforman la clave externa de las filas a las que se hace
referencia se establecen en NULL.
25

26. Regla de integridad referencial
• PROGRAMADA o predeterminada : Especifica que si se
intenta eliminar una fila con una clave a la que hacen
referencia las claves externas de las filas existentes de otras
tablas, todos los valores que conforman la clave externa de
las filas a las que se hace referencia se establecen como
predeterminados. Todas las columnas de clave externa de la
tabla de destino deben tener una definición
predeterminada para que esta restricción se ejecute. Si una
columna acepta valores NULL y no se ha establecido ningún
valor predeterminado explícito, NULL se convierte en el
valor predeterminado implícito de la columna.
26

27. Regla de integridad referencial
• La misma pregunta en el caso de actualización del
padre…
• CASCADA: Especifica que si se intenta actualizar un valor de clave
de una fila a cuyo valor de clave hacen referencia claves externas
de filas existentes en otras tablas, también se actualizan todos los
valores que conforman la clave externa al nuevo valor
especificado para la clave.
• NULIFICACION: Especifica que si se intenta actualizar una fila con
una clave a la que hacen referencia las claves externas de las filas
existentes de otras tablas, todos los valores que conforman la
clave externa de las filas a las que se hace referencia se
establecen en NULL. Todas las columnas de clave externa de la
tabla de destino deben aceptar valores NULL para que esta
restricción se ejecute.
27

28. MODELO RELACIONAL
Diseño de Bases de Datos
Transformación del MER a Modelo Relacional
Reglas de transformación
28

29. Diseño de Bases de Datos
• El diseño de la base de datos se realiza durante la etapa de
diseño del sistema, al tiempo que se diseña la aplicación.
• El diseño produce especificaciones para la base de datos
relacional.
• Definiciones para las relaciones, los índices, las vistas a crear.
• Se debe documentar el sistema, con una tabla de
especificaciones para cada relación en el modelo relacional.
29

30. Convenciones
CP o PK = Clave Primaria
NN = No Nulo
CA = Clave Alternativa
CF o FK= Clave Foránea
Nota: En caso de varias claves (alternativas,
foráneas) compuestas se les coloca un subíndice
para diferenciarlas
30

31. Tabla de especificación
NOMBRE
COLUMNA
EMPNO CÉDULA NOMBRE SALARIO DEPTNO
Tipo de clave PK CA FK
Nulos/única NN/U NN/U NN NN NN
Tabla clave
foránea
DEPARTAMENTO
Columna que
referencia la
FK
DEPTNO
Tipo de dato texto entero texto entero texto
Longitud
máxima
3 10 30 10 3
Ejemplos de
datos
E1 256888 López 3400000 D1
E3 34568900 Gutiérrez 2000000 D2
31
NOMBRE DE LA TABLA: Empleado

32. MER ->Modelo Relacional
32
ESTUDIANTE
# identificación
* nombre
* apellido
* teléfono
INSCRIPCIÓN
* fecha_inscripcion
o fecha_fin
o nota
CURSO
# código
* nombre
* duración
PROFESOR
# identificación
* nombre
* apellido
o teléfono_oficina
de
Registrado con
para
Tomado por
medio de
Dictado
por
Instructor de

33. Análisis del modelo
• Entidad: ESTUDIANTE
- identificador: CP
- nombre, apellido, teléfono: No nulos
- No tiene claves foráneas
• Entidad PROFESOR
- identificación: CP
- nombre, apellido : No nulos
- teléfono_oficina : admite nulos
- No tiene claves foráneas
33

34. Análisis del modelo
• Entidad : CURSO
- código: CP
- nombre, duración: No nulos
- “aparece” un atributo (clave foránea) por
ejemplo idProfesor que establece la relación*
con PROFESOR
• Entidad INSCRIPCIÓN
- fecha_inscripción : No nulos
- fecha_fin, nota: acepta nulos
- aparecen dos CF: idEstudiante, codCurso
34
CP de la relación
INSCRIPCIÓN

35. Pasos
1. Convertir las entidades simples a relaciones (tablas)
2. Convertir los atributos a columnas
3. Convertir los identificadores únicos a claves primarias
4. Convertir las relaciones (asociaciones) en claves foráneas
5. Escoger opciones de arco
6. Escoger opciones para las relaciones supertipo/subtipos
35

36. 1 - Convertir las entidades en
relaciones (tablas)
• Las entidades simples que no son supertipo
/subtipos, que no participan de una relación
exclusiva (arco) en el MER, se transforman en
relaciones.
• Nombre de la relación igual al de la entidad en el
diagrama E/R, se ACOSTUMBRA que sea en
plural.
• Se crea una tabla de especificación para cada
entidad simple del MER.
36

37. 2 - Convertir los atributos a
columnas
• Cada atributo se vuelve una columna de la relación a la que
pertenece
• Se debe especificar que los obligatorios son No Nulos (NN).
37
NOMBRE COLUMNA IDENTIFICACIÓN NOMBRE APELLIDO TEL_OFICINA
Tipo de clave
Nulos/única NN NN NN
Tabla clave foránea
Columna que
referencia la FK
Tipo de dato
Longitud máxima
Ejemplos de datos
PROFESORES

38. Recomendaciones
• Para cada atributo se sugiere usar nombres cortos de fácil
recordación.
• Usar abreviaturas consistentes, por ejemplo:
Número_departamento como:
ˉ numDepto
ˉ nroDepto
• Para esclarecer los tipos de dato, es útil documentar las tablas
de especificación con tuplas ejemplo, que se obtienen de:
ˉ Entrevistas y conversaciones a los usuarios
ˉ Documentación de los sistemas actuales
38

39. 3-Convertir Id únicos en claves
• Cada atributo único que forma parte de los identificadores de
la entidad se convierte en columnas con tipo de clave primaria
(CP/PK).
• Identificador único con varios atributos => clave primaria compuesta.
39
NOMBRE COLUMNA IDENTIFICACIÓN NOMBRE APELLIDO TEL_OFICINA
Tipo de clave CP
Nulos/única NN/U NN NN
Tabla clave foránea
Columna que referencia la
FK
Tipo de dato
Longitud máxima
Ejemplos de datos 71729315 Felipe Gutierrez 234 3456
45689900 Mónica Marín
PROFESORES

40. 4-Convertir las relaciones
(asociaciones) en claves
foráneas
• Asignar un nombre de columna para la Clave Foránea y
rotularlo “CF”.
• Relaciones 1 a muchos: se toma el Identificador único de la
entidad con cardinalidad uno y se pone en la entidad con
cardinalidad muchos. Es decir, la CF se coloca en la entidad a la
que “le llega” cardinalidad muchos.
• Si la relación es obligatoria (en el lado de la entidad que posee
la CF), la CF debe ser NN.
40

41. Transformación
41
CURSO
# código
* nombre
* duración
PROFESOR
* identificación
* nombre
* apellido
o
teléfono_oficin
a
Dictado
por
Instructor de
NOMBRE
COLUMNA
CÓDIGO NOMBRE DURACIÓN IDPROF
Tipo de clave CP CF
Nulos/única NN/U NN NN
Tabla clave
foránea
PROFESOR
Columna que
referencia la FK
identificació
n
Tipo de dato
Longitud
máxima
Ejemplos de
datos
32 Oracle 3 71729315
35 SqlServe
r
2 45689900
CURSOS

42. 4-Convertir las relaciones
(asociaciones) en claves
foráneas • Relaciones 1 a 1:
• Si la relación tiene un lado obligatorio, se debe
colocar la CF en el lado de la obligatoriedad y
debe ser NN.
EMPLEADO
DEPARTAMENTO
Si ambos lados de la relación son obligatorios, la
CF se debe colocar en cualquiera de los dos lados. 42
EMPLEADO
# código
* nombre
O tel_oficina
DEPARTAMENTO
* codigo
* nombre
* presupuesto
Responsable de
A cargo de
codigo nombre tel_oficina
PK NN
codigo nombre presupuesto Cod_empleado
PK NN NN FK,NN

43. 4-Convertir las relaciones
(asociaciones) en claves
foráneas • Relaciones 1:1
Si la relación es opcional en ambos sentidos, la
CF se puede colocar en cualquiera de los dos
lados. Se recomienda colocar la CF en la de
mucho menor cardinalidad.
En algunos casos suele ser conveniente
transformar la relación 1:1 en una tabla.
Razón: minimizar valores nulos
HOMBRE (identificacion, nombre)
MUJER (identificacion, nombre)
MATRIMONIO (id_hombre, id_mujer)
Clave alternativa
UNIQUE, NOT NULL
43
HOMBRE
# identificación
* Nombre
…
MUJER
* identificación
* Nombre
…
Casado con
Casada con

44. 4-Convertir las relaciones
(asociaciones) en claves foráneas
• Si el identificador único está formado por relaciones con otras
entidades, se deben generar las claves foráneas respectivas y éstas
harán parte de la clave primaria
44
NOMBRE
COLUMNA
FECHA_INSCRIPCION FECHA_FIN NOTA IDESTUDIANTE CODCURSO
Tipo de clave CP/CF1 CP/CF2
Nulos/única NN NN/U1 NN/U1
Tabla clave foránea ESTUDIANTE CURSOS
Columna que
referencia la FK
identificador Codigo
Ejemplos de datos 25/05/2010 25/06/201
0
4.0 23546 32
25/05/2010 34567 35
INSCRIPCION

45. 4-Convertir las relaciones
(asociaciones) en claves foráneas
• Para relaciones recursivas 1:N, se debe adicionar
una columna CF a la relación. ¿Cómo se hace en
relaciones recursivas 1:1?
45
EMPLEADO
# cédula
* nombre
* apellido
Ser jefe de
Supervisado
por
NOMBRE
COLUMNA
CEDULA NOMBRE APELLIDO IDJEFE
Tipo de clave CP CF
Nulos/única NN/U NN NN
Tabla clave foránea EMPLEADO
Columna que
referencia la FK
Cédula
Ejmplos 3421 fernando perez 3241
3241 isabel martinez
EMPLEADOS

46. 4-Convertir las relaciones
(asociaciones) en claves
foráneas
• Para relaciones recursivas 1:1, se debe adicionar una
columna CF a la relación.
46
PERSONA
# cédula
* nombre
* apellido
* genero
Esposo(a) de
Casado con
NOMBRE
COLUMNA
CEDULA NOMBRE APELLIDO GENERO IDCONYUGE
Tipo de clave CP CF
Nulos/única NN NN NN
Tabla clave
foránea
PERSONA
Columna que
referencia la FK
Cédula
PERSONA

47. 5-Escoger opciones de arco
 Se pueden llevar al modelo relacional de dos formas:
 Diseño de Arco Explícito
 Diseño de Arco Genérico.
47
generadora
de
FACTURA
#código
*fecha
EMPRESA
#nit
*conmutador
para
generadora
de
PERSONA
#cédula
*añoNacimiento
para

48. Diseño de Arco Explícito
• Una CF por cada asociación incluida en el arco
• Se debe utilizar cuando las claves foráneas tienen diferentes
dominios (formatos).
• Para manejar la exclusividad se debe recurrir a una cláusula de
chequeo (check) la cual garantiza que si una CF es No nula las demás
CF’s del arco deberán contener nulos
48
NOMBRE COLUMNA CÓDIGO FECHA NITEMPRESA CEDPERSONA
Tipo de clave CP CF1 CF2
Nulos/única NN/U NN
Tabla clave foránea EMPRESA PERSONA
Columna que referencia la
FK
nit empresa
Ejemplos de datos 1234 25/06/201
0
23546 NULL
1235 26/06/201
0
NULL 67
FACTURA

49. Diseño de Arco Genérico
Una sola columna que funcionará como CF para todas las relaciones en
el arco.
• Una columna adicional para saber cual de las tablas se
referencia en la clave foránea.
• Si el arco es obligatorio, se debe exigir que la CF sea NO nula.
• El dominio debe ser igual en todas las CFs del arco
• La columna que funciona como CF para todas las relaciones no
queda explícitamente ligada a ninguna de las entidades a las
que referencia.
• La relación de exclusividad queda asegurada, no se debe hacer
nada adicional.
49

50. Diseño de Arco Genérico
• Se debe definir el dominio de TipoGenerador, por
ejemplo:
• P: Persona
• E: Empresa
50
NOMBRE COLUMNA CÓDIGO FECHA IDGENERADOR TIPOGENERADOR
Tipo de clave CP CF
Nulos/única NN/U NN NN NN
Tabla clave foránea
Columna que referencia la
FK
Ejemplos de datos 1234 25/06/201
0
23546 E
1235 26/06/201
0
67 P
FACTURA No es explícita la
relación con
EMPRESA/PERSONA
En este diseño el campo cédula y nit en las
tablas PERSONA y EMPRESA deben tener el
mismo formato

51. 6-Escoger opciones para las
relaciones supertipo/subtipos
• Opciones
• Subtipos en una sola tabla
• Subtipos en tablas separadas
51

52. Opc. 1: Subtipos en una sola
tabla
PASOS:
• Crear una tabla para el supertipo.
• Crear una columna TIPO para identificar el subtipo.
• Crear una columna para cada atributo del supertipo.
• Crear una columna para cada atributo de los subtipos.
• Crear columnas CF para cada relación del supertipo.
• Crear columnas CF para cada relación de los subtipos.
52

53. Opc. 1: Subtipos en una sola
tabla
Características del diseño de los subtipos en una sola tabla :
• Recomendable cuando los subtipos tienen pocos atributos y
pocas asociaciones propias
• Consultas frecuentes que involucran datos de diferentes subtipos
• La tabla resultante contiene las informaciones de todos los
subtipos
• El acceso al supertipo es directo
• Acceso a los subtipos mediante vistas
53

54. Opc. 1: Subtipos en una sola
tabla
• Todos las columnas pertenecientes a los subtipos deben ser
opcionales (admitir nulos) ¿Por qué?
¿Esto qué implicaciones tiene?
• Implica una cláusula check que garantice que si una fila
pertenece a un subtipo dado los atributos pertenecientes a los
demás subtipos deberán ser nulos
54

55. Opc. 1: Subtipos en una sola
tabla
• La columna TIPO, identifica los subtipos (T - TEMPORAL, P –
DEPLANTA)
55
NOMBRE
COLUMNA
CODEMP NOMBRE APELLIDOS TIPO SALARIO VRHORA VREXTRA NITEMP CODDEPTO
Tipo de clave CP CF1 CF2
Nulos/única NN/U NN NN NN NN NN
Tabla clave
foránea
EMPRESA DEPTO
Columna que
referencia la
FK
nit Cod_depto
Ejemplos de
datos
67 Mónica Rojas T 2000 4000 123 D1
89 Camila Sánchez P 400000 D2
EMPLEADO

56. Opc. 1: Subtipos en una sola
tabla
• Desventajas de este diseño:
• Los requisitos de atributos obligatorios en el
modelo E/A de cada subtipo no se pueden hacer
cumplir
• Implica el manejo de vistas para extraer los
subtipos
56

57. Opc. 2: Subtipos en tablas
separadas
PASOS:
• Crear una tabla para el supertipo
• Crear una columna por cada atributo del supertipo
• Crear columnas CF para cada relación* del supertipo.
• Crear una tabla para cada subtipo
• Crear columnas para cada atributo del subtipo
• Crear columnas CF para cada relación* del
subtipo
• Crear una CF única hacia el supertipo en todos
los subtipos
*Relación en el sentido del modelo E/A
57

58. NOMBRE
COLUMNA
CODEMPTEMP VRHORA VREXTRA NITEMP
Tipo de
clave
CP, CF1 CF2
Nulos/única NN/U NN NN NN
Tabla clave
foránea
EMPRESA
Columna
que
referencia
la FK
nit
Ejemplos
de datos
67 2000 4000 123
345 1500 3500 456
58
NOMBRE
COLUMNA
CODEMP NOMBRE APELLIDOS CODDEPTO
Tipo de clave CP CF
Nulos/única NN/U NN NN NN
Tabla clave
foránea
DEPTO
Columna que
referencia la
FK
Cod_depto
Ejemplos de
datos
67 Mónica Rojas D1
89 Camila Sánchez D2
34 Andrés Gutiérrez D1
EMPLEADO
NOMBRE
COLUMNA
CODEMPPLANTA SALARIO
Tipo de clave CP, CF
Nulos/única NN/U
Tabla clave
foránea
EMPLEADO
Columna que
referencia la FK
CODEMP
Ejemplos de
datos
34 3400000
89 400000
DEPLANTA
TEMPORAL

59. Opc. 2: Subtipos en tablas
separadas
• Cada tabla del subtipo contiene instancias sólo del subtipo
• La opcionalidad de los atributos del subtipo en el modelo E-R
se hace cumplir desde la definición de la BD
• Acceso al supertipo que implique atributos de los subtipos
implica una reunión (join)
• Subtipos excluyentes: Implica garantizar por programación que
la CP del supertipo sólo aparezca en uno de sus subtipos
• También es posible eliminar la tabla supertipo y agregar todas
sus columnas a cada subtipo, pero igualmente exige control
por programación, y además se pierde un poco el concepto
original de supertipo...
59

60. Refencias
Basado en:
• Claudia Jimenez. Bases de datos. Universidad Nacional (Medellín)
http://www.unalmed.edu.co/~csjimene/pub2/bd.pdf
• Margarita Hincapie. Notas de clase Bases de Datos. Politécnico
Colombiano Jaime Isaza Cadavid.
60