Presentación IES Planes sobre normalización de base de datos

1. MODELO
RELACIONAL Y
NORMALIZACIÓN
Javier Andrés Gutiérrez
1

2. Modelo de datos
2

3. Modelo de datos
Para clasificar los modelos debemos pensar en el nivel de abstracción:
 Los modelos de datos conceptuales son aquellos que describen las
estructuras de datos y restricciones de integridad. Se utiliza durante la etapa
de análisis de un problema dado, y están orientados a representar los elementos
que intervienen en sus relaciones, un ejemplo ya visto todo es el modelo entidad
relación.
 Los modelos de datos lógicos se centran en las operaciones y se implementan
en algún sistema gestor de bases de datos. Se verá el modelo relacional.
 Los modelos de datos físicos, son estructuras de datos a bajo nivel
implementadas dentro del propio sistema gestor de bases de datos.
3

4. Modelo Relacional
Edgar Frank Codd es el padre del modelo relacional y lo
definió en un artículo publicado en 1970. Este modelo está
basado en dos teorías matemáticas: la teoría de conjuntos y la lógica
de predicados de primer orden. Pero no es necesario aprender estas
teorías para poder utilizar el modelo relacional.
4

5. Modelo de relacional
Se observan los siguientes objetivos:
 Independencia física de los datos: el modo de almacenamiento de los datos no debe
influir en su manipulación lógica.
 Independencia lógica de los datos: los cambios que se realicen en los objetos de la
base de datos no deben repercutir en los programas y usuarios que accedan a ella.
 Flexibilidad: presentar los datos a los usuarios de la forma más adecuada a la
aplicación que utilicen.
 Uniformidad: presentación de las estructuras lógicas en forma de tablas, fáciles de
comprender y manipular por los usuarios.
 Sencillez: las características anteriores, junto con los lenguajes de usuario hacen que
este modelo sea fácil de entender y utilizar por el usuario.
5

6. Modelo de relacional
Los conceptos básicos de este modelo son:
 Interrelación es la asociación entre dos tablas.
 El conjunto de columnas representa las propiedades de la tabla y se denominan
atributos.
 El conjunto de filas se denomina tuplas y contienen los valores que toman cada uno
de los atributos para cada elemento de la relación.
6

7. Modelo de relacional
Una relación es una tabla con columnas y filas. En este caso grado n y cardinalidad m.
7

8. Modelo de relacional
 Una tabla se percibe como una estructura bidimensional compuesta de filas y
columnas.
 Cada tabla o relación tiene un nombre que la diferencia de las demás.
 Cada fila de la tabla se denomina tupla y representa la ocurrencia de una entidad.
 No admiten filas duplicadas y el orden de las filas no es significativo.
 Cada columna representa un atributo, y cada columna tiene un nombre distinto.
 El orden de las columnas es irrelevante. No están ordenadas.
 La intersección fila/columna solo puede haber un valor, no se admiten atributos
multivaluados.
 Cada tabla debe tener un atributo o conjunto de atributos que identifique a cada fila de
forma única.
 Cada columna tiene un mismo tipo de datos.
8

9. Restricciones
En todos los modelos de datos existen restricciones que deben tenerse en cuenta
a la hora de diseñar una base de datos.
Restricciones inherentes al modelo: Son restricciones propias del modelo e indican las
características propias de una relación, por tanto, han de cumplirse obligatoriamente.
 Ausencia de tuplas repetidas.
 Irrelevancia del orden de las tuplas.
 Irrelevancia del orden de los atributos.
 Cada atributo solo puede tomar un único valor del dominio al que pertenece.
9

10. Restricciones
Otras restricciones inherentes son:
 La restricción de clave primaria: (PRIMARY KEY), permite declarar uno o varios
atributos como clave primaria de una relación.
 Integridad de clave: es una restricción que exige que todos los atributos de la clave
primaria han de contener valores no nulos (NOT NULL).
 Integridad referencial (FOREIGN KEY): Consiste en que no puede haber un valor en
una clave ajena de una tabla, si antes no existe en la tabla de la que ese campo o
conjunto de campos formen la clave primaria. Se permiten valores nulos en las claves
ajenas.
10

11. Restricciones
Restricciones de usuario: Son impuestas para cada problema concreto.
 Restricción de unicidad: (UNIQUE) permite definir claves alternativas.
 Restricción de obligatoriedad: (NOT NULL) permite declarar si uno o varios atributos pueden
tomar valores nulos. .
 Los disparadores (TRIGGER) son acciones a través de código de usuario.
 Restricciones de verificación: (CHECK) comprueban en una actualización si se cumplen las
condiciones exigidas en la restricción o no.
11

