Activa JavaScript para disfrutar de los vídeos de la Mediateca.
Reglas de transformación de E/R a Relacional. Vídeo2 - Contenido educativo
Ajuste de pantallaEl ajuste de pantalla se aprecia al ver el vídeo en pantalla completa. Elige la presentación que más te guste:
Reglas de transformación de E/R a Relacional. Vídeo2
Bien, con este repaso de las reflexivas pasamos a las dependencias, en el que una dependencia, según habréis visto en el aula virtual, las dependencias pueden ser en existencia y en existencia e identificación.
00:00:04
Bien, ¿qué hacemos cuando tenemos una dependencia en existencia? Pues que se va a propagar la clave, creando una clave ajena con las características que vienen aquí. Pues que no va a permitir nulos, que la modificación encascada y que el borrado sea encascada.
00:00:21
Esto sería cuando tenemos una en existencia
00:00:43
Pero ¿qué sucede cuando la tenemos en existencia y además en identificación?
00:00:49
Entonces la propagación de la clave se hace de forma que
00:00:53
Tenemos que la clave primaria de la entidad débil
00:00:56
Estará formada por la concatenación de las dos claves
00:00:59
Ahora lo veremos
00:01:03
Aquí tenemos una dependencia en existencia
00:01:04
Tenemos aquí una entidad débil que es ejemplar
00:01:08
porque depende del libro, pero es en existencia, o sea, en el momento en el que el libro no exista, ejemplar no existirá.
00:01:11
Aquí vemos que la relación es una relación 1 a n. ¿Por qué? Porque tenemos que un libro puede tener cero o más ejemplares.
00:01:21
Un ejemplar va a estar comprendido en un único libro.
00:01:30
Entonces, cada uno tiene su clave primaria y ¿qué tenemos cuando la dependencia es en existencia?
00:01:37
Hemos visto en el que se propaga la clave.
00:01:44
Entonces, lo que hacemos es que no se crea ninguna tabla, sino que tendríamos las dos entidades, libro y ejemplar, tendríamos cada una su tabla.
00:01:48
Pero ¿qué se va a hacer? Para que ejemplar esté identificada, se necesita propagar código libro a la tabla ejemplar.
00:01:56
con la condición
00:02:05
que esta nueva clave primaria formada por las dos
00:02:09
la condición que el código ejemplar
00:02:12
o la clave ajena
00:02:15
se anula y que
00:02:17
el borrado sea encascado y la actualización también
00:02:20
¿eso qué quiere decir? que si se borra un libro
00:02:23
automáticamente se tienen que borrar todos los ejemplares
00:02:26
eso sería el onDelayedCascade
00:02:29
mientras que si se modifica el código del libro
00:02:32
automáticamente, pues también se tiene que actualizar en todos los ejemplares.
00:02:35
Pasamos a las relaciones exclusivas.
00:02:43
Las relaciones exclusivas, ahora lo que vamos a tener,
00:02:46
en el que vamos a tener que se va a propagar la clave de las entidades que se excluyen
00:02:51
a la otra entidad como claves ajenas.
00:02:57
Bien, entonces hay que identificar primero cuáles son esas entidades que se excluyen
00:03:02
para que migremos sus claves a la otra entidad.
00:03:07
Para que se cumpla la exclusividad, entonces es necesario definir restricciones en cada caso.
00:03:15
Por ejemplo, vamos a ver este ejemplo en el que tenemos un libro en el que tiene una relación de exclusividad,
00:03:21
en el que puede ser editado o bien por una editorial o bien por una universidad, pero no por las dos a la vez.
00:03:26
Tanto la entidad editorial como la universidad, cada una tiene su clave primaria,
00:03:32
Y lo que sucedería ahora es que se generarían la tabla universidad con su clave primaria, la editorial, y luego tendríamos el libro, que es en el que hemos dicho que se propaga la clave de las entidades, tanto código editorial como código universidad, se van a propagar a la tabla libro.
00:03:35
En el diagrama, la entidad libro puede ser editado por una editorial o por una universidad, pero no por ambas
00:03:57
Y si indica que la relación se edita 1 y edita 2, tienen que ser, lógicamente, excluyentes
00:04:08
Entonces, ya lo hemos visto, esta sería la nueva tabla creada, que sería la tabla libro
00:04:15
que tendría su propia clave primaria y, como claves ajenas, las dos migradas desde cada una de las dos entidades excluyentes.
00:04:25
¿Qué significa propagar la clave de las entidades que se excluyen?
00:04:40
Bueno, ya lo he explicado, pero aquí viene en esta nueva imagen el libro que necesita.
00:04:46
El libro va a necesitar saber quién lo edita, pero puede ser, ¿cómo puede ser? Tanto un editorial o una universidad. Pero muy claro, no pueden ser nunca ambas. Eso sería lo que son las relaciones exclusivas.
00:04:53
Por tanto, se añaden dos posibles claves foráneas. Se están añadiendo estas dos claves foráneas, código editorial y código de universidad, a la propia tabla libro.
00:05:17
Bien, para asegurar que sólo una de las dos claves foráneas esté rellena, se definen restricciones de comprobación.
00:05:31
Habría que hacer un check en el modelo relacional. Por ejemplo, en SQL, veis aquí, aquí lo que se ha añadido es un código SQL en el que lo que está haciendo es alterar la tabla libro, añadiendo en el que una restricción.
00:05:38
Esa restricción, este sería el nombre de la restricción y la que le aplica en la cláusula check que le está diciendo, oye, cuidado, código editorial, si no es nulo, que se cumpla que código editorial no sea nulo y, por tanto, si no es nulo, el código de universidad sí lo tiene que ser.
00:05:56
O que código editorial sea nulo y, por tanto, código de universidad no lo sea. Lo que hace la cláusula check es comprobar que se va a cumplir la exclusividad o lo que es lo mismo, el O o el OR.
00:06:17
En resumen de las relaciones exclusivas
00:06:39
es decir que propagar la clave
00:06:46
es incluir la clave primaria de otra entidad
00:06:49
como clave foránea
00:06:50
aquí las tenemos
00:06:52
que exclusividad solo puede existir una de las dos relaciones
00:06:53
editorial o universidad
00:06:57
y que la solución técnica
00:06:59
para que esto se pueda cumplir
00:07:00
hay que añadir una restricción check
00:07:05
que obligue a que una de las claves
00:07:06
se anula
00:07:08
Nos quedan las relaciones exclusivas, que vamos a añadir aquí, en cuanto a las relaciones exclusivas, una relación ternaria.
00:07:10
Esta relación ternaria va a ser una relación NM1, donde tenemos que un cliente, uno o más clientes, pueden tener cero o más cuentas.
00:07:27
En esa relación, cliente tiene cuenta, pues estará añadida en una única curso. Bien, ¿qué sucede aquí? Es importante que veamos que si alguna tiene un grado 1 dentro de esa relación ternaria, participará en la relación como clave ajena, pero no como clave principal.
00:07:38
Bien, entonces la única que tiene un grado 1 sería la sucursal. Entonces, sucursal, si veis aquí, se ha creado una nueva tabla, que la tabla tiene, donde dentro de la clave primaria, añadido tanto código cliente como código cuenta, pero a código sucursal, que sería la de grado 1, no va a participar dentro de la clave primaria,
00:08:00
sino que la clave principal, sino que actuaría como clave ajena.
00:08:28
Por último, ya nos queda la transformación de jerarquías,
00:08:37
en el que pueden darse, dentro de estas, tres opciones.
00:08:40
Vamos a ver las tres opciones y vamos a ver qué es necesario para que se dé una opción u otra.
00:08:47
La primera opción sería crear una sola tabla.
00:08:54
Al final, lo que tienes es crear una sola tabla,
00:08:57
en el que se van a unir allí todos los atributos, tanto de la entidad padre como la de los subtipos.
00:09:00
¿Esto cuándo se aplica? Se va a aplicar cuando los subtipos se diferencian en muy pocos atributos.
00:09:07
Las relaciones que asocian al resto de las entidades sean las mismas para los subtipos.
00:09:16
Y tenemos que si la jerarquía es total, pues el atributo discriminante no admitirá nulos.
00:09:23
Y si tenemos que es parcial, el atributo discriminante sí admitirá nulos. Si entre los subtipos puede haber solucionamiento o exclusividad, entonces tenemos que el solucionamiento se forma en grupos repetitivos, por tanto, será necesario crear una nueva tabla.
00:09:28
Si entre los subtipos puede haber exclusividad, no va a ser necesario crear una nueva tabla.
00:09:42
Aquí tenemos la segunda opción, en la que se va a crear una tabla, pero para cada tipo y subtipos que haya
00:09:48
Antes no teníamos más que una sola tabla, donde añadíamos todos los atributos, tanto del supertipo como de los subtipos
00:09:59
Ahora aquí lo que vamos a tener es una tabla para cada uno
00:10:04
Para si tiene dos subtipos y un supertipo, tendrá una tabla para el supertipo y una tabla para cada uno de los subtipos
00:10:07
¿Dónde se aplica esto? Cuando existen muchos atributos distintos entre los subtipos, lo contrario a lo que hemos dicho anteriormente. Y si se quieren mantener los atributos comunes en una tabla.
00:10:14
La tercera opción sería crear una tabla para cada subtipo, pero ahora tenemos que el supertipo no va a tener tabla. Esto cuando sucede, cuando hay muchos atributos distintos entre los subtipos.
00:10:27
Y cuando los accesos a los datos de los subtipos siempre afectan a los atributos comunes.
00:10:43
Aquí tenemos el ejemplo en el que vamos a ver una primera transformación de jerarquías
00:10:50
en donde tenemos el que, a ver si veis, solo se ha creado una única tabla
00:10:57
esa sería la jerarquía, en el que un documento es un, la jerarquía acordado
00:11:02
va con un triángulo invertido, en el que la relación de esta jerarquía
00:11:05
es una relación, es uno a uno
00:11:11
Y tenemos que un documento puede ser o es un libro o es una revista. Tendríamos que esta sea la jerarquía, es un libro, es una revista y lo que haría es que se resuelve a través de una única tabla, que sería con la tabla con el mismo nombre que la entidad documento, que sería la del propio supertipo con todos los atributos.
00:11:16
La clave primaria sería la del código de la propia entidad documento o del super tipo
00:11:38
¿Qué sucede en el segundo caso?
00:11:47
En el segundo caso tendríamos una única tabla para cada una de ellas
00:11:51
Como veis, documento tendrá su propia tabla, libro y revista también, y cuyas claves primarias, tanto de los dos subtipos, tendrán la misma clave primaria que la de su supertipo.
00:11:59
Aquí estarán los atributos propios de documento, aquí estarán los atributos propios de libro y aquí los atributos propios de revista.
00:12:14
Si libro y revista tenían atributos, pues esos atributos anteriormente en la opción A iban todos dentro de la tabla documento.
00:12:21
La opción C sería cuando lo que vamos a crear son dos tablas que serían únicamente las de los subtipos. Cada uno tendrá sus propios atributos, pero además hay que añadir a esta libro y revista la clave primaria del supertipo, que irá en ámbar 2, y los propios atributos que no sean clave primaria de documento también pasarían a cada una de las tablas.
00:12:28
La transformación de jerarquías, ¿qué ventajas e inconvenientes tiene?
00:12:58
Pues la opción A es la más rápida por tener que acceder a una sola entidad, lógicamente.
00:13:03
Mientras que la opción B es la menos eficiente, pero la mejor desde un punto de vista semántico.
00:13:07
Con lo cual, la opción A es la más rápida, solo tiene una entidad.
00:13:14
la opción B es la menos eficiente pero desde el punto de vista semántico es la mejor
00:13:22
y la opción C es la más eficiente en consultas
00:13:29
menos eficiente en consultas que afecten a todos los atributos de un subtipo
00:13:34
pero menos eficiente en los que afecten a los atributos comunes
00:13:40
introduce redundancias y es la que pierde más semántica
00:13:44
- Idioma/s:
- Materias:
- Informática
- Niveles educativos:
- ▼ Mostrar / ocultar niveles
- Formación Profesional
- Ciclo formativo de grado superior
- Primer Curso
- Segundo Curso
- Autor/es:
- Francisco José González Constanza
- Subido por:
- Francisco J. G.
- Licencia:
- Todos los derechos reservados
- Visualizaciones:
- 91
- Fecha:
- 25 de octubre de 2025 - 13:51
- Visibilidad:
- Público
- Centro:
- IES CIFP a Distancia Ignacio Ellacuría
- Duración:
- 13′ 54″
- Relación de aspecto:
- 1.78:1
- Resolución:
- 1920x1080 píxeles
- Tamaño:
- 47.09 MBytes