1
00:00:04,269 --> 00:00:21,629
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.

2
00:00:21,629 --> 00:00:43,189
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.

3
00:00:43,189 --> 00:00:49,649
Esto sería cuando tenemos una en existencia

4
00:00:49,649 --> 00:00:52,969
Pero ¿qué sucede cuando la tenemos en existencia y además en identificación?

5
00:00:53,490 --> 00:00:56,090
Entonces la propagación de la clave se hace de forma que

6
00:00:56,090 --> 00:00:59,250
Tenemos que la clave primaria de la entidad débil

7
00:00:59,250 --> 00:01:03,450
Estará formada por la concatenación de las dos claves

8
00:01:03,450 --> 00:01:04,510
Ahora lo veremos

9
00:01:04,510 --> 00:01:08,170
Aquí tenemos una dependencia en existencia

10
00:01:08,170 --> 00:01:11,109
Tenemos aquí una entidad débil que es ejemplar

11
00:01:11,109 --> 00:01:21,129
porque depende del libro, pero es en existencia, o sea, en el momento en el que el libro no exista, ejemplar no existirá.

12
00:01:21,129 --> 00:01:30,730
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.

13
00:01:30,870 --> 00:01:37,769
Un ejemplar va a estar comprendido en un único libro.

14
00:01:37,769 --> 00:01:44,310
Entonces, cada uno tiene su clave primaria y ¿qué tenemos cuando la dependencia es en existencia?

15
00:01:44,650 --> 00:01:47,370
Hemos visto en el que se propaga la clave.

16
00:01:48,030 --> 00:01:56,069
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.

17
00:01:56,370 --> 00:02:05,670
Pero ¿qué se va a hacer? Para que ejemplar esté identificada, se necesita propagar código libro a la tabla ejemplar.

18
00:02:05,670 --> 00:02:09,509
con la condición

19
00:02:09,509 --> 00:02:12,409
que esta nueva clave primaria formada por las dos

20
00:02:12,409 --> 00:02:15,210
la condición que el código ejemplar

21
00:02:15,210 --> 00:02:17,490
o la clave ajena

22
00:02:17,490 --> 00:02:20,069
se anula y que

23
00:02:20,069 --> 00:02:23,909
el borrado sea encascado y la actualización también

24
00:02:23,909 --> 00:02:26,629
¿eso qué quiere decir? que si se borra un libro

25
00:02:26,629 --> 00:02:29,930
automáticamente se tienen que borrar todos los ejemplares

26
00:02:29,930 --> 00:02:32,229
eso sería el onDelayedCascade

27
00:02:32,229 --> 00:02:35,090
mientras que si se modifica el código del libro

28
00:02:35,090 --> 00:02:39,090
automáticamente, pues también se tiene que actualizar en todos los ejemplares.

29
00:02:43,449 --> 00:02:45,509
Pasamos a las relaciones exclusivas.

30
00:02:46,889 --> 00:02:51,030
Las relaciones exclusivas, ahora lo que vamos a tener,

31
00:02:51,030 --> 00:02:57,310
en el que vamos a tener que se va a propagar la clave de las entidades que se excluyen

32
00:02:57,310 --> 00:03:00,990
a la otra entidad como claves ajenas.

33
00:03:02,370 --> 00:03:07,750
Bien, entonces hay que identificar primero cuáles son esas entidades que se excluyen

34
00:03:07,750 --> 00:03:14,349
para que migremos sus claves a la otra entidad.

35
00:03:15,689 --> 00:03:21,270
Para que se cumpla la exclusividad, entonces es necesario definir restricciones en cada caso.

36
00:03:21,669 --> 00:03:26,289
Por ejemplo, vamos a ver este ejemplo en el que tenemos un libro en el que tiene una relación de exclusividad,

37
00:03:26,289 --> 00:03:31,889
en el que puede ser editado o bien por una editorial o bien por una universidad, pero no por las dos a la vez.

38
00:03:32,229 --> 00:03:35,810
Tanto la entidad editorial como la universidad, cada una tiene su clave primaria,

39
00:03:35,810 --> 00:03:57,490
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.

40
00:03:57,490 --> 00:04:08,800
En el diagrama, la entidad libro puede ser editado por una editorial o por una universidad, pero no por ambas

41
00:04:08,800 --> 00:04:15,599
Y si indica que la relación se edita 1 y edita 2, tienen que ser, lógicamente, excluyentes

42
00:04:15,599 --> 00:04:25,180
Entonces, ya lo hemos visto, esta sería la nueva tabla creada, que sería la tabla libro

43
00:04:25,180 --> 00:04:38,839
que tendría su propia clave primaria y, como claves ajenas, las dos migradas desde cada una de las dos entidades excluyentes.

44
00:04:40,079 --> 00:04:46,139
¿Qué significa propagar la clave de las entidades que se excluyen?

45
00:04:46,699 --> 00:04:53,779
Bueno, ya lo he explicado, pero aquí viene en esta nueva imagen el libro que necesita.

46
00:04:53,779 --> 00:05:17,220
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.

47
00:05:17,220 --> 00:05:27,259
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.

48
00:05:31,589 --> 00:05:38,589
Bien, para asegurar que sólo una de las dos claves foráneas esté rellena, se definen restricciones de comprobación.

49
00:05:38,589 --> 00:05:56,810
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.

50
00:05:56,810 --> 00:06:17,850
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.

51
00:06:17,850 --> 00:06:39,970
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.

52
00:06:39,970 --> 00:06:46,850
En resumen de las relaciones exclusivas

53
00:06:46,850 --> 00:06:49,009
es decir que propagar la clave

54
00:06:49,009 --> 00:06:50,970
es incluir la clave primaria de otra entidad

55
00:06:50,970 --> 00:06:52,029
como clave foránea

56
00:06:52,029 --> 00:06:53,990
aquí las tenemos

57
00:06:53,990 --> 00:06:57,170
que exclusividad solo puede existir una de las dos relaciones

58
00:06:57,170 --> 00:06:59,589
editorial o universidad

59
00:06:59,589 --> 00:07:00,930
y que la solución técnica

60
00:07:00,930 --> 00:07:05,189
para que esto se pueda cumplir

61
00:07:05,189 --> 00:07:06,730
hay que añadir una restricción check

62
00:07:06,730 --> 00:07:08,310
que obligue a que una de las claves

63
00:07:08,310 --> 00:07:10,649
se anula

64
00:07:10,649 --> 00:07:27,430
Nos quedan las relaciones exclusivas, que vamos a añadir aquí, en cuanto a las relaciones exclusivas, una relación ternaria.

65
00:07:27,430 --> 00:07:38,329
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.

66
00:07:38,329 --> 00:07:59,810
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.

67
00:08:00,649 --> 00:08:28,389
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,

68
00:08:28,389 --> 00:08:31,930
sino que la clave principal, sino que actuaría como clave ajena.

69
00:08:37,720 --> 00:08:40,379
Por último, ya nos queda la transformación de jerarquías,

70
00:08:40,799 --> 00:08:46,419
en el que pueden darse, dentro de estas, tres opciones.

71
00:08:47,019 --> 00:08:53,879
Vamos a ver las tres opciones y vamos a ver qué es necesario para que se dé una opción u otra.

72
00:08:54,600 --> 00:08:57,360
La primera opción sería crear una sola tabla.

73
00:08:57,919 --> 00:09:00,019
Al final, lo que tienes es crear una sola tabla,

74
00:09:00,019 --> 00:09:06,519
en el que se van a unir allí todos los atributos, tanto de la entidad padre como la de los subtipos.

75
00:09:07,539 --> 00:09:15,340
¿Esto cuándo se aplica? Se va a aplicar cuando los subtipos se diferencian en muy pocos atributos.