12. PASO DEL MODELO E/R AL RELACIONAL
 Toda entidad se transforma en una tabla.
 Todo atributo se transforma en columna dentro de la tabla.
 El identificador único de la entidad se convierte en clave primaria
 Como las relaciones del modelo E/R no tienen equivalente en el modelo relacional, ya que
sólo existen tablas y operaciones entre ellas, es necesario aplicar lo siguiente:
 En las relaciones M:N se crea una nueva tabla que tendrá como clave primaria la
concatenación de los atributos clave de las entidades que asocia y con los atributos
propios de la relación si los hay. Esta tabla posee dos claves ajenas, una por cada
entidad con la que está relacionada.
 En las relaciones 1:N la entidad del lado N de la relación añade el conjunto de campos
necesarios para incorporar a sus atributos la totalidad de la clave primaria de la entidad
del lado 1, creando una clave ajena, de modo que se puedan relacionar ambas tablas
mediante operadores relacionales. El nombre de la relación desaparece.
12

13. PASO DEL MODELO E/R AL RELACIONAL
 Las relaciones 1:1 se transforman:
 Propagando cualquiera de los atributos identificadores y sus atributos asociados creando una única
tabla con el conjunto de los atributos de ambas entidades. La clave primaria sería cualquiera de las
dos. Ambas entidades participan con cardinalidades (1,1).
 Propagando la clave de cualquier tabla a la otra, según cuál sea la que tenga accesos más
frecuentes. Ambas cardinalidades (1,1)
 Propagar la clave de la entidad con cardinalidad (1,1) a la entidad que tenga (0,1).
 Crear una nueva tabla a partir de la relación con las dos claves de ambas. Cuando ambas tablas
tienen cardinalidades (0,1).
13

14. Relaciones binarias N:M
En este tipo de relaciones siempre la relación es tabla (0,N) (1,N); (0,N) (0,N); (1,N)
(1,N).
14

15. Relaciones binarias 1:N
En este tipo de relaciones podemos incluir las del tipo (1,1) (1,N) y las del tipo (1,1)
(0,N) y sin atributos en la relación.
15

16. Relaciones binarias 1:N Excepción
Nota: Cuando la relación tiene atributos siempre es tabla independientemente de la
cardinalidad.
16

17. Relaciones binarias 1:N Excepción
En el caso que sea (0,1) en uno de sus lados, y en el otro (1,N) o (0,N) lo siguiente:
17

18. Relaciones binarias 1:1
Primera solución: Una tabla y eliges como PK uno de las dos PKs.
18

19. Relaciones binarias 1:1
Segunda solución: Dos tablas, propagas claves PKs como FKs.
19

20. Relaciones binarias 1:1 Excepción
Si ambos lados es del tipo (0,1) entonces funciona como una relación N:M, es decir, la
relación genera una tabla.
20

21. Relaciones binarias 1:1 Excepción
Si en lado es del tipo (0,1) y en el otro es (1,1) entonces funciona como una relación 1:N.
21

22. Relaciones Reflexivas
Se trata de relaciones en las que solo participa una entidad. Pero las vamos a operar como
fuesen dos, es decir, que se aplica todos lo visto anteriormente en N:M, 1:N y 1:1
Según lo visto anteriormente
ES_JEFE se convierte en tabla.
22

23. Relaciones Ternarias
23

24. Atributos compuestos
24

25. Atributos multivaluados – 1º Solución
Determinamos un número n de
correos necesarios por ejemplo 3 distintos
25

26. Atributos multivaluados – 2º Solución
Creamos una nueva tabla con los correos.
26

27. Atributos derivados
Nota: Edad no se almacena, se
obtendrá mediante código, campo
calculado.
27

28. Entidades débiles
28

29. Relaciones exclusivas
Nota: No se debe confundir con las restricciones de exclusividad, exclusión,
inclusividad e inclusión vistas en el MER. Esas restricciones se especificaran por
código.
29

30. Jerarquías – Opción 1
 Se crea una única tabla con los atributos de la superclase y de las subclases.
 Se aplica cuando:
 Las subclases se diferencian en pocos atributos.
 La superclase tiene la mismas relaciones que se asocian al resto de entidades.
 Funciona para jerarquías parciales y exclusivas.
 Consecuencias:
 Genera nulos.
 Quizá hay que introducir algún campo de control respecto a los campos de las
subclases y el control de los nulos.
30

31. Jerarquías – Opción 1
31

32.  Crear una tabla para cada tipo y subtipos que haya.
 Existen muchos atributos distintos entre los subtipos.
 Se quieren mantener los atributos comunes en una tabla.
 Se debe poner como clave primaria en las tablas de las subclases la clave primaria