76
00:09:16,580 --> 00:09:22,240
Las relaciones que asocian al resto de las entidades sean las mismas para los subtipos.

77
00:09:23,659 --> 00:09:28,000
Y tenemos que si la jerarquía es total, pues el atributo discriminante no admitirá nulos.

78
00:09:28,000 --> 00:09:41,120
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.

79
00:09:42,600 --> 00:09:48,299
Si entre los subtipos puede haber exclusividad, no va a ser necesario crear una nueva tabla.

80
00:09:48,299 --> 00:09:59,360
Aquí tenemos la segunda opción, en la que se va a crear una tabla, pero para cada tipo y subtipos que haya

81
00:09:59,360 --> 00:10:04,779
Antes no teníamos más que una sola tabla, donde añadíamos todos los atributos, tanto del supertipo como de los subtipos

82
00:10:04,779 --> 00:10:07,899
Ahora aquí lo que vamos a tener es una tabla para cada uno

83
00:10:07,899 --> 00:10:14,919
Para si tiene dos subtipos y un supertipo, tendrá una tabla para el supertipo y una tabla para cada uno de los subtipos

84
00:10:14,919 --> 00:10:26,000
¿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.

85
00:10:27,659 --> 00:10:43,440
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.

86
00:10:43,440 --> 00:10:50,700
Y cuando los accesos a los datos de los subtipos siempre afectan a los atributos comunes.

87
00:10:50,700 --> 00:10:57,039
Aquí tenemos el ejemplo en el que vamos a ver una primera transformación de jerarquías

88
00:10:57,039 --> 00:11:02,259
en donde tenemos el que, a ver si veis, solo se ha creado una única tabla

89
00:11:02,259 --> 00:11:05,840
esa sería la jerarquía, en el que un documento es un, la jerarquía acordado

90
00:11:05,840 --> 00:11:11,779
va con un triángulo invertido, en el que la relación de esta jerarquía

91
00:11:11,779 --> 00:11:16,580
es una relación, es uno a uno

92
00:11:16,580 --> 00:11:38,039
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.

93
00:11:38,039 --> 00:11:47,639
La clave primaria sería la del código de la propia entidad documento o del super tipo

94
00:11:47,639 --> 00:11:51,879
¿Qué sucede en el segundo caso?

95
00:11:51,879 --> 00:11:59,299
En el segundo caso tendríamos una única tabla para cada una de ellas

96
00:11:59,299 --> 00:12:13,299
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.

97
00:12:14,399 --> 00:12:20,539
Aquí estarán los atributos propios de documento, aquí estarán los atributos propios de libro y aquí los atributos propios de revista.

98
00:12:21,120 --> 00:12:28,299
Si libro y revista tenían atributos, pues esos atributos anteriormente en la opción A iban todos dentro de la tabla documento.

99
00:12:28,299 --> 00:12:56,080
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.

100
00:12:58,759 --> 00:13:02,500
La transformación de jerarquías, ¿qué ventajas e inconvenientes tiene?

101
00:13:03,360 --> 00:13:07,200
Pues la opción A es la más rápida por tener que acceder a una sola entidad, lógicamente.

102
00:13:07,720 --> 00:13:14,399
Mientras que la opción B es la menos eficiente, pero la mejor desde un punto de vista semántico.

103
00:13:14,399 --> 00:13:22,059
Con lo cual, la opción A es la más rápida, solo tiene una entidad.

104
00:13:22,059 --> 00:13:29,960
la opción B es la menos eficiente pero desde el punto de vista semántico es la mejor

105
00:13:29,960 --> 00:13:34,600
y la opción C es la más eficiente en consultas

106
00:13:34,600 --> 00:13:40,919
menos eficiente en consultas que afecten a todos los atributos de un subtipo

107
00:13:40,919 --> 00:13:44,379
pero menos eficiente en los que afecten a los atributos comunes

108
00:13:44,379 --> 00:13:49,960
introduce redundancias y es la que pierde más semántica