de la primaria de la superclase que funciona como clave foránea además.
 Funciona bien en las jerarquías totales, y si es jerarquía solapada puede
aparecer duplicados.
Jerarquías – Opción 2
32

33. Jerarquías – Opción 2
33

34. Jerarquías – Opción 3
 Crear una tabla por cada subtipo, incluyendo los atributos comunes en cada una.
 Esto sucede:
 En jerarquías totales y exclusivas
 Existen muchos atributos en las subclases.
Observación: Muchas veces debido a los requerimientos será interesante utilizar más
una opción que otra a la hora de transformar las jerarquías al modelo relacional.
34

35. Jerarquías – Opción 3
35

36. Propuesta de ejercicio
36

37. 12 REGLAS DE CODD
DEPENDENCIAS
FUNCIONALES
37

38. Comenzando…
El inglés Edgar Frank “Ted” Codd está reconocido de forma unánime como el padre
de las bases de datos relacionales. Preocupado por la tendencia de los fabricantes de
SGBDR a obviar elementos fundamentales de su propuesta de modelo relacional, a
mediados de los años ochenta aportó una serie de definiciones conocidas como las 12
reglas de Codd que todo SGBDR debe cumplir.
A pesar de que algunas de ellas son muy complejas de seguir, la mera existencia de
las 12 reglas supuso una declaración de intenciones sobre el camino que debía tomar el
mundo de las bases de datos.
38

39. 39

40. Regla 0
40

41. Regla 1
41

42. Regla 2
42

43. Regla 3. Aparición del valor NULL
43

44. Regla 4
44

45. Regla 5. Existencia DML, DCL y DDL
45

46. Regla 6. Situación 1 actualizable
46

47. Regla 6. Situación 2 no actualizable
47

48. Regla 7
48

49. Regla 8
49

50. Regla 9
50

51. Regla 10
51

52. Regla 11
52

53. Regla 12
53

54. Hoy en día los SGBD….
54

55. Dependencias funcionales
55

56. Dependencias funcionales
56

57. Dependencias funcionales
57

58. Dependencias funcionales
58

59. Dependencias funcionales
59

60. Dependencias funcionales
60

61. Dependencias funcionales
61

62. Dependencias funcionales
62

63. Dependencias funcionales
63

64. Dependencias funcionales
64

65. Dependencias funcionales
65

66. Dependencias funcionales. Ejemplo1
66

67. Dependencias funcionales. Ejemplo2
67

68. Dependencias funcionales. Resumen
68

69. FORMAS
NORMALES
69

70. Formas Normales
70

71. FN. Anomalía de Inserción
71

72. FN. Anomalía de Actualización
72

73. FN. Anomalía de Eliminación
73

74. FN. Normalización
74

75. FN. Normalización
75

76. FN. Normalización
76

77. 1FN. Normalización
77

78. 1FN. Normalización
78

79. 1FN. Normalización. Grupo Repetitivo
79

80. 1FN. Normalización. Grupo Repetitivo
80

81. 1FN. Normalización. Grupo Repetitivo
81

82. 1FN. Normalización. Grupo Repetitivo
82

83. 1FN. Normalización.
83

84. 1FN. Normalización.
84

85. 1FN. Normalización.
85

86. 1FN. Normalización.
86

87. 1FN. Normalización.
87

88. 1FN. Normalización.
88

89. 1FN. Normalización.
89

90. 1FN. Normalización. Otro ejemplo
90

91. 1FN. Normalización. Otro ejemplo
91

92. 2FN. Normalización
92

93. 2FN. Normalización
93

94. 2FN. Normalización
94

95. 2FN. Normalización
95

96. 2FN. Normalización
96

97. 2FN. Normalización
97

98. 2FN. Normalización
98

99. 2FN. Normalización. Otro ejemplo
99

100. 2FN. Normalización. Otro ejemplo
100

101. 2FN. Normalización. Otro ejemplo
101

102. 2FN. Normalización. Otro ejemplo
102

103. 2FN. Normalización. Resultado final
103

104. 3FN. Normalización.
104

105. 3FN. Normalización. Recordamos
105

106. 3FN. Normalización.
106

107. 3FN. Normalización.
107

108. 3FN. Normalización.
108

109. 3FN. Normalización.
109

110. 3FN. Normalización.
110

111. 3FN. Normalización. Ejemplo
111

112. 3FN. Normalización. Ejemplo
112

113. 3FN. Normalización. Ejemplo
113

114. 3FN. Normalización. Ejemplo
114

115. Desnormalizar. Redundancia. Derivable
115

116. Desnormalizar. Redundancia. Derivable
116

117. Desnormalizar. Redundancia. Derivable
